[coreboot] Re: Locking coreboot against internal flashing
On Mon, Feb 25, 2019 at 03:42:41PM -0500, taii...@gmx.com wrote: I'm reasonably sure that this is not true and security-conscious users can disable internal flashing, but I haven't been able to find any mention of such a setting in the documentation. Isn't it possible to set the flash chip write lock bit on the flash chip so things can't be flashed internally the same way intel blocks one from re-writing the ME region internally? That sounds like what I was asking about. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Locking coreboot against internal flashing
On 02/16/2019 07:31 AM, Frank Beuth wrote: > On Thu, Feb 14, 2019 at 12:21:36PM -0500, Matt B wrote: >> For Coreboot afaik the only two methods available are to flash with a >> programmer or to flash internally from linux with iomem=relaxed. > > On another mailing list, someone commented "I would never use Coreboot, > because it would let malware flash your bios from within Linux." > (paraphrased) Those people are silly then, since a propriatary BIOS doesn't prevent that either. They also think that if something isn't absolutely perfect that one should not bother which is absurd. The ones that prompt for BIOS passwords or w/e are just doing it to be polite they have no software-enforced firmware update signing mechanisms - now of course ones that do enforce it (but via hardware) always include external flashes too making them not owner controlled and thus evil. > > I'm reasonably sure that this is not true and security-conscious users > can disable internal flashing, but I haven't been able to find any > mention of such a setting in the documentation. Isn't it possible to set the flash chip write lock bit on the flash chip so things can't be flashed internally the same way intel blocks one from re-writing the ME region internally? ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Locking coreboot against internal flashing
Would it make the most sense to put locking option in coreboot's
board-specific code, since the method varies between boards? Could a common
ACPI call for it be provided that could be called by a payload or OS later
if it's present?
-Matt
On Sun, Feb 17, 2019 at 8:48 PM Frank Beuth wrote:
> 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 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 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] 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
[coreboot] Re: Locking coreboot against internal flashing
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? So if somebody tells you that coreboot doesn't have an option to lock the flash chip, that might actually be true for their combination of coreboot + payload and hardware. The only option in coreboot itself that I know is the LOCK_SPI_FLASH_RO Kconfig. It should be available for all boards that use one of the fol- lowing Intel PCHs and a directly attached SPI flash: o Ibex Peak, o Cougar Point, o Panther Point, o Lynx Point, o Lynx Point-LP (integrated into a Haswell SoC). This can easily be extended to support any newer Intel chipset. Beside that, I know there are locking options in the FILO payload. And I suspect HEADS to do something about it, too. Google uses the block pro- tection of the flash chip on their ChromeBooks/Boxes. They have the WP pin controllable with a screw/switch/security chip. So if you got one of these, it would be wise to make use of that. 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 Sat, Feb 16, 2019 at 4:31 AM Frank Beuth wrote: > On another mailing list, someone commented "I would never use Coreboot, > because > it would let malware flash your bios from within Linux." (paraphrased) well, send them here, and we can try to explain the world as it is. But this particular FUD has been bouncing around for 20 years so I don't hold much hope out for changing minds. ron ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Locking coreboot against internal flashing
On 16.02.19 16:08, Frank Beuth wrote: > On Sat, Feb 16, 2019 at 05:23:40PM +0300, Sergej Ivanov wrote: >> To make a real write protection on your spi flash you may go two ways >> after >> setting region protection and configuration bits in your flash > > Where are the write protection bits for the flash set, in which menu / > config file? That is my question. What Sergej suggested would have to be done out of band and not by coreboot. You can configure your flash chip to protect itself, which is unlike most firmware does it. 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. So if somebody tells you that coreboot doesn't have an option to lock the flash chip, that might actually be true for their combination of coreboot + payload and hardware. The only option in coreboot itself that I know is the LOCK_SPI_FLASH_RO Kconfig. It should be available for all boards that use one of the fol- lowing Intel PCHs and a directly attached SPI flash: o Ibex Peak, o Cougar Point, o Panther Point, o Lynx Point, o Lynx Point-LP (integrated into a Haswell SoC). This can easily be extended to support any newer Intel chipset. Beside that, I know there are locking options in the FILO payload. And I suspect HEADS to do something about it, too. Google uses the block pro- tection of the flash chip on their ChromeBooks/Boxes. They have the WP pin controllable with a screw/switch/security chip. So if you got one of these, it would be wise to make use of that. 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 Sat, Feb 16, 2019 at 05:23:40PM +0300, Sergej Ivanov wrote: To make a real write protection on your spi flash you may go two ways after setting region protection and configuration bits in your flash Where are the write protection bits for the flash set, in which menu / config file? That is my question. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Locking coreboot against internal flashing
To make a real write protection on your spi flash you may go two ways after setting region protection and configuration bits in your flash 1) Write a SMM handler, that will prevent software to set high level on SPI #WP/WE pin (that can be done it it connected to chipset) absolute chipset-specific, also possibly this will be a mainboard specific task. Or 2) After flashing coreboot with setted up protection bits you can disconnect #WP/WE pin from mainboard and hardwire it to ground. Second way is a bit simple, but you may lost hibernation/S3 on amd and lost memory training data on intel FSP based boards. The final decision is yours. сб, 16 февр. 2019 г., 15:31 Frank Beuth secli...@boxdan.com: > On Thu, Feb 14, 2019 at 12:21:36PM -0500, Matt B wrote: > >For Coreboot afaik the only two methods available are to flash with a > >programmer or to flash internally from linux with iomem=relaxed. > > On another mailing list, someone commented "I would never use Coreboot, > because > it would let malware flash your bios from within Linux." (paraphrased) > > I'm reasonably sure that this is not true and security-conscious users can > disable internal flashing, but I haven't been able to find any mention of > such > a setting in the documentation. > > How can users disable internal flashing? > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
