[edk2-devel] [RFC] EDK2 Design Meeting 5/17: Revisiting Memory Protections

[Ard Biesheuvel]

On Mon, 22 May 2023 at 08:59, Taylor Beebe <t at taylorbeebe.com> wrote:
>
>  Hi all,
>
> During the EDK2 design meeting on 5/17, Project Mu developers presented memory protection
> and DXE Core revisions.
>
> The presentation covered the following topics:
>
> 1. The motivation for improving memory protections
> 2. Specifics on Microsoft's requirements for memory protection in UEFI
> 3. Changes Project Mu has made to the EDK2 memory protection logic to meet the requirements
> 4. A proposal of changes to DXE Core which will improve consistency and protection in EDK2
>
> The link below contains the presentation and supplementary files from the meeting.
>
> https://github.com/TaylorBeebe/edk2/tree/edk2_design_meeting_5_17_documents
>
> Below is an EDK2 branch containing the changes described in the design meeting tested
> using OvmfPkg. Two paging audits were collected from the branch to help illustrate the
> difference in memory protections. The file labeled ovmf_protected_base is the base
> X64 OVMF from May 5, 2023 with the protection PCDs set to the values in the
> "Basic Info" tab of the audit. The file ovmf_protected_updated was created with nearly
> identical settings at the same hash but with the updates from Project Mu.
>
> The EKD2 branch which created the  ovmf_protected_updated paging audit is linked below.
>
> IMPORTANT: This implementation is not going to be converted to patch series, and is only
> offered as a sandbox/reference for the above audits.
>
> https://github.com/TaylorBeebe/edk2/tree/revisiting_memory_protections
>
> The protection issues discussed in the design meeting indicate work which can be done to refocus
> DXE Core to contain all necessary services required for the initialization of modern platforms
> and to close protection gaps which currently exist in EDK2. To explore this topic with the
> community, a new GitHub Project will be created in the Tianocore organization to help track
> progress and drive engagement. A follow-up email will be sent when the project is made public
> to provide more info and enable community members to get involved.
>

Hello Taylor,

Thanks again for involving the community in this.

I agree with most of the points made regarding the need for these
changes, and the overall philosophy behind them.

However, I think we will be more successful engaging the community and
converging on an approach that works for everyone if we break this
down into more manageable chunks. (The first patch in your series
touches 97 files with 5,271 additions and 1,299 deletions, and has no
commit log, which makes is rather difficult to digest for someone who
has only read the docs but was not involved in the development)

Going back to the discussion we had in the video call, there are a
couple of aspects to this that I think we should separate from the
principal changes in terms of memory protections:
- having a dynamic memory protection policy that gets updated on the fly
- handling page faults resulting from access violations
- turning DXE core into a monolithic driver that encompasses various
PI architectural protocols.

These may all be worthwhile changes, but I would prefer to avoid
presenting them as prerequisites for being able to tighten memory
permissions per se. - architectures with less legacy than x86 (or
confidential VM platforms perhaps) may not have a need for these
additional pieces at all.

Please keep me on cc for when this edk2 staging project is published - thanks.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105186): https://edk2.groups.io/g/devel/message/105186
Mute This Topic: https://groups.io/mt/99059931/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-