coreboot September 2018

coreboot@coreboot.org

59 participants
160 discussions

Re: [coreboot] SPI controller and Lock bits
by Dhaval Sharma 27 Sep '18

27 Sep '18

"but once you boot an OS, Heads would first lock the flash so it can't be written to'. Is this some kind of a OS driver? The typical usage of all locking register which are write once is to have them locked up within BIOS itself which is within the most trusted boundary. Best we could do it push out the locking part to the latest stages but not completely out IMHO. On Thu, Sep 27, 2018 at 9:55 PM Lance Zhao <lance.zhao(a)gmail.com> wrote: > Okay, then I believe we should leave the decision on CONFIG instead of > force lockdown blindly. As of now, that's still optional I believe. > > > On Thu, Sep 27, 2018 at 3:49 AM Nico Huber <nico.huber(a)secunet.com> wrote: > >> Am 26.09.18 um 22:26 schrieb Lance Zhao: >> > I am reading the "flash security recommendation" from PCH BIOS writer >> > guide now, it did say strongly recommend to take those actions. The EISS >> > feature to ensure BIOS region can only get modfiyed from SMM. >> >> The EISS bit is a highly questionable feature. It's part of the lost >> cause of security by treating SMM more privileged than the OS. AFAIK, >> coreboot vendors have secured flash access properly in the past without >> SMM features and never failed [1]. OTOH, UEFI vendors often granted SMM >> full flash access in the past and failed to secure SMM [2]. >> >> To my knowledge, EISS is incompatible to vboot btw. (not by design but >> to the current implementation). >> >> So I "strongly recommend" to ignore Intel's SMM recommendations wrt. >> flash access and recommend instead to never grant SMM more privileges >> than the OS. >> >> Nico >> >> [1] At least since the introduction of SPI flash chips. Earlier there >> were possible race conditions regarding the BIOS Write Enable bit >> where you needed SMM for protection, or had to use the flash chip's >> own security features. But that was before/maybe why EISS became a >> feature. >> [2] e.g. https://github.com/Cr4sh/ThinkPwn (the list of vulnerable >> systems is long and incomplete) >> > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] SPI controller and Lock bits
by Nico Huber 27 Sep '18

27 Sep '18

Am 26.09.18 um 22:26 schrieb Lance Zhao: > I am reading the "flash security recommendation" from PCH BIOS writer > guide now, it did say strongly recommend to take those actions. The EISS > feature to ensure BIOS region can only get modfiyed from SMM. The EISS bit is a highly questionable feature. It's part of the lost cause of security by treating SMM more privileged than the OS. AFAIK, coreboot vendors have secured flash access properly in the past without SMM features and never failed [1]. OTOH, UEFI vendors often granted SMM full flash access in the past and failed to secure SMM [2]. To my knowledge, EISS is incompatible to vboot btw. (not by design but to the current implementation). So I "strongly recommend" to ignore Intel's SMM recommendations wrt. flash access and recommend instead to never grant SMM more privileges than the OS. Nico [1] At least since the introduction of SPI flash chips. Earlier there were possible race conditions regarding the BIOS Write Enable bit where you needed SMM for protection, or had to use the flash chip's own security features. But that was before/maybe why EISS became a feature. [2] e.g. https://github.com/Cr4sh/ThinkPwn (the list of vulnerable systems is long and incomplete)

2 1

Re: [coreboot] Lenovo G505S - spkmodem console sound, is correct? Please listen and tell
by Anac 27 Sep '18

27 Sep '18

On 09/27/2018 05:22 AM, Ivan Ivanov wrote: > I suspect: despite that the "PC Speaker"-style beeping output is > working fine at this laptop/speakers while we are using Linux or even > some very simple OS like FreeDOS or Kolibri - that coreboot's spkmodem > might be buggy at G505S laptop, since there are only a few distinct > beeps (a couple of them are long enough to be visible at Soundcloud's > waveform) - everything else sounds like maybe an encrypted message but > could be just garbage (far from being similar to some morse code) Hi Ivan, sorry to say that I'm de facto illiterate when it comes to CoreBoot or even spkmodem. What I can say, though, is that regarding transmitting hidden information through sound, the best way-to-go IMO would be piggybacking scattered, high-tuned and encrypted pieces of data on otherwise unsuspected waves. The frequencies would preferably be between what human ears can hear and what loudspeakers can transmit. Unfortunately, this is where compression algorithms come into play. So, any compressed file types (like ogg or mp3) may not convey sufficient suspicious data and therefore are no reliable grounds for checks/audits. Directly seeing magnified waves seems to be required here. I'm not even sure if any software based tools like Audacity or any other vulnerable-to-attacks tools are suitable for those audits. Well, despite their huge budgets, **they** are sloppy or out-dated sometimes. So, using software based tools may be useful or not. Definitely better would be old-school analog oscilloscopes, and then go further from there. Hoping I could be helpful in some way despite my illiteracy on CoreBoot. Sincerely!

