coreboot October 2018

coreboot@coreboot.org

53 participants
145 discussions

Re: [coreboot] SPI controller and Lock bits
by Nico Huber 03 Oct '18

03 Oct '18

Am 02.10.18 um 13:48 schrieb Sam Kuper: > On 02/10/2018, Nico Huber <nico.huber(a)secunet.com> wrote: >> Am 02.10.18 um 11:53 schrieb Sam Kuper: >>> On 01/10/2018, Youness Alaoui <kakaroto(a)kakaroto.homelinux.net> wrote: >> tldr; whether the effort to disable write protection is reasonable >> or not depends on what you want to write protect. > > Agreed. > > >> You two might have different kinds of updates in mind. You don't need >> a switch for every update. With a read-only root of trust, for instance, >> that is secured by the switch or jumper or whatever, you could still >> update everything else with software only. That root of trust could >> either verify a signature of the following firmware parts (like vboot >> does) or start a measuring chain or (ideally) do both. >> >> Separating functional updates from those that change platform-ownership >> is a key feature of vboot. Without such separation, you'll either make >> owning too easy or updating too hard. > > In principle, I agree. But in practice, Librems don't seem to possess > this kind of separation (yet?). The software doesn't. But it's much easier to add it later once the hardware supports it. IMHO, design decisions for future hardware should prepare for state of the art security and not the security of yesterdays soft/firmware. >>>> As for your question earlier about someone forgetting it. I would >>>> assume that it would be easy to have the Heads menu show a big warning >>>> to the user if it's left unprotected >>> >>> Your assumption fails against a BadHeads attack. >> >> You need to tamper more than just HEADS, otherwise the attestation of >> the firmware (e.g. via TOTP or a Librem Key) would fail. > > That was not my understanding. > > See this outline of a putative "BadHeads" attack: > https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-… > > Also see Kyle Rankin's apparent confirmation that such attacks succeed > (on current Librems): > https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-… > > If I was mistaken about this, then I apologise. Sorry, I won't have the time to read through all this. In theory, it depends on when the measuring is started. If the measuring starts only late in HEADS (and not in coreboot), you are right. Generally you'd have to tamper the piece of software that starts the measuring. > >> But... >> there are technical pitfalls that leave the same problem for a momentary >> switch: Unless you use real custom chips, you'll have to use the access >> protection current chips support and in the case of SPI NOR flashes >> there usually is no simple on/off signal that tells the chip to deny >> writes. Usually, you only signal it to protect its write-protection >> configuration which you could forget to set correctly after flashing >> too. > > Does this mean that Peter Stuge's suggestion to (de-)solder a typical > SPI flash chip's write-protect pin was erroneous? > > https://media.ccc.de/v/30C3_-_5529_-_en_-_saal_2_-_201312271830_-_hardening… No, I wouldn't think so (without watching that video). What I meant is that lifting your finger from a momentary switch won't be enough. You, or the software you use, could still "forget" other things with the same effect. The problem is that what the flash chip does when the /WP pin is asserted usually depends on the chip's configuration (that you might have to change to be able to flash; depends on the chip I guess). Just read your chip's datasheet if you want to know the whole story. Nico

2 1

removing bounce buffers
by ron minnich 02 Oct '18

02 Oct '18

we are at long last removing bounce buffers from selfboot. https://review.coreboot.org/c/coreboot/+/28647 This greatly simplifies the code and there are almost no platforms left that need them. Here are the ones that seem to: src/northbridge/amd/amdfam10/Kconfig src/northbridge/amd/lx/Kconfig src/northbridge/via/vx900/Kconfig src/soc/intel/fsp_baytrail/Kconfig src/soc/intel/fsp_broadwell_de/Kconfig For these boards, I made the following change: "For these five boards we change CONFIG_RAMBASE from 0x100000 (the value needed in 1999 for the 32-bit Linux kernel, the original ramstage) to 0x3d00000 (64 MiB - 2 MiB) which will put the non-relocatable x86 ramstage out of the way of any reasonable payload until we can get rid of it for good." Julius suggested that I ping the list to see if anyone would like to test with the change. The change is +2'ed but i will wait to submit it for another day or so. thanks ron

