<div dir="ltr"><div><div><div>I don't know about you, but once I have a minimal working kernel or a coreboot fallback, I never really update them. So having no way to recover them without hardware intervention is fine. The kernel I may recompile, patch, etc would be somewhere else.<br><br></div>The job of this minimal kernel and initrd would just be to kexec the other kernel, and let you recover coreboot if needed.<br><br></div>Having both of them write protected is just fine, if the cmdline used for the kexec is be read from another part of the spi for when you have to add some kernel parameters<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 27, 2016 at 8:09 PM, Trammell Hudson <span dir="ltr"><<a href="mailto:hudson@trmm.net" target="_blank">hudson@trmm.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, Nov 27, 2016 at 07:30:07PM -0500, Charlotte Plusplus wrote:<br>
> [...]<br>
<span class="">> With the amount of flash we have, sharing the kernel and initrd doesn't<br>
> seem like a bad idea.<br>
<br>
</span>The problem is if a bad kernel or initrd is flashed then there is no<br>
way to recover without hardware intervention.  Having a truly minimal<br>
recovery kernel with USB and a spiflash writer makes it possible<br>
to boot into some sort of mode to reocver from that failure.<br>
<br>
For both root of trust as well as reliability concerns, the recovery<br>
image at the top of the SPI flash should be read-only with the BP bits<br>
and the WP# pin enabled.  That way hardware is required to really mess<br>
it up.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Trammell<br>
</font></span></blockquote></div><br></div>