<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p>Gerd/Ard,</p>
    <p>This is a great topic and shows some of the challenges of
      tightening up security/enforcing correctness in UEFI.</p>
    <p>I wanted to let you know that we have been doing a lot of work in
      both edk2 firmware and discussing with partners in the Linux
      community and PC ecosystem.  The Shim and Grub teams have been
      directly engaged and have code patches that correct a number of
      problems as well as make their code compliant with even tighter
      restrictions.   Engineers from redhat, canonical, oracle, and
      others have all been involved.  Also note Microsoft's UEFI CA now
      requires submissions to be compliant with a strict set of memory
      mitigations.  <a href="https://learn.microsoft.com/en-us/windows-hardware/drivers/bringup/uefi-ca-memory-mitigation-requirements">UEFI
        CA Memory Mitigation Requirements for Signing - Windows drivers
        | Microsoft Learn</a> and <a href="https://techcommunity.microsoft.com/t5/hardware-dev-center/updated-uefi-signing-requirements/ba-p/1062916">UPDATED:
        UEFI Signing Requirements - Microsoft Community Hub</a>.  This
      means any new shim submitted must now meet these requirements. 
      How long it takes for distros to update to a new shim is still
      unknown.  <br>
    </p>
    <p><br>
    </p>
    <p>Hopefully sometime in the next few weeks we can prepare a
      comprehensive set of patches and changes needed in edk2 to
      implement this strict environment.  One of the relevant changes to
      this discussion and patch series is we switched the configuration
      from PCD to hob (<a href="https://github.com/microsoft/mu_basecore/blob/release/202208/MdeModulePkg/Include/Guid/DxeMemoryProtectionSettings.h">mu_basecore/DxeMemoryProtectionSettings.h
        at release/202208 · microsoft/mu_basecore (github.com)</a>). 
      This allows our platforms complete control of the config per
      boot.  Some platforms have compatibility requirements and have
      implemented code so that when a PF is triggered by incompatible
      software, it is recorded and then the system rebooted.  On the
      next boot the platform changes the HOB configuration to be in a
      more compatible mode (this mode could be measured in a PCR and/or
      other hints to the user/system of degraded security).  We hope
      this balance makes compatibility possible but inconvenient and
      with a less than desirable user experience.  Will this help move
      the industry, I don't know?</p>
    <p><br>
    </p>
    <p>Anyway, rather than a patchwork of changes going into different
      platforms and components of edk2 I would like to see alignment
      between x86/arm64 in edk2 and a complete set of changes for edk2. 
      We have developed a tool and some tests that can capture the
      memory environment in DXE and export it to then allow a developer
      to review.  This has identified dozens of problems in edk2 code as
      well as platform code.  See attached a report file showing a
      passing report for our q35 qemu based platform.  <a href="https://github.com/microsoft/mu_tiano_platforms/tree/main/Platforms/QemuQ35Pkg">mu_tiano_platforms/Platforms/QemuQ35Pkg
        at main · microsoft/mu_tiano_platforms (github.com)</a>  We are
      still working on getting the equivalent for arm64.   Happy to
      discuss more if anyone else is interested.  <br>
    </p>
    <p><br>
    </p>
    <p>Thanks</p>
    <p>sean</p>
    <p><br>
    </p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 1/5/2023 11:58 AM, Gerd Hoffmann
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:20230105195836.hh3guyztbn2asyur@sirius.home.kraxel.org">
      <pre class="moz-quote-pre" wrap="">  Hi,

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">Tried booting grub.efi directly and via shim.efi, on Fedora 37 GA.

In both cases I get a pagefault on linux kernel boot (before any other
message is printed), which I guess happens because the loader places the
linux kernel efi stub in EfiLoaderData memory.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
When compiling ovmf with the same pcd value I get the same behavior
on x64, so it's consistently buggy across architectures.

take care,
  Gerd






</pre>
    </blockquote>
  </body>
</html>


<div width="1" style="color:white;clear:both">_._,_._,_</div>
<hr>


Groups.io Links:<p>


  
    You receive all messages sent to this group.
  
  


<p>
<a target="_blank" href="https://edk2.groups.io/g/devel/message/98047">View/Reply Online (#98047)</a> |


  

|

  <a target="_blank" href="https://groups.io/mt/93922691/1813853">Mute This Topic</a>

| <a href="https://edk2.groups.io/g/devel/post">New Topic</a><br>




<a href="https://edk2.groups.io/g/devel/editsub/1813853">Your Subscription</a> |
<a href="mailto:devel+owner@edk2.groups.io">Contact Group Owner</a> |

<a href="https://edk2.groups.io/g/devel/unsub">Unsubscribe</a>

 [edk2-devel-archive@redhat.com]<br>
<div width="1" style="color:white;clear:both">_._,_._,_</div>