1 0

Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip
by Zvi Vered 02 Oct '18

02 Oct '18

Hi Jose, All, Highly appreciate your answers. It seems the vital information in your replies are not documented. The original vendor's rom file size is 5MB. Do you think I can create a 5MB coreboot.rom ? It seems that AfuEfix64.efi supplied by vendor is looking for 5MB rom file like the original one. For any other file size, AfuEfix64 fails. Thank you, Zvika On Mon, Oct 1, 2018 at 2:08 PM Jose Trujillo <ce.autom(a)protonmail.com> wrote: > Zvika: > > There are 2 ways to build coreboot: (choose one).... > 1.- Including IFD, TXE, GBE etc.... inside coreboot CBFS. > 2.- Using the original firmware(FW) with IFD, TXE, GBE already in flash > and just rewrite coreboot on top of the BIOS block. > > Your original computer Firmware = Intel FW + "BIOS" > > Intel FW = IFD +PD+ME/TXE+GBE > BIOS=AMI-Phoenix etc... > > IFD=Intel Firmware Descriptor Table. > PD=Parameters > ME=Management Engine (For "Core" kind of processors). > TXE=Trusted Execution Engine (For "Atom" kind of processors). > GBE=Network card firmware. > > Zvika said: > "After creating coreboot.rom should I always use the original BIOS with > ifdtool to convert rom to bin ?" > Answer: > No, there are other methods and tools that can do the merge.... (ifdtool > and Intel's FIT are working fine for me) > > After the creation of the coreboot build you have 2 ways of doing the > flashing for your case: (with fpt). > 1.- Flash the full 8MB (Intel FW+coreboot) if the SPI flash is blank or > have unknown firmware. > Use IFDTool in this case to inject coreboot to Intel FW..... then > flash it with fpt . > 2.- Flash only the BIOS block (5MB your specific case) in this case ask > someone else how to do it with fpt.... > > I hope this answered your questions. > Jose.. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Saturday, September 29, 2018 12:24 AM, Zvi Vered <veredz72(a)gmail.com> > wrote: > > Hi Jose, > > You wrote: > "My recommended approach is using the original Intel FW with already > included the FD, TXE". > > What is "original intel FW" ? > What is FD, TXE ? > > After creating coreboot.rom should I always use the original BIOS with > ifdtool to convert rom to bin ? > > Thank you, > Zvika > > On Wed, Sep 26, 2018 at 7:27 PM Jose Trujillo <ce.autom(a)protonmail.com> > wrote: > >> You are right Nico, >> >> I just forgot the troubles this caused me. >> I am sorry Vika... My mistake. >> >> I can confirm with Nico: >> ROM chip size = 8MB (your case) >> CBFS_SIZE = 2 to 5MB (your specific case) >> >> My recommended approach is using the original Intel FW with already >> included the FD, TXE. >> >> I never tested adding regions to coreboot but you can try. >> >> To have better chances of success you should be dumping hardware settings >> booting with your original "BIOS" (look for the attached file). >> >> Check if the system is "Memory down"or/and ECC because it will be needed >> to edit FSP (if using it). >> Dump memory settings with the following commands: >> >> sudo dnf install i2c-tools-perl >> sudo modprobe eeprom >> decode-dimms >> >> If you have not done this already there is still a long way to go. >> Don't get intimidated, just do it, if you have questions just ask.... I >> will try to help >> >> Good luck, >> Jose. >> >> >> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >> On Wednesday, September 26, 2018 6:28 PM, Nico Huber <nico.h(a)gmx.de> >> wrote: >> >> > Hi, >> > >> > On 9/26/18 9:19 AM, Jose Trujillo via coreboot wrote: >> > >> > > No, don't change it, you change the size of coreboot only if during >> the >> > > building process "make" complain that there is not enough space but in >> > > your case your build was already successful leave it like that. >> > >> > this advice seems very weird to me. I'm not experienced with Bay Trail. >> > But unless there is a bug in the Bay Trail code, you should always set >> > the correct ROM_SIZE (to the full flash chip size). Otherwise you may >> > introduce bugs in code that relies on this setting (e.g. saving the >> > MRC cache might fail and so would S3 resume). >> > >> > CBFS_SIZE however is the setting to adjust according to your needs. It >> > should be at most the size of the BIOS region. >> > >> > > In the rare circumstance that more space is required you can increase >> > > coreboot size to 4MB and istill will fit into your system 5MB of space >> > > available. >> > > "ifdtool" will inject coreboot in the top of the BYT_orig.bin and save >> > > as BYT_orig.bin.new that you can flash to your system. >> > >> > I assume this doesn't work oob if you set ROM_SIZE correctly. But it is >> > unnecessary to craft a single file by hand. You can either only flash >> > the BIOS region (recommended) or add the other regions in coreboot's >> > config (HAVE_{IFD,ME,GBE}_BIN). >> > >> > Nico >> >> >> >

