sets: factor shared badaml machinery into _badaml.nix

[sespiros]

An idea for addressing the TODO in badaml-sandbox.nix: the BadAML test machinery (qemu-wrapped, kata kernel-uvm + image, node-installer-image payload) lives in _badaml.nix, taking withAMLSandbox so vuln and sandbox share one source of truth.

setsFromDirectory skips underscore-prefixed files so the helper sits with its consumers without being loaded as a set.

For more ideas, this is an example combined set I was using to test the badaml-vuln failures with a debug firmware on top of the badaml-vuln set changes:

# overlays/sets/_debug.nix
_contrastPkgsFinal: contrastPkgsPrev: {
  OVMF-SNP = contrastPkgsPrev.OVMF-SNP.override { debug = true; };
  OVMF-TDX = contrastPkgsPrev.OVMF-TDX.override { debug = true; };
  contrast = contrastPkgsPrev.contrast.overrideScope (
    _contrastFinal: contrastPrev: {
      node-installer-image = contrastPrev.node-installer-image.override {
        withDebug = true;
      };
    }
  );
}

# overlays/sets/badaml-vuln-debug.nix
let
  debugScope = import ./_debug.nix;
  badamlScope = import ./_badaml.nix;   # added in this PR
in
_final: prev: {
  contrastPkgs =
    (prev.contrastPkgs.overrideScope debugScope).overrideScope (badamlScope {
      withAMLSandbox = false;
    });
}

# then ovelrays/sets/debug.nix becomes
let
  debugScope = import ./_debug.nix;
in
_final: prev: {
  contrastPkgs = prev.contrastPkgs.overrideScope debugScope;
}

[charludo]

For this specific usecase, the strategy makes sense. However, I think it doesn't quite capture the other usecases we want to cover eventually - e.g. combine runtime-rs and debug. We could of course add a new set runtime-rs-debug which just imports the debug changes. But that gets tedious fast.

The idea I've been toying with would be to add a sepcial syntax for specifying multiple sets. For example, use + as a delimiter, so that you can run nix run .#any+combo+of+sets.package. The setsFromDirectory function would then simply(*) split by +, and for each part, add the set to the list.

In your concrete usecase, IMO badaml-vuln should contain everything in badaml now, and badaml-sandbox should simply overwrite the withAMLSandbox value to true. Sure then either badaml-sanbox imports badaml-vuln, or you specify .#badaml-vuln+badaml-sandbox.package.

But this way there'd not be two mechanisms for factoring out duplication, and IMO the "combine sets" approach is more flexible.

(*) caveat: to allow all combinations of sets that's 2^n for n sets, which is fine, nix builds them lazily anyways; for all permutations, n^n grows a little bit fast-ish. We could also just limit this to a depth of 3 or whatever.

[sespiros]

For this specific usecase, the strategy makes sense. However, I think it doesn't quite capture the other usecases we want to cover eventually - e.g. combine runtime-rs and debug. We could of course add a new set runtime-rs-debug which just imports the debug changes. But that gets tedious fast.

This might be the only solution though. For instance another use case I have now with the oak set, I want to combine with debug, but in that case it doesn't make sense to do debug builds of OVMF for oak (and oak doesn't have debug builds). It just so happens for that particular one, that this derivation change simply doesn't affect it (it doesn't matter which derivation gets build for OVMF, the set will be using oak anyway). It's hard to capture all these/build truly generic sets that can be combined.

The idea I've been toying with would be to add a sepcial syntax for specifying multiple sets. For example, use + as a delimiter, so that you can run nix run .#any+combo+of+sets.package. The setsFromDirectory function would then simply(*) split by +, and for each part, add the set to the list.

On first thought, this seems complex to me for the same reason I already stated but I am curious to see it in action so keep me posted if these explorations lead somewhere.

In your concrete usecase, IMO badaml-vuln should contain everything in badaml now, and badaml-sandbox should simply overwrite the withAMLSandbox value to true. Sure then either badaml-sanbox imports badaml-vuln, or you specify .#badaml-vuln+badaml-sandbox.package.

But this way there'd not be two mechanisms for factoring out duplication, and IMO the "combine sets" approach is more flexible.

(*) caveat: to allow all combinations of sets that's 2^n for n sets, which is fine, nix builds them lazily anyways; for all permutations, n^n grows a little bit fast-ish. We could also just limit this to a depth of 3 or whatever.

Or even better, the vuln one would simply be named badaml and the sandbox one maybe badaml-sandbox and the invocation would look like badaml+badaml-sandbox. Ok interesting.

I think in any case, maybe we should write down some concrete use cases we currently have or few potential ones to avoid overengineering this. Some I have in mind:

• the badaml is a specific one (this PR)
• the runtime-rs is also a specific one
• the oak set is(will) also very specific
• the debug is a more generic one, we could have split debug-fw, debug-kata, debug-kernel, debug-foo and then a global debug which enables all of them or something?