[coreboot] Re: Locking coreboot against internal flashing
On Sun, Feb 17, 2019 at 12:24:38PM +0100, Nico Huber wrote:
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).
I see, this explains a lot and goes a long way to resolving the original issue
("installing Coreboot makes me less secure because it enables software
reflashing").
[Coreboot] offers only
locking options that make sense in certain use cases.
Most of the locking options that have been discussed in this thread so far are
rather hacky (often requiring writing new code) and not part of any
Coreboot or related (e.g SeaBIOS) software package.
For Coreboot and related packages, you previously mentioned LOCK_SPI_FLASH_RO
and some unspecified locking options in the FILO payload. Are there any others?
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Locking coreboot against internal flashing
> > 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. > I think the most common retrofitted coreboot solution that people use is for older thinkpads. So it seems reasonable to provide some additional guidance for people attempting that in the official documentation. The threat model in baseline is that even if the OS is compromised, it cannot write to the bios. The vendor's signing keys are considered trusted in this model, exploits notwithstanding. i.e., You can get to a clean slate by wiping your hard drive. So with that it mind, it may be useful to help people achieve a similar goal. In general, the landscape of different security measures such as vboot, heads etc. is hard to grasp for lay people. It is not immediately obvious how to use them, or specifically how they differ in threat models, whether they allow subsequent flashing without using an external programmer if the hardware doesn't have dedicated hardware like chromebooks, whether it is possible to have a clean trusted/airgapped machine for just building and signing coreboot builds which would be the only trusted builds by your target devices, etc. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] FSP Memory down setup
Helllo, In my BayTrail module, Enable Memory Down = Enabled. In this case are the following parameters relevant ? DIMM 0 Enable DIMM 1 Enable DIMM_DWidth DIMM_Density DIMM _BusWidth DIMM_Sides Thank you, Zvika ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: AMDFlaws
On Sun, Feb 17, 2019 at 8:47 AM Mike Banon wrote: > Hi, Almost all the coreboot-supported AMD 16h boards are AMD _early_ 16h > (so no PSP). Please tell what 16h systems do you have, maybe they > don't have a PSP at all? > > Well pcengines/apu2 variants are fam16h model30h with PSP. I have done experiments with it to reduce PSP blob footprint, see the branch [1] in gerrit. There is some (NDAd) documentation about the firmware signatures and one can capture PSP firwmare POST codes from LPC. Now since the build of x86 AGESA blob used never actually sends PSP the message RAM is ready, I figured that we may never actually load the "PSP Secure OS" but only the bootloader part. Also, don't forget pre-PSP silicons still have SMU/PMU. [1] https://review.coreboot.org/q/topic:"amd-fw-layout; ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Locking coreboot against internal flashing
在 2019/2/17 下午5:02, Nico Huber 写道: > When you are sure that you want a lock, you still have to decide what > kind of lock. And that depends on what you actually want to protect > against (e.g. online attack by a compromised OS) and how much flexi- > bility you are willing to sacrifice (e.g. online firmware updates). Nico is right, and I personally like locks that can and should be unlocked with physical access during boot via some sort of authentication, so they are usually performed by payloads with authentication and programming capabilities. You can see some boot-time-unlockable lock schemes here: https://github.com/hardenedlinux/Debian-GNU-Linux-Profiles/blob/master/docs/hardened_boot/grub-for-coreboot.md#update-for-coreboot-after-commit-2ac149d294af795710eb4bb20f093e9920604abd , performed by a grub payload. https://github.com/hardenedlinux/Debian-GNU-Linux-Profiles/blob/master/docs/hardened_boot/heads-atop-coreboot.md#update-3 , performed by a modified heads payload. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Locking coreboot against internal flashing
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
[coreboot] Re: Locking coreboot against internal flashing
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. 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. 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." ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Locking coreboot against internal flashing
在 2019/2/17 下午5:02, Nico Huber 写道: > When you are sure that you want a lock, you still have to decide what > kind of lock. And that depends on what you actually want to protect > against (e.g. online attack by a compromised OS) and how much flexi- > bility you are willing to sacrifice (e.g. online firmware updates). Nico is right, and I personally like locks that can and should be unlocked with physical access during boot via some sort of authentication, so they are usually performed by payloads with authentication and programming capabilities. You can see some boot-time-unlockable lock schemes here: https://github.com/hardenedlinux/Debian-GNU-Linux-Profiles/blob/master/docs/hardened_boot/grub-for-coreboot.md#update-for-coreboot-after-commit-2ac149d294af795710eb4bb20f093e9920604abd , performed by a grub payload. https://github.com/hardenedlinux/Debian-GNU-Linux-Profiles/blob/master/docs/hardened_boot/heads-atop-coreboot.md#update-3 , performed by a modified heads payload. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Locking coreboot against internal flashing
On 17.02.19 02:35, Frank Beuth wrote: > On Sat, Feb 16, 2019 at 06:00:26PM +0100, Nico Huber wrote: >> Generally, what locking options you have depend much on your hardware. >> Hence, there is no generic solution in coreboot. Plus, coreboot is more >> a firmware framework than a firmware. It can only "boot" programs from >> flash and not your OS from disk. So you need a coreboot "payload" to do >> the latter and sometimes it's up to that payload to do such locking. > > I see, so this question would be more properly directed at the SeaBIOS > list? 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). Before you ask somebody to implement a lock, you should ask yourself why. "Somebody said malware can overwrite x" isn't a good reason. We allow malware to overwrite our on-disk boot loader, we allow malware to overwrite our kernel; nobody cares / it depends on the way we use our software. We are used to rely on some firmware lock because their vendors gave us no other means to feel secure. But coreboot can give us other means, because it is no black box. For instance, one can just reflash coreboot when they feel compromised, like we reinstall our OS in case. When you are sure that you want a lock, you still have to decide what kind of lock. And that depends on what you actually want to protect against (e.g. online attack by a compromised OS) and how much flexi- bility you are willing to sacrifice (e.g. online firmware updates). Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