1 0

Re: [coreboot] microcode blob or ascii
by galla rao 02 Oct '18

02 Oct '18

Thanks Jose, My actual query is FSP Binary also has below ucode update which is same to coreboot\src\cpu\intel\microcode\microcode.c msr.lo = (unsigned long)m + sizeof(struct microcode); msr.hi = 0; wrmsr(0x79, msr); Atom E3845 BayTrail with D-Stepping never returns after writing uCode, tried different ucode revisions On Mon, Oct 1, 2018 at 1:49 PM Jose Trujillo <ce.autom(a)protonmail.com> wrote: > Hello Ranga: > It is ASCII just not properly formatted.... > > Just remove the text from this: > > 0x00000001, /* Header Version */ > 0x00000901, /* Patch ID */ > 0x04212014, /* DATE */ > 0x00030679, /* CPUID */ > 0x69c4e6f1, /* Checksum */ > 0x00000001, /* Loader Version */ > 0x00000001, /* Platform ID */ > 0x0000cbd0, /* Data size */ > 0x0000cc00, /* Total size */ > 0x00000000, /* reserved */ > 0x00000000, /* reserved */ > 0x00000000, /* reserved */ > > to this format: > > 0x00000001, \ > 0x00000901, \ > 0x04212014, \ > 0x00030679, \ > 0x69c4e6f1, \ > 0x00000001, \ > 0x00000001, \ > 0x0000cbd0, \ > 0x0000cc00, \ > 0x00000000, \ > 0x00000000, \ > 0x00000000, > > And try again... > Jose Trujillo. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Friday, September 28, 2018 7:28 PM, galla rao <galla.rao80(a)gmail.com> > wrote: > > Hi , > > How does the coreboot picks the cpu microcodes > > as a blob or ASCII ? > > Tried both option GENERATE FROM TREE and INCLUDE EXTERNAL HEADER > > In Memory it appears it picks the ASCII file, but not a blob > > intel/cpu/baytrail/microcode/M0130679901.h > > 0x00000001, /* Header Version */ > 0x00000901, /* Patch ID */ > 0x04212014, /* DATE */ > 0x00030679, /* CPUID */ > 0x69c4e6f1, /* Checksum */ > 0x00000001, /* Loader Version */ > 0x00000001, /* Platform ID */ > 0x0000cbd0, /* Data size */ > 0x0000cc00, /* Total size */ > 0x00000000, /* reserved */ > 0x00000000, /* reserved */ > 0x00000000, /* reserved */ > > Help me out in understanding this issue > > Regards > Ranga > > >

1 0

Re: [coreboot] SPI controller and Lock bits
by Peter Stuge 02 Oct '18

02 Oct '18

