On 17.02.19 11:12, Frank Beuth wrote: > On Sun, Feb 17, 2019 at 10:02:42AM +0100, Nico Huber wrote: >> What, why? Did you just say "SeaBIOS" because I said "sometimes ... >> payload"? >> >> SeaBIOS is a very generic payload, trying not to be board specific. And >> I just said it depends on the hardware. Also, all generic, one-fits-all- >> scenarios solutions for flash locking that I've heard about failed (ex- >> ploits, exploits, exploits). > > SeaBIOS being the most commonly used one, and you seemed to imply > locking should/must be done by the payload.
Well, I didn't mean to imply that. That's why I highlighted "sometimes" above. "sometimes" / "always" there is a difference, you see? What I tried to express is that how and where a lock has to be implemented depends on your complete firmware and not just coreboot. So locking *may* involve the payload. Whether or not depends on your threat model, what you want to protect from and what you still want to allow (e.g. firmware updates). You don't seem to have a threat model. It seems you just want to feel safe. That's fair enough. But doesn't provide any value in reasoning about locks. > > It sounds like you are saying the locking which one is used to with > proprietary/manufacturers' firmwares, the locking which often requires a > hardware programmer, is possible because those firmwares are board > specific. And therefore not really possible for an open source firmware > like Coreboot+$PAYLOAD. I'm not sure if I quite follow. You mean the locking that prevents you from installing a retrofitted coreboot? That's not a lock that prevents malware from anything (because of existing exploits). There are ways to install coreboot on such systems without external programmer. It's just sometimes a very uncomfortable, hacky way and if it fails you'll need an external programmer anyway. But nothing is too uncomfortable for crimi- nals. They just have to figure it out once and then profit per every- body's unit (not just there own unit). > >> Before you ask somebody to implement a lock, you should ask yourself >> why. > > The "why" here is "so that Coreboot is at least as secure as the > original firmware in this respect." Again, you seem to imply a retrofitted coreboot. If you can tell me any model with a firmware lock in particular, I can try to compare it to the coreboot situation for that model. But these things are hard to compare anyway. You have a hidden cat-and-mouse game on one side, where you may believe if the vendor or the criminal is the cat or the mouse as you wish, and on the other side an open-source solution that you may choose to trust for its auditability and reproducibility, that doesn't blind you by pretending to offer general security but instead offers only locking options that make sense in certain use cases. Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
