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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 20 Oct 2022 14:05:27 +0300 From: Evgeniy Baskov <baskov@...ras.ru> To: Peter Jones <pjones@...hat.com> 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>, 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 00/16] x86_64: Improvements at compressed kernel stage On 2022-10-19 00:04, Peter Jones wrote: > On Tue, Sep 06, 2022 at 01:41:04PM +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. > > Hi Evgeniy, > > I've tested this set of patches with the Mu firmware that supports the > W^X > feature and a modified bootloader to also support it, and also with an > existing firmware and the grub2 build in fedora 36. On the firmware > without W^X support, this all works for me. With W^X support, it works > so long as I use CONFIG_EFI_STUB_EXTRACT_DIRECT, though I still need > some changes in grub's loader. IMO that's a big step forward. > > I can't currently make it work with W^X enabled but without direct > extraction, and I'm still investigating why not, but I figured I'd give > you a heads up. Hi Peter, Thank you for testing! Without direct extraction enabled this patch set does not implement total W^X and needs to allocate RWX memory regions, since it should go through common code path that relocates kernel. So if the firmware does not allow allocating RWX regions, it might prevent the kernel from booting, I think. I will look into that problem soon and let you know it I find anything. Thanks, Evgeniy Baskov
Powered by blists - more mailing lists