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
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
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
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
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
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
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
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.
>>>
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
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
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*
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
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.
>
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
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
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
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
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!
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
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
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,
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
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
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
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
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
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
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
>>
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
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
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
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
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:
>
>
> 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
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
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
"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
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
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
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
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
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
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
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
44 matches
Mail list logo