Sam Kuper wrote: > > But... > > there are technical pitfalls that leave the same problem for a momentary > > switch: Unless you use real custom chips, you'll have to use the access > > protection current chips support and in the case of SPI NOR flashes > > there usually is no simple on/off signal that tells the chip to deny > > writes. Usually, you only signal it to protect its write-protection > > configuration which you could forget to set correctly after flashing > > too. > > Does this mean that Peter Stuge's suggestion to (de-)solder a typical > SPI flash chip's write-protect pin was erroneous? Indeed soldering the WP#-pin to ground is not sufficient to disable writes on any and every flash chip, but for chips where writes *can* be disabled electrically it is the key step that overrides software. Many flash chips support a write enable policy for parts and/or all of the chip. (See status register/block protect bits in flash chip data sheets.) The WP#-pin usually controls whether software is allowed to change that policy. If the WP#-pin is connected to ground then the policy can only be changed from write-enable to write-disable, but the other way around requires disconnecting WP# from ground first. (That's what a switch would do.) It is worth noting (I think I mentioned it in that talk) that not all chips store the policy in non-volatile memory - only some do! Some flash chips forget the write-protect policy on reset, meaning that the WP#-pin has no effect from reset until a software-issued command sets a write-protect policy. That's potentially a problem if something can access the flash chip before the x86 root-of-trust runs. //Peter

1 0

Re: [coreboot] SPI controller and Lock bits
by Martin Kepplinger 02 Oct '18

02 Oct '18

Am 26.09.2018 01:30 schrieb Youness Alaoui: > 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. > I might be wrong, but since Heads already authenticates to you via TOTP, this wouldn't really add extra security, wouldn't it?

2 3

Re: [coreboot] SPI controller and Lock bits
by Nico Huber 02 Oct '18

02 Oct '18

Am 02.10.18 um 11:53 schrieb Sam Kuper: > On 01/10/2018, Youness Alaoui <kakaroto(a)kakaroto.homelinux.net> wrote: >>> [...] Youness and others at Purism: if you are reading this, please do >>> spec a momentary switch to control flashing on future Librems. Your >>> security-conscious users will thank you for it. >> >> Yes, I already suggested it for the next iteration. > > Great! > >> It wouldn't be a switch though, but rather a low profile 90-degrees >> jumper on the motherboard. > > This seems to imply that each time a Librem user wants to internally > flash the ROM, she would have to: > > - power down the laptop(?); > - implement ESD precautions; > - remove the half a dozen or so tiny bottom case screws, without > losing them, and without stripping their heads or threads or threaded > inserts; > - remove the bottom case; > - move a tiny motherboard jumper to "write-enable", without losing it; > - power up the laptop with the bottom case off(?); > - run FlashROM (or equivalent); > - power down the laptop again(?); > - move the tiny motherboard jumper to "write-protect", without losing it; > - push-fit the bottom case correctly; > - insert the half a dozen or so tiny bottom case screws, without > losing them, and without stripping their heads or threads or threaded > inserts; > - power the laptop back up(?). > > Surely, having a momentary switch next to the existing kill switches > would be *much* more user-friendly! With such a switch, such a user > would just have to: > > - hold the switch down while starting Flashrom (or equivalent); > - release the switch and let the flashing process finish. tldr; whether the effort to disable write protection is reasonable or not depends on what you want to write protect. You two might have different kinds of updates in mind. You don't need a switch for every update. With a read-only root of trust, for instance, that is secured by the switch or jumper or whatever, you could still update everything else with software only. That root of trust could either verify a signature of the following firmware parts (like vboot does) or start a measuring chain or (ideally) do both. Separating functional updates from those that change platform-ownership is a key feature of vboot. Without such separation, you'll either make owning too easy or updating too hard. >> As for your question earlier about someone forgetting it. I would >> assume that it would be easy to have the Heads menu show a big warning >> to the user if it's left unprotected > > Your assumption fails against a BadHeads attack. You need to tamper more than just HEADS, otherwise the attestation of the firmware (e.g. via TOTP or a Librem Key) would fail. So BadHeads seems to be the wrong name here, but I understand your concerns. But... there are technical pitfalls that leave the same problem for a momentary switch: Unless you use real custom chips, you'll have to use the access protection current chips support and in the case of SPI NOR flashes there usually is no simple on/off signal that tells the chip to deny writes. Usually, you only signal it to protect its write-protection configuration which you could forget to set correctly after flashing too. What I'm trying to show here is that there is no simple solution that can be implemented in a single spot like putting a switch next to the existing kill switches. One shouldn't rush to implement new schemes that might seem better (compared to the state of the art, which is vboot, imho). If one wants to enhance the security of their next batch of laptops, implementing something compatible to what is already there and has itself proven to work would be a good approach (and it seems to me that is what Youness has in mind). Also, Sam, you seem to be pushing for a hardware addition that suits your own threat model (which I don't know). I can only assume that you would only want to install updates that you just compiled yourself. But that's not everybody's use case. Nico