1 0

Re: [coreboot] Loading Linux payloads on RISC-V
by Patrick Rudolph 27 Sep '18

27 Sep '18

On 2018-09-26 10:29 PM, Philipp Hug wrote: > In my local tree I just added the ram address in selfboot. > Doing this beforehand with cbfstool would be even better. (E.g. only > when choosing linux payload) > The proposed mechanism was already implemented here: https://review.coreboot.org/#/c/coreboot/+/13762/ We decided to use FIT instead, as it has the following advantages: * Supports architecture specific calling conventions * Supports devicetree and initrd * Supports PIE > The FIT probably needs to be created by distro tools: assembling > kernel, dt and initramfs. > > On Wed, Sep 26, 2018, 17:42 ron minnich <rminnich(a)gmail.com> wrote: > >> But the kernel can start anywhere. I don't see a reason to do this >> complex objcopy step when all that is needed is to have cbfstool set >> some entries in the SELF or just have selfboot use "0" to mean >> "somewhere useful"? Did I miss something? >> >> On Tue, Sep 25, 2018 at 10:32 PM 王翔 <wxjstz(a)126.com> wrote: >> >> This elf file is position-independent and can be loaded to any >> location. We can add a simple script to handle it. >> >> 1. Convert vmlinux to binary by objcopy, the binary file name is >> flat_file >> >> 2. Write a simple assembly file (tmp.S), convert binary to object, >> the file name is obj_file >> ``` >> .section .text >> .globl _start >> _start: >> .incbin "flat_file" >> ``` >> command: as tmp.S -o obj_file >> >> 3. Relink. Linker script like this(tmp.ld): >> ``` >> ENTRY(_start) >> >> SECTIONS { >> . = target_address; >> .text : { *(.text) } >> } >> ``` >> command: ld -T tmp.ld obj_file >> >> 在2018年09月25 20时51分, "Philipp Hug"<philipp(a)hug.cx>写道: >> >> Am Di., 25. Sep. 2018 um 13:50 Uhr schrieb Jonathan Neuschäfer >> <j.neuschaefer(a)gmx.net>: >> Would FIT support require discussion/cooperation with other projects >> like Linux or u-boot? >> >> What seems to be missing is the kernel image format to be used >> within the FIT. e.g. look at arm64: >> > https://github.com/torvalds/linux/blob/master/arch/arm64/kernel/head.S#L73 >> > https://github.com/coreboot/coreboot/blob/master/src/arch/arm64/fit_payload… >> As the riscv kernel doesn't have a header, just place it anywhere in usable RAM and set the entrypoint to the same address. It looks like it's very easy to add FIT support. Regards, Patrick >> >> Philipp

1 0

Re: [coreboot] Loading Linux payloads on RISC-V
by 王翔 27 Sep '18

27 Sep '18

