September 2018 - coreboot - mail.coreboot.org

microcode blob or ascii
by galla rao Sept. 28, 2018

Sept. 28, 2018

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] Downloading an archive of the coreboot wiki
by Taiidan＠gmx.com Sept. 28, 2018

Sept. 28, 2018

On 09/15/2018 10:11 AM, Patrick Georgi wrote: > Am Sa., 15. Sep. 2018 um 16:10 Uhr schrieb Taiidan(a)gmx.com <Taiidan(a)gmx.com >> : > >> Would this be the best way to do it? [...] > > wget -r -k -np -p -l 0 http://coreboot.com/wiki > > Maybe not. See https://www.coreboot.org/wikidump/ for more suitable formats. > > > Patrick > Thanks, but are those new? The date says june 2018. And are they are all identical?

2 1

Re: [coreboot] SPI controller and Lock bits
by Prasun Gera Sept. 27, 2018

Sept. 27, 2018

> > > 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 ?

1 0

Re: [coreboot] SPI controller and Lock bits
by Youness Alaoui Sept. 27, 2018

Sept. 27, 2018

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?) - Remove the chipset_lockdown devicetree config and change the code to always assume it's LOCKDOWN_COREBOOT (this applies to all platforms, right?) - remove the call to fast_spi_pr_dlock() and fix the comment above that function to be more accurate - 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) ? Can you please confirm the ones with question marks? Is there some rule on "add as little CONFIG options as possible" ? > 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). On Thu, Sep 27, 2018 at 1:09 PM Dhaval Sharma <dvsharma.work(a)gmail.com> wrote: > > "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. 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). > You can have write opcodes in the menu, they won't work on protected regions. But if you have > a partially protected flash (e.g. vboot), they are still useful. Ok, that's interesting. I was actually thinking of just completely disabling writing to any region, but maybe I can use the PRR instead. > 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. 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. > 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 ? Thanks again, Youness. > > > 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

KCMA-D8 /D16 and xen+bsd
by Jo Sept. 27, 2018

Sept. 27, 2018

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cheers Guys, im currently trying to migrate kmca-d8 servers from libreboot+ debian to coreboot+xen (ideally arch/centos/alpine as host, with openbsd /windows vms). however, i do have a weird bug, resulting in an immediate shutdown / reboot into the payload after decrypting the main partition. There are no error-outputs whatsoever, and i dont have a serial-to usb cable (yet), so i cant get any output from serial console. Has anyone ever tried this setup/ get it to work? Hardware: Mobo: kcma-D8 , CPU: dual Opteron 4284, Ram: 16 or 32 gb KVR16E11/8 . The problem is persistent/reproducible with different kcma-d8 and kgpe-d16, with any os+xen setup we tried so far, also with qubes os. Since im using Qubes on various coreboot devices, it has to be something specific with those 2 boards. Any hints would be greatly appreciated. Jo -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEfey6Nh/HHy+X/4a4nXsEbQ3HzboFAluhJqYACgkQnXsEbQ3H zbo2Sgf7BbetzUqyLA3lRLIf2c6HmB7pIsRdUJDC+7vjjr+BeBAmuETnqTxf2nx1 fhHkdExtrClS17SWl6vvL1be2IJbQwffOALh9vOt+gQ53wUGtVJDTYedvAv9G4eG pYHi34I21eumqNJPTzZoYZBfjHvES6gt/PQ2rrpyg9gD+agAQzABgFqSM84AP92x OodYRJTaF8abKNxs8YA4vHKtd6omKdAmFK1LY2u+b86XfIF3/OFgcthyCk/UL6Xz OCN4lim46zWyjdKPVlmfNsEgjqZFdzxkz+T/ZNmYfLf1eSidiN490vALJMOCQLQU QQVitz30bWkn/iIex1M1LczXIz+40w== =3nxj -----END PGP SIGNATURE-----

2 1

Re: [coreboot] flashrom and 256 MiB S256FL256S
by Nico Huber Sept. 27, 2018

Sept. 27, 2018

Ah, dediprog... you happen to have the one programmer that is hard to support. On 9/27/18 9:49 PM, ron minnich wrote: > hmm, is this useful? > > Found Spansion flash chip "S25FL256S......0" (32768 kB, SPI) on dediprog. > Erasing and writing flash chip... 4-byte address requested but master can't > handle 4-byte addresses. That is expected, native 4-byte instructions are tried first but they are not implemented yet for dediprog. It should fall back to another instruction though. Unless the dediprog resets the chip between in- structions, it should actually work. Though, David seemed to have trouble with that too, I didn't test it myself yet. > Looking for another erase function. Can you please just post the whole log (best taken with -o logfile). Nico

2 1

Re: [coreboot] flashrom and 256 MiB S256FL256S
by ron minnich Sept. 27, 2018

Sept. 27, 2018

Erasing and writing flash chip... Erase/write done. Verifying flash... FAILED at 0x01000000! Expected=0x00, Found=0xff, failed byte count from 0x00000000-0x01ffffff: 0xffc000 Your flash chip is in an unknown state. Please report this on IRC at chat.freenode.net (channel #flashrom) or mail flashrom(a)flashrom.org, thanks! On Thu, Sep 27, 2018 at 12:49 PM ron minnich <rminnich(a)gmail.com> wrote: > hmm, is this useful? > > Found Spansion flash chip "S25FL256S......0" (32768 kB, SPI) on dediprog. > Erasing and writing flash chip... 4-byte address requested but master > can't handle 4-byte addresses. > Looking for another erase function. > > > > On Thu, Sep 27, 2018 at 12:40 PM ron minnich <rminnich(a)gmail.com> wrote: > >> Thanks, let me send you the output I got. I am looking at the code too. >> >> >> >> On Thu, Sep 27, 2018 at 12:29 PM Nico Huber <nico.h(a)gmx.de> wrote: >> >>> Hi Ron, >>> >>> On 9/27/18 8:05 PM, ron minnich wrote: >>> > sadly, they do not work ... >>> >>> what does work? does flashrom detect the chip reliably? >>> What programmer do you use? what is your physical setup? >>> If these patches don't work, I would expect that the failure is not >>> about the flash chip model. >>> >>> Nico >>> >>

1 0

Re: [coreboot] flashrom and 256 MiB S256FL256S
by ron minnich Sept. 27, 2018

Sept. 27, 2018

hmm, is this useful? Found Spansion flash chip "S25FL256S......0" (32768 kB, SPI) on dediprog. Erasing and writing flash chip... 4-byte address requested but master can't handle 4-byte addresses. Looking for another erase function. On Thu, Sep 27, 2018 at 12:40 PM ron minnich <rminnich(a)gmail.com> wrote: > Thanks, let me send you the output I got. I am looking at the code too. > > > > On Thu, Sep 27, 2018 at 12:29 PM Nico Huber <nico.h(a)gmx.de> wrote: > >> Hi Ron, >> >> On 9/27/18 8:05 PM, ron minnich wrote: >> > sadly, they do not work ... >> >> what does work? does flashrom detect the chip reliably? >> What programmer do you use? what is your physical setup? >> If these patches don't work, I would expect that the failure is not >> about the flash chip model. >> >> Nico >> >

1 0

Re: [coreboot] flashrom and 256 MiB S256FL256S
by Nico Huber Sept. 27, 2018

Sept. 27, 2018

Hi Ron, On 9/27/18 8:05 PM, ron minnich wrote: > sadly, they do not work ... what does work? does flashrom detect the chip reliably? What programmer do you use? what is your physical setup? If these patches don't work, I would expect that the failure is not about the flash chip model. Nico

2 1

Re: [coreboot] flashrom and 256 MiB S256FL256S
by ron minnich Sept. 27, 2018

Sept. 27, 2018

sadly, they do not work ... but many thanks for the pointer! On Wed, Sep 26, 2018 at 1:16 PM Angel Pons <th3fanbus(a)gmail.com> wrote: > 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