Coreboot Self-Flashing Through Payload?
Hi, I was helping a friend with a bios issue (we may have an involuntary coreboot convert on our hands ;) ) and realized that a lot of BIOSs provide a way for the BIOS to flash itself but Coreboot doesn't. For Coreboot afaik the only two methods available are to flash with a programmer or to flash internally from linux with iomem=relaxed. For most proprietary BIOSs, you can boot a utility that knows what USB drives are and flash from there. What I'm thinking of trying, and would appreciate feedback on, is the idea of making a Seabios floppy image specifically intended for flashing Coreboot. I figure this has a few advantages: -It's OS-agnostic, meaning you can reflash the BIOS regardless of what you boot into, or even if there's nothing to boot at all (without running to grab some jumper cables) -It means you don't have to fiddle with setting iomem=relaxed on your main install and un-setting it when you're done (I don't fancy leaving it on all the time) -Some level of confidence that you can trust the flashing environment, being as it's stripped down and purpose built, while also residing on the flash itself Might be a security advantage if flashing could be restricted to only this pathway (and not say, through the main OS), but let's not get ahead of ourselves. I figure the easiest way would be to build a floppy image for seabios with a kernel and a copy of busybox, with the bare essentials to find an image on a usb drive and run flashrom. (maybe even a convenient shell script :P) What I'm not sure on (not having built an install completely from scratch) is what else those bare essentials might include. Eventually something akin to (or included in?) LinuxBoot might be better, integrating everything into a single payload and cutting out the dependency on seabios. -Matt
Why does it have to be done by Seabios as opposed to Linux? It is easy to create a USB stick which would boot Linux compiled with permissions needed and with startup files which will program the new firmware image. This would be much easier to debug and modify when needed, right? -vb On Thu, Feb 14, 2019 at 9:30 AM Matt B <matthewwbradley6@gmail.com> wrote:
Hi,
I was helping a friend with a bios issue (we may have an involuntary coreboot convert on our hands ;) ) and realized that a lot of BIOSs provide a way for the BIOS to flash itself but Coreboot doesn't.
For Coreboot afaik the only two methods available are to flash with a programmer or to flash internally from linux with iomem=relaxed. For most proprietary BIOSs, you can boot a utility that knows what USB drives are and flash from there.
What I'm thinking of trying, and would appreciate feedback on, is the idea of making a Seabios floppy image specifically intended for flashing Coreboot.
I figure this has a few advantages: -It's OS-agnostic, meaning you can reflash the BIOS regardless of what you boot into, or even if there's nothing to boot at all (without running to grab some jumper cables) -It means you don't have to fiddle with setting iomem=relaxed on your main install and un-setting it when you're done (I don't fancy leaving it on all the time) -Some level of confidence that you can trust the flashing environment, being as it's stripped down and purpose built, while also residing on the flash itself
Might be a security advantage if flashing could be restricted to only this pathway (and not say, through the main OS), but let's not get ahead of ourselves.
I figure the easiest way would be to build a floppy image for seabios with a kernel and a copy of busybox, with the bare essentials to find an image on a usb drive and run flashrom. (maybe even a convenient shell script :P) What I'm not sure on (not having built an install completely from scratch) is what else those bare essentials might include.
Eventually something akin to (or included in?) LinuxBoot might be better, integrating everything into a single payload and cutting out the dependency on seabios.
-Matt _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Am Do., 14. Feb. 2019 um 18:47 Uhr schrieb Vadim Bendebury <vbendeb@chromium.org>:
Why does it have to be done by Seabios as opposed to Linux? It is easy to create a USB stick which would boot Linux compiled with permissions needed and with startup files which will program the new firmware image. This would be much easier to debug and modify when needed, right? I think the idea is to provide flashing from within the boot flow. But even then I wouldn't rely on SeaBIOS for that, but use libflashrom to build a payload: SeaBIOS can load other payloads, as can GRUB2, so that increases the potential user base of the flashing feature, and it would be smaller than a disk image of a Linux that's put into flash (which sounds rather convoluted to me).
Patrick
Hi Matt, On 14.02.19 18:56, Patrick Georgi via coreboot wrote:
Am Do., 14. Feb. 2019 um 18:47 Uhr schrieb Vadim Bendebury <vbendeb@chromium.org>:
Why does it have to be done by Seabios as opposed to Linux? It is easy to create a USB stick which would boot Linux compiled with permissions needed and with startup files which will program the new firmware image. This would be much easier to debug and modify when needed, right? I think the idea is to provide flashing from within the boot flow. But even then I wouldn't rely on SeaBIOS for that, but use libflashrom to build a payload: SeaBIOS can load other payloads, as can GRUB2, so that increases the potential user base of the flashing feature, and it would be smaller than a disk image of a Linux that's put into flash (which sounds rather convoluted to me).
libflashrom and libpayload integrate very well. Actually that's what we do in the FILO payload. The upstream code is stale, though, and won't compile with current libflashrom. Let me know if you want to try that path (FILO is a pain to compile atm). Nico
Actually that's what we do in the FILO payload.
What is libflashrom used for in FILO? Was it intended at some point that FILO be able to reflash the BIOS, or is it being used for something like reading the flash chip in order to load other things? -Matt On Thu, Feb 14, 2019 at 3:45 PM Nico Huber <nico.h@gmx.de> wrote:
Hi Matt,
On 14.02.19 18:56, Patrick Georgi via coreboot wrote:
Am Do., 14. Feb. 2019 um 18:47 Uhr schrieb Vadim Bendebury <vbendeb@chromium.org>:
Why does it have to be done by Seabios as opposed to Linux? It is easy to create a USB stick which would boot Linux compiled with permissions needed and with startup files which will program the new firmware image. This would be much easier to debug and modify when needed, right? I think the idea is to provide flashing from within the boot flow. But even then I wouldn't rely on SeaBIOS for that, but use libflashrom to build a payload: SeaBIOS can load other payloads, as can GRUB2, so that increases the potential user base of the flashing feature, and it would be smaller than a disk image of a Linux that's put into flash (which sounds rather convoluted to me).
libflashrom and libpayload integrate very well. Actually that's what we do in the FILO payload. The upstream code is stale, though, and won't compile with current libflashrom. Let me know if you want to try that path (FILO is a pain to compile atm).
Nico
On 14.02.19 21:54, Matt B wrote:
Actually that's what we do in the FILO payload.
What is libflashrom used for in FILO? Was it intended at some point that FILO be able to reflash the BIOS, or is it being used for something like reading the flash chip in order to load other things?
The former, have a look here [1]. As I said, it won't compile against current flashrom, but I could push something tomorrow. Getting FILO to compile at all, is the tricky part ;) Nico [1] https://review.coreboot.org/cgit/filo.git/tree/flashupdate/flashupdate.c
On Thu, Feb 14, 2019 at 9:29 AM Matt B <matthewwbradley6@gmail.com> wrote:
Hi,
I was helping a friend with a bios issue (we may have an involuntary coreboot convert on our hands ;) ) and realized that a lot of BIOSs provide a way for the BIOS to flash itself but Coreboot doesn't.
And, for the record, this was intentional, a decision I made in 1999 when I started the project. I had been burned big time by firmware systems that claimed to be able to reliably reflash themselves, and the history of UEFI self-reflash, at least in my view, confirms that this was the right call. I just wanted to make clear that this was not an oversight, it was a decision we made from the start. We always felt more willing to trust a user mode program running under Linux to get it right, as opposed to some magic thing in the firmware ... :-) thanks ron
Makes sense. That was one thing that gave me a bit of a gut feeling to do it in a small linux install than to try to integrate more tightly with the firmware. The linux utility is what everyone uses and should be more reliable. I've been recently burned by that issue too, on proprietary firmware from around 2008. -Matt On Thu, Feb 14, 2019 at 7:56 PM ron minnich <rminnich@gmail.com> wrote:
On Thu, Feb 14, 2019 at 9:29 AM Matt B <matthewwbradley6@gmail.com> wrote:
Hi,
I was helping a friend with a bios issue (we may have an involuntary
coreboot convert on our hands ;) ) and realized that a lot of BIOSs provide a way for the BIOS to flash itself but Coreboot doesn't.
And, for the record, this was intentional, a decision I made in 1999 when I started the project. I had been burned big time by firmware systems that claimed to be able to reliably reflash themselves, and the history of UEFI self-reflash, at least in my view, confirms that this was the right call.
I just wanted to make clear that this was not an oversight, it was a decision we made from the start. We always felt more willing to trust a user mode program running under Linux to get it right, as opposed to some magic thing in the firmware ... :-)
thanks
ron
It's also possible to make Linux (with included ramdisk) into a payload, so maybe that could be a middle ground: It's still usable by all payloads that can execute payloads, it's still Linux + userland in a more or less normal configuration. It has some overhead, but OTOH brings the peace of mind of the battle hardened environment. Patrick Am Fr., 15. Feb. 2019 um 22:33 Uhr schrieb Matt B <matthewwbradley6@gmail.com>:
Makes sense. That was one thing that gave me a bit of a gut feeling to do it in a small linux install than to try to integrate more tightly with the firmware. The linux utility is what everyone uses and should be more reliable.
I've been recently burned by that issue too, on proprietary firmware from around 2008.
-Matt
On Thu, Feb 14, 2019 at 7:56 PM ron minnich <rminnich@gmail.com> wrote:
On Thu, Feb 14, 2019 at 9:29 AM Matt B <matthewwbradley6@gmail.com> wrote:
Hi,
I was helping a friend with a bios issue (we may have an involuntary coreboot convert on our hands ;) ) and realized that a lot of BIOSs provide a way for the BIOS to flash itself but Coreboot doesn't.
And, for the record, this was intentional, a decision I made in 1999 when I started the project. I had been burned big time by firmware systems that claimed to be able to reliably reflash themselves, and the history of UEFI self-reflash, at least in my view, confirms that this was the right call.
I just wanted to make clear that this was not an oversight, it was a decision we made from the start. We always felt more willing to trust a user mode program running under Linux to get it right, as opposed to some magic thing in the firmware ... :-)
thanks
ron
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
I agree with patrick :-) On Fri, Feb 15, 2019 at 1:38 PM Patrick Georgi <pgeorgi@google.com> wrote:
It's also possible to make Linux (with included ramdisk) into a payload, so maybe that could be a middle ground: It's still usable by all payloads that can execute payloads, it's still Linux + userland in a more or less normal configuration. It has some overhead, but OTOH brings the peace of mind of the battle hardened environment.
Patrick
Am Fr., 15. Feb. 2019 um 22:33 Uhr schrieb Matt B <matthewwbradley6@gmail.com>:
Makes sense. That was one thing that gave me a bit of a gut feeling to do it in a small linux install than to try to integrate more tightly with the firmware. The linux utility is what everyone uses and should be more reliable.
I've been recently burned by that issue too, on proprietary firmware from around 2008.
-Matt
On Thu, Feb 14, 2019 at 7:56 PM ron minnich <rminnich@gmail.com> wrote:
On Thu, Feb 14, 2019 at 9:29 AM Matt B <matthewwbradley6@gmail.com> wrote:
Hi,
I was helping a friend with a bios issue (we may have an involuntary coreboot convert on our hands ;) ) and realized that a lot of BIOSs provide a way for the BIOS to flash itself but Coreboot doesn't.
And, for the record, this was intentional, a decision I made in 1999 when I started the project. I had been burned big time by firmware systems that claimed to be able to reliably reflash themselves, and the history of UEFI self-reflash, at least in my view, confirms that this was the right call.
I just wanted to make clear that this was not an oversight, it was a decision we made from the start. We always felt more willing to trust a user mode program running under Linux to get it right, as opposed to some magic thing in the firmware ... :-)
thanks
ron
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
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?
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 seclists@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-leave@coreboot.org
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.
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
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
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
在 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/... , performed by a grub payload. https://github.com/hardenedlinux/Debian-GNU-Linux-Profiles/blob/master/docs/... , performed by a modified heads payload.
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."
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
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.
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?
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 <seclists@boxdan.com> 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-leave@coreboot.org
在 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/... , performed by a grub payload. https://github.com/hardenedlinux/Debian-GNU-Linux-Profiles/blob/master/docs/... , performed by a modified heads payload.
On Sat, Feb 16, 2019 at 4:31 AM Frank Beuth <seclists@boxdan.com> 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
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?
On Mon, Feb 25, 2019 at 03:42:41PM -0500, Taiidan@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.
participants (10)
-
Frank Beuth -
Matt B -
Nico Huber -
Patrick Georgi -
persmule -
Prasun Gera -
ron minnich -
Sergej Ivanov -
Taiidan＠gmx.com -
Vadim Bendebury