<div dir="ltr">It's not a screw in Chromebooks any more, see vadim's excellent OSFC.io talk on how it works now.<div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Sep 29, 2018 at 8:26 AM Nico Huber <<a href="mailto:nico.h@gmx.de">nico.h@gmx.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 9/28/18 4:18 AM, Sam Kuper wrote:<br>
> On 28/09/2018, Peter Stuge <<a href="mailto:peter@stuge.se" target="_blank">peter@stuge.se</a>> wrote:<br>
>> Youness Alaoui wrote:<br>
>>> avoid any malware writing to the flash<br>
>><br>
>> Just disallow flash writes by the platform. Allow flash writes only<br>
>> by dedicated hardware (maybe ChromeEC?) which implements a simple and<br>
>> efficient security protocol.<br>
> <br>
> Relevant URL: <a href="https://www.chromium.org/chromium-os/ec-development#TOC-Write-Protect" rel="noreferrer" target="_blank">https://www.chromium.org/chromium-os/ec-development#TOC-Write-Protect</a><br>
<br>
This seems to state the opposite of what Peter suggested, i.e. the host<br>
firmware is responsible of validating the EC firmware('s update) and<br>
not the other way around. IMHO, a good idea.<br>
<br>
Nico<br>
<br>
-- <br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a><br>
<a href="https://mail.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://mail.coreboot.org/mailman/listinfo/coreboot</a><br>
</blockquote></div>