<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2017-06-30 19:46 GMT+02:00 ron minnich <span dir="ltr"><<a href="mailto:rminnich@gmail.com" target="_blank">rminnich@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">The only question that has been raised: are we losing an essential security guarantee since flash is writeable in this kernel-based "SMM"? The big question is whether we're opening up the possibility of firmware getting changed, once the kernel is our "smm mode". Is there a reasonable mitigation we could use in the SMM handler before we trampoline back up to the kernel?</div></blockquote><div>To expand on Trammell's comment, FILO has code to work around a similar issue on some older AMD chipsets: There, you can lock down the chipset's flash write capability, only to see it circumvented by manual SPI commands to write to flash. The solution is to tell the SPI flash itself to go read-only: <a href="https://review.coreboot.org/cgit/filo.git/tree/drivers/sb600.c#n1204">https://review.coreboot.org/cgit/filo.git/tree/drivers/sb600.c#n1204</a></div><div><br></div><div>If you're certain that you don't need any more flash writes (for a _long_ time - I believe that one even survived cold resets), that could be another defensive layer.</div><div><br></div><div><br></div><div>Patrick</div></div>-- <br><div class="gmail_signature">Google Germany GmbH, ABC-Str. 19, 20354 Hamburg<br>Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg<br>Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle</div>
</div></div>