Yes, kernel can be start at any address. You can refer to BBL implementation : https://github.com/riscv/riscv-pk BBL converts vmlinux to binary and inserts it into the section named .payload which is one section of BBL. Because the size of the BBL cannot be known before compiling and linking, the address of the payload is not specific. 在2018年09月27 04时29分, "Philipp Hug"<philipp(a)hug.cx>写道: In my local tree I just added the ram address in selfboot. Doing this beforehand with cbfstool would be even better. (E.g. only when choosing linux payload) The FIT probably needs to be created by distro tools: assembling kernel, dt and initramfs. On Wed, Sep 26, 2018, 17:42 ron minnich <rminnich(a)gmail.com> wrote: But the kernel can start anywhere. I don't see a reason to do this complex objcopy step when all that is needed is to have cbfstool set some entries in the SELF or just have selfboot use "0" to mean "somewhere useful"? Did I miss something? On Tue, Sep 25, 2018 at 10:32 PM 王翔 <wxjstz(a)126.com> wrote: This elf file is position-independent and can be loaded to any location. We can add a simple script to handle it. 1. Convert vmlinux to binary by objcopy, the binary file name is flat_file 2. Write a simple assembly file (tmp.S), convert binary to object, the file name is obj_file ``` .section .text .globl _start _start: .incbin "flat_file" ``` command: as tmp.S -o obj_file 3. Relink. Linker script like this(tmp.ld): ``` ENTRY(_start) SECTIONS { . = target_address; .text : { *(.text) } } ``` command: ld -T tmp.ld obj_file 在2018年09月25 20时51分, "Philipp Hug"<philipp(a)hug.cx>写道: Am Di., 25. Sep. 2018 um 13:50 Uhr schrieb Jonathan Neuschäfer <j.neuschaefer(a)gmx.net>: Would FIT support require discussion/cooperation with other projects like Linux or u-boot? What seems to be missing is the kernel image format to be used within the FIT. e.g. look at arm64: https://github.com/torvalds/linux/blob/master/arch/arm64/kernel/head.S#L73 https://github.com/coreboot/coreboot/blob/master/src/arch/arm64/fit_payload… Philipp

1 0

Lenovo G505S - spkmodem console sound, is correct? Please listen and tell
by Ivan Ivanov 27 Sep '18

27 Sep '18

Good day! We are debugging a custom config of G505S coreboot which currently can't boot beyond SeaBIOS to any Linux: kernel gets stuck at the early booting stages regardless of its' parameters. So we can't access cbmem console, and are exploring the alternative console output options. One of them is spkmodem - console output through this G505S laptop's speakers. But we can't decode any symbols of its' output with spkmodem-recv, regardless of the options we use, or whether we're trying parec or arecord to achieve that. I suspect: despite that the "PC Speaker"-style beeping output is working fine at this laptop/speakers while we are using Linux or even some very simple OS like FreeDOS or Kolibri - that coreboot's spkmodem might be buggy at G505S laptop, since there are only a few distinct beeps (a couple of them are long enough to be visible at Soundcloud's waveform) - everything else sounds like maybe an encrypted message but could be just garbage (far from being similar to some morse code) If you've ever heard the spkmodem output, please could you try to decode this stuff if its' easy for you, or at least to tell if it sounds OK or not? Its the first ~4 minutes of like 30 minutes log output, then the sounds stop: just play - https://soundcloud.com/qma-ster/g505s-spkmodem download - https://www.sendspace.com/file/y2j15y Best regards, Ivan

1 0

Re: [coreboot] Loading Linux payloads on RISC-V
by Philipp Hug 26 Sep '18

26 Sep '18

In my local tree I just added the ram address in selfboot. Doing this beforehand with cbfstool would be even better. (E.g. only when choosing linux payload) The FIT probably needs to be created by distro tools: assembling kernel, dt and initramfs. On Wed, Sep 26, 2018, 17:42 ron minnich <rminnich(a)gmail.com> wrote: > But the kernel can start anywhere. I don't see a reason to do this complex > objcopy step when all that is needed is to have cbfstool set some entries > in the SELF or just have selfboot use "0" to mean "somewhere useful"? Did I > miss something? > > On Tue, Sep 25, 2018 at 10:32 PM 王翔 <wxjstz(a)126.com> wrote: > >> This elf file is position-independent and can be loaded to any location. >> We can add a simple script to handle it. >> >> 1. Convert vmlinux to binary by objcopy, the binary file name is flat_file >> >> 2. Write a simple assembly file (tmp.S), convert binary to object, the >> file name is obj_file >> ``` >> .section .text >> .globl _start >> _start: >> .incbin "flat_file" >> ``` >> command: as tmp.S -o obj_file >> >> 3. Relink. Linker script like this(tmp.ld): >> ``` >> ENTRY(_start) >> >> SECTIONS { >> . = target_address; >> .text : { *(.text) } >> } >> ``` >> command: ld -T tmp.ld obj_file >> >> >> >> 在2018年09月25 20时51分, "Philipp Hug"<philipp(a)hug.cx>写道: >> >> >> Am Di., 25. Sep. 2018 um 13:50 Uhr schrieb Jonathan Neuschäfer < >> j.neuschaefer(a)gmx.net>: >> >>> Would FIT support require discussion/cooperation with other projects >>> like Linux or u-boot? >>> >>> What seems to be missing is the kernel image format to be used within >> the FIT. e.g. look at arm64: >> https://github.com/torvalds/linux/blob/master/arch/arm64/kernel/head.S#L73 >> >> https://github.com/coreboot/coreboot/blob/master/src/arch/arm64/fit_payload… >> >> >> Philipp >> >> >> >> >> >> >> >

1 0

Re: [coreboot] SPI controller and Lock bits
by Patrick Rudolph 26 Sep '18

26 Sep '18

Hi Youness, On 2018-09-26 01:30 AM, Youness Alaoui wrote: > Hi, > > I'm trying to add a way to lock the SPI flash to be read-only via > software *after* coreboot boots. The scenario is basically with using > Heads, you could authenticate to it (with a yubikey/nitrokey/librem > key) then be able to flash a new rom (update your BIOS), but once you > boot an OS, Heads would first lock the flash so it can't be written > to. > This should add some security to avoid any malware writing to the > flash, or someone booting into a USB stick and using that to flash a > malicious BIOS, but still gives the user the freedom of updating their > flash whenever they want to. > > The problem is that I can't make the flash read-only because the SPI > interface is already locked down by coreboot (see > src/soc/intel/skylake/lockdown.c and > src/soc/intel/common/block/fast_spi/fast_spi.c). > > There's a couple of things happening here : > First, the FLOCKDN bit is set which prevents us from enabling the > write protection. the BIOS Interface lock down is controlled by the > chipset_lockdown config variable, but the FLOCKDN is not behind a > config variable. > The second thing is that if I wanted to use the protected ranges > feature to lock specific regions, they are all getting locked using > the discrete lock register even while being unused. The locking of the > protected ranges was added in this change : > https://review.coreboot.org/c/coreboot/+/21064 and it passed without > notice among the move that the commit was supposed to do. > > The commit states that the lockdown is meant to "support platform > security guidelines", but I think that this is not actually good > because coreboot leaves everything read-write and locks down the > registers so we can't make it read-only. I think that the security > guidelines would say to disable the write protection before locking > the registers down. > Feel free to propose a new "security guideline", but document it in the tree. A similar mechanism is already implemented on Intel: https://review.coreboot.org/#/c/coreboot/+/21327/ Feel free to make it configurable on intel/soc, too. > Either way, I'm going to need to add a way to make this configurable, > so my main questions here are : > - Should I create a new config variable to decide on whether or not to > lock the spi registers and another one to decide on whether or not to > lock the protected ranges ? > - Should I make the chipset_lockdown (currently used for locking the > BIOS CNTL register from LPC and SPI controllers) into an OR-ed flags > variable where we can say : chipset_lockdown = LOCKDOWN_COREBOOT | > LOCKDOWN_SPI | LOCKDOWN_PROTECTED_RANGES ? > - Should I make a single new config variable to decide what to > lockdown (LPC_BIOS, SPI_BIOS, SPI_BAR, SPI_PROTECTED_RANGES) and only > set them if the CHIPSET_LOCKDOWN_COREBOOT is set ? And if > chipset_lockdown is set to CHIPSET_LOCKDOWN_FSP not lockdown anything > at all ? > - Do we want to keep the protected ranges locked down at all, have > them configurable or completely remove that as I don't see the point > in using the discrete lock register ? > The protected ranges will be used on non Chromeos devices to support vboot. A common interface is being worked on right now, but it'll take some time. > Once I see a consensus on what's the best way to move forward, I'll > implement it and push it for review. > > Note: I think these only affect hardware sequencing though so I assume > someone could always use software sequencing to do the writes. As long > as the FLOCKDN bit isn't set though, I could remove all write-related > opcodes from the software sequencing register, which would also > prevent someone using swseq to do writes. > > Thanks, > Youness.

3 2

Re: [coreboot] flashrom and 256 MiB S256FL256S
by Angel Pons 26 Sep '18

26 Sep '18

Hello Ron, I do not have such chip, but I am aware there are three patches regarding the S25FL256S: [1] Best regards, Angel Pons [1]: https://review.coreboot.org/q/topic:"s25fl256s"

1 0

flashrom and 256 MiB S256FL256S
by ron minnich 26 Sep '18

26 Sep '18

we're trying to use a 32 MiB part with flashrom and failing, I just wanted to see if anyone else has had good luck here. It reads back as all FF, but there is no indication of trouble. ron

1 0

← Newer
1
2
3
4
5
6
7
8
...
16
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot September 2018