On 2/8/2023 2:08 PM, Ard Biesheuvel wrote:
On Wed, 8 Feb 2023 at 20:12, Taylor Beebe wrote:
I ran some tests and did some quick napkin math. Based on the time it
takes to perform the SetMemoryAttributes() routine on QEMU, as long as
<79% of the calls to ApplyMemoryProtectionPolicy() actuall
On Wed, 8 Feb 2023 at 20:12, Taylor Beebe wrote:
>
> I ran some tests and did some quick napkin math. Based on the time it
> takes to perform the SetMemoryAttributes() routine on QEMU, as long as
> <79% of the calls to ApplyMemoryProtectionPolicy() actually require a
> subsequent call to SetMemory
I ran some tests and did some quick napkin math. Based on the time it
takes to perform the SetMemoryAttributes() routine on QEMU, as long as
<79% of the calls to ApplyMemoryProtectionPolicy() actually require a
subsequent call to SetMemoryAttributes(), it is more efficient to walk
the page/tran
> On 8. Feb 2023, at 19:49, Ard Biesheuvel wrote:
>
> This is all copy-pasted from MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
:(
>
> The ordering here is a bit tricky. As soon as the CPU arch protocol is
> exposed, every allocation will be remapped individually, resulting in
> page table
On Wed, 8 Feb 2023 at 18:58, Ard Biesheuvel wrote:
>
> Instead of relying on a questionable heuristic that avoids calling into
> the SetMemoryAttributes () DXE service when the old memory type and the
> new one are subjected to the same NX memory protection policy, make this
> call unconditionally
Instead of relying on a questionable heuristic that avoids calling into
the SetMemoryAttributes () DXE service when the old memory type and the
new one are subjected to the same NX memory protection policy, make this
call unconditionally. This avoids corner cases where memory region
attributes are