2 1

Re: [coreboot] SPI controller and Lock bits
by Sam Kuper 02 Oct '18

02 Oct '18

On 01/10/2018, Youness Alaoui <kakaroto(a)kakaroto.homelinux.net> wrote: >> [...] Youness and others at Purism: if you are reading this, please do >> spec a momentary switch to control flashing on future Librems. Your >> security-conscious users will thank you for it. > > Yes, I already suggested it for the next iteration. Great! > It wouldn't be a switch though, but rather a low profile 90-degrees > jumper on the motherboard. This seems to imply that each time a Librem user wants to internally flash the ROM, she would have to: - power down the laptop(?); - implement ESD precautions; - remove the half a dozen or so tiny bottom case screws, without losing them, and without stripping their heads or threads or threaded inserts; - remove the bottom case; - move a tiny motherboard jumper to "write-enable", without losing it; - power up the laptop with the bottom case off(?); - run FlashROM (or equivalent); - power down the laptop again(?); - move the tiny motherboard jumper to "write-protect", without losing it; - push-fit the bottom case correctly; - insert the half a dozen or so tiny bottom case screws, without losing them, and without stripping their heads or threads or threaded inserts; - power the laptop back up(?). Surely, having a momentary switch next to the existing kill switches would be *much* more user-friendly! With such a switch, such a user would just have to: - hold the switch down while starting Flashrom (or equivalent); - release the switch and let the flashing process finish. > As for your question earlier about someone forgetting it. I would > assume that it would be easy to have the Heads menu show a big warning > to the user if it's left unprotected Your assumption fails against a BadHeads attack. > Right now, if you boot into linux while ignoring tampering, you get > your ttys in red, as a huge and very visible warning. Only in the absence of BadHeads. > Also, yes Sam, you did understand me perfectly, thanks! Great! :)

1 0

Re: [coreboot] SPI controller and Lock bits
by Nico Huber 02 Oct '18

02 Oct '18

Am 28.09.18 um 03:20 schrieb Prasun Gera: >> The problem is we want to allow users to update their flash and >> coreboot doesn't have a "flash update utility" integrated, so it has >> to happen in the payload, which is why coreboot needs to not lock >> anything then let the payload do the locking for us instead. Heads is >> the linux-based payload we're using, and the idea is that Heads would >> lock the flash before it actually boots any OS (from HDD or from USB), >> this way you can only update your flash from within Heads itself and >> Heads will ensure that the image you're trying to flash is properly >> signed, or that you authenticate first before it would allow you to do >> that (prevents someone from booting into a live USB and flash a >> malicious bios). >> > > This is a pretty useful feature, and it would be nice if it weren't tied to > heads (or any payload for that matter). What about tianocore's capsule > update mechanism, as well as stuff like fwupd ? Any way to have something > like a common solution ? IIRC, HEADS already reuses a lot of common software, e.g. PGP for sig- natures, flashrom for flashing. So the bulk of the implementation is not tied to a specific payload. Actually, we use a similar scheme and (lib)flashrom in our payload for years. I guess the only thing missing for a common solution would be a scheme or configuration file format to discover the update. And there is also vboot. Which is already implemented in coreboot and might even provide better security. It's not tied to any specific pay- load. Nico

1 0

Re: [coreboot] SPI controller and Lock bits
by Nico Huber 01 Oct '18

01 Oct '18

On 9/27/18 10:29 PM, Youness Alaoui wrote: > Thanks everyone for the responses. > So far my understanding on the task at hand is : > - Add a CONFIG to decide if we set FLOCKDN or not (and one to decide > if we lock it on the resume path?) Maybe no config at all, see discussion of PRR34_LOCKDN below. But if, then only one config, IMO: On the resume path FLOCKDN should always be set. > - Remove the chipset_lockdown devicetree config and change the code to > always assume it's LOCKDOWN_COREBOOT (this applies to all platforms, > right?) Yes, unless somebody objects. Please make sure to add the right reviewers to this patch. I expect some resistance. > - remove the call to fast_spi_pr_dlock() and fix the comment above > that function to be more accurate Please also check the tree for code that sets PRRs. IIRC, it is used somewhere to protect the MRC cache. I would set the discrete lock directly after writing the region. > - Add .config CONFIG options or maybe optional devicetree configs for > how to setup the registers so coreboot can prepare them (due to the > resume path) ? Hmm, I would add Kconfig options for this as well. I you want to match the configuration of your payload, it definitely doesn't belong into the devicetree. Note that "prepare" also implies to lock them on the resume path. >> AIUI, FLOCKDN always locks the PRRs. > Actually from what I can see, the FLOCKDN will lock a few registers, > among which it will lock the "discrete PR locks" register, and it will > lock the PR 0, 1 and 2, but there's also a PRR34_LOCKDN bit to > separately lock the PRR 3 and 4. So technically, I could leave FLOCKDN > set, and in the payload, just set protected range in PRR3 or PRR4, > then set the PRR34_LOCKDN. Unfortunately, I can't do that because the > PRR3 and 4 were already locked with the discrete lock register (if I > remove the call to fast_spi_pr_dlock(), it should be fine for my needs > though I think, since you said swseq would also fail for protected > ranges). Ah, that PRR34_LOCKDN was only introduced with SKL. Didn't know it or at least didn't remember it. In this case it seems best to always set FLOCKDN in coreboot. The payload can then still protect additional regions with PRR3/4. On the resume path, coreboot would set both FLOCKDN and PRR34_LOCKDN, right? >> Also note that swseq is not an option anymore since Skylake (IIRC, the >> ME protects the flash-cycle go bit in its default configuration). With >> only hwseq, you can only access the flash chip's first status register >> which makes many security features unusable. So we have to rely on the >> protected regions :-/ I hope Intel is going to fix that for future plat- >> forms (or with an ME update if that could add more hwseq commands). > > Well, I saw the opmenu/optypes/etc.. registers still being set in > skylake (their offsets were not in the datasheet though), so I figured > swseq is still there, just undocumented. It might work on systems > where the ME is disabled. I'd have to test. I was thinking of using > swseq and add the write-register-2 opcode and use it to set SPR1 and > lock the entire flash until it gets power cycled. I don't know if that > would work during suspend, but if it does, it might help with the > resume path at least (but would prevent updating flash after a reboot > and would force user to shut down and boot). I guess I have some > trial-error to do. The tricky part is to get access to the flash chip's second status register. I couldn't figure any way to do that with SKL (this cost me some weeks of work once because FSP also locked empty flash pro- tection). > Actually, if status register remains the same through a > reboot/suspend/resume, and swseq doesn't work on skylake at all, I > could just set the protect bits and prevent writing to status register > on resume path. I don't understand, is there a lock to prevent status register writes with hwseq? Also I though, you can't disable these status register bits w/o a reset. Whether the flash chip is reset, depends on your board design and power sequencing ofc. > >> One way would be to let coreboot decide, e.g. prepare the configuration >> and don't lock it, and let the payload lock. The payload could validate >> this configuration before locking (and issue a warning if coreboot >> didn't set the expected bits). > > Thanks, that's a good idea, I forgot about the suspend/resume case. > This implies I need coreboot to know about what config the payload > will want to set. I'm not sure if that should go into a CONFIG or a > devicetree config. Since it might be user-configured, it makes more > sense for it to go into .config, right ? Yes, Kconfig seems to be the right place. Nico

2 1

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 October 2018