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: Tue, 14 Mar 2023 14:23:39 -0700 From: "Andy Lutomirski" <luto@...nel.org> To: "Evgeniy Baskov" <baskov@...ras.ru>, "Ard Biesheuvel" <ardb@...nel.org> Cc: "Borislav Petkov" <bp@...en8.de>, "Dave Hansen" <dave.hansen@...ux.intel.com>, "Ingo Molnar" <mingo@...hat.com>, "Peter Zijlstra (Intel)" <peterz@...radead.org>, "Thomas Gleixner" <tglx@...utronix.de>, "Alexey Khoroshilov" <khoroshilov@...ras.ru>, "Peter Jones" <pjones@...hat.com>, "Gerd Hoffmann" <kraxel@...hat.com>, "Limonciello, Mario" <mario.limonciello@....com>, joeyli <jlee@...e.com>, lvc-project@...uxtesting.org, "the arch/x86 maintainers" <x86@...nel.org>, linux-efi@...r.kernel.org, "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>, linux-hardening@...r.kernel.org Subject: Re: [PATCH v5 00/27] x86_64: Improvements at compressed kernel stage On Tue, Mar 14, 2023, at 3:13 AM, 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. The overall code quality seems okay, but I have some questions as to what this is for. The early boot environment is not exposed to most sorts of attacks -- there's no userspace, there's no network, and there is not a whole lot of input that isn't implicitly completely trusted. What parts of this series are actually needed to get these fancy new bootloaders to boot Linux? And why? > > 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. Can you clarify > > 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]. Maybe make this a separate series? > > Kernel image generation tool (tools/build.c) is refactored as a part > of changes that makes PE image more compatible. > > The patchset implements memory protection for compressed kernel > code while executing both inside EFI boot services and outside of > them. For EFISTUB code path W^X protection policy is maintained > throughout the whole execution of compressed kernel. The latter > is achieved by extracting the kernel directly from EFI environment > and jumping to it's head immediately after exiting EFI boot services. > As a side effect of this change one page table rebuild and a copy of > the kernel image is removed. I have no problem with this, but what's it needed for? > > Memory protection inside EFI environment is controlled by the > CONFIG_DXE_MEM_ATTRIBUTES option, although with these patches this > option also control the use EFI_MEMORY_ATTTRIBUTE_PROTOCOL and memory > protection attributes of PE sections and not only DXE services as the > name might suggest. > > [1] > https://lore.kernel.org/lkml/893da11995f93a7ea8f7485d17bf356a@ispras.ru/ > [2] https://github.com/acidanthera/audk/tree/secure_pe Link is broken > [3] > https://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/pecoff_v83.docx I skimmed this very briefly, and I have no idea what I'm supposed to look at. This is the entire PE spec!
Powered by blists - more mailing lists