BMC firmware validation / Secure boot

[bluecmd]

Given that we're targeting specific platforms this is going to be optional and not useful for everyone.

However, it should be possible to create something that's reasonably secure by default.

The idea so far is to:

• Ensure the BMC SPI flash has a protectable region that is volatile. Volatile is to prevent bricking, but the locking also needs to be persistent until power reset without any other option to unlock. For the Leopards I have access to that means replacing the SPI flashes with something like MT25QL256ABA (or even MT25QL512ABB for a nice upgrade).

• Make u-boot verify Linux kernel, make the Linux kernel verify /init U-boot can already do this using signatures, and Linux can be made to do it using a initramfs. This would still allow for persistence for files around the /init - but not modifications of /init (bbin/bb) itself.

There are some interesting open issues that needs to be solved.

1. Need to disable LPC super-duper access (iLPC2AHB) during this time and ASAP on power-up to reduce the timing window for attacks on that. Given that this is on power-on we should be good as the host system does not boot automatically.
2. U-boot upgrades. How will they work?

[bluecmd]

Yet another alternative: IS25LP512M-RMLE

The locking functionality is not the same in these chips, which does not come as a surprise. That means that to support this we need a configuration option, or dynamically detect (which is fragile), how to ensure that the chips are locked and how to program the lock tables.

For my own notes, found both for delivery to Sweden: https://www.mouser.se/ProductDetail/870-IS25LP512M-RMLE https://www.mouser.se/ProductDetail/340-278183-REEL

[hugelgupf]

Re the second thing... I think u-boot should just verify the kernel and the full initramfs. Why allow random files around init to be modified, and why rely on having to make a Linux kernel patch to verify init?

[bluecmd]

I agree what you're saying, but I'm not sure how to do it in practice. Where should we store the SSH server key and the gRPC TLS certificate+keys? Those will be generated by the BMC and we cannot let the BMC be able to sign it's own stuff while also be resistent to tampering, I think?

[bluecmd]

Oh, re-reading your reply I think you misunderstood my proposal. I could have been clearer, I admit.

why rely on having to make a Linux kernel patch to verify init?

I'm talking about a "1st stage initramfs" that is static, that will indeed be validated by u-boot. Not patching the kernel. That 1 stage initramfs will then do a gpg check or whatever on /init and then exec it if it passes.

[bluecmd]

Chips arrived, MT25QL512ABB8ESF-0SIT seems to have worked out of the box, IS25LP512M-RMLE did not.

For now I think it's OK if the locking of the boot flash is done in the loader application, that should be simple.

After that, what needs to be done is to make sure that the PCH cannot boot before the flash has been locked. Alternatively we can detect that the PCH is turned on when we have booted userspace from cold-boot and force it to shut down by long-pressing the power button. Then we can proceed with the firmware validation. It seems more complicated than it may be worth though, just holding the reset line seems simpler.

[bluecmd]

Current state is that the RDID command works in qemu but not on real chip, it just returns ffffffff so the lock will of course not engage:

/sys/kernel/bootlock# cat lock
2018/10/15 19:45:40 cat: read lock: wrong medium type
Exception: cat exited with 1
[tty], line 1: cat lock
/sys/kernel/bootlock# dmesg | grep chip                                root@ubmc
/sys/kernel/bootlock# dmesg | grep chip
<6>[   28.249350] chip is ffffffff
<6>[   35.516485] chip is ffffffff
<6>[   43.674714] chip is ffffffff
/sys/kernel/bootlock#