Re: [coreboot] SPI controller and Lock bits
On Wed, Oct 17, 2018 at 9:42 AM R S wrote: > > Yes, thanks Youness for all the hard work and research. You provided an > exceptional service. I enjoyed your rants and explanations both on Purism's > blog and here. Hopefully Purism can fill that void you are leaving behind. > Thanks! I had a lot of fun, and this community is really great! I hope we still get to work together again in the future and cross paths! > On Tue, Oct 16, 2018 at 7:45 PM Sam Kuper wrote: >> >> Hi Youness, >> >> On 15/10/2018, Youness Alaoui wrote: >> > One thing to note is that this week will be my last week at Purism as >> > I'm going on sabbatical for a few months, and I may or may not (most >> > likely won't) come back to Purism in a few months. >> >> Thank you for your efforts to make Coreboot work on the Librems, and >> for the enthusiasm you displayed here in the mailing list and on the >> Purism blog. >> >> Although I might have sounded critical on occasion, this was never >> personal; it was always out of a concern to avoid missing >> opportunities to achieve the most secure and privacy-protecting >> machines available within the constraints of the hardware and the >> business model. I.e. my "criticisms" were always intended to be >> constructive. I hope that they did not form any part of your decision >> to take a break from Purism, and if they did, I apologise. >> >> I wish you a good sabbatical, in any case. >> Thanks! I understand that the criticism was never personal, and I think you all were justified in being critical as well, but then things started to change for the better in purism and it took time for people here (understandably) to see that the change was not just smoke and mirrors. I hope that with me gone, they'll find a good replacement and they'll continue working with the coreboot community and keep moving forward, instead of backward. No, you or anyone else's criticism here had zero part in my decision to leave. On the contrary, I really enjoyed working with the coreboot community, you're all very welcoming, so thanks for that! I'm leaving because I'm feeling close to a burnout, and I don't want to get stuck in one, so I dropped both Purism and a second client I had, in order to concentrate on my health and well being. The reason I might not be coming back to Purism in the future is because they have a new contract for employees/contractors which I disagree with and I'm not ready to sign. It's still a draft though so if the feedback is taken into consideration and lawyers don't reject the feedback and the final version of the contract is acceptable to me, then I might come back. We'll see what happens! :) >> >> > @Sam >> > for 90% of the users, they would either : >> > - never [flash the ROM] >> > - only do it when a new update is released and interests them, i.e: >> > once or twice a year. >> > So [...] it would be far >> > from annoying to users since most won't care or notice that all that >> > is needed, and if they do, they won't care to have to do it so rarely. >> >> I fear that even performed rarely, it might be beyond some users' >> abilities. But... >> Yeah, it might make someone not update if they realize they need to do that, but I guess if they'd only need to do it in order to break the root of trust and overwrite the bootblock or whatever, then that might be good. Either way, it's better than having the WP# hard wired to VCC as it is right now. >> > It will however, especially with cover-opening protections (either >> > using glitter/whatever methods on screws to notice if they'd been >> > opened, or with an EC handling a cover switch notification), that >> > could be very helpful to increase their security. >> >> ... I agree that making it tamper-evident is indeed potentially valuable. >> >> >> >> Your assumption fails against a BadHeads attack. >> > Yes indeed, I wrote a proof of concept which was a Heads that would >> > extend PCRs with the same values that coreboot did (and have a >> > coreboot with measured boot disabled) and it passed the TOTP >> > authentication. >> >> Many thanks for confirming this to the mailing list. I was hoping to >> write and somehow disseminate (e.g. to the Heads developers) a POC >> myself, but I'm glad to be spared that need. >> >> If you could send your POC to the Heads team for integration into the >> test suite, that would be great. This flaw in Heads needs to be fixed >> (if it hasn't already been). Having the POC in the test suite would >> also help to detect future regressions, once the issue is fixed (if it >> *can* be fixed). >> Yeah, I did that a few months ago, the PoC is rather simple but would be hard to have in a test suite, I'm not sure. Basically, I did 'cbmem -c | grep -i extend" to get the log which says "extending PCR with ", then I rebuilt coreboot and disabled MEASURED_BOOT, then in head's init script I just added the lines : tpmcli pcr extend -h (more or less, can't remember the name of the command or what arguments it needed..
Re: [coreboot] SPI controller and Lock bits
Yes, thanks Youness for all the hard work and research. You provided an exceptional service. I enjoyed your rants and explanations both on Purism's blog and here. Hopefully Purism can fill that void you are leaving behind. On Tue, Oct 16, 2018 at 7:45 PM Sam Kuper wrote: > Hi Youness, > > On 15/10/2018, Youness Alaoui wrote: > > One thing to note is that this week will be my last week at Purism as > > I'm going on sabbatical for a few months, and I may or may not (most > > likely won't) come back to Purism in a few months. > > Thank you for your efforts to make Coreboot work on the Librems, and > for the enthusiasm you displayed here in the mailing list and on the > Purism blog. > > Although I might have sounded critical on occasion, this was never > personal; it was always out of a concern to avoid missing > opportunities to achieve the most secure and privacy-protecting > machines available within the constraints of the hardware and the > business model. I.e. my "criticisms" were always intended to be > constructive. I hope that they did not form any part of your decision > to take a break from Purism, and if they did, I apologise. > > I wish you a good sabbatical, in any case. > > > > @Sam > > for 90% of the users, they would either : > > - never [flash the ROM] > > - only do it when a new update is released and interests them, i.e: > > once or twice a year. > > So [...] it would be far > > from annoying to users since most won't care or notice that all that > > is needed, and if they do, they won't care to have to do it so rarely. > > I fear that even performed rarely, it might be beyond some users' > abilities. But... > > > It will however, especially with cover-opening protections (either > > using glitter/whatever methods on screws to notice if they'd been > > opened, or with an EC handling a cover switch notification), that > > could be very helpful to increase their security. > > ... I agree that making it tamper-evident is indeed potentially valuable. > > > >> Your assumption fails against a BadHeads attack. > > Yes indeed, I wrote a proof of concept which was a Heads that would > > extend PCRs with the same values that coreboot did (and have a > > coreboot with measured boot disabled) and it passed the TOTP > > authentication. > > Many thanks for confirming this to the mailing list. I was hoping to > write and somehow disseminate (e.g. to the Heads developers) a POC > myself, but I'm glad to be spared that need. > > If you could send your POC to the Heads team for integration into the > test suite, that would be great. This flaw in Heads needs to be fixed > (if it hasn't already been). Having the POC in the test suite would > also help to detect future regressions, once the issue is fixed (if it > *can* be fixed). > > If it hasn't yet been fixed... Thinking aloud: as a community, we need > to find a way (or else, determine that it really is impossible) to > achieve robust mutual authentication between PC and user, with just an > SPI ROM and a boot disk and a TPM and a TOTP/challenge-response token. > Some kind of formal verification might be in order. > > > > That's something that other possible solutions would > > try to mitigate (such as vboot I think). > > In the open world, vboot does seem to be the state of the art. > > Apple's T2 chip might also mitigate against this sort of thing, > although it does not authenticate to the user via TOTP: the check is > implicit rather than explicit. I may be wrong, though. Public > documentation seems to be scarce. > > > >> it would be great if Purism could be > >> sure not only to spec, but also to list on the Librem specification > >> pages on the website, a SPI flash ROM chip that *does* obey its > >> write-protect pin regardless of firmware. Thanks :) > > I didn't realize that "some chips don't obey the write-protect pin", > > but rather my understanding is that the write protect pin is there to > > say "the protected blocks are protected/not-protected according to > > hardware. > > The SPI flash (according to the datasheets I've read) can protect > > regions either with "don't protect" or "protected by WP#" or > > "protected until power-cycle". > > The status register bits can be written to either as volatile or > > non-volatile (for non volatile, you need another command iirc, and you > > can't do it with hardware sequencing, same for the 'protect until > > power cycle', which also needs to write to status-register-2 which > > can't be done with hardware sequencing either). > > So, really, a flash rom chip does obey its WP pin, it just depends on > > how it's set. > > Thanks for this. I clearly need to spend more time reading data sheets > and running tests on SPI flash ROM chips. > > All best, > > Sam > > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot > -- Tech III * AppControl * Endpoint Protection * Server Maintenance Buncombe County Schools Technology Department Network Group
Re: [coreboot] SPI controller and Lock bits
Youness Alaoui wrote: > So, really, a flash rom chip does obey its WP pin, it just depends > on how it's set. For all flash with non-volatile status register the WP pin is irrelevant from reset until software (in same write-enabled flash) writes block protection into the status register. (Only then does the WP pin matter.) The later that status register write happens the more time there is for anything with access to the SPI bus to write to the flash. //Peter -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
Hi Youness, On 15/10/2018, Youness Alaoui wrote: > One thing to note is that this week will be my last week at Purism as > I'm going on sabbatical for a few months, and I may or may not (most > likely won't) come back to Purism in a few months. Thank you for your efforts to make Coreboot work on the Librems, and for the enthusiasm you displayed here in the mailing list and on the Purism blog. Although I might have sounded critical on occasion, this was never personal; it was always out of a concern to avoid missing opportunities to achieve the most secure and privacy-protecting machines available within the constraints of the hardware and the business model. I.e. my "criticisms" were always intended to be constructive. I hope that they did not form any part of your decision to take a break from Purism, and if they did, I apologise. I wish you a good sabbatical, in any case. > @Sam > for 90% of the users, they would either : > - never [flash the ROM] > - only do it when a new update is released and interests them, i.e: > once or twice a year. > So [...] it would be far > from annoying to users since most won't care or notice that all that > is needed, and if they do, they won't care to have to do it so rarely. I fear that even performed rarely, it might be beyond some users' abilities. But... > It will however, especially with cover-opening protections (either > using glitter/whatever methods on screws to notice if they'd been > opened, or with an EC handling a cover switch notification), that > could be very helpful to increase their security. ... I agree that making it tamper-evident is indeed potentially valuable. >> Your assumption fails against a BadHeads attack. > Yes indeed, I wrote a proof of concept which was a Heads that would > extend PCRs with the same values that coreboot did (and have a > coreboot with measured boot disabled) and it passed the TOTP > authentication. Many thanks for confirming this to the mailing list. I was hoping to write and somehow disseminate (e.g. to the Heads developers) a POC myself, but I'm glad to be spared that need. If you could send your POC to the Heads team for integration into the test suite, that would be great. This flaw in Heads needs to be fixed (if it hasn't already been). Having the POC in the test suite would also help to detect future regressions, once the issue is fixed (if it *can* be fixed). If it hasn't yet been fixed... Thinking aloud: as a community, we need to find a way (or else, determine that it really is impossible) to achieve robust mutual authentication between PC and user, with just an SPI ROM and a boot disk and a TPM and a TOTP/challenge-response token. Some kind of formal verification might be in order. > That's something that other possible solutions would > try to mitigate (such as vboot I think). In the open world, vboot does seem to be the state of the art. Apple's T2 chip might also mitigate against this sort of thing, although it does not authenticate to the user via TOTP: the check is implicit rather than explicit. I may be wrong, though. Public documentation seems to be scarce. >> it would be great if Purism could be >> sure not only to spec, but also to list on the Librem specification >> pages on the website, a SPI flash ROM chip that *does* obey its >> write-protect pin regardless of firmware. Thanks :) > I didn't realize that "some chips don't obey the write-protect pin", > but rather my understanding is that the write protect pin is there to > say "the protected blocks are protected/not-protected according to > hardware. > The SPI flash (according to the datasheets I've read) can protect > regions either with "don't protect" or "protected by WP#" or > "protected until power-cycle". > The status register bits can be written to either as volatile or > non-volatile (for non volatile, you need another command iirc, and you > can't do it with hardware sequencing, same for the 'protect until > power cycle', which also needs to write to status-register-2 which > can't be done with hardware sequencing either). > So, really, a flash rom chip does obey its WP pin, it just depends on > how it's set. Thanks for this. I clearly need to spend more time reading data sheets and running tests on SPI flash ROM chips. All best, Sam -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
Hi Everyone! Sorry for the 2 weeks late reply, I've read your responses, but I've been too busy and dealing with stuff and haven't had/taken the time to reply but your input was very much appreciated and not ignored! One thing to note is that this week will be my last week at Purism as I'm going on sabbatical for a few months, and I may or may not (most likely won't) come back to Purism in a few months. So this feature will probably be my last coreboot contribution (for a while at least). I'm going to try and reply quickly to some of the comments. @Sam > This seems to imply that each time a Librem user wants to internally flash the ROM, she would have to: Yes, updating the flash would be a relatively complicated process which is ok, because for me and you, sure, we'd update the rom a few times a day/week, but for 90% of the users, they would either : - never do it - only do it when a new update is released and interests them, i.e: once or twice a year. So it's a complicated process (as you've outlined) but it would be far from annoying to users since most won't care or notice that all that is needed, and if they do, they won't care to have to do it so rarely. It will however, especially with cover-opening protections (either using glitter/whatever methods on screws to notice if they'd been opened, or with an EC handling a cover switch notification), that could be very helpful to increase their security. > Your assumption fails against a BadHeads attack. Yes indeed, I wrote a proof of concept which was a Heads that would extend PCRs with the same values that coreboot did (and have a coreboot with measured boot disabled) and it passed the TOTP authentication. That's something that other possible solutions would try to mitigate (such as vboot I think). @Nico: > You two might have different kinds of updates in mind. You don't need a switch for every update. Well, I hadn't thought this through to be honest, but in theory you could still flash early in the boot process (in heads) if the protection bits aren't set on the flash. So using the jumper might only allow flashing within the OS itself. Or maybe if the bootblock locks its own region, maybe setting the jumpre would allow the user to flash a new root of trust only. I suppose that's where vboot comes through, and I've left Kyle to investigate all that (though he says we don't need it, but I'm starting to think he's wrong and I think he could be convinced easily enough, I'll point him to this thread which should do the trick). Anyways, I'm leaving Purism now and going on vacation so I'm not going to bother trying to wrap my head around all that. FYI: What I'm trying to do is to improve the security for current machines, so the discussion on the jumper/etc.. is irrelevant for machines already in the hands of customers. @ Sam : >Youness and others at Purism: it would be great if Purism could be > sure not only to spec, but also to list on the Librem specification > pages on the website, a SPI flash ROM chip that *does* obey its > write-protect pin regardless of firmware. Thanks :) I didn't realize that "some chips don't obey the write-protect pin", but rather my understanding is that the write protect pin is there to say "the protected blocks are protected/not-protected according to hardware. The SPI flash (according to the datasheets I've read) can protect regions either with "don't protect" or "protected by WP#" or "protected until power-cycle". The status register bits can be written to either as volatile or non-volatile (for non volatile, you need another command iirc, and you can't do it with hardware sequencing, same for the 'protect until power cycle', which also needs to write to status-register-2 which can't be done with hardware sequencing either). So, really, a flash rom chip does obey its WP pin, it just depends on how it's set. On Fri, Oct 5, 2018 at 6:14 AM Nico Huber wrote: > > Hi, > > Am 05.10.18 um 08:39 schrieb Martin Kepplinger: > > is there already a gerrit change you are working on this? Do plan to > > support / test > > a X230 flash chip's lock bits? > > * MX25L6406E/MX25L6408E > > * EN25QH64 > > * MX25L3206E > > not about this request in particular but such flash-chip features in > general: IMO, the best solution is to implement these in (lib)flashrom > and integrate that into coreboot. I wouldn't say that it's wasted time > to implement it in coreboot directly. But, in the long run, taking > shortcuts or maintaining redundant implementations will slow the pro- > ject down overall. > > Nico > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
Hi, Am 05.10.18 um 08:39 schrieb Martin Kepplinger: > is there already a gerrit change you are working on this? Do plan to > support / test > a X230 flash chip's lock bits? > * MX25L6406E/MX25L6408E > * EN25QH64 > * MX25L3206E not about this request in particular but such flash-chip features in general: IMO, the best solution is to implement these in (lib)flashrom and integrate that into coreboot. I wouldn't say that it's wasted time to implement it in coreboot directly. But, in the long run, taking shortcuts or maintaining redundant implementations will slow the pro- ject down overall. Nico 0xBD56B4A4138B3CE3.asc Description: application/pgp-keys -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
Am 01.10.2018 23:38 schrieb Youness Alaoui: On Sat, Sep 29, 2018 at 12:21 PM Nico Huber wrote: 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. Ok, this is already done, but I want to finish/test my work before I send for review and I might not have time until the end of the week. > - 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. Ok, thanks, will do. Note: I've also changed the fast_spi_pr_dlock() function to take 5 u8 arguments to allow the caller to lock each prr individually instead of being an all or nothing. > - 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. Yeah, so far, the KConfigs I added are : FAST_SPI_LOCK_REGISTERS FAST_SPI_LOCK_REGISTERS_ON_RESUME FAST_SPI_LOCK_PRR34_REGISTERS FAST_SPI_LOCK_PRR34_REGISTERS_ON_RESUME FAST_SPI_PRR3_REGISTER (hex value) FAST_SPI_PRR4_REGISTER (hex value) This way, a user can lock/unlock the register (since it affects more than just the PRRs) and they can override/set the PRR3 and PRR4 values and decide whether to lock them or not or only on resume, etc.. I think those should be enough for most use cases and it's enough for what I need. >> 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? On resume, even if coreboot sets them, the PRRs need to be filled, which is why I also added the hex value of the PRR in the KConfig. I also want to keep FLOCKDN unlocked, so Heads can set the write protect bits in the flash then prevent writing to the status register via hwseq before locking it with FLOCKDN. >> 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). Only way I see is through swseq, but you say it doesn't work because of the ME. I'd have to
Re: [coreboot] SPI controller and Lock bits
On 10/3/18 12:31 AM, Sam Kuper wrote: > On 02/10/2018, Nico Huber wrote: >> Am 02.10.18 um 13:48 schrieb Sam Kuper: >>> On 02/10/2018, Nico Huber wrote: 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-without-physical-access/3786/3 >>> >>> 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-without-physical-access/3786/4 >> >> 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. > > The putative attack bypasses the measuring. As such, I can't see why > it makes any difference whether the measuring starts early (in > Coreboot), or late (in Heads). Sorry if I'm misunderstanding something > basic. Sorry, we might talk past each other here. I was talking about type 2. attacks (in your forum post). But if you consider type 1. and can just skip the attestation, you are right, the measuring doesn't matter any more. But there are other means to detect this (e.g. a TPM sealed disk- encryption key; if you can't boot anymore, you'll notice). About type 2.: To me HEADS is a coreboot payload that runs after core- boot. If the measuring starts in coreboot, you have to tamper coreboot which is "more than just HEADS" (in my terms). Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
On 02/10/2018, Nico Huber wrote: > Am 02.10.18 um 13:48 schrieb Sam Kuper: >> On 02/10/2018, Nico Huber wrote: >>> 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. In principle, I agree. I was just trying to clarify the reason for my choice of earlier comments. >>> 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-without-physical-access/3786/3 >> >> 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-without-physical-access/3786/4 > > 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. The putative attack bypasses the measuring. As such, I can't see why it makes any difference whether the measuring starts early (in Coreboot), or late (in Heads). Sorry if I'm misunderstanding something basic. >>> 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_hardware_and_choosing_a_goodbios_-_peter_stuge#webm > > 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. On 02/10/2018, Peter Stuge wrote: > 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. You are both correct that I was assuming a chip that obeys the write-protect pin regardless of the firmware. I would be surprised if Purism ordered their motherboards to be built with chips of which that is not true, but perhaps that was unduly optimistic of me. I have not attempted to check (yet). Thank you both for your informative replies :) Youness and others at Purism: it would be great if Purism could be sure not only to spec, but also to list on the Librem specification pages on the website, a SPI flash ROM chip that *does* obey its write-protect pin regardless of firmware. Thanks :) -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
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 -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
Am 02.10.18 um 14:31 schrieb Martin Kepplinger: > Am 02.10.2018 13:51 schrieb Nico Huber: >> Am 02.10.18 um 13:01 schrieb Martin Kepplinger: >>> 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? >> >> This is the most common misunderstanding about a measured boot. If you >> don't have separate hardware that starts the measuring (usually you let >> the firmware measure itself), you need a firmware part that starts the >> measuring and is read-only for an attacker (referred to as read-only or >> static `root of trust`). Otherwise you leave the decision what to mea- >> sure to the attacker (and he can choose to measure the original software >> before his tampering instead of the running program, and TOTP will still >> work flawlessly). >> >> So it's the other way around: without this, TOTP doesn't provide any >> security at all. >> >> Nico > > thanks! My high-level understanding was that Heads uses the > TPM as said "root of trust" and the TOTP shared secret will be lost > in any changed firmware. > > So a changed firmware would basically need to write PCRs to the TPM > in order for the "PCR matching" to succeed and release the valid TOTP > secret. Be it by measuring and remembering the original firmware or > somehow else. Correct. > > I don't know why, but I've though that the TPM would prevent a modified > firmware to do this -.- Alas, they can't (on their own). OTOH, TPMs are already too complex for real security IMO. Adding more features would just weaken it further. > > http://osresearch.net/Keys is quite good, but maybe we'd need a wiki > with real setups compared, or something. I fear that I'm not the only one > who's confused with trusted boot stuff. > > As a quick fix, couldn't Heads offer to create an image with the IFD > re-locked, I don't understand why you would unlock the IFD in the first place. But anyway, the usual lock settings only protect the IFD itself and the ME firmware, not the BIOS region for the host firmware (e.g. coreboot). Also, if you'd protect the BIOS region too, coreboot couldn't write to the flash itself anymore which would prevent suspend-to-RAM to work; but maybe you are too security concerned for that anyway ;) > in order to force (yourself) to hardware-flashing. Has this been discussed? Ofc, it has. And there is even an option in coreboot to lock the flash (after coreboot is done with it). But this is only available for few platforms (Sandy/Ivy Bridge IIRC; config LOCK_SPI_FLASH_RO). Nico 0xBD56B4A4138B3CE3.asc Description: application/pgp-keys -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
Am 02.10.2018 13:51 schrieb Nico Huber: Am 02.10.18 um 13:01 schrieb Martin Kepplinger: 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? This is the most common misunderstanding about a measured boot. If you don't have separate hardware that starts the measuring (usually you let the firmware measure itself), you need a firmware part that starts the measuring and is read-only for an attacker (referred to as read-only or static `root of trust`). Otherwise you leave the decision what to mea- sure to the attacker (and he can choose to measure the original software before his tampering instead of the running program, and TOTP will still work flawlessly). So it's the other way around: without this, TOTP doesn't provide any security at all. Nico thanks! My high-level understanding was that Heads uses the TPM as said "root of trust" and the TOTP shared secret will be lost in any changed firmware. So a changed firmware would basically need to write PCRs to the TPM in order for the "PCR matching" to succeed and release the valid TOTP secret. Be it by measuring and remembering the original firmware or somehow else. I don't know why, but I've though that the TPM would prevent a modified firmware to do this -.- http://osresearch.net/Keys is quite good, but maybe we'd need a wiki with real setups compared, or something. I fear that I'm not the only one who's confused with trusted boot stuff. As a quick fix, couldn't Heads offer to create an image with the IFD re-locked, in order to force (yourself) to hardware-flashing. Has this been discussed? thanks martin -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
Am 02.10.18 um 13:48 schrieb Sam Kuper: > On 02/10/2018, Nico Huber wrote: >> Am 02.10.18 um 11:53 schrieb Sam Kuper: >>> On 01/10/2018, Youness Alaoui 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-without-physical-access/3786/3 > > 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-without-physical-access/3786/4 > > 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_hardware_and_choosing_a_goodbios_-_peter_stuge#webm 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 0xBD56B4A4138B3CE3.asc Description: application/pgp-keys -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
Am 02.10.18 um 13:01 schrieb Martin Kepplinger: > 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? This is the most common misunderstanding about a measured boot. If you don't have separate hardware that starts the measuring (usually you let the firmware measure itself), you need a firmware part that starts the measuring and is read-only for an attacker (referred to as read-only or static `root of trust`). Otherwise you leave the decision what to mea- sure to the attacker (and he can choose to measure the original software before his tampering instead of the running program, and TOTP will still work flawlessly). So it's the other way around: without this, TOTP doesn't provide any security at all. Nico 0xBD56B4A4138B3CE3.asc Description: application/pgp-keys -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
On 02/10/2018, Nico Huber wrote: > Am 02.10.18 um 11:53 schrieb Sam Kuper: >> On 01/10/2018, Youness Alaoui 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?). >>> 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-without-physical-access/3786/3 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-without-physical-access/3786/4 If I was mistaken about this, then I apologise. > 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_hardware_and_choosing_a_goodbios_-_peter_stuge#webm > 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). I agree about not leaping to conclusions. Sorry if it seemed that this is what I was doing. A couple of posts back, I did try to make clear that I believe security improvements in the firmware will be valuable (albeit probably not sufficient; i.e. a hardware switch of some kind would also be helpful). > Also, Sam, you seem to be pushing for a hardware addition that suits > [wanting] to install updates that you just compiled yourself. > But that's not everybody's use case. Whether the context is a solo user, a small organisation, or a large one, it seems to me that upgrading at least *some* parts of the firmware should require physical access. As for how much effort it should be to gain that physical access, I agree with your implicit point that if changing the root of trust is separated from upgrading other parts of the firmware, then it may make sense for the former, which should probably be done only rarely, to be effortful (e.g. to require removal of the bottom case, and use of ESD precautions). This would reduce the risk of a passer-by being able to change the root of trust on a laptop that someone has accidentally left running and unlocked for a moment while going to the bathroom or whatever. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
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? -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
Am 02.10.18 um 11:53 schrieb Sam Kuper: > On 01/10/2018, Youness Alaoui 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 0xBD56B4A4138B3CE3.asc Description: application/pgp-keys -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
On 01/10/2018, Youness Alaoui 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! :) -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
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 0xBD56B4A4138B3CE3.asc Description: application/pgp-keys -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
On Sat, Sep 29, 2018 at 12:21 PM Nico Huber wrote: > > 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. > Ok, this is already done, but I want to finish/test my work before I send for review and I might not have time until the end of the week. > > - 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. > Ok, thanks, will do. Note: I've also changed the fast_spi_pr_dlock() function to take 5 u8 arguments to allow the caller to lock each prr individually instead of being an all or nothing. > > - 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. > Yeah, so far, the KConfigs I added are : FAST_SPI_LOCK_REGISTERS FAST_SPI_LOCK_REGISTERS_ON_RESUME FAST_SPI_LOCK_PRR34_REGISTERS FAST_SPI_LOCK_PRR34_REGISTERS_ON_RESUME FAST_SPI_PRR3_REGISTER (hex value) FAST_SPI_PRR4_REGISTER (hex value) This way, a user can lock/unlock the register (since it affects more than just the PRRs) and they can override/set the PRR3 and PRR4 values and decide whether to lock them or not or only on resume, etc.. I think those should be enough for most use cases and it's enough for what I need. > >> 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? On resume, even if coreboot sets them, the PRRs need to be filled, which is why I also added the hex value of the PRR in the KConfig. I also want to keep FLOCKDN unlocked, so Heads can set the write protect bits in the flash then prevent writing to the status register via hwseq before locking it with FLOCKDN. > > >> 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). Only way I see is
Re: [coreboot] SPI controller and Lock bits
Oh boy, lots of emails to answer! So first, thanks for everyone who shared their input, I very much appreciate it. > I think you can decide what hardware your products include, right? I meant dedicated hardware on the mainboard. Yes, but I'm currently looking for a solution to existing hardware, not for the next laptop Purism produces. And by 'dedicated hardware' I thought you meant only allow users to update their BIOS using an external SPI flasher, which would be impractical of course. > > > > It's not just the part. A single simple part like that has all kinds of > > follow-on effects that are not obvious unless you've been at a company > > which designs and builds consumer electronics. > > Thank you for the perspective. I do understand that changing one > component can affect others. > > Purism isn't a typical laptop company. The addition of hardware > switches, to control webcam, mic and Wi-Fi, is one of the USPs for > their Librem models. These undoubtedly had knock-on effects for the > BOM. Purism was undeterred by that. In that context... > > I'm just asking for one more switch. > > So, 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. It wouldn't be a switch though, but rather a low profile 90-degrees jumper on the motherboard. 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 (I assume there would be a way to detect if WP# is 1/0 through a GPIO (or other method) without being able to use that GPIO to override the WP# value). Right now, if you boot into linux while ignoring tampering, you get your ttys in red, as a huge and very visible warning. Also, yes Sam, you did understand me perfectly, thanks! > > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
On 29/09/2018, ron minnich wrote: > On Sat, Sep 29, 2018 at 1:59 PM Sam Kuper wrote: >> Small momentary switches cost pennies and laptops usually have about a >> hundred of them fitted, of various kinds. (Power on/off/suspend; >> volume up/down; keyboard keys; maybe others.) So, fitting laptops with >> momentary switches is definitely acceptable to manufacturers. > > I'm guessing you don't work in a company that designs or builds laptops :-) True enough. I have worked at a company that designed and built other consumer electronics, though, and spent time with people speccing PCBs and custom silicon. > b/c they agonize over parts like this. I ran into one situation where the > ODM removed a single pulldown to save cost. One little > almost-too-small-to-see part which cost a fraction of a cent. But a laptop > BOM is a consequence of thousands of decisions of this type. > > Nope, the switch is definitely a non-starter, esp. given that there are > solutions that don't require it. > > It's not just the part. A single simple part like that has all kinds of > follow-on effects that are not obvious unless you've been at a company > which designs and builds consumer electronics. Thank you for the perspective. I do understand that changing one component can affect others. Purism isn't a typical laptop company. The addition of hardware switches, to control webcam, mic and Wi-Fi, is one of the USPs for their Librem models. These undoubtedly had knock-on effects for the BOM. Purism was undeterred by that. In that context... I'm just asking for one more switch. So, 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. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
On Sat, Sep 29, 2018 at 1:59 PM Sam Kuper wrote: > Small momentary switches cost pennies and laptops usually have about a > hundred of them fitted, of various kinds. (Power on/off/suspend; > volume up/down; keyboard keys; maybe others.) So, fitting laptops with > momentary switches is definitely acceptable to manufacturers. > I'm guessing you don't work in a company that designs or builds laptops :-) b/c they agonize over parts like this. I ran into one situation where the ODM removed a single pulldown to save cost. One little almost-too-small-to-see part which cost a fraction of a cent. But a laptop BOM is a consequence of thousands of decisions of this type. Nope, the switch is definitely a non-starter, esp. given that there are solutions that don't require it. It's not just the part. A single simple part like that has all kinds of follow-on effects that are not obvious unless you've been at a company which designs and builds consumer electronics. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
On 29/09/2018, ron minnich wrote: > It's not a screw in Chromebooks any more, see vadim's excellent OSFC.io > talk on how it works now. Vadim Bendebury? This talk below? https://osfc.io/talks/google-secure-microcontroller-and-ccd-closed-case-debugging If so, is there a video or audio recording available? Thanks. > I think the momentary switch would not be acceptable to anyone for cost Small momentary switches cost pennies and laptops usually have about a hundred of them fitted, of various kinds. (Power on/off/suspend; volume up/down; keyboard keys; maybe others.) So, fitting laptops with momentary switches is definitely acceptable to manufacturers. > and reliability reasons. Such switches are often rated for ~100,000 cycles. It seems unlikely that any laptop or its owner would live long enough to flash the ROM chip even close to 100,000 times. So, I don't anticipate a reliability problem. > The way chromebooks do the protection now is really well done. I look forward to reading Vadim's slides, and perhaps also to watching or listening to his talk. Thanks for the pointer. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
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 -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
On 9/28/18 1:30 AM, Peter Stuge wrote: > Youness Alaoui wrote: >> avoid any malware writing to the flash > > Just disallow flash writes by the platform. Allow flash writes only > by dedicated hardware (maybe ChromeEC?) which implements a simple and > efficient security protocol. It's not as easy as you might think. You are looking forward to an additional flash chip at least because the ME needs direct access to a SPI flash (you could try to route that through the EC as well, but that would be everything but simple). Then your customers might ask for suspend-to-RAM, for which you need to cache memory-training data somewhere. You can't authenticate this data to the EC. That's solvable too, ofc. But there might be more pitfalls. And I'm not convinced that you'd end up with a simpler solution than your host firmware flipping a bit at the right point in time. > > Looking for a software solution is IMO like Intel trying to secure SMM. No matter if you run it on the EC or the host processor, it will be a software solution. You can make things simpler with a dedicated control- ler, right. But if you succeed still depends on the skills of software developers. ECs can be attacked too (especially if they have a host interface for software updates). Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
It's not a screw in Chromebooks any more, see vadim's excellent OSFC.io
talk on how it works now.
I think the momentary switch would not be acceptable to anyone for cost and
reliability reasons. The way chromebooks do the protection now is really
well done.
On Sat, Sep 29, 2018 at 8:26 AM Nico Huber wrote:
> On 9/28/18 4:18 AM, Sam Kuper wrote:
> > On 28/09/2018, Peter Stuge wrote:
> >> Youness Alaoui wrote:
> >>> avoid any malware writing to the flash
> >>
> >> Just disallow flash writes by the platform. Allow flash writes only
> >> by dedicated hardware (maybe ChromeEC?) which implements a simple and
> >> efficient security protocol.
> >
> > Relevant URL:
> https://www.chromium.org/chromium-os/ec-development#TOC-Write-Protect
>
> This seems to state the opposite of what Peter suggested, i.e. the host
> firmware is responsible of validating the EC firmware('s update) and
> not the other way around. IMHO, a good idea.
>
> Nico
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
On 9/28/18 4:18 AM, Sam Kuper wrote:
> On 28/09/2018, Peter Stuge wrote:
>> Youness Alaoui wrote:
>>> avoid any malware writing to the flash
>>
>> Just disallow flash writes by the platform. Allow flash writes only
>> by dedicated hardware (maybe ChromeEC?) which implements a simple and
>> efficient security protocol.
>
> Relevant URL:
> https://www.chromium.org/chromium-os/ec-development#TOC-Write-Protect
This seems to state the opposite of what Peter suggested, i.e. the host
firmware is responsible of validating the EC firmware('s update) and
not the other way around. IMHO, a good idea.
Nico
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
On 9/27/18 6:24 PM, Lance Zhao 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. AFAIK, EISS is not a configurable option in coreboot atm. And it shouldn't be, IMHO, as it encourages to weaken security. Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
I have been giving Youness's reply some thought. On 29/09/2018, Peter Stuge wrote: > Youness Alaoui wrote: >> On Thu, Sep 27, 2018 at 10:18 PM Sam Kuper wrote: >>> Relevant URL: >>> https://www.chromium.org/chromium-os/ec-development#TOC-Write-Protect >> >> We don't have/use ChromeEC and I think that telling every user that >> they'd need dedicated hardware to update their BIOS makes no sense. > > I think you can decide what hardware your products include, right? I > meant dedicated hardware on the mainboard. I think Youness's point, essentially, was that with: - Heads running from the ROM chip; and - suitable secrets sealed in the TPM; and - additional suitable secrets sealed in a Nitrokey; any additional dedicated hardware on the motherboard would be unnecessary in order to achieve: - a "secure", pre-OS environment in which to upgrade Heads; and - a way to prevent the OS from flashing the ROM. (Youness, please correct me if I misunderstood you.) That is all good stuff, and I want it to be achieved. However, I don't think it goes far enough. I know that several Chromebooks, as described at the URL above, include a hardware switch (typically implemented as a screw or bolt acting as a *latching* SPST switch) that allows ROM flashing to be enabled/disabled. This seems to me a step in the right direction, but I don't think it goes far enough, either. Personally, I would prefer that, in addition to the Heads approach, a hardware switch should be present, but unlike on the Chromebooks it should be a *momentary* switch that stays in the write-protect position by default, and that has to be held in the write-enable position in order for the flashing process to be able to begin. (Essentially, a "dead man's handle" or fail-safe.) This mitigates two potential attack vectors: 1. a user, after she sets her Chromebook-style latching hardware switch to write-enable and flashes the ROM, forgets to set the hardware switch back to write-protect, leaving the ROM vulnerable; 2. a remote attacker finds a way to write a "badHeads" to the ROM from the OS.[1][2][3] >> > > Looking for a software solution is IMO like Intel trying to secure >> > > SMM. >> >> I don't see why that would be true, the software solution is pretty >> simple. You boot, you can write to the flash in a secure environment, > > Intel also considered SMM a secure environment, until they realised > that it isn't. These days I think they consider ME a secure environment. Ouch! It's unkind to liken Heads developers to ME developers... :p - Sam [1] https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-without-physical-access/3786/3 [2] https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-without-physical-access/3786/4 [3] https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-without-physical-access/3786/6 -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
Youness Alaoui wrote: > We don't have/use ChromeEC and I think that telling every user that > they'd need dedicated hardware to update their BIOS makes no sense. I think you can decide what hardware your products include, right? I meant dedicated hardware on the mainboard. > > > Looking for a software solution is IMO like Intel trying to secure SMM. > > I don't see why that would be true, the software solution is pretty > simple. You boot, you can write to the flash in a secure environment, Intel also considered SMM a secure environment, until they realised that it isn't. These days I think they consider ME a secure environment. //Peter -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
On Thu, Sep 27, 2018 at 10:18 PM Sam Kuper wrote: > > On 28/09/2018, Peter Stuge wrote: > > Youness Alaoui wrote: > >> avoid any malware writing to the flash > > > > Just disallow flash writes by the platform. Allow flash writes only > > by dedicated hardware (maybe ChromeEC?) which implements a simple and > > efficient security protocol. > > Relevant URL: > https://www.chromium.org/chromium-os/ec-development#TOC-Write-Protect We don't have/use ChromeEC and I think that telling every user that they'd need dedicated hardware to update their BIOS makes no sense. > > > > Looking for a software solution is IMO like Intel trying to secure SMM. > > Hear, hear! > I don't see why that would be true, the software solution is pretty simple. You boot, you can write to the flash in a secure environment, once you decide you don't need to write to the flash, you lock it until your next reboot. > 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 ? Tianocore is a payload, so tianocore's update mechanism is still about doing the update in the payload.. All heads is going to do is to run a script that calls flashrom (and actually use cbfstool to extract/inject the heads-specific cbfs files into the new image, such as the user's pgp keys for example, before flashing).. so it will have to be tied to heads either way. Heads is the one booting into your OS, so it can read-only lock the entire flash before the user (real or malicious) gets control. The use of heads is already tied in with the use a gpg key (nitrokey, yubikey, librem key), and you'd already need to have the key inserted (and pin valid) before it would give you access to a recovery shell, and the same can be done before it allows the flash to be updated. I hadn't thought of the use case of fwupd (which we're currently adding support for) since it wouldn't be able to flash from the OS, but I think that having the update file deosited in /boot under a specific filename and rebooting would be all that fwupd would need to do, then on the next boot, heads would find the file and suggest to the user to flash it. > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
On 28/09/2018, Peter Stuge wrote: > Youness Alaoui wrote: >> avoid any malware writing to the flash > > Just disallow flash writes by the platform. Allow flash writes only > by dedicated hardware (maybe ChromeEC?) which implements a simple and > efficient security protocol. Relevant URL: https://www.chromium.org/chromium-os/ec-development#TOC-Write-Protect > Looking for a software solution is IMO like Intel trying to secure SMM. Hear, hear! -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
> > > 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 ? -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
Youness Alaoui wrote: > avoid any malware writing to the flash Just disallow flash writes by the platform. Allow flash writes only by dedicated hardware (maybe ChromeEC?) which implements a simple and efficient security protocol. Looking for a software solution is IMO like Intel trying to secure SMM. //Peter -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
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 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 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 wrote: >>> >>> Am 26.09.18 um 22:26 schrieb Lance
Re: [coreboot] SPI controller and Lock bits
"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 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 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@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
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 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@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
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) 0xBD56B4A4138B3CE3.asc Description: application/pgp-keys -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
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. On Wed, Sep 26, 2018 at 7:01 AM Nico Huber wrote: > Am 26.09.18 um 10:50 schrieb Patrick Rudolph: > > 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/ > > Please note this is about having the whole chip protected. But not about > the decision whether or not to lock this configuration. It reminds me of > something, though: If you want to do such configuration in the payload, > both coreboot and payload code/configuration have to be kept in sync > if you have suspend-to-ram. Because coreboot has to do the same confi- > guration as the payload on the resume path (where the payload is not > executed). > > 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). > > Nico > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
Am 26.09.18 um 10:50 schrieb Patrick Rudolph: > 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/ Please note this is about having the whole chip protected. But not about the decision whether or not to lock this configuration. It reminds me of something, though: If you want to do such configuration in the payload, both coreboot and payload code/configuration have to be kept in sync if you have suspend-to-ram. Because coreboot has to do the same confi- guration as the payload on the resume path (where the payload is not executed). 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). Nico 0xBD56B4A4138B3CE3.asc Description: application/pgp-keys -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
Hi Youness, Am 26.09.18 um 01:30 schrieb Youness Alaoui: > 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. the code is flawed, I'm not sure if I noticed during review, probably only when it was too late. It seems to me that these "security guide- lines" have two issues: 1. They are written with UEFI style security in mind (e.g. updates in SMM). 2. They are meant to be understandable for a humble reader and hence can't comprise all the details (like threat models etc.) for real security. They seem to be for getting-a-green-light-in-CHIPSEC security. Not sure how CHIPSEC would react if the individual PRR locks aren't set. But feel free to remove the locking of unset PR registers on any path where we don't set FLOCKDN. > > 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 ? I would prefer to have a single Kconfig option like INTEL_CHIPSET_ LOCKDOWN (sb/intel/common) but for FLOCKDN only. This option for the whole chipset lockdown on older platforms only made sense because the lockdown was done in SMM to allow the payload to call into coreboot. As SMM is not a good idea and reimplementing the whole lockdown in the pay- load isn't either, just skipping flash locking bits seems to be the right way. Please take care that this only affects a clean boot, i.e. not a resume when the payload is not going to be executed. > - 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 ? The current `chipset_lockdown` option is nonsense. 1. during review when I noticed a flaw in the LOCKDOWN_FSP path, the answer was something like "but we set it to coreboot for all boards in the tree". So it seems the author didn't even intend to add an option but just did it because eve- rything else was an option? 2. Having to maintain two variants in core- boot makes it harder to keep it secure. Please just kill this option and all but the LOCKDOWN_COREBOOT path. Then add the Kconfig option men-tioned above on this path. > - 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 ? I would prefer to have the PR registers locked right after they are set, in the same function. Also remove fast_spi_pr_dlock() or at least fix the comment above it, it seems the author didn't understand the meaning of "discrete" in this context. Optionally, if CHIPSEC complains other- wise, set the discrete locks for empty PRRs before setting FLOCKDN. AIUI, FLOCKDN always locks the PRRs. > Once I see a consensus on what's the best way to move forward, I'll > implement it and push it for review. Thank you for looking into this it would be very nice to have this cleaned up. I guess if we do it right, we'll have less code that is more useful. > 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. In the past, we (at secunet) had FLOCKDN always set in the payload just like you plan to do. We also made it the payload's responsibility to set the OPMENU accordingly before setting FLOCKDN. You can have write
Re: [coreboot] SPI controller and Lock bits
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. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] SPI controller and Lock bits
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. 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 ? 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. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
