<html><head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body><div>On Mon, 2018-03-12 at 10:01 +1000, Brett Grandbois wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">
    <p>Hi,</p>
    <p>We're looking at adopting the signed-boot system in our platform
      and going through the implementation I've noticed something I need
      to ask the wider community about.  In lib/security/gpg.c in
      gpg_validate_boot_files() the initial commit had this code block:</p>
    <p>
      </p><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">+    if
        (verify_file_signature(kernel_filename,<br>
        +        local_image_signature,<br>
        +        authorized_signatures_handle, "/etc/gpg"))<br>
        +        result = KEXEC_LOAD_SIGNATURE_FAILURE;<br>
        +    if (verify_file_signature(cmdline_template,<br>
        +        local_cmdline_signature,<br>
        +        authorized_signatures_handle, "/etc/gpg"))<br>
        +        result = KEXEC_LOAD_SIGNATURE_FAILURE;</blockquote>
    <p></p>
    <p>where the following commit that adds in the decryption support
      removes the:
      </p><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">result = KEXEC_LOAD_SIGNATURE_FAILURE;</blockquote>
      lines to the kernel and command line checks, effectively making
      them irrelevant in the boot_task->verify_signature path?<p></p>
    <p>Is there some other check somewhere else that I've missed?<br>
    </p>
    <p><br></p></blockquote><div><br></div><div>Hi Brett,</div><div><br></div><div>No, looks like you've found a legitimate bug. Those if statements will fall through to the initrd signature check,</div><div>making it possible to boot with an invalid kernel and command line.</div><div>In the short term we should obviously fix that. Longer term I reckon it's worth thinking about how/if we use and</div><div>consume the signed boot code.</div><div><br></div><div>The signed/encrypted boot code was added in 2016 by Timothy (CC'd) mainly for their TALOS OpenPOWER P8</div><div>machine. That didn't fully ship AFAIK and focus moved to TALOS II (P9). So while the signed/encrypted boot code</div><div>has been tested and checked by myself and Timothy, I don't know anyone that's actually used this in any</div><div>seriousness, and I'm not sure whether the Raptor Engineering people intend to use it for TALOS II - Timothy can you</div><div>weigh in on that?</div><div><br></div><div>At the same time I'm aware of a lot of work going on by other IBMers to implement full-stack secure and trusted boot.</div><div>How that fits in next to what we have now or whether we should see if one should replace the other are questions that</div><div>have been the back of my mind.</div><div>George and Claudio - would you mind giving us a brief rundown for the benefit of the Petitboot list of how IBM's</div><div>secure/trusted boot process will work, and the main ways that could impact Petitboot specifically?</div><div>Additionally how will IBM's implementation affect users such as Brett who are using Petitboot but are not running on a</div><div>POWER machine, ie. not OPAL?</div><div><br></div><div>Regards,</div><div>Sam</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><p>
    </p>
    <p><br>
    </p>
    <div class="moz-signature">-- <br>
      Brett Grandbois<br>
      Software Engineering<br>
      Opengear Inc.<br>
      <a href="http://www.opengear.com">www.opengear.com</a></div>
  

<pre>_______________________________________________
Petitboot mailing list
<a href="mailto:Petitboot@lists.ozlabs.org">Petitboot@lists.ozlabs.org</a>
<a href="https://lists.ozlabs.org/listinfo/petitboot">https://lists.ozlabs.org/listinfo/petitboot</a>
</pre></blockquote><div><br></div></body></html>