Re: [PATCH v3 3/4] x86/efi: move common keyring handler functions to new file
Mimi Zohar writes: > (Cc'ing Josh Boyer, David Howells) > > On Mon, 2019-09-02 at 21:55 +1000, Michael Ellerman wrote: >> Nayna Jain writes: >> >> > The handlers to add the keys to the .platform keyring and blacklisted >> > hashes to the .blacklist keyring is common for both the uefi and powerpc >> > mechanisms of loading the keys/hashes from the firmware. >> > >> > This patch moves the common code from load_uefi.c to keyring_handler.c >> > >> > Signed-off-by: Nayna Jain > > Acked-by: Mimi Zohar > >> > --- >> > security/integrity/Makefile | 3 +- >> > .../platform_certs/keyring_handler.c | 80 +++ >> > .../platform_certs/keyring_handler.h | 32 >> > security/integrity/platform_certs/load_uefi.c | 67 +--- >> > 4 files changed, 115 insertions(+), 67 deletions(-) >> > create mode 100644 security/integrity/platform_certs/keyring_handler.c >> > create mode 100644 security/integrity/platform_certs/keyring_handler.h >> >> This has no acks from security folks, though I'm not really clear on who >> maintains those files. > > I upstreamed David's, Josh's, and Nayna's patches, so that's probably > me. > >> Do I take it because it's mostly just code movement people are OK with >> it going in via the powerpc tree? > > Yes, the only reason for splitting load_uefi.c is for powerpc. These > patches should be upstreamed together. Thanks. cheers
Re: [PATCH v5 00/10] EFI Specific Purpose Memory Support
On Mon, Sep 2, 2019 at 4:09 AM Rafael J. Wysocki wrote:
>
> On Friday, August 30, 2019 3:52:18 AM CEST Dan Williams wrote:
> > Changes since v4 [1]:
> > - Rename the facility from "Application Reserved" to "Soft Reserved" to
> > better reflect how the memory is treated. While the spec talks about
> > "specific / application purpose" memory the expected kernel behavior is
> > to make a best effort at reserving the memory from general purpose
> > allocations.
> >
> > - Add a new efi=nosoftreserve option to disable consideration of the
> > EFI_MEMORY_SP attribute at boot time. This is also motivated by
> > Christoph's initial feedback of allowing the kernel to opt-out of the
> > policy whims of the platform BIOS implementation.
> >
> > - Update the KASLR implementation to exclude soft-reserved memory
> > including the case where soft-reserved memory is specified via the
> > efi_fake_mem= attribute-override command-line option.
> >
> > - Move the memregion allocator to its own object file. v4 had it in
> > kernel/resource.c which caused compile errors on Sparc. I otherwise
> > could not find an appropriate place to stash it.
> >
> > - Rebase on a merge of tip/master and rafael/linux-next since the series
> > collides with changes in both those trees.
> >
> > [1]:
> > https://lore.kernel.org/r/156140036490.2951909.1837804994781523185.st...@dwillia2-desk3.amr.corp.intel.com/
> >
> > ---
> >
> > Thomas, Rafael,
> >
> > This happens to collide with both your trees. I think the content
> > warrants going through the x86 tree, but would need to publish commit:
> >
> > 5c7ed4385424 HMAT: Skip publishing target info for nodes with no online
> > memory
> >
> > ...in Rafael's tree as a stable id for -tip to pull in, but I'm also
> > open to other options. I've retained Dave's reviewed-by from v4.
> >
> > ---
> >
> > The EFI 2.8 Specification [2] introduces the EFI_MEMORY_SP ("specific
> > purpose") memory attribute. This attribute bit replaces the deprecated
> > ACPI HMAT "reservation hint" that was introduced in ACPI 6.2 and removed
> > in ACPI 6.3.
> >
> > Given the increasing diversity of memory types that might be advertised
> > to the operating system, there is a need for platform firmware to hint
> > which memory ranges are free for the OS to use as general purpose memory
> > and which ranges are intended for application specific usage. For
> > example, an application with prior knowledge of the platform may expect
> > to be able to exclusively allocate a precious / limited pool of high
> > bandwidth memory. Alternatively, for the general purpose case, the
> > operating system may want to make the memory available on a best effort
> > basis as a unique numa-node with performance properties by the new
> > CONFIG_HMEM_REPORTING [3] facility.
> >
> > In support of optionally allowing either application-exclusive and
> > core-kernel-mm managed access to differentiated memory, claim
> > EFI_MEMORY_SP ranges for exposure as "soft reserved" and assigned to a
> > device-dax instance by default. Such instances can be directly owned /
> > mapped by a platform-topology-aware application. Alternatively, with the
> > new kmem facility [4], the administrator has the option to instead
> > designate that those memory ranges be hot-added to the core-kernel-mm as
> > a unique memory numa-node. In short, allow for the decision about what
> > software agent manages soft-reserved memory to be made at runtime.
> >
> > The patches build on the new HMAT+HMEM_REPORTING facilities merged
> > for v5.2-rc1. The implementation is tested with qemu emulation of HMAT
> > [5] plus the efi_fake_mem facility for applying the EFI_MEMORY_SP
> > attribute. Specific details on reproducing the test configuration are in
> > patch 10.
> >
> > [2]: https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf
> > [3]:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e1cf33aafb84
> > [4]:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c221c0b0308f
> > [5]: http://patchwork.ozlabs.org/cover/1096737/
> >
> > ---
> >
> > Dan Williams (10):
> > acpi/numa: Establish a new drivers/acpi/numa/ directory
> > efi: Enumerate EFI_MEMORY_SP
> > x86, efi: Push EFI_MEMMAP check into leaf routines
> > x86, efi: Reserve UEFI 2.8 Specific Purpose Memory for dax
> > x86, efi: Add efi_fake_mem support for EFI_MEMORY_SP
> > lib: Uplevel the pmem "region" ida to a global allocator
> > dax: Fix alloc_dax_region() compile warning
> > device-dax: Add a driver for "hmem" devices
> > acpi/numa/hmat: Register HMAT at device_initcall level
> > acpi/numa/hmat: Register "soft reserved" memory as an "hmem" device
> >
> >
> > Documentation/admin-guide/kernel-parameters.txt | 19 +++
> > arch/x86/Kconfig| 21
> > arch/x86/boot/compressed/eboot.c|7 +
> >
Re: arm64/efistub boot error with CONFIG_GCC_PLUGIN_STACKLEAK
On Sat, 31 Aug 2019 at 10:20, skodde wrote: > > On Thu, Aug 15, 2019 at 8:17 AM skodde wrote: > > On Thu, Aug 15, 2019 at 7:21 AM Ard Biesheuvel > > wrote: > > > On Thu, 15 Aug 2019 at 14:03, Mark Rutland wrote: > > > > On Thu, Aug 15, 2019 at 05:56:27AM -0400, skodde wrote: > > > > > The kernel boots fine with that option disabled, but strangely > > > > > presents the same error when disabling only CONFIG_RANDOMIZE_BASE. > > > > > > > > That shouldn't be possible, given the IS_ENABLED(CONFIG_RANDOMIZE_BASE) > > > > guard around the efi_get_random_bytes() call, so something sounds wrong. > > > > > > > > Maybe there's a problem with stale objects. If you're not doing so > > > > already, could you try a clean build with CONFIG_RANDOMIZE_BASE > > > > deselected? > > > > > > > Also, can you try booting with the nokaslr command line option added? > > > > You were right, I haven't tried with nokaslr, but it worked fine by > > rebuilding the kernel after a distclean with CONFIG_RANDOMIZE_BASE > > disabled and CONFIG_GCC_PLUGIN_STACKLEAK enabled. That's what I was > > expecting the first time and this is the reason why I mentioned it. > > I've been recompiling too many times, sorry about that. > > > > Anyhow, the main issue is the efi_get_random_bytes() fail with > > CONFIG_GCC_PLUGIN_STACKLEAK enabled, and that's still valid. > > Now the configuration that was working on 5.8 fails on 5.11 (haven't > tried 5.9 or 5.10): > What do these version numbers mean? v5.8 vs v5.11?? > - CONFIG_GCC_PLUGIN_STACKLEAK=n && CONFIG_RANDOMIZE_BASE=y (working on 5.8) > > Loading Linux 5.2.11-00015-g0cc3335a89ac ... > Loading initial ramdisk ... > EFI stub: Booting Linux Kernel... > EFI stub: ERROR: efi_get_random_bytes() failed > EFI stub: ERROR: Failed to relocate kernel To be honest, this looks like a firmware issue. Its implementation of EFI_RNG_PROTOCOL is throwing an error. I guess we could choose to handle this error more gracefully, but the result above is the expected behavior when EFI_RNG_PROTOCOL throws an error. > Error: Image at 0007956 start failed: Load Error > Unloading driver at 0x0007956 > > > - CONFIG_GCC_PLUGIN_STACKLEAK=n && CONFIG_RANDOMIZE_BASE=y && nokaslr > > Loading Linux 5.2.11-00015-g0cc3335a89ac ... > Loading initial ramdisk ... > EFI stub: Booting Linux Kernel... > EFI stub: KASLR disabled on kernel command line > EFI stub: Using DTB from configuration table > EFI stub: Exiting boot services and installing virtual address map... > EFI stub: ERROR: Unable to construct new device tree. > EFI stub: ERROR: Failed to update FDT and exit boot services > Error: Image at 00079561000 start failed: Load Error > Unloading driver at 0x00079561000 > This looks unrelated. update_fdt() is faling, but we don't know why. Could you add some debug prints at the various return sites to figure out why it is failing? > > After getting back to the bootloader, loading a known working kernel > fails (but it works fine after a reboot): > > Loading Linux 5.2.8-00016-ga0d5f389a536 ... > > Synchronous Exception at 0xB652157C > PC 0xB652157C > PC 0xB65226B4 > PC 0xB6522EE0 > PC 0xB646BB10 > PC 0xB6468580 > PC 0xB6524600 > PC 0xB6420078 > PC 0xB6485CFC > PC 0xB64849B4 > PC 0xB648586C > PC 0xB64849B4 > PC 0xB6485E68 > PC 0xB6485EC0 > PC 0xB647C5C8 > PC 0xB647C2C8 > PC 0xB647C658 > PC 0xB647C2C8 > PC 0xB64784A8 > PC 0xB646F1FC > PC 0xB6485CFC > PC 0xB64849B4 > PC 0xB648586C > PC 0xB64849B4 > PC 0xB6483C94 > PC 0xB64785A4 > PC 0xB6478794 > PC 0xB647880C > PC 0xB652532C > PC 0x3F95B714 (0x3F952000+0x9714) [ 1] DxeCore.dll > PC 0xB66CC440 (0xB66B9000+0x00013440) [ 2] UiApp.dll > PC 0xB66CCD8C (0xB66B9000+0x00013D8C) [ 2] UiApp.dll > PC 0xBF73D880 (0xBF729000+0x00014880) [ 3] SetupBrowser.dll > PC 0xBF737BFC (0xBF729000+0xEBFC) [ 3] SetupBrowser.dll > PC 0xB66C2700 (0xB66B9000+0x9700) [ 4] UiApp.dll > PC 0x3F95B714 (0x3F952000+0x9714) [ 5] DxeCore.dll > PC 0xBF71AEBC (0xBF711000+0x9EBC) [ 6] BdsDxe.dll > PC 0xBF721C8C (0xBF711000+0x00010C8C) [ 6] BdsDxe.dll > PC 0x3F95F470 (0x3F952000+0xD470) [ 7] DxeCore.dll > [ 1] > /home/skodde/macchiatobin/edk/uefi-marvell/Build/Armada80x0McBin-AARCH64/RELEASE_GCC5/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll > [ 2] > /home/skodde/macchiatobin/edk/uefi-marvell/Build/Armada80x0McBin-AARCH64/RELEASE_GCC5/AARCH64/MdeModulePkg/Application/UiApp/UiApp/DEBUG/UiApp.dll > [ 3] > /home/skodde/macchiatobin/edk/uefi-marvell/Build/Armada80x0McBin-AARCH64/RELEASE_GCC5/AARCH64/MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe/DEBUG/SetupBrowser.dll > [ 4] > /home/skodde/macchiatobin/edk/uefi-marvell/Build/Armada80x0McBin-AARCH64/RELEASE_GCC5/AARCH64/MdeModulePkg/Application/UiApp/UiApp/DEBUG/UiApp.dll > [ 5] >
Re: [PATCH] sysfs: add BIN_ATTR_WO() macro
On Tue, Sep 03, 2019 at 01:37:02PM +1000, Michael Ellerman wrote: > Greg Kroah-Hartman writes: > > This variant was missing from sysfs.h, I guess no one noticed it before. > > > > Turns out the powerpc secure variable code can use it, so add it to the > > tree for it, and potentially others to take advantage of, instead of > > open-coding it. > > > > Reported-by: Nayna Jain > > Signed-off-by: Greg Kroah-Hartman > > --- > > > > I'll queue this up to my tree for 5.4-rc1, but if you want to take this > > in your tree earlier, feel free to do so. > > OK. This series is blocked on the firmware support going in, so at the > moment it might miss v5.4 anyway. So this going via your tree is no > problem. Ok, will queue it up now, thanks! greg k-h
