[Testing] virtual targets about m1n1 HOT 2 CLOSED

I already replied elsewhere, but for the record: this is difficult, because m1n1 is deeply tied to Apple-specific CPU and hardware features by design (its job is to deal with all that). Even if you stripped out all the CPU stuff, there's still Apple's bespoke NVMe controller to deal with, and qemu doesn't emulate any of that.

That said, debugging is already easy: just run m1n1 inside the m1n1 hypervisor. You even get a virtual UART and a gdb stub to play around with :)

For the Rust secureboot stuff specifically, I think it would make more sense to have testing mocks/a stub to run that part of the code in userspace. That code doesn't really have any hardware dependencies, and it would be much easier to make it run standalone than the entirety of m1n1. The filesystem block backend can be replaced with something that just reads/writes a disk image file with ease.

from m1n1.

Thank you for elaboration. I'm closing this now, secure boot discussion should be moved over to #195 . We should consider a first generation of secure boot without SEP support, even though it's vulnerable in case somebody examines the NAND storage for leftover key encrypted with an old passphrase.

from m1n1.