| 3 Oct 2024 |
 raitobezarius | probably if you infiltrate the UEFI forum | 21:03:37 |
| raitobezarius | you can find the informations | 21:03:39 |
 ElvishJerricco | heh bummer | 21:03:50 |
| raitobezarius | classical :) | 21:03:57 |
 emily | any chance of per-OS keys/security levels like Apple Silicon has? | 21:13:21 |
| ElvishJerricco | TPM | 21:13:55 |
| ElvishJerricco | just bind keys and stuff to measurements for your OS | 21:14:15 |
| emily | that's not quite the same, but sure | 21:14:32 |
| ElvishJerricco | what's different? | 21:14:40 |
| emily | you can't have, say, one OS partition where you can boot unsigned arbitrary kernels for development but another where you have strict requirements. admittedly segregating secrets is most of why it makes sense to do this on Apple Silicon, but you can segregate secrets and still want to enforce certain OS signing keys per-OS | 21:18:02 |
| emily | (or else why do Secure Boot at all? just rely on the measurements) | 21:18:08 |
 K900 | You can do that with secure boot? | 21:18:38 |
| ElvishJerricco | isn't that essentially just having one signed OS that doesn't check signatures of following boot components and one that does? | 21:19:00 |
| ElvishJerricco | IIRC macs do this by enrolling what is essentially a MOK for your custom OS | 21:19:55 |
| ElvishJerricco | (look at that, Apple has MOK built in, unlike UEFI :P) | 21:20:38 |
| emily | In reply to @elvishjerricco:matrix.org
isn't that essentially just having one signed OS that doesn't check signatures of following boot components and one that does? I guess this is true in the same sense that Secure Boot is the same as a facility to store one trusted hash of a bootloader that handles chain-loading and enforcing any other security policy | 21:21:54 |
| emily | i.e., in terms of raw capabilities, sure I guess, but in terms of the UX and what's reasonable to set up not really | 21:22:09 |
| emily | admittedly the less integration with your secure element you have the less sense a lot of the Apple Silicon boot design makes | 21:22:36 |
| ElvishJerricco | I dunno, apple's mechanism for letting you boot your own OS really does just seem like first party MOK to me | 21:23:26 |
| raitobezarius | In reply to @emilazy:matrix.org
any chance of per-OS keys/security levels like Apple Silicon has? i know there's a lot of activity on the concept of multiboot | 21:23:54 |
| ElvishJerricco | like even in terms of UX, I can just boot into the MOK manager thingy and say "please allow my other OS now please", which is basically what you do with apple | 21:23:58 |
| raitobezarius | there's a big problem that has been realized regarding dual boot operations | 21:24:10 |
| raitobezarius | https://github.com/uapi-group/specifications/pull/117 | 21:24:34 |
| raitobezarius | so maybe maybe there could be per-OS specific stuff | 21:24:42 |
| raitobezarius | but unclear to me yet | 21:24:44 |
| ElvishJerricco | well, DPS isn't necessary for secure boot, strictly speaking | 21:26:13 |
| ElvishJerricco | I was about to complain I wish I could read that diff in actual markdown, and then I discovered github has a "rich diff" view. Neat | 21:27:07 |
| ElvishJerricco | ... and it's not useful for tables :P | 21:27:26 |
 Arian | Btw i dont think After=multi-user.target is a hack | 21:39:17 |
| Arian | It's even documented in https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/ | 21:39:42 |
