Secure boot support? about m1n1 HOT 4 OPEN

<marcan> that's a fair point, but a bit tricky... and at that point, it might actually make sense to make m1n1-stage1 able to boot multiple stage2s. That also, conveniently, solves the device tree incompatibility problem, by allowing separate DTs for each kernel.
<DmitrySharshakov[m]> We can use AES + password-derived key I guess. recoveryOS part of the installer generates the keypair, burns pubkey into m1n1-1, and encrypts private one to be stored in the ESP
<marcan> that's a bad idea, it lowers the security guarantees of the platform
<marcan> it's not possible to guarantee secure erasure of such a key file (this is why apple have effaceable storage), and therefore you potentially forever tie the security of secureboot to the user password, even if they change it
<marcan> but if we can do SEP-backed FDE that's much better and solves this problem
<marcan> ideally we figure out some SEP voodoo to allow wrapping the key file with that in macOS in a way that is then accessible again from Linux, but I'm not entirely sure that's possible, though it ought to be, since FileVault works like that?
<DmitrySharshakov[m]> At least that 'first approach' I suggested gives the same degree of security as custom sb keys on PC platforms. Btw you could also store the key on external media or do a secure erasure of the key material when changing the password
<marcan> "secure erasure" isn't a thing on SSDs
<marcan> "secure erasure" isn't a thing on SSDs
<DmitrySharshakov[m]> Well yes. But the risk is still low enough for casual users and attacker will have to desolder NAND to take a look at lost fragments of a broken cryptocontainer (which first has to have a compromised password or cryptography)
<DmitrySharshakov[m]> And for high-value cases a config option can be set to store the key on external media which can be wiped better