lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 20 Nov 2022 09:49:19 +0800 From: joeyli <jlee@...e.com> To: Evgeniy Baskov <baskov@...ras.ru> Cc: Ard Biesheuvel <ardb@...nel.org>, Borislav Petkov <bp@...en8.de>, Andy Lutomirski <luto@...nel.org>, Dave Hansen <dave.hansen@...ux.intel.com>, Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>, Thomas Gleixner <tglx@...utronix.de>, Alexey Khoroshilov <khoroshilov@...ras.ru>, Peter Jones <pjones@...hat.com>, lvc-project@...uxtesting.org, x86@...nel.org, linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org Subject: Re: [PATCH v2 00/23] x86_64: Improvements at compressed kernel stage Hi Evgeniy, Thanks for your effort! On Tue, Oct 25, 2022 at 05:12:38PM +0300, Evgeniy Baskov wrote: > This patchset is aimed > * to improve UEFI compatibility of compressed kernel code for x86_64 > * to setup proper memory access attributes for code and rodata sections > * to implement W^X protection policy throughout the whole execution > of compressed kernel for EFISTUB code path. > > Kernel is made to be more compatible with PE image specification [3], > allowing it to be successfully loaded by stricter PE loader > implementations like the one from [2]. There is at least one > known implementation that uses that loader in production [4]. > There are also ongoing efforts to upstream these changes. > > Also the patchset adds EFI_MEMORY_ATTTRIBUTE_PROTOCOL, included into > EFI specification since version 2.10, as a better alternative to > using DXE services for memory protection attributes manipulation, > since it is defined by the UEFI specification itself and not UEFI PI > specification. This protocol is not widely available so the code > using DXE services is kept in place as a fallback in case specific > implementation does not support the new protocol. > One of EFI implementations that already support > EFI_MEMORY_ATTTRIBUTE_PROTOCOL is Microsoft Project Mu [5]. > Because Peter Jones point out this patchset to me, so I tried it on OVMF, and I set the EfiLoaderData in DXE memory protection policy: Index: edk2/MdeModulePkg/MdeModulePkg.dec =================================================================== --- edk2.orig/MdeModulePkg/MdeModulePkg.dec +++ edk2/MdeModulePkg/MdeModulePkg.dec @@ -1392,7 +1392,7 @@ # e.g. 0x7BD4 can be used for all memory except Code and ACPINVS/Reserved. <BR> # # @Prompt Set DXE memory protection policy. - gEfiMdeModulePkgTokenSpaceGuid.PcdDxeNxMemoryProtectionPolicy|0x0000000|UINT64|0x00001048^M + gEfiMdeModulePkgTokenSpaceGuid.PcdDxeNxMemoryProtectionPolicy|0x0000004|UINT64|0x00001048^M ## PCI Serial Device Info. It is an array of Device, Function, and Power Management # information that describes the path that contains zero or more PCI to PCI bridges I applied this v2 patch set on top of v6.1-rc5 kernel, and boot with a shim which set the PE NX-compatibility DLL Characteristic flag. I got a page fault exception: Loading Linux 6.1.0-rc5-default+ ... Loading initial ramdisk ... !!!! X64 Exception Type - 0E(#PF - Page-Fault) CPU Apic ID - 00000000 !!!! ExceptionData - 0000000000000011 I:1 R:0 U:0 W:0 P:1 PK:0 SS:0 SGX:0 RIP - 0000000076A3C390, CS - 0000000000000038, RFLAGS - 0000000000210202 RAX - 000000007D8CCDF8, RCX - 0000000076A3C390, RDX - 000000007DE86000 RBX - 0000000076A3C000, RSP - 000000007FF0D2C8, RBP - 000000007DE86000 RSI - 000000007F9EE018, RDI - 000000007DFD1C18 R8 - 0000000076A3C000, R9 - 0000000000000190, R10 - 000000007FF1D658 R11 - 0000000000000004, R12 - 0000000000000190, R13 - 000000007D8CCE00 R14 - 000000007D8C76B4, R15 - 000000007BF0CBD5 DS - 0000000000000030, ES - 0000000000000030, FS - 0000000000000030 GS - 0000000000000030, SS - 0000000000000030 CR0 - 0000000080010033, CR2 - 0000000076A3C390, CR3 - 000000007FC01000 CR4 - 0000000000000668, CR8 - 0000000000000000 DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000 DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400 GDTR - 000000007F9DE000 0000000000000047, LDTR - 0000000000000000 IDTR - 000000007F2E9018 0000000000000FFF, TR - 0000000000000000 FXSAVE_STATE - 000000007FF0CF20 !!!! Find image based on IP(0x7BF0BAB5) /mnt/working/source_code-git/edk2/Build/OvmfX64/DEBUG_GCC5/X64/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe/DEBUG/VariableRuntimeDxe.dll (ImageBase=0000000000F40E7C, EntryPoint=0000000000F767B8) !!!! My question is: Can I just set EfiLoaderData in DXE memory protection policy in EDK2/OVMF to test this patchset? Or which platform (virtual or physical) can we use for testing? Thanks a lot! Joey Lee
Powered by blists - more mailing lists