13:35 <leezu> Is it possible to sign custom kernels and enforce signed only boot / disable dev boot? Is it possible to disable the developer mode screen and directly boot the kernel?

15:39 <amstan> leezu: before i get into the longer spiel, you do know about the short delay gbb flag, right?

15:55 <leezu> amstan: Yes, I'm using the 0x19 flag

15:56 <leezu> I guess the first question is if there's an established procedure to add a custom signing key

15:57 <leezu> But before getting to that: I was just flashing the 0x19 flag on the DE version of lazor but it failed and "Your flash chip is in an unknown state." https://pastebin.com/MmkVDBGy

15:57 <leezu> Have you seen that before?

15:58 <amstan> did you remove write protect?

16:00 <leezu> I thought I did, but apparently not. Now it works

16:01 <amstan> ok, so once you have that going.... signing

16:01 <amstan> there's this tool called futility that can help you sign things

16:02 <amstan> so you could resign your firmware with your own keys

16:02 <amstan> then you have to do the same with your kernel around this step: https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/linux-aarch64/PKGBUILD#L219

16:02 <amstan> at that point switching to normal mode should work

16:04 <amstan> then you need some kind of extra code, idk really where, to handle the normal to dev transition, otherwise all of this is kind of pointless if you can just switch to dev mode whenever you want with your data right there is still kind of insecure

16:05 <leezu> In this setup, there would be no signature validation besides checking that there is a signature?

16:06 <amstan> in dev mode there is no signature validation (this is why that link has a blank one), in normal mode there is

16:07 <leezu> My confusion is how do I register my public signing key so that the signed blob would be accepted by normal mode

16:13 <amstan> "futility"

16:18 <amstan> leezu: https://bpa.st/GQ3A

16:21 <amstan> i was going to send you to https://source.chromium.org/search?q=vbutil&ss=chromium for inspiration

16:21 <amstan> but then heheh, look what i found: https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/custom-firmware/

16:22 <leezu> Thank you, so futility enables users to rebuild the firmware including their own key. Once flashed, enabling dev_boot_signed_only (Enable developer mode boot only from official kernels) for example would keep dev mode on but only allow booting with kernels signed by my key

16:25 <amstan> why do you want to keep dev mode on?

16:26 <amstan> i'm pretty sure dev_boot_signed_only is for testing, not for what you want it to use

16:27 <amstan> you can just use normal mode at that point

16:34 <leezu> Wouldn't it address the "otherwise all of this is kind of pointless if you can just switch to dev mode whenever you want with your data right there is still kind of insecure"?

16:40 <leezu> The emmc is fully encrypted besides the kernel partition. So as long as that one is signed and can't be modified without my key, what threat do you see from switching between normal and dev mode?

16:46 <amstan> well, for one your dev mode would look identical to normal dev mode while it boots, so how will you know nobody hacked you?

16:58 <leezu> I'm unclear about the type of hack feasible without having my private signing key?

17:00 <amstan> i guess maybe

17:00 <amstan> but i still don't think dev_boot_signed_only is meant for normal usage, so it's not necessarly secure

17:00 <amstan> i think it's more for quick testing of keys in dev mode

17:19 <leezu> Do you have any suggestion how we can gain clarity on the security of dev_boot_signed_only?

17:20 <amstan> https://code.google.com/archive/p/chromium-os/issues/36011 mentions that "doesn't enforce the entire chain of trust"

17:20 <amstan> why don't you just use normal mode?

17:23 <leezu> I think the threat model here is that even if I use the normal mode, anyone can switch to dev mode by simply pressing "esc + refresh" and pressing the power button?