I think that is an interesting idea but I would expect some push back
from OS loader maintainers. I would expect they don't want to be
constrained by the lowest common capabilities of the platforms they
still support/run on in the ecosystem. Not to mention the challenges
around servicing and/or updating for bugs or features.
Example: Shim would not have been able to implement their version of
SBAT in said scenario.
I know the Windows Boot team has been cautious about taking a dependency
on the platform's UEFI and I would expect strong push back on them
moving to using the platform's provided UEFI loader.
But I do agree with your goals. Is there a better way using open
source? Could the PE loader/authenticode be a library managed as it's
own project and be integrated into other pre-boot applications? Would
that help to eliminate bugs like this one and provide a better
infrastructure to build on?
Thanks
Sean
On 6/23/2023 9:26 AM, Ard Biesheuvel wrote:
On Tue, 20 Jun 2023 at 19:07, Sean Brogan <spbro...@outlook.com> wrote:
I don't think a MemoryAttributes2Protocol with a single API would have avoided
the errors.
The programming pattern that triggered this would still need multiple calls to
any API and in the future where all memory is allocated as NX this possibility
would still exist.
A short term effort to minimize the compatibility problem in the ecosystem is
documented here Memory Protections: Document compatibility challenges · Issue
#18 · tianocore/projects (github.com) It does not address (and i don't see any
reason to try to) a loader that uses the protocol incorrectly.
We have provided virtual reference platforms with these features enabled (both arm and x86) and
have been working with the relevant communities for multiple years now. The UEFI CA for option
roms already have compliance requirements (UPDATED: UEFI Signing Requirements - Microsoft Community
Hub). But there are and will continue to be compatibility challenges when enabling a more
restrictive execution environment in uefi and the uefi ecosystem. The more things we make optional
the longer this transition period will take. "Memory Mitigations" were proposed and
mostly coded over a decade ago. The code changes are not that difficult. To change our vast and
unwieldy ecosystem is the hard part. Please help to "stay the course" for this very
necessary industry change. If a production platform has requirements that force such a
configuration option that is understandable but it is counter productive in open-source industry
standard reference Edk2 code.
Fair enough.
But I will note that the only reason we are in this situation in the
first place is because shim has to re-implement the PE loader, cert
handling and all related crypto, and needs the memory attributes
protocol to manipulate the RO/NX permissions.
Now that we are taking these things seriously, wouldn't it be *much*
better to get rid of all this cruft, and specify a method by which a
loader can provide an ephemeral DB that the system firmware will
authenticate against? That way, we can reduce shim to a single
SetVariable() call that creates the ephemeral DB (and perhaps a call
into the TPM code to measure it), which is arguably a lot easier to
audit than the code we have today.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#106310): https://edk2.groups.io/g/devel/message/106310
Mute This Topic: https://groups.io/mt/99631663/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
