Re: [PATCH v7 00/12] EFI Specific Purpose Memory Support

2019-10-16 Thread Ard Biesheuvel
On Wed, 16 Oct 2019 at 03:13, Dan Williams  wrote:
>
> Changes since v6 [1]:
> - Collect Ard's ack / review on patches 5-7, but not on patch 4 since it
>   needed a non-trivial rework for linker error reported by the 0day robot.
>
> - Fixup "efi: Common enable/disable infrastructure for EFI soft
>   reservation" with a new dependency on CONFIG_EFI_STUB for
>   CONFIG_EFI_SOFT_RESERVE since the efi_soft_reserve_enabled() helper is
>   only built with EFI_STUB=y and the support depends on early reservations
>   to keep the kernel text from landing in the reservation.

As far as I know, GRUB on x86 still boots without the EFI stub by
default (i.e., using the 'linux' command instead of the 'linuxefi'
command), so even if you build the stub, it is not going to be called
in many cases. Is that going to be a problem?

> This also
>   moved the IS_ENABLED(CONFIG_EFI_SOFT_RESERVE) check into the header so
>   that the stub does not try to link to __efi_soft_reserve_enabled() in
>   the EFI_STUB=n case.
>
> - Rework "x86/efi: EFI soft reservation to E820 enumeration" to always
>   add the full EFI memory map when EFI_MEMORY_SP ranges are found. This
>   simplifies the logic to just add the full EFI map rather than try to
>   tease out just the EFI_MEMORY_SP ranges. (Ard)
>
> [1]: 
> https://lore.kernel.org/lkml/157066227329.1059972.5659620631541203458.st...@dwillia2-desk3.amr.corp.intel.com/
>
> ---
> Merge notes:
>
> Hi Ingo,
>
> I'm still looking for Ard's ack on the revised patch 4, but otherwise
> feel like this is ready for your consideration.
>

Patch 4 looks fine to me,

Reviewed-by: Ard Biesheuvel 


> ---
>
> 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 12.
>
> [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 (12):
>   acpi/numa: Establish a new drivers/acpi/numa/ directory
>   efi: Enumerate EFI_MEMORY_SP
>   x86/efi: Push EFI_MEMMAP check into leaf routines
>   efi: Common enable/disable infrastructure for EFI soft reservation
>   x86/efi: EFI soft reservation to E820 enumeration
>   arm/efi: EFI soft reservation to memblock
>   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/kerne

[PATCH] efi: libstub/arm: account for firmware reserved memory at the base of RAM

2019-10-14 Thread Ard Biesheuvel
The EFI stubloader for ARM starts out by allocating a 32 MB window
at the base of RAM, in order to ensure that the decompressor (which
blindly copies the uncompressed kernel into that window) does not
overwrite other allocations that are made while running in the context
of the EFI firmware.

In some cases, (e.g., U-Boot running on the Raspberry Pi 2), this is
causing boot failures because this initial allocation conflicts with
a page of reserved memory at the base of RAM that contains the SMP spin
tables and other pieces of firmware data and which was put there by
the bootloader under the assumption that the TEXT_OFFSET window right
below the kernel is only used partially during early boot, and will be
left alone once the memory reservations are processed and taken into
account.

So let's permit reserved memory regions to exist in the region starting
at the base of RAM, and ending at TEXT_OFFSET - 5 * PAGE_SIZE, which is
the window below the kernel that is not touched by the early boot code.

Cc: Guillaume Gardet 
Cc: Chester Lin  
Signed-off-by: Ard Biesheuvel 
---
 drivers/firmware/efi/libstub/Makefile |  1 +
 drivers/firmware/efi/libstub/arm32-stub.c | 16 +---
 2 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/firmware/efi/libstub/Makefile 
b/drivers/firmware/efi/libstub/Makefile
index 0460c7581220..ee0661ddb25b 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -52,6 +52,7 @@ lib-$(CONFIG_EFI_ARMSTUB) += arm-stub.o fdt.o string.o 
random.o \
 
 lib-$(CONFIG_ARM)  += arm32-stub.o
 lib-$(CONFIG_ARM64)+= arm64-stub.o
+CFLAGS_arm32-stub.o:= -DTEXT_OFFSET=$(TEXT_OFFSET)
 CFLAGS_arm64-stub.o:= -DTEXT_OFFSET=$(TEXT_OFFSET)
 
 #
diff --git a/drivers/firmware/efi/libstub/arm32-stub.c 
b/drivers/firmware/efi/libstub/arm32-stub.c
index e8f7aefb6813..47aafeff3e01 100644
--- a/drivers/firmware/efi/libstub/arm32-stub.c
+++ b/drivers/firmware/efi/libstub/arm32-stub.c
@@ -195,6 +195,7 @@ efi_status_t handle_kernel_image(efi_system_table_t 
*sys_table,
 unsigned long dram_base,
 efi_loaded_image_t *image)
 {
+   unsigned long kernel_base;
efi_status_t status;
 
/*
@@ -204,9 +205,18 @@ efi_status_t handle_kernel_image(efi_system_table_t 
*sys_table,
 * loaded. These assumptions are made by the decompressor,
 * before any memory map is available.
 */
-   dram_base = round_up(dram_base, SZ_128M);
+   kernel_base = round_up(dram_base, SZ_128M);
 
-   status = reserve_kernel_base(sys_table, dram_base, reserve_addr,
+   /*
+* Note that some platforms (notably, the Raspberry Pi 2) put
+* spin-tables and other pieces of firmware at the base of RAM,
+* abusing the fact that the window of TEXT_OFFSET bytes at the
+* base of the kernel image is only partially used at the moment.
+* (Up to 5 pages are used for the swapper page table)
+*/
+   kernel_base += TEXT_OFFSET - 5 * PAGE_SIZE;
+
+   status = reserve_kernel_base(sys_table, kernel_base, reserve_addr,
 reserve_size);
if (status != EFI_SUCCESS) {
pr_efi_err(sys_table, "Unable to allocate memory for 
uncompressed kernel.\n");
@@ -220,7 +230,7 @@ efi_status_t handle_kernel_image(efi_system_table_t 
*sys_table,
*image_size = image->image_size;
status = efi_relocate_kernel(sys_table, image_addr, *image_size,
 *image_size,
-dram_base + MAX_UNCOMP_KERNEL_SIZE, 0);
+kernel_base + MAX_UNCOMP_KERNEL_SIZE, 0);
if (status != EFI_SUCCESS) {
pr_efi_err(sys_table, "Failed to relocate kernel.\n");
efi_free(sys_table, *reserve_size, *reserve_addr);
-- 
2.20.1



Re: [PATCH v1] Ask user input only when CONFIG_X86 or CONFIG_COMPILE_TEST is set to y

2019-10-14 Thread Ard Biesheuvel
On Mon, 14 Oct 2019 at 08:41, Geert Uytterhoeven  wrote:
>
> Hi Narendra,
>
> On Sun, Oct 13, 2019 at 8:57 PM  wrote:
> > From: Narendra K 
> >
> > For the EFI_RCI2_TABLE kconfig option, 'make oldconfig' asks the user
> > for input on platforms where the option may not be applicable. This patch
> > modifies the kconfig option to ask the user for input only when CONFIG_X86
> > or CONFIG_COMPILE_TEST is set to y.
> >
> > Reported-by: Geert Uytterhoeven 
> > Fix-suggested-by: Geert Uytterhoeven 
>
> Suggested-by: ...?
>

Indeed

> > Signed-off-by: Narendra K 
>
> Thanks for your patch!
>
> Tested-by: Geert Uytterhoeven 
>

Thanks all. I'll get this queued as a fix.


Re: [PATCH v6 05/12] x86/efi: EFI soft reservation to E820 enumeration

2019-10-11 Thread Ard Biesheuvel
On Fri, 11 Oct 2019 at 16:35, Dan Williams  wrote:
>
> On Thu, Oct 10, 2019 at 10:52 PM Ard Biesheuvel
>  wrote:
> >
> > On Fri, 11 Oct 2019 at 04:39, Dan Williams  wrote:
> > >
> > > On Thu, Oct 10, 2019 at 11:41 AM Ard Biesheuvel
> > >  wrote:
> > > >
> > > > On Thu, 10 Oct 2019 at 20:31, Dan Williams  
> > > > wrote:
> > > > >
> > > > > On Wed, Oct 9, 2019 at 11:45 PM Ard Biesheuvel
> > > > >  wrote:
> > > > > >
> > > > > > On Thu, 10 Oct 2019 at 01:19, Dan Williams 
> > > > > >  wrote:
> > > > > > >
> > > > > > > UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the
> > > > > > > interpretation of the EFI Memory Types as "reserved for a specific
> > > > > > > purpose".
> > > > > > >
> > > > > > > The proposed Linux behavior for specific purpose memory is that 
> > > > > > > it is
> > > > > > > reserved for direct-access (device-dax) by default and not 
> > > > > > > available for
> > > > > > > any kernel usage, not even as an OOM fallback.  Later, through 
> > > > > > > udev
> > > > > > > scripts or another init mechanism, these device-dax claimed 
> > > > > > > ranges can
> > > > > > > be reconfigured and hot-added to the available System-RAM with a 
> > > > > > > unique
> > > > > > > node identifier. This device-dax management scheme implements 
> > > > > > > "soft" in
> > > > > > > the "soft reserved" designation by allowing some or all of the
> > > > > > > reservation to be recovered as typical memory. This policy can be
> > > > > > > disabled at compile-time with CONFIG_EFI_SOFT_RESERVE=n, or 
> > > > > > > runtime with
> > > > > > > efi=nosoftreserve.
> > > > > > >
> > > > > > > This patch introduces 2 new concepts at once given the 
> > > > > > > entanglement
> > > > > > > between early boot enumeration relative to memory that can 
> > > > > > > optionally be
> > > > > > > reserved from the kernel page allocator by default. The new 
> > > > > > > concepts
> > > > > > > are:
> > > > > > >
> > > > > > > - E820_TYPE_SOFT_RESERVED: Upon detecting the EFI_MEMORY_SP
> > > > > > >   attribute on EFI_CONVENTIONAL memory, update the E820 map with 
> > > > > > > this
> > > > > > >   new type. Only perform this classification if the
> > > > > > >   CONFIG_EFI_SOFT_RESERVE=y policy is enabled, otherwise treat it 
> > > > > > > as
> > > > > > >   typical ram.
> > > > > > >
> > > > > > > - IORES_DESC_SOFT_RESERVED: Add a new I/O resource descriptor for
> > > > > > >   a device driver to search iomem resources for application 
> > > > > > > specific
> > > > > > >   memory. Teach the iomem code to identify such ranges as "Soft 
> > > > > > > Reserved".
> > > > > > >
> > > > > > > A follow-on change integrates parsing of the ACPI HMAT to 
> > > > > > > identify the
> > > > > > > node and sub-range boundaries of EFI_MEMORY_SP designated memory. 
> > > > > > > For
> > > > > > > now, just identify and reserve memory of this type.
> > > > > > >
> > > > > > > Cc: 
> > > > > > > Cc: Borislav Petkov 
> > > > > > > Cc: Ingo Molnar 
> > > > > > > Cc: "H. Peter Anvin" 
> > > > > > > Cc: Darren Hart 
> > > > > > > Cc: Andy Shevchenko 
> > > > > > > Cc: Andy Lutomirski 
> > > > > > > Cc: Peter Zijlstra 
> > > > > > > Cc: Thomas Gleixner 
> > > > > > > Cc: Ard Biesheuvel 
> > > > > > > Reported-by: kbuild test robot 
> > > > > > > Reviewed-by: Dave Hansen 
> > > > > > > Signed-off-by: Dan Williams 
> > > > > >
> > > > > > For

Re: [PATCH v6 05/12] x86/efi: EFI soft reservation to E820 enumeration

2019-10-10 Thread Ard Biesheuvel
On Fri, 11 Oct 2019 at 04:39, Dan Williams  wrote:
>
> On Thu, Oct 10, 2019 at 11:41 AM Ard Biesheuvel
>  wrote:
> >
> > On Thu, 10 Oct 2019 at 20:31, Dan Williams  wrote:
> > >
> > > On Wed, Oct 9, 2019 at 11:45 PM Ard Biesheuvel
> > >  wrote:
> > > >
> > > > On Thu, 10 Oct 2019 at 01:19, Dan Williams  
> > > > wrote:
> > > > >
> > > > > UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the
> > > > > interpretation of the EFI Memory Types as "reserved for a specific
> > > > > purpose".
> > > > >
> > > > > The proposed Linux behavior for specific purpose memory is that it is
> > > > > reserved for direct-access (device-dax) by default and not available 
> > > > > for
> > > > > any kernel usage, not even as an OOM fallback.  Later, through udev
> > > > > scripts or another init mechanism, these device-dax claimed ranges can
> > > > > be reconfigured and hot-added to the available System-RAM with a 
> > > > > unique
> > > > > node identifier. This device-dax management scheme implements "soft" 
> > > > > in
> > > > > the "soft reserved" designation by allowing some or all of the
> > > > > reservation to be recovered as typical memory. This policy can be
> > > > > disabled at compile-time with CONFIG_EFI_SOFT_RESERVE=n, or runtime 
> > > > > with
> > > > > efi=nosoftreserve.
> > > > >
> > > > > This patch introduces 2 new concepts at once given the entanglement
> > > > > between early boot enumeration relative to memory that can optionally 
> > > > > be
> > > > > reserved from the kernel page allocator by default. The new concepts
> > > > > are:
> > > > >
> > > > > - E820_TYPE_SOFT_RESERVED: Upon detecting the EFI_MEMORY_SP
> > > > >   attribute on EFI_CONVENTIONAL memory, update the E820 map with this
> > > > >   new type. Only perform this classification if the
> > > > >   CONFIG_EFI_SOFT_RESERVE=y policy is enabled, otherwise treat it as
> > > > >   typical ram.
> > > > >
> > > > > - IORES_DESC_SOFT_RESERVED: Add a new I/O resource descriptor for
> > > > >   a device driver to search iomem resources for application specific
> > > > >   memory. Teach the iomem code to identify such ranges as "Soft 
> > > > > Reserved".
> > > > >
> > > > > A follow-on change integrates parsing of the ACPI HMAT to identify the
> > > > > node and sub-range boundaries of EFI_MEMORY_SP designated memory. For
> > > > > now, just identify and reserve memory of this type.
> > > > >
> > > > > Cc: 
> > > > > Cc: Borislav Petkov 
> > > > > Cc: Ingo Molnar 
> > > > > Cc: "H. Peter Anvin" 
> > > > > Cc: Darren Hart 
> > > > > Cc: Andy Shevchenko 
> > > > > Cc: Andy Lutomirski 
> > > > > Cc: Peter Zijlstra 
> > > > > Cc: Thomas Gleixner 
> > > > > Cc: Ard Biesheuvel 
> > > > > Reported-by: kbuild test robot 
> > > > > Reviewed-by: Dave Hansen 
> > > > > Signed-off-by: Dan Williams 
> > > >
> > > > For the EFI changes
> > > >
> > > > Acked-by: Ard Biesheuvel 
> > > >
> > > > although I must admit I don't follow the enum add_efi_mode logic 100%
> > >
> > > I'm open to suggestions as I'm not sure it's the best possible
> > > organization. The do_add_efi_memmap() routine has the logic to
> > > translate EFI to E820, but unless "add_efi_memmap" is specified on the
> > > kernel command line the EFI memory map is ignored. For
> > > soft-reservation support I want to reuse do_add_efi_memmap(), but
> > > otherwise avoid any other side effects of considering the EFI map.
> > > What I'm missing is the rationale for why "add_efi_memmap" is required
> > > before considering the EFI memory map.
> > >
> > > If there is a negative side effect to always using the EFI map then
> > > the new "add_efi_mode" designation constrains it to just the
> > > soft-reservation case.
> > >
> >
> > Could we make the presence of any EFI_MEMORY_SP regions imply
> > add_efi_memmap? That way, it is guaranteed that we don't regress
> > existing systems, while establishing clear and unambiguous semantics
> > for new systems that rely on these changes in order to be able to use
> > the special purpose memory as intended.
>
> In fact that's how it works. EFI_MEMORY_SP is unconditionally added.
> Other EFI memory types are optionally added with the add_efi_memmap
> option.

That is not what I meant.

Why not behave as if 'add_efi_memmap' was passed if any EFI_MEMORY_SP
regions exist?


Re: [PATCH v6 05/12] x86/efi: EFI soft reservation to E820 enumeration

2019-10-10 Thread Ard Biesheuvel
On Thu, 10 Oct 2019 at 20:31, Dan Williams  wrote:
>
> On Wed, Oct 9, 2019 at 11:45 PM Ard Biesheuvel
>  wrote:
> >
> > On Thu, 10 Oct 2019 at 01:19, Dan Williams  wrote:
> > >
> > > UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the
> > > interpretation of the EFI Memory Types as "reserved for a specific
> > > purpose".
> > >
> > > The proposed Linux behavior for specific purpose memory is that it is
> > > reserved for direct-access (device-dax) by default and not available for
> > > any kernel usage, not even as an OOM fallback.  Later, through udev
> > > scripts or another init mechanism, these device-dax claimed ranges can
> > > be reconfigured and hot-added to the available System-RAM with a unique
> > > node identifier. This device-dax management scheme implements "soft" in
> > > the "soft reserved" designation by allowing some or all of the
> > > reservation to be recovered as typical memory. This policy can be
> > > disabled at compile-time with CONFIG_EFI_SOFT_RESERVE=n, or runtime with
> > > efi=nosoftreserve.
> > >
> > > This patch introduces 2 new concepts at once given the entanglement
> > > between early boot enumeration relative to memory that can optionally be
> > > reserved from the kernel page allocator by default. The new concepts
> > > are:
> > >
> > > - E820_TYPE_SOFT_RESERVED: Upon detecting the EFI_MEMORY_SP
> > >   attribute on EFI_CONVENTIONAL memory, update the E820 map with this
> > >   new type. Only perform this classification if the
> > >   CONFIG_EFI_SOFT_RESERVE=y policy is enabled, otherwise treat it as
> > >   typical ram.
> > >
> > > - IORES_DESC_SOFT_RESERVED: Add a new I/O resource descriptor for
> > >   a device driver to search iomem resources for application specific
> > >   memory. Teach the iomem code to identify such ranges as "Soft Reserved".
> > >
> > > A follow-on change integrates parsing of the ACPI HMAT to identify the
> > > node and sub-range boundaries of EFI_MEMORY_SP designated memory. For
> > > now, just identify and reserve memory of this type.
> > >
> > > Cc: 
> > > Cc: Borislav Petkov 
> > > Cc: Ingo Molnar 
> > > Cc: "H. Peter Anvin" 
> > > Cc: Darren Hart 
> > > Cc: Andy Shevchenko 
> > > Cc: Andy Lutomirski 
> > > Cc: Peter Zijlstra 
> > > Cc: Thomas Gleixner 
> > > Cc: Ard Biesheuvel 
> > > Reported-by: kbuild test robot 
> > > Reviewed-by: Dave Hansen 
> > > Signed-off-by: Dan Williams 
> >
> > For the EFI changes
> >
> > Acked-by: Ard Biesheuvel 
> >
> > although I must admit I don't follow the enum add_efi_mode logic 100%
>
> I'm open to suggestions as I'm not sure it's the best possible
> organization. The do_add_efi_memmap() routine has the logic to
> translate EFI to E820, but unless "add_efi_memmap" is specified on the
> kernel command line the EFI memory map is ignored. For
> soft-reservation support I want to reuse do_add_efi_memmap(), but
> otherwise avoid any other side effects of considering the EFI map.
> What I'm missing is the rationale for why "add_efi_memmap" is required
> before considering the EFI memory map.
>
> If there is a negative side effect to always using the EFI map then
> the new "add_efi_mode" designation constrains it to just the
> soft-reservation case.
>

Could we make the presence of any EFI_MEMORY_SP regions imply
add_efi_memmap? That way, it is guaranteed that we don't regress
existing systems, while establishing clear and unambiguous semantics
for new systems that rely on these changes in order to be able to use
the special purpose memory as intended.


Re: [PATCH v6 07/12] x86/efi: Add efi_fake_mem support for EFI_MEMORY_SP

2019-10-10 Thread Ard Biesheuvel
On Thu, 10 Oct 2019 at 01:19, Dan Williams  wrote:
>
> Given that EFI_MEMORY_SP is platform BIOS policy decision for marking
> memory ranges as "reserved for a specific purpose" there will inevitably
> be scenarios where the BIOS omits the attribute in situations where it
> is desired. Unlike other attributes if the OS wants to reserve this
> memory from the kernel the reservation needs to happen early in init. So
> early, in fact, that it needs to happen before e820__memblock_setup()
> which is a pre-requisite for efi_fake_memmap() that wants to allocate
> memory for the updated table.
>
> Introduce an x86 specific efi_fake_memmap_early() that can search for
> attempts to set EFI_MEMORY_SP via efi_fake_mem and update the e820 table
> accordingly.
>
> The KASLR code that scans the command line looking for user-directed
> memory reservations also needs to be updated to consider
> "efi_fake_mem=nn@ss:0x4" requests.
>
> Cc: 
> Cc: Borislav Petkov 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: Thomas Gleixner 
> Cc: Ard Biesheuvel 
> Reviewed-by: Dave Hansen 
> Signed-off-by: Dan Williams 

Acked-by: Ard Biesheuvel 

> ---
>  Documentation/admin-guide/kernel-parameters.txt |   10 +++
>  arch/x86/boot/compressed/kaslr.c|   42 --
>  arch/x86/include/asm/efi.h  |8 +++
>  arch/x86/platform/efi/efi.c |2 +
>  drivers/firmware/efi/Makefile   |5 +-
>  drivers/firmware/efi/fake_mem.c |   24 
>  drivers/firmware/efi/fake_mem.h |   10 +++
>  drivers/firmware/efi/x86_fake_mem.c |   69 
> +++
>  8 files changed, 147 insertions(+), 23 deletions(-)
>  create mode 100644 drivers/firmware/efi/fake_mem.h
>  create mode 100644 drivers/firmware/efi/x86_fake_mem.c
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> b/Documentation/admin-guide/kernel-parameters.txt
> index 47478a730011..9489d76b0e9f 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1196,15 +1196,21 @@
> updating original EFI memory map.
> Region of memory which aa attribute is added to is
> from ss to ss+nn.
> +
> If efi_fake_mem=2G@4G:0x1,2G@0x10a000:0x1
> is specified, EFI_MEMORY_MORE_RELIABLE(0x1)
> attribute is added to range 0x1-0x18000 
> and
> 0x10a000-0x112000.
>
> +   If efi_fake_mem=8G@9G:0x4 is specified, the
> +   EFI_MEMORY_SP(0x4) attribute is added to
> +   range 0x24000-0x43fff.
> +
> Using this parameter you can do debugging of EFI 
> memmap
> -   related feature. For example, you can do debugging of
> +   related features. For example, you can do debugging of
> Address Range Mirroring feature even if your box
> -   doesn't support it.
> +   doesn't support it, or mark specific memory as
> +   "soft reserved".
>
> efivar_ssdt=[EFI; X86] Name of an EFI variable that contains an 
> SSDT
> that is to be dynamically loaded by Linux. If there 
> are
> diff --git a/arch/x86/boot/compressed/kaslr.c 
> b/arch/x86/boot/compressed/kaslr.c
> index ff6fa81949cd..da0eedd5635d 100644
> --- a/arch/x86/boot/compressed/kaslr.c
> +++ b/arch/x86/boot/compressed/kaslr.c
> @@ -132,8 +132,14 @@ char *skip_spaces(const char *str)
>  #include "../../../../lib/ctype.c"
>  #include "../../../../lib/cmdline.c"
>
> +enum parse_mode {
> +   PARSE_MEMMAP,
> +   PARSE_EFI,
> +};
> +
>  static int
> -parse_memmap(char *p, unsigned long long *start, unsigned long long *size)
> +parse_memmap(char *p, unsigned long long *start, unsigned long long *size,
> +   enum parse_mode mode)
>  {
> char *oldp;
>
> @@ -156,8 +162,29 @@ parse_memmap(char *p, unsigned long long *start, 
> unsigned long long *size)
> *start = memparse(p + 1, );
> return 0;
> case '@':
> -   /* memmap=nn@ss specifies usable region, should be skipped */
> -   *size = 0;
> +   if (mode == PARSE_MEMMAP) {
> +   /*
> +* memmap=nn@ss specifies usable regi

Re: [PATCH v6 06/12] arm/efi: EFI soft reservation to memblock

2019-10-10 Thread Ard Biesheuvel
On Thu, 10 Oct 2019 at 01:19, Dan Williams  wrote:
>
> UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the
> interpretation of the EFI Memory Types as "reserved for a specific
> purpose".
>
> The proposed Linux behavior for specific purpose memory is that it is
> reserved for direct-access (device-dax) by default and not available for
> any kernel usage, not even as an OOM fallback.  Later, through udev
> scripts or another init mechanism, these device-dax claimed ranges can
> be reconfigured and hot-added to the available System-RAM with a unique
> node identifier. This device-dax management scheme implements "soft" in
> the "soft reserved" designation by allowing some or all of the
> reservation to be recovered as typical memory. This policy can be
> disabled at compile-time with CONFIG_EFI_SOFT_RESERVE=n, or runtime with
> efi=nosoftreserve.
>
> For this patch, update the ARM paths that consider
> EFI_CONVENTIONAL_MEMORY to optionally take the EFI_MEMORY_SP attribute
> into account as a reservation indicator. Publish the soft reservation as
> IORES_DESC_SOFT_RESERVED memory, similar to x86.
>
> (Based on an original patch by Ard)
>
> Cc: Will Deacon 
> Cc: Catalin Marinas 
> Cc: Ard Biesheuvel 
> Signed-off-by: Dan Williams 

Reviewed-by: Ard Biesheuvel 

> ---
>  arch/arm64/mm/mmu.c   |2 ++
>  drivers/firmware/efi/arm-init.c   |9 +
>  drivers/firmware/efi/arm-runtime.c|   24 
>  drivers/firmware/efi/libstub/arm32-stub.c |5 +
>  drivers/firmware/efi/libstub/random.c |4 
>  5 files changed, 44 insertions(+)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 60c929f3683b..2c385fe05fde 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -1061,6 +1061,8 @@ int arch_add_memory(int nid, u64 start, u64 size,
> __create_pgd_mapping(swapper_pg_dir, start, __phys_to_virt(start),
>  size, PAGE_KERNEL, __pgd_pgtable_alloc, flags);
>
> +   memblock_clear_nomap(start, size);
> +
> return __add_pages(nid, start >> PAGE_SHIFT, size >> PAGE_SHIFT,
>restrictions);
>  }
> diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
> index 311cd349a862..904fa09e6a6b 100644
> --- a/drivers/firmware/efi/arm-init.c
> +++ b/drivers/firmware/efi/arm-init.c
> @@ -163,6 +163,15 @@ static __init int is_usable_memory(efi_memory_desc_t *md)
> case EFI_BOOT_SERVICES_DATA:
> case EFI_CONVENTIONAL_MEMORY:
> case EFI_PERSISTENT_MEMORY:
> +   /*
> +* Special purpose memory is 'soft reserved', which means it
> +* is set aside initially, but can be hotplugged back in or
> +* be assigned to the dax driver after boot.
> +*/
> +   if (efi_soft_reserve_enabled() &&
> +   (md->attribute & EFI_MEMORY_SP))
> +   return false;
> +
> /*
>  * According to the spec, these regions are no longer reserved
>  * after calling ExitBootServices(). However, we can only use
> diff --git a/drivers/firmware/efi/arm-runtime.c 
> b/drivers/firmware/efi/arm-runtime.c
> index e2ac5fa5531b..899b803842bb 100644
> --- a/drivers/firmware/efi/arm-runtime.c
> +++ b/drivers/firmware/efi/arm-runtime.c
> @@ -121,6 +121,30 @@ static int __init arm_enable_runtime_services(void)
> return 0;
> }
>
> +   if (efi_soft_reserve_enabled()) {
> +   efi_memory_desc_t *md;
> +
> +   for_each_efi_memory_desc(md) {
> +   int md_size = md->num_pages << EFI_PAGE_SHIFT;
> +   struct resource *res;
> +
> +   if (!(md->attribute & EFI_MEMORY_SP))
> +   continue;
> +
> +   res = kzalloc(sizeof(*res), GFP_KERNEL);
> +   if (WARN_ON(!res))
> +   break;
> +
> +   res->start  = md->phys_addr;
> +   res->end= md->phys_addr + md_size - 1;
> +   res->name   = "Soft Reserved";
> +   res->flags  = IORESOURCE_MEM;
> +   res->desc   = IORES_DESC_SOFT_RESERVED;
> +
> +   insert_resource(_resource, res);
> +   }
> +   }
> +
> if (efi_runtime_disabled()) {
> pr_info("

Re: [PATCH v6 05/12] x86/efi: EFI soft reservation to E820 enumeration

2019-10-10 Thread Ard Biesheuvel
On Thu, 10 Oct 2019 at 01:19, Dan Williams  wrote:
>
> UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the
> interpretation of the EFI Memory Types as "reserved for a specific
> purpose".
>
> The proposed Linux behavior for specific purpose memory is that it is
> reserved for direct-access (device-dax) by default and not available for
> any kernel usage, not even as an OOM fallback.  Later, through udev
> scripts or another init mechanism, these device-dax claimed ranges can
> be reconfigured and hot-added to the available System-RAM with a unique
> node identifier. This device-dax management scheme implements "soft" in
> the "soft reserved" designation by allowing some or all of the
> reservation to be recovered as typical memory. This policy can be
> disabled at compile-time with CONFIG_EFI_SOFT_RESERVE=n, or runtime with
> efi=nosoftreserve.
>
> This patch introduces 2 new concepts at once given the entanglement
> between early boot enumeration relative to memory that can optionally be
> reserved from the kernel page allocator by default. The new concepts
> are:
>
> - E820_TYPE_SOFT_RESERVED: Upon detecting the EFI_MEMORY_SP
>   attribute on EFI_CONVENTIONAL memory, update the E820 map with this
>   new type. Only perform this classification if the
>   CONFIG_EFI_SOFT_RESERVE=y policy is enabled, otherwise treat it as
>   typical ram.
>
> - IORES_DESC_SOFT_RESERVED: Add a new I/O resource descriptor for
>   a device driver to search iomem resources for application specific
>   memory. Teach the iomem code to identify such ranges as "Soft Reserved".
>
> A follow-on change integrates parsing of the ACPI HMAT to identify the
> node and sub-range boundaries of EFI_MEMORY_SP designated memory. For
> now, just identify and reserve memory of this type.
>
> Cc: 
> Cc: Borislav Petkov 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: Darren Hart 
> Cc: Andy Shevchenko 
> Cc: Andy Lutomirski 
> Cc: Peter Zijlstra 
> Cc: Thomas Gleixner 
> Cc: Ard Biesheuvel 
> Reported-by: kbuild test robot 
> Reviewed-by: Dave Hansen 
> Signed-off-by: Dan Williams 

For the EFI changes

Acked-by: Ard Biesheuvel 

although I must admit I don't follow the enum add_efi_mode logic 100%


> ---
>  arch/x86/boot/compressed/eboot.c  |6 -
>  arch/x86/boot/compressed/kaslr.c  |4 +++
>  arch/x86/include/asm/e820/types.h |8 ++
>  arch/x86/kernel/e820.c|   12 -
>  arch/x86/platform/efi/efi.c   |   48 
> +
>  include/linux/ioport.h|1 +
>  6 files changed, 71 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/boot/compressed/eboot.c 
> b/arch/x86/boot/compressed/eboot.c
> index d6662fdef300..f3b03229c44c 100644
> --- a/arch/x86/boot/compressed/eboot.c
> +++ b/arch/x86/boot/compressed/eboot.c
> @@ -553,7 +553,11 @@ setup_e820(struct boot_params *params, struct setup_data 
> *e820ext, u32 e820ext_s
> case EFI_BOOT_SERVICES_CODE:
> case EFI_BOOT_SERVICES_DATA:
> case EFI_CONVENTIONAL_MEMORY:
> -   e820_type = E820_TYPE_RAM;
> +   if (efi_soft_reserve_enabled() &&
> +   (d->attribute & EFI_MEMORY_SP))
> +   e820_type = E820_TYPE_SOFT_RESERVED;
> +   else
> +   e820_type = E820_TYPE_RAM;
> break;
>
> case EFI_ACPI_MEMORY_NVS:
> diff --git a/arch/x86/boot/compressed/kaslr.c 
> b/arch/x86/boot/compressed/kaslr.c
> index 2e53c056ba20..ff6fa81949cd 100644
> --- a/arch/x86/boot/compressed/kaslr.c
> +++ b/arch/x86/boot/compressed/kaslr.c
> @@ -760,6 +760,10 @@ process_efi_entries(unsigned long minimum, unsigned long 
> image_size)
> if (md->type != EFI_CONVENTIONAL_MEMORY)
> continue;
>
> +   if (efi_soft_reserve_enabled() &&
> +   (md->attribute & EFI_MEMORY_SP))
> +   continue;
> +
> if (efi_mirror_found &&
> !(md->attribute & EFI_MEMORY_MORE_RELIABLE))
> continue;
> diff --git a/arch/x86/include/asm/e820/types.h 
> b/arch/x86/include/asm/e820/types.h
> index c3aa4b5e49e2..314f75d886d0 100644
> --- a/arch/x86/include/asm/e820/types.h
> +++ b/arch/x86/include/asm/e820/types.h
> @@ -28,6 +28,14 @@ enum e820_type {
>  */
> E820_TYPE_PRAM  = 12,
>
> +   /*
> +* Special-purpose memory is indicated to the system via the
> +* E

Re: [PATCH v6 04/12] efi: Common enable/disable infrastructure for EFI soft reservation

2019-10-10 Thread Ard Biesheuvel
On Thu, 10 Oct 2019 at 01:19, Dan Williams  wrote:
>
> UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the
> interpretation of the EFI Memory Types as "reserved for a specific
> purpose".
>
> The proposed Linux behavior for specific purpose memory is that it is
> reserved for direct-access (device-dax) by default and not available for
> any kernel usage, not even as an OOM fallback.  Later, through udev
> scripts or another init mechanism, these device-dax claimed ranges can
> be reconfigured and hot-added to the available System-RAM with a unique
> node identifier. This device-dax management scheme implements "soft" in
> the "soft reserved" designation by allowing some or all of the
> reservation to be recovered as typical memory. This policy can be
> disabled at compile-time with CONFIG_EFI_SOFT_RESERVE=n, or runtime with
> efi=nosoftreserve.
>
> As for this patch, define the common helpers to determine if the
> EFI_MEMORY_SP attribute should be honored. The determination needs to be
> made early to prevent the kernel from being loaded into soft-reserved
> memory, or otherwise allowing early allocations to land there. Follow-on
> changes are needed per architecture to leverage these helpers in their
> respective mem-init paths.
>
> Cc: Ard Biesheuvel 
> Signed-off-by: Dan Williams 

Reviewed-by: Ard Biesheuvel 

> ---
>  Documentation/admin-guide/kernel-parameters.txt |9 -
>  drivers/firmware/efi/Kconfig|   21 +
>  drivers/firmware/efi/efi.c  |9 +
>  drivers/firmware/efi/libstub/efi-stub-helper.c  |   19 +++
>  include/linux/efi.h |8 
>  5 files changed, 65 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> b/Documentation/admin-guide/kernel-parameters.txt
> index c7ac2f3ac99f..47478a730011 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1168,7 +1168,8 @@
> Format: {"off" | "on" | "skip[mbr]"}
>
> efi=[EFI]
> -   Format: { "old_map", "nochunk", "noruntime", "debug" }
> +   Format: { "old_map", "nochunk", "noruntime", "debug",
> + "nosoftreserve" }
> old_map [X86-64]: switch to the old ioremap-based EFI
> runtime services mapping. 32-bit still uses this one 
> by
> default.
> @@ -1177,6 +1178,12 @@
> firmware implementations.
> noruntime : disable EFI runtime services support
> debug: enable misc debug output
> +   nosoftreserve: The EFI_MEMORY_SP (Specific Purpose)
> +   attribute may cause the kernel to reserve the
> +   memory range for a memory mapping driver to
> +   claim. Specify efi=nosoftreserve to disable this
> +   reservation and treat the memory by its base type
> +   (i.e. EFI_CONVENTIONAL_MEMORY / "System RAM").
>
> efi_no_storage_paranoia [EFI; X86]
> Using this parameter you can use more than 50% of
> diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
> index 178ee8106828..9fa79f9fa0af 100644
> --- a/drivers/firmware/efi/Kconfig
> +++ b/drivers/firmware/efi/Kconfig
> @@ -75,6 +75,27 @@ config EFI_MAX_FAKE_MEM
>   Ranges can be set up to this value using comma-separated list.
>   The default value is 8.
>
> +config EFI_SOFT_RESERVE
> +   bool "Reserve EFI Specific Purpose Memory"
> +   depends on EFI && ACPI_HMAT
> +   default ACPI_HMAT
> +   help
> + On systems that have mixed performance classes of memory EFI
> + may indicate specific purpose memory with an attribute (See
> + EFI_MEMORY_SP in UEFI 2.8). A memory range tagged with this
> + attribute may have unique performance characteristics compared
> + to the system's general purpose "System RAM" pool. On the
> + expectation that such memory has application specific usage,
> + and its base EFI memory type is "conventional" answer Y to
> + arrange for the kernel to reserve it as a "Soft Reserved"
> + resource, and set aside for direct-access (device-dax) by
> + default. The mem

Re: [PATCH] Ask user input only when CONFIG_X86 or CONFIG_COMPILE_TEST is set to y

2019-10-09 Thread Ard Biesheuvel
Hello Narendra,

On Wed, 2 Oct 2019 at 21:44,  wrote:
>
> From: Narendra K 
>
> For the EFI_RCI2_TABLE kconfig option, 'make oldconfig' asks the user
> for input as it is a new kconfig option in kernel version 5.4. This patch
> modifies the kconfig option to ask the user for input only when CONFIG_X86
> or CONFIG_COMPILE_TEST is set to y.
>
> The patch also makes EFI_RCI2_TABLE kconfig option depend on CONFIG_EFI.
>
> Signed-off-by: Narendra K 
> ---
> The patch is created on kernel version 5.4-rc1.
>
> Hi Ard, I have made following changes -
>
> - changed the prompt string from "EFI Runtime Configuration
> Interface Table Version 2 Support" to "EFI RCI Table Version 2 Support"
> as the string crossed 80 char limit.
>
> - added "depends on EFI" so that code builds only when CONFIG_EFI is
> set to y.
>
> - added 'default n' for ease of understanding though default is set to n.
>

None of these changes are necessary, tbh. 'depends on EFI' is implied
by the placement of the option, and default n is indeed the default.


>  drivers/firmware/efi/Kconfig | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
> index 178ee8106828..6e4c46e8a954 100644
> --- a/drivers/firmware/efi/Kconfig
> +++ b/drivers/firmware/efi/Kconfig
> @@ -181,7 +181,10 @@ config RESET_ATTACK_MITIGATION
>   reboots.
>
>  config EFI_RCI2_TABLE
> -   bool "EFI Runtime Configuration Interface Table Version 2 Support"
> +   bool
> +   prompt "EFI RCI Table Version 2 Support" if X86 || COMPILE_TEST

You can drop the || COMPILE_TEST as well.
> +   depends on EFI
> +   default n
> help
>   Displays the content of the Runtime Configuration Interface
>   Table version 2 on Dell EMC PowerEdge systems as a binary
> --
> 2.18.1
>
> --
> With regards,
> Narendra K


Re: [RFC PATCH] arch/x86: efistub: Invoke EFI_RNG_PROTOCOL to seed the UEFI RNG table

2019-10-09 Thread Ard Biesheuvel
On Sat, 5 Oct 2019 at 13:38, Dominik Brodowski
 wrote:
>
> Implement the same mechanism for x86 efistub as introduced by commit
> 568bc4e87033 ("efi/arm*/libstub: Invoke EFI_RNG_PROTOCOL to seed the
> UEFI RNG table") for efi/arm*/libstub, and best described here and there
> as:
>
> Invoke the EFI_RNG_PROTOCOL protocol in the context of the stub and
> install the Linux-specific RNG seed UEFI config table. This will be
> picked up by the EFI routines in the core kernel to seed the kernel
> entropy pool.
>
> Signed-off-by: Dominik Brodowski 
> Cc: Ard Biesheuvel 
> Cc: Hsin-Yi Wang 
> Cc: Stephen Boyd 
> Cc: Rob Herring 
> Cc: Theodore Ts'o 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: Borislav Petkov 
> Cc: "H. Peter Anvin" 
> Cc: 
>
> ---
>
> As far as I can see, we do not yet make use of the UEFI RNG on x86 at all,
> but only on arm.

If you have a ChaosKey, you may be able to use this driver

http://people.linaro.org/~ard.biesheuvel/ChaosKey/ChaosKeyDxe.efi

to get UEFI to expose the EFI_RNG_PROTOCOL. (Use efibootmgr -r to
install it as Driver or load it from the UEFI shell using 'load
xxx.efi')

> Note that this works only when Linux is booted as an EFI
> stub, and that the EFI-provided randomness is not credited as entropy
> unless RANDOM_TRUST_BOOTLOADER is set _and_ another patch (on its way
> upstream; thanks Ard!) is applied, see
> 
> https://lore.kernel.org/lkml/20190928101428.ga222...@light.dominikbrodowski.net/
>
> Further note that this patch is untested, as the firmware on my old x86
> laptop only has UEFI v2.31. If you want to test it, you may wish to apply
> 
> https://lore.kernel.org/lkml/20191005113632.ga74...@light.dominikbrodowski.net/T/#u
> first to get a clear indication in dmesg.
>


>
> diff --git a/arch/x86/boot/compressed/eboot.c 
> b/arch/x86/boot/compressed/eboot.c
> index d6662fdef300..4b909e5ab857 100644
> --- a/arch/x86/boot/compressed/eboot.c
> +++ b/arch/x86/boot/compressed/eboot.c
> @@ -781,6 +781,9 @@ efi_main(struct efi_config *c, struct boot_params 
> *boot_params)
>
> /* Ask the firmware to clear memory on unclean shutdown */
> efi_enable_reset_attack_mitigation(sys_table);
> +
> +   efi_random_get_seed(sys_table);
> +
> efi_retrieve_tpm2_eventlog(sys_table);
>
> setup_graphics(boot_params);
> diff --git a/drivers/firmware/efi/libstub/Makefile 
> b/drivers/firmware/efi/libstub/Makefile
> index 0460c7581220..ece24c60fc2c 100644
> --- a/drivers/firmware/efi/libstub/Makefile
> +++ b/drivers/firmware/efi/libstub/Makefile
> @@ -38,7 +38,8 @@ OBJECT_FILES_NON_STANDARD := y
>  # Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
>  KCOV_INSTRUMENT:= n
>
> -lib-y  := efi-stub-helper.o gop.o secureboot.o tpm.o
> +lib-y  := efi-stub-helper.o gop.o secureboot.o tpm.o 
> \
> +  random.o
>
>  # include the stub's generic dependencies from lib/ when building for 
> ARM/arm64
>  arm-deps-y := fdt_rw.c fdt_ro.c fdt_wip.c fdt.c fdt_empty_tree.c fdt_sw.c
> @@ -47,7 +48,7 @@ arm-deps-$(CONFIG_ARM64) += sort.c
>  $(obj)/lib-%.o: $(srctree)/lib/%.c FORCE
> $(call if_changed_rule,cc_o_c)
>
> -lib-$(CONFIG_EFI_ARMSTUB)  += arm-stub.o fdt.o string.o random.o \
> +lib-$(CONFIG_EFI_ARMSTUB)  += arm-stub.o fdt.o string.o \
>$(patsubst %.c,lib-%.o,$(arm-deps-y))
>
>  lib-$(CONFIG_ARM)  += arm32-stub.o
> diff --git a/drivers/firmware/efi/libstub/efistub.h 
> b/drivers/firmware/efi/libstub/efistub.h
> index 7f1556fd867d..05739ae013c8 100644
> --- a/drivers/firmware/efi/libstub/efistub.h
> +++ b/drivers/firmware/efi/libstub/efistub.h
> @@ -63,8 +63,6 @@ efi_status_t efi_random_alloc(efi_system_table_t 
> *sys_table_arg,
>
>  efi_status_t check_platform_features(efi_system_table_t *sys_table_arg);
>
> -efi_status_t efi_random_get_seed(efi_system_table_t *sys_table_arg);
> -
>  void *get_efi_config_table(efi_system_table_t *sys_table, efi_guid_t guid);
>
>  /* Helper macros for the usual case of using simple C variables: */
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index bd3837022307..a17cc5841668 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -1631,6 +1631,8 @@ static inline void
>  efi_enable_reset_attack_mitigation(efi_system_table_t *sys_table_arg) { }
>  #endif
>
> +efi_status_t efi_random_get_seed(efi_system_table_t *sys_table_arg);
> +
>  void efi_retrieve_tpm2_eventlog(efi_system_table_t *sys_table);
>
>  /*


Re: [PATCH v2] efi/efi_test: lock down /dev/efi_test and require CAP_SYS_ADMIN

2019-10-09 Thread Ard Biesheuvel
On Wed, 9 Oct 2019 at 04:18, Matthew Garrett  wrote:
>
> On Tue, Oct 8, 2019 at 9:55 PM Javier Martinez Canillas
>  wrote:
> > Signed-off-by: Javier Martinez Canillas 
> > Acked-by: Laszlo Ersek 
>
> Acked-by: Matthew Garrett 

Thanks all. Queued as a fix.


[tip: efi/urgent] efivar/ssdt: Don't iterate over EFI vars if no SSDT override was specified

2019-10-07 Thread tip-bot2 for Ard Biesheuvel
The following commit has been merged into the efi/urgent branch of tip:

Commit-ID: c05f8f92b701576b615f30aac31fabdc0648649b
Gitweb:
https://git.kernel.org/tip/c05f8f92b701576b615f30aac31fabdc0648649b
Author:Ard Biesheuvel 
AuthorDate:Wed, 02 Oct 2019 18:58:59 +02:00
Committer: Ingo Molnar 
CommitterDate: Mon, 07 Oct 2019 15:24:35 +02:00

efivar/ssdt: Don't iterate over EFI vars if no SSDT override was specified

The kernel command line option efivar_ssdt= allows the name to be
specified of an EFI variable containing an ACPI SSDT table that should
be loaded into memory by the OS, and treated as if it was provided by
the firmware.

Currently, that code will always iterate over the EFI variables and
compare each name with the provided name, even if the command line
option wasn't set to begin with.

So bail early when no variable name was provided. This works around a
boot regression on the 2012 Mac Pro, as reported by Scott.

Tested-by: Scott Talbert 
Signed-off-by: Ard Biesheuvel 
Cc:  # v4.9+
Cc: Ben Dooks 
Cc: Dave Young 
Cc: Jarkko Sakkinen 
Cc: Jerry Snitselaar 
Cc: Linus Torvalds 
Cc: Lukas Wunner 
Cc: Lyude Paul 
Cc: Matthew Garrett 
Cc: Octavian Purdila 
Cc: Peter Jones 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Cc: linux-integr...@vger.kernel.org
Fixes: 475fb4e8b2f4 ("efi / ACPI: load SSTDs from EFI variables")
Link: https://lkml.kernel.org/r/20191002165904.8819-3-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
---
 drivers/firmware/efi/efi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 8d3e778..69f00f7 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -267,6 +267,9 @@ static __init int efivar_ssdt_load(void)
void *data;
int ret;
 
+   if (!efivar_ssdt[0])
+   return 0;
+
ret = efivar_init(efivar_ssdt_iter, , true, );
 
list_for_each_entry_safe(entry, aux, , list) {


[PATCH 6/7] efi: make unexported efi_rci2_sysfs_init static

2019-10-02 Thread Ard Biesheuvel
From: Ben Dooks 

The efi_rci2_sysfs_init() is not used outside of rci2-table.c so
make it static to silence the following sparse warning:

drivers/firmware/efi/rci2-table.c:79:12: warning: symbol 'efi_rci2_sysfs_init' 
was not declared. Should it be static?

Signed-off-by: Ben Dooks 
Signed-off-by: Ard Biesheuvel 
---
 drivers/firmware/efi/rci2-table.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/rci2-table.c 
b/drivers/firmware/efi/rci2-table.c
index 3e290f96620a..76b0c354a027 100644
--- a/drivers/firmware/efi/rci2-table.c
+++ b/drivers/firmware/efi/rci2-table.c
@@ -76,7 +76,7 @@ static u16 checksum(void)
return chksum;
 }
 
-int __init efi_rci2_sysfs_init(void)
+static int __init efi_rci2_sysfs_init(void)
 {
struct kobject *tables_kobj;
int ret = -ENOMEM;
-- 
2.20.1



[PATCH 2/7] efivar/ssdt: don't iterate over EFI vars if no SSDT override was specified

2019-10-02 Thread Ard Biesheuvel
The kernel command line option efivar_ssdt= allows the name to be
specified of an EFI variable containing an ACPI SSDT table that should
be loaded into memory by the OS, and treated as if it was provided by
the firmware.

Currently, that code will always iterate over the EFI variables and
compare each name with the provided name, even if the command line
option wasn't set to begin with.

So bail early when no variable name was provided. This works around a
boot regression on the 2012 Mac Pro, as reported by Scott.

Fixes: 475fb4e8b2f4 ("efi / ACPI: load SSTDs from EFI variables")
Cc:  # v4.9+
Cc: Octavian Purdila 
Tested-by: Scott Talbert 
Signed-off-by: Ard Biesheuvel 
---
 drivers/firmware/efi/efi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 8d3e778e988b..69f00f7453a3 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -267,6 +267,9 @@ static __init int efivar_ssdt_load(void)
void *data;
int ret;
 
+   if (!efivar_ssdt[0])
+   return 0;
+
ret = efivar_init(efivar_ssdt_iter, , true, );
 
list_for_each_entry_safe(entry, aux, , list) {
-- 
2.20.1



[PATCH 3/7] efi/tpm: Don't access event->count when it isn't mapped.

2019-10-02 Thread Ard Biesheuvel
From: Peter Jones 

Some machines generate a lot of event log entries.  When we're
iterating over them, the code removes the old mapping and adds a
new one, so once we cross the page boundary we're unmapping the page
with the count on it.  Hilarity ensues.

This patch keeps the info from the header in local variables so we don't
need to access that page again or keep track of if it's mapped.

Fixes: 44038bc514a2 ("tpm: Abstract crypto agile event size calculations")
Cc: linux-efi@vger.kernel.org
Cc: linux-integr...@vger.kernel.org
Cc: sta...@vger.kernel.org
Signed-off-by: Peter Jones 
Tested-by: Lyude Paul 
Reviewed-by: Jarkko Sakkinen 
Acked-by: Matthew Garrett 
Acked-by: Ard Biesheuvel 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: Ard Biesheuvel 
---
 include/linux/tpm_eventlog.h | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/include/linux/tpm_eventlog.h b/include/linux/tpm_eventlog.h
index 63238c84dc0b..12584b69a3f3 100644
--- a/include/linux/tpm_eventlog.h
+++ b/include/linux/tpm_eventlog.h
@@ -170,6 +170,7 @@ static inline int __calc_tpm2_event_size(struct 
tcg_pcr_event2_head *event,
u16 halg;
int i;
int j;
+   u32 count, event_type;
 
marker = event;
marker_start = marker;
@@ -190,16 +191,22 @@ static inline int __calc_tpm2_event_size(struct 
tcg_pcr_event2_head *event,
}
 
event = (struct tcg_pcr_event2_head *)mapping;
+   /*
+* the loop below will unmap these fields if the log is larger than
+* one page, so save them here for reference.
+*/
+   count = READ_ONCE(event->count);
+   event_type = READ_ONCE(event->event_type);
 
efispecid = (struct tcg_efi_specid_event_head *)event_header->event;
 
/* Check if event is malformed. */
-   if (event->count > efispecid->num_algs) {
+   if (count > efispecid->num_algs) {
size = 0;
goto out;
}
 
-   for (i = 0; i < event->count; i++) {
+   for (i = 0; i < count; i++) {
halg_size = sizeof(event->digests[i].alg_id);
 
/* Map the digest's algorithm identifier */
@@ -256,8 +263,9 @@ static inline int __calc_tpm2_event_size(struct 
tcg_pcr_event2_head *event,
+ event_field->event_size;
size = marker - marker_start;
 
-   if ((event->event_type == 0) && (event_field->event_size == 0))
+   if (event_type == 0 && event_field->event_size == 0)
size = 0;
+
 out:
if (do_mapping)
TPM_MEMUNMAP(mapping, mapping_size);
-- 
2.20.1



[PATCH 5/7] efi/tpm: only set efi_tpm_final_log_size after successful event log parsing

2019-10-02 Thread Ard Biesheuvel
.

Fixes: c46f3405692de ("tpm: Reserve the TPM final events table")
Cc: linux-efi@vger.kernel.org
Cc: linux-integr...@vger.kernel.org
Cc: sta...@vger.kernel.org
Cc: Matthew Garrett 
Cc: Ard Biesheuvel 
Cc: Jarkko Sakkinen 
Signed-off-by: Jerry Snitselaar 
Signed-off-by: Ard Biesheuvel 
---
 drivers/firmware/efi/tpm.c   | 9 -
 include/linux/tpm_eventlog.h | 2 +-
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/efi/tpm.c b/drivers/firmware/efi/tpm.c
index b9ae5c6f9b9c..703469c1ab8e 100644
--- a/drivers/firmware/efi/tpm.c
+++ b/drivers/firmware/efi/tpm.c
@@ -85,11 +85,18 @@ int __init efi_tpm_eventlog_init(void)
final_tbl->nr_events,
log_tbl->log);
}
+
+   if (tbl_size < 0) {
+   pr_err(FW_BUG "Failed to parse event in TPM Final Events 
Log\n");
+   goto out_calc;
+   }
+
memblock_reserve((unsigned long)final_tbl,
 tbl_size + sizeof(*final_tbl));
-   early_memunmap(final_tbl, sizeof(*final_tbl));
efi_tpm_final_log_size = tbl_size;
 
+out_calc:
+   early_memunmap(final_tbl, sizeof(*final_tbl));
 out:
early_memunmap(log_tbl, sizeof(*log_tbl));
return ret;
diff --git a/include/linux/tpm_eventlog.h b/include/linux/tpm_eventlog.h
index 12584b69a3f3..2dfdd63ac034 100644
--- a/include/linux/tpm_eventlog.h
+++ b/include/linux/tpm_eventlog.h
@@ -152,7 +152,7 @@ struct tcg_algorithm_info {
  * total. Once we've done this we know the offset of the data length field,
  * and can calculate the total size of the event.
  *
- * Return: size of the event on success, <0 on failure
+ * Return: size of the event on success, 0 on failure
  */
 
 static inline int __calc_tpm2_event_size(struct tcg_pcr_event2_head *event,
-- 
2.20.1



[GIT PULL 0/7] EFI fixes for v5.4

2019-10-02 Thread Ard Biesheuvel
The following changes since commit 54ecb8f7028c5eb3d740bb82b0f1d90f2df63c5c:

  Linux 5.4-rc1 (2019-09-30 10:35:40 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-urgent

for you to fetch changes up to d45bb93ac68495a8c53126742b4d2223101cfb7f:

  efi/x86: do not clean dummy variable in kexec path (2019-10-02 18:44:23 +0200)


A couple of EFI fixes for v5.4:
- a cosmetic fix for the byte order of PCI class codes in CPER error reports
- bail early instead of pointlessly iterating over all EFI variables looking
  for the one containing a supplementary ACPI SSDT table if we never specified
  a variable name to begin with
- some fixes for TPM event log parsing
- fix kexec hangs on OVMF/x86 caused by attempts to delete a dummy variable
  which shouldn't even exist at that point.


Ard Biesheuvel (1):
  efivar/ssdt: don't iterate over EFI vars if no SSDT override was specified

Ben Dooks (1):
  efi: make unexported efi_rci2_sysfs_init static

Dave Young (1):
  efi/x86: do not clean dummy variable in kexec path

Jerry Snitselaar (1):
  efi/tpm: only set efi_tpm_final_log_size after successful event log 
parsing

Lukas Wunner (1):
  efi: cper: Fix endianness of PCIe class code

Peter Jones (2):
  efi/tpm: Don't access event->count when it isn't mapped.
  efi/tpm: don't traverse an event log with no events

 arch/x86/platform/efi/efi.c   |  3 ---
 drivers/firmware/efi/cper.c   |  2 +-
 drivers/firmware/efi/efi.c|  3 +++
 drivers/firmware/efi/rci2-table.c |  2 +-
 drivers/firmware/efi/tpm.c| 24 ++--
 include/linux/tpm_eventlog.h  | 16 
 6 files changed, 35 insertions(+), 15 deletions(-)


[PATCH 7/7] efi/x86: do not clean dummy variable in kexec path

2019-10-02 Thread Ard Biesheuvel
From: Dave Young 

kexec reboot fails randomly in UEFI based kvm guest.  The firmware
just reset while calling efi_delete_dummy_variable();  Unfortunately
I don't know how to debug the firmware, it is also possible a potential
problem on real hardware as well although nobody reproduced it.

The intention of efi_delete_dummy_variable is to trigger garbage collection
when entering virtual mode.  But SetVirtualAddressMap can only run once
for each physical reboot, thus kexec_enter_virtual_mode is not necessarily
a good place to clean dummy object.

Drop efi_delete_dummy_variable so that kexec reboot can work.

Signed-off-by: Dave Young 
Acked-by: Matthew Garrett 
Signed-off-by: Ard Biesheuvel 
---
 arch/x86/platform/efi/efi.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index c202e1b07e29..425e025341db 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -917,9 +917,6 @@ static void __init kexec_enter_virtual_mode(void)
 
if (efi_enabled(EFI_OLD_MEMMAP) && (__supported_pte_mask & _PAGE_NX))
runtime_code_page_mkexec();
-
-   /* clean DUMMY object */
-   efi_delete_dummy_variable();
 #endif
 }
 
-- 
2.20.1



[PATCH 4/7] efi/tpm: don't traverse an event log with no events

2019-10-02 Thread Ard Biesheuvel
From: Peter Jones 

When there are no entries to put into the final event log, some machines
will return the template they would have populated anyway.  In this case
the nr_events field is 0, but the rest of the log is just garbage.

This patch stops us from trying to iterate the table with
__calc_tpm2_event_size() when the number of events in the table is 0.

Fixes: c46f3405692d ("tpm: Reserve the TPM final events table")
Cc: linux-efi@vger.kernel.org
Cc: linux-integr...@vger.kernel.org
Cc: sta...@vger.kernel.org
Signed-off-by: Peter Jones 
Tested-by: Lyude Paul 
Reviewed-by: Jarkko Sakkinen 
Acked-by: Matthew Garrett 
Acked-by: Ard Biesheuvel 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: Ard Biesheuvel 
---
 drivers/firmware/efi/tpm.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/firmware/efi/tpm.c b/drivers/firmware/efi/tpm.c
index 1d3f5ca3eaaf..b9ae5c6f9b9c 100644
--- a/drivers/firmware/efi/tpm.c
+++ b/drivers/firmware/efi/tpm.c
@@ -75,11 +75,16 @@ int __init efi_tpm_eventlog_init(void)
goto out;
}
 
-   tbl_size = tpm2_calc_event_log_size((void *)efi.tpm_final_log
-   + sizeof(final_tbl->version)
-   + sizeof(final_tbl->nr_events),
-   final_tbl->nr_events,
-   log_tbl->log);
+   tbl_size = 0;
+   if (final_tbl->nr_events != 0) {
+   void *events = (void *)efi.tpm_final_log
+   + sizeof(final_tbl->version)
+   + sizeof(final_tbl->nr_events);
+
+   tbl_size = tpm2_calc_event_log_size(events,
+   final_tbl->nr_events,
+   log_tbl->log);
+   }
memblock_reserve((unsigned long)final_tbl,
 tbl_size + sizeof(*final_tbl));
early_memunmap(final_tbl, sizeof(*final_tbl));
-- 
2.20.1



[PATCH 1/7] efi: cper: Fix endianness of PCIe class code

2019-10-02 Thread Ard Biesheuvel
From: Lukas Wunner 

The CPER parser assumes that the class code is big endian, but at least
on this edk2-derived Intel Purley platform it's little endian:

efi: EFI v2.50 by EDK II BIOS ID:PLYDCRB1.86B.0119.R05.1701181843
DMI: Intel Corporation PURLEY/PURLEY, BIOS PLYDCRB1.86B.0119.R05.1701181843 
01/18/2017

{1}[Hardware Error]:   device_id: :5d:00.0
{1}[Hardware Error]:   slot: 0
{1}[Hardware Error]:   secondary_bus: 0x5e
{1}[Hardware Error]:   vendor_id: 0x8086, device_id: 0x2030
{1}[Hardware Error]:   class_code: 000406
   ^^ (should be 060400)

Signed-off-by: Lukas Wunner 
Signed-off-by: Ard Biesheuvel 
---
 drivers/firmware/efi/cper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
index addf0749dd8b..b1af0de2e100 100644
--- a/drivers/firmware/efi/cper.c
+++ b/drivers/firmware/efi/cper.c
@@ -381,7 +381,7 @@ static void cper_print_pcie(const char *pfx, const struct 
cper_sec_pcie *pcie,
printk("%s""vendor_id: 0x%04x, device_id: 0x%04x\n", pfx,
   pcie->device_id.vendor_id, pcie->device_id.device_id);
p = pcie->device_id.class_code;
-   printk("%s""class_code: %02x%02x%02x\n", pfx, p[0], p[1], p[2]);
+   printk("%s""class_code: %02x%02x%02x\n", pfx, p[2], p[1], p[0]);
}
if (pcie->validation_bits & CPER_PCIE_VALID_SERIAL_NUMBER)
printk("%s""serial number: 0x%04x, 0x%04x\n", pfx,
-- 
2.20.1



Re: 5.3.1: x86: efi stub seems to fail to load initrd file

2019-10-02 Thread Ard Biesheuvel
On Wed, 2 Oct 2019 at 00:42, Thomas Meyer  wrote:
>
> Hi,
>
> I've got this old x86 MacBookPro1,1 and I wanted to switch to systemd-boot.
>
> systemd-boot works fine but the Linux efistub somehow fails to load the 
> initrd, sadly the monitor seems to be switched off/no backlight after 
> systemd-boot menu selection and Linux kernel starting efifb.
>
> Any ideas what could be the culprit?
> I tried to boot with efi=nochunk but same result.
>
> I tried to understand what systemd boot does for file loading and what 
> libefistub does, it looks very similar.
>
> So any ideas and hints are welcome what is maybe wrong in my setup.
>
> When I embedded the initramfs in the kernel, boot of Linux and system works 
> correctly.
>
> Ps: all efi_printk seems to be lost in the kernel. Is there a way to transfer 
> this into the kernel somehow?
>

Unfortunately not. Do you actually see the output? (which may require
removing 'quiet' from the command line) If so, can you capture it with
your phone camera perhaps?


Re: [PATCH 4/5] efi: Export Runtime Configuration Interface table to sysfs

2019-10-01 Thread Ard Biesheuvel
On Tue, 1 Oct 2019 at 11:03, Geert Uytterhoeven  wrote:
>
> Hi Ard,
>
> On Tue, Oct 1, 2019 at 10:54 AM Ard Biesheuvel
>  wrote:
> > On Tue, 1 Oct 2019 at 10:51, Geert Uytterhoeven  
> > wrote:
> > > On Mon, Aug 12, 2019 at 5:07 PM Ard Biesheuvel
> > >  wrote:
> > > > From: Narendra K 
> > > >
> > > > System firmware advertises the address of the 'Runtime
> > > > Configuration Interface table version 2 (RCI2)' via
> > > > an EFI Configuration Table entry. This code retrieves the RCI2
> > > > table from the address and exports it to sysfs as a binary
> > > > attribute 'rci2' under /sys/firmware/efi/tables directory.
> > > > The approach adopted is similar to the attribute 'DMI' under
> > > > /sys/firmware/dmi/tables.
> > > >
> > > > RCI2 table contains BIOS HII in XML format and is used to populate
> > > > BIOS setup page in Dell EMC OpenManage Server Administrator tool.
> > > > The BIOS setup page contains BIOS tokens which can be configured.
> > > >
> > > > Signed-off-by: Narendra K 
> > > > Reviewed-by: Mario Limonciello 
> > > > Signed-off-by: Ard Biesheuvel 
> > >
> > > Thanks, this is now commit 1c5fecb61255aa12 ("efi: Export Runtime
> > > Configuration Interface table to sysfs").
> > >
> > > > --- a/drivers/firmware/efi/Kconfig
> > > > +++ b/drivers/firmware/efi/Kconfig
> > > > @@ -180,6 +180,19 @@ config RESET_ATTACK_MITIGATION
> > > >   have been evicted, since otherwise it will trigger even on 
> > > > clean
> > > >   reboots.
> > > >
> > > > +config EFI_RCI2_TABLE
> > > > +   bool "EFI Runtime Configuration Interface Table Version 2 
> > > > Support"
> > > > +   help
> > > > + Displays the content of the Runtime Configuration Interface
> > > > + Table version 2 on Dell EMC PowerEdge systems as a binary
> > > > + attribute 'rci2' under /sys/firmware/efi/tables directory.
> > > > +
> > > > + RCI2 table contains BIOS HII in XML format and is used to 
> > > > populate
> > > > + BIOS setup page in Dell EMC OpenManage Server Administrator 
> > > > tool.
> > > > + The BIOS setup page contains BIOS tokens which can be 
> > > > configured.
> > > > +
> > > > + Say Y here for Dell EMC PowerEdge systems.
> > >
> > > A quick Google search tells me these are Intel Xeon.
> > > Are arm/arm64/ia64 variants available, too?
> > > If not, this should be protected by "depends on x86" ("|| COMPILE_TEST"?).
> >
> > The code in question is entirely architecture agnostic, and defaults
> > to 'n', so I am not convinced this is needed. (It came up in the
> > review as well)
>
> "make oldconfig" still asks me the question on e.g. arm64, where it is
> irrelevant, until arm64 variants of the hardware show up.
>
> So IMHO it should have "depends on X86 || COMPILE_TEST".
>

Fair enough. I am going to send out a bunch of EFI fixes this week, so
I'll accept a patch that makes the change above.


Re: [PATCH 4/5] efi: Export Runtime Configuration Interface table to sysfs

2019-10-01 Thread Ard Biesheuvel
On Tue, 1 Oct 2019 at 10:51, Geert Uytterhoeven  wrote:
>
> Hi Ard, Narendra,
>
> On Mon, Aug 12, 2019 at 5:07 PM Ard Biesheuvel
>  wrote:
> > From: Narendra K 
> >
> > System firmware advertises the address of the 'Runtime
> > Configuration Interface table version 2 (RCI2)' via
> > an EFI Configuration Table entry. This code retrieves the RCI2
> > table from the address and exports it to sysfs as a binary
> > attribute 'rci2' under /sys/firmware/efi/tables directory.
> > The approach adopted is similar to the attribute 'DMI' under
> > /sys/firmware/dmi/tables.
> >
> > RCI2 table contains BIOS HII in XML format and is used to populate
> > BIOS setup page in Dell EMC OpenManage Server Administrator tool.
> > The BIOS setup page contains BIOS tokens which can be configured.
> >
> > Signed-off-by: Narendra K 
> > Reviewed-by: Mario Limonciello 
> > Signed-off-by: Ard Biesheuvel 
>
> Thanks, this is now commit 1c5fecb61255aa12 ("efi: Export Runtime
> Configuration Interface table to sysfs").
>
> > --- a/drivers/firmware/efi/Kconfig
> > +++ b/drivers/firmware/efi/Kconfig
> > @@ -180,6 +180,19 @@ config RESET_ATTACK_MITIGATION
> >   have been evicted, since otherwise it will trigger even on clean
> >   reboots.
> >
> > +config EFI_RCI2_TABLE
> > +   bool "EFI Runtime Configuration Interface Table Version 2 Support"
> > +   help
> > + Displays the content of the Runtime Configuration Interface
> > + Table version 2 on Dell EMC PowerEdge systems as a binary
> > + attribute 'rci2' under /sys/firmware/efi/tables directory.
> > +
> > + RCI2 table contains BIOS HII in XML format and is used to populate
> > + BIOS setup page in Dell EMC OpenManage Server Administrator tool.
> > + The BIOS setup page contains BIOS tokens which can be configured.
> > +
> > + Say Y here for Dell EMC PowerEdge systems.
>
> A quick Google search tells me these are Intel Xeon.
> Are arm/arm64/ia64 variants available, too?
> If not, this should be protected by "depends on x86" ("|| COMPILE_TEST"?).
>

Hello Geert,

The code in question is entirely architecture agnostic, and defaults
to 'n', so I am not convinced this is needed. (It came up in the
review as well)


Re: [RFC] random: UEFI RNG input is bootloader randomness

2019-09-30 Thread Ard Biesheuvel
On Sat, 28 Sep 2019 at 12:14, Dominik Brodowski
 wrote:
>
> Depending on RANDOM_TRUST_BOOTLOADER, bootloader-provided randomness
> is credited as entropy. As the UEFI seeding entropy pool is seeded by
> the UEFI firmware/bootloader, add its content as bootloader randomness.
>
> Note that this UEFI (v2.4 or newer) feature is currently only
> implemented for EFI stub booting on ARM, and further note that
> RANDOM_TRUST_BOOTLOADER must only be enabled if there indeed is
> sufficient trust in the bootloader _and_ its source of randomness.
>
> Signed-off-by: Dominik Brodowski 
> Cc: Ard Biesheuvel 
> Cc: Hsin-Yi Wang 
> Cc: Stephen Boyd 
> Cc: Rob Herring 
> Cc: Theodore Ts'o 
> Cc: Lee, Chun-Yi 
>
> ---
>
> Untested patch, as efi_random_get_seed() is only hooked up on ARM,
> and the firmware on my old x86 laptop only has UEFI v2.31 anyway.
>
> Thanks,
> Dominik
>
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index 8f1ab04f6743..db0bffce754e 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -545,7 +545,7 @@ int __init efi_config_parse_tables(void *config_tables, 
> int count, int sz,
>   sizeof(*seed) + size);
> if (seed != NULL) {
> pr_notice("seeding entropy pool\n");
> -   add_device_randomness(seed->bits, seed->size);
> +   add_bootloader_randomness(seed->bits, 
> seed->size);
> early_memunmap(seed, sizeof(*seed) + size);
> } else {
> pr_err("Could not map UEFI random seed!\n");

Thanks, I like this change. I'll get it queued up in efi/next.


Re: [PATCH] x86/efi: Don't require non-blocking EFI callbacks

2019-09-26 Thread Ard Biesheuvel
On Thu, 26 Sep 2019 at 17:47, Ross Lagerwall  wrote:
>
> On 9/26/19 4:29 PM, Ard Biesheuvel wrote:
> > On Thu, 26 Sep 2019 at 16:12, Ross Lagerwall  
> > wrote:
> >>
> >> If a backend does not implement non-blocking EFI operations, it implies
> >> that the normal operations are non-blocking.
> >
> > Is that documented anywhere?
>
> Sort of. From commit 6d80dba1c9fe "efi: Provide a non-blocking
> SetVariable() operation"
>
> """
> Introduce ->set_variable_nonblocking() for this use case. It is an
> optional EFI backend operation, and need only be implemented by those
> backends that usually acquire locks to serialize access to EFI
> variables, as is the case for virt_efi_set_variable() where we now grab
> the EFI runtime spinlock.
> """
>
> >
> >> Instead of crashing
> >> dereferencing a NULL pointer, fallback to the normal operations since it
> >> is safe to do so.
> >>
> >
> > I agree that crashing is never the right thing to do, but I wonder
> > whether we shouldn't just bail instead. If the provided default
> > operation is non-blocking, the platform can populate the function
> > pointer with a reference to the default implementation.
>
> If you would prefer it that platforms are always required to implement
> the non-blocking functions, then I will just send a simple patch fixing
> up the Xen implementation.
>

Yes, please, that sounds like a safer option to me.


Re: [PATCH] x86/efi: Don't require non-blocking EFI callbacks

2019-09-26 Thread Ard Biesheuvel
On Thu, 26 Sep 2019 at 16:12, Ross Lagerwall  wrote:
>
> If a backend does not implement non-blocking EFI operations, it implies
> that the normal operations are non-blocking.

Is that documented anywhere?

> Instead of crashing
> dereferencing a NULL pointer, fallback to the normal operations since it
> is safe to do so.
>

I agree that crashing is never the right thing to do, but I wonder
whether we shouldn't just bail instead. If the provided default
operation is non-blocking, the platform can populate the function
pointer with a reference to the default implementation.


> Fixes: 5a58bc1b1edc ("efi/x86: Use non-blocking SetVariable() for 
> efi_delete_dummy_variable()")
> Fixes: ca0e30dcaa53 ("efi: Add nonblocking option to 
> efi_query_variable_store()")
> Signed-off-by: Ross Lagerwall 
> ---
>  arch/x86/platform/efi/quirks.c | 20 
>  1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
> index 3b9fd679cea9..4167f5e8f3e8 100644
> --- a/arch/x86/platform/efi/quirks.c
> +++ b/arch/x86/platform/efi/quirks.c
> @@ -106,11 +106,13 @@ early_param("efi_no_storage_paranoia", 
> setup_storage_paranoia);
>  */
>  void efi_delete_dummy_variable(void)
>  {
> -   efi.set_variable_nonblocking((efi_char16_t *)efi_dummy_name,
> -_DUMMY_GUID,
> -EFI_VARIABLE_NON_VOLATILE |
> -EFI_VARIABLE_BOOTSERVICE_ACCESS |
> -EFI_VARIABLE_RUNTIME_ACCESS, 0, NULL);
> +   efi_set_variable_t *set_variable = efi.set_variable_nonblocking ?:
> +  efi.set_variable;
> +
> +   set_variable((efi_char16_t *)efi_dummy_name, _DUMMY_GUID,
> +EFI_VARIABLE_NON_VOLATILE |
> +EFI_VARIABLE_BOOTSERVICE_ACCESS |
> +EFI_VARIABLE_RUNTIME_ACCESS, 0, NULL);
>  }
>
>  /*
> @@ -127,10 +129,12 @@ query_variable_store_nonblocking(u32 attributes, 
> unsigned long size)
>  {
> efi_status_t status;
> u64 storage_size, remaining_size, max_size;
> +   efi_query_variable_info_t *query_variable_info =
> +   efi.query_variable_info_nonblocking ?:
> +   efi.query_variable_info;
>
> -   status = efi.query_variable_info_nonblocking(attributes, 
> _size,
> -_size,
> -_size);
> +   status = query_variable_info(attributes, _size,
> +_size, _size);
> if (status != EFI_SUCCESS)
> return status;
>
> --
> 2.21.0
>


Re: [PATCH v3] tpm: only set efi_tpm_final_log_size after successful event log parsing

2019-09-25 Thread Ard Biesheuvel
On Wed, 25 Sep 2019 at 19:27, Jerry Snitselaar  wrote:
>
> If __calc_tpm2_event_size fails to parse an event it will return 0,
> resulting tpm2_calc_event_log_size returning -1. Currently there is
> no check of this return value, and efi_tpm_final_log_size can end up
> being set to this negative value resulting in a panic like the
> the one given below.
>
> Also __calc_tpm2_event_size returns a size of 0 when it fails
> to parse an event, so update function documentation to reflect this.
>
...
>
> The root cause of the issue that caused the failure of event parsing
> in this case is resolved by Peter Jone's patchset dealing with large
> event logs where crossing over a page boundary causes the page with
> the event count to be unmapped.
>
> Fixes: c46f3405692de ("tpm: Reserve the TPM final events table")
> Cc: linux-efi@vger.kernel.org
> Cc: linux-integr...@vger.kernel.org
> Cc: sta...@vger.kernel.org
> Cc: Matthew Garrett 
> Cc: Ard Biesheuvel 
> Cc: Jarkko Sakkinen 
> Signed-off-by: Jerry Snitselaar 

Thanks Jerry, I have queued this in the efi/urgent branch.


> ---
> v3: rebase on top of Peter Jone's patchset
> v2: added FW_BUG to pr_err, and renamed label to out_calc.
> Updated doc comment for __calc_tpm2_event_size.
>
>  drivers/firmware/efi/tpm.c   | 9 -
>  include/linux/tpm_eventlog.h | 2 +-
>  2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/firmware/efi/tpm.c b/drivers/firmware/efi/tpm.c
> index b9ae5c6f9b9c..703469c1ab8e 100644
> --- a/drivers/firmware/efi/tpm.c
> +++ b/drivers/firmware/efi/tpm.c
> @@ -85,11 +85,18 @@ int __init efi_tpm_eventlog_init(void)
> final_tbl->nr_events,
> log_tbl->log);
> }
> +
> +   if (tbl_size < 0) {
> +   pr_err(FW_BUG "Failed to parse event in TPM Final Events 
> Log\n");
> +   goto out_calc;
> +   }
> +
> memblock_reserve((unsigned long)final_tbl,
>  tbl_size + sizeof(*final_tbl));
> -   early_memunmap(final_tbl, sizeof(*final_tbl));
> efi_tpm_final_log_size = tbl_size;
>
> +out_calc:
> +   early_memunmap(final_tbl, sizeof(*final_tbl));
>  out:
> early_memunmap(log_tbl, sizeof(*log_tbl));
> return ret;
> diff --git a/include/linux/tpm_eventlog.h b/include/linux/tpm_eventlog.h
> index 12584b69a3f3..2dfdd63ac034 100644
> --- a/include/linux/tpm_eventlog.h
> +++ b/include/linux/tpm_eventlog.h
> @@ -152,7 +152,7 @@ struct tcg_algorithm_info {
>   * total. Once we've done this we know the offset of the data length field,
>   * and can calculate the total size of the event.
>   *
> - * Return: size of the event on success, <0 on failure
> + * Return: size of the event on success, 0 on failure
>   */
>
>  static inline int __calc_tpm2_event_size(struct tcg_pcr_event2_head *event,
> --
> 2.23.0
>


Re: [PATCH] efi: don't iterate over EFI vars pointlessly if no SSDT override was specified

2019-09-25 Thread Ard Biesheuvel
On Thu, 19 Sep 2019 at 20:01, Scott Talbert  wrote:
>
> On Thu, 12 Sep 2019, Ard Biesheuvel wrote:
>
> >>> The kernel command line option efivar_ssdt= allows a EFI variable name
> >>> to be specified which contains an ACPI SSDT table that will be loaded
> >>> into memory by the OS.
> >>>
> >>> Currently, that code will always iterate over the EFI variables and
> >>> compare each name with the provided name, even if the command line
> >>> option wasn't set to begin with.
> >>>
> >>> So bail early when no variable name was provided.
> >>>
> >>> Cc: Scott Talbert 
> >>> Signed-off-by: Ard Biesheuvel 
> >>> ---
> >>> drivers/firmware/efi/efi.c | 3 +++
> >>> 1 file changed, 3 insertions(+)
> >>>
> >>> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> >>> index ad3b1f4866b3..8f020827cdd3 100644
> >>> --- a/drivers/firmware/efi/efi.c
> >>> +++ b/drivers/firmware/efi/efi.c
> >>> @@ -282,6 +282,9 @@ static __init int efivar_ssdt_load(void)
> >>>   void *data;
> >>>   int ret;
> >>>
> >>> + if (!efivar_ssdt[0])
> >>> + return 0;
> >>> +
> >>>   ret = efivar_init(efivar_ssdt_iter, , true, );
> >>>
> >>>   list_for_each_entry_safe(entry, aux, , list) {
> >>
> >> Thanks for the quick fix!
> >>
> >> I can confirm this fixes booting on my Mac Pro 2012 system when applied to
> >> 5.3-rc7.
> >>
> >> Whenever this makes it in, if it could be targeted for the stable kernels
> >> as well, that would be appreciated.
> >>
> >
> > I'll send it out as a fix with a cc to -stable.
>
> Hi - just a quick reminder on this as I don't see it in Linus' tree yet.
> Not that I need it urgently, but just want to make sure it isn't
> forgotten.
>

Hi Scott,

This should get sent out in the next couple of day. It usually takes
another week or so after that for changes to make it into Linus's
tree.


Re: [PATCH 1/2] efi: Add efi_memmap_free() to free EFI memory map

2019-09-25 Thread Ard Biesheuvel
On Wed, 25 Sep 2019 at 11:17, Yunfeng Ye  wrote:
>
> In efi_fake_memmap(), the commit 20b1e22d01a4 ("x86/efi: Don't allocate
> memmap through memblock after mm_init()") replace memblock_alloc() with
> efi_memmap_alloc(), but there is no matching modification of
> memblock_free() when early_memremap() fail.
>
> Fix this by adding efi_memmap_free() to instead of memblock_free().
>
> Fixes: 20b1e22d01a4 ("x86/efi: Don't allocate memmap through memblock after 
> mm_init()")
> Signed-off-by: Yunfeng Ye 

What happens if you try to call efi_memmap_free() /after/ slab has
become available on an allocation that was created before?

> ---
>  drivers/firmware/efi/fake_mem.c |  2 +-
>  drivers/firmware/efi/memmap.c   | 34 ++
>  include/linux/efi.h |  1 +
>  3 files changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/efi/fake_mem.c b/drivers/firmware/efi/fake_mem.c
> index 9501edc..c2f69f6 100644
> --- a/drivers/firmware/efi/fake_mem.c
> +++ b/drivers/firmware/efi/fake_mem.c
> @@ -65,7 +65,7 @@ void __init efi_fake_memmap(void)
> new_memmap = early_memremap(new_memmap_phy,
> efi.memmap.desc_size * new_nr_map);
> if (!new_memmap) {
> -   memblock_free(new_memmap_phy, efi.memmap.desc_size * 
> new_nr_map);
> +   efi_memmap_free(new_memmap_phy, new_nr_map);
> return;
> }
>
> diff --git a/drivers/firmware/efi/memmap.c b/drivers/firmware/efi/memmap.c
> index 38b686c..35dc189 100644
> --- a/drivers/firmware/efi/memmap.c
> +++ b/drivers/firmware/efi/memmap.c
> @@ -18,6 +18,11 @@ static phys_addr_t __init 
> __efi_memmap_alloc_early(unsigned long size)
> return memblock_phys_alloc(size, SMP_CACHE_BYTES);
>  }
>
> +static void __init __efi_memmap_free_early(phys_addr_t addr, unsigned long 
> size)
> +{
> +   memblock_free(addr, size);
> +}
> +
>  static phys_addr_t __init __efi_memmap_alloc_late(unsigned long size)
>  {
> unsigned int order = get_order(size);
> @@ -29,6 +34,15 @@ static phys_addr_t __init __efi_memmap_alloc_late(unsigned 
> long size)
> return PFN_PHYS(page_to_pfn(p));
>  }
>
> +static void __init __efi_memmap_free_late(phys_addr_t addr, unsigned long 
> size)
> +{
> +   unsigned int order = get_order(size);
> +   struct page *p = pfn_to_page(PHYS_PFN(addr));
> +
> +   if (p)
> +   __free_pages(p, order);
> +}
> +
>  /**
>   * efi_memmap_alloc - Allocate memory for the EFI memory map
>   * @num_entries: Number of entries in the allocated map.
> @@ -50,6 +64,26 @@ phys_addr_t __init efi_memmap_alloc(unsigned int 
> num_entries)
>  }
>
>  /**
> + * efi_memmap_free - Free memory for the EFI memory map
> + * @addr: Physical address of the EFI memory map to be freed.
> + * @num_entries: Number of the EFI memory map entries.
> + *
> + * Depending on whether mm_init() has already been invoked or not,
> + * either memblock or "normal" page free is used.
> + */
> +void __init efi_memmap_free(phys_addr_t addr, unsigned int num_entries)
> +{
> +   unsigned long size = num_entries * efi.memmap.desc_size;
> +
> +   if (slab_is_available()) {
> +   __efi_memmap_free_late(addr, size);
> +
> +   return;
> +   }
> +   __efi_memmap_free_early(addr, size);
> +}
> +
> +/**
>   * __efi_memmap_init - Common code for mapping the EFI memory map
>   * @data: EFI memory map data
>   * @late: Use early or late mapping function?
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index bd38370..8bb741a 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -1057,6 +1057,7 @@ static inline efi_status_t efi_query_variable_store(u32 
> attributes,
>  extern void __iomem *efi_lookup_mapped_addr(u64 phys_addr);
>
>  extern phys_addr_t __init efi_memmap_alloc(unsigned int num_entries);
> +extern void __init efi_memmap_free(phys_addr_t addr, unsigned int 
> num_entries);
>  extern int __init efi_memmap_init_early(struct efi_memory_map_data *data);
>  extern int __init efi_memmap_init_late(phys_addr_t addr, unsigned long size);
>  extern void __init efi_memmap_unmap(void);
> --
> 1.8.3.1
>


Re: [PATCH v2] x86, efi: never relocate kernel below lowest acceptable address

2019-09-25 Thread Ard Biesheuvel
On Thu, 19 Sep 2019 at 18:06, Kairui Song  wrote:
>
> Currently, kernel fails to boot on some HyperV VMs when using EFI.
> And it's a potential issue on all platforms.
>
> It's caused a broken kernel relocation on EFI systems, when below three
> conditions are met:
>
> 1. Kernel image is not loaded to the default address (LOAD_PHYSICAL_ADDR)
>by the loader.
> 2. There isn't enough room to contain the kernel, starting from the
>default load address (eg. something else occupied part the region).
> 3. In the memmap provided by EFI firmware, there is a memory region
>starts below LOAD_PHYSICAL_ADDR, and suitable for containing the
>kernel.
>
> Efi stub will perform a kernel relocation when condition 1 is met. But
> due to condition 2, efi stub can't relocate kernel to the preferred
> address, so it fallback to query and alloc from EFI firmware for lowest
> usable memory region.
>
> It's incorrect to use the lowest memory address. In later stage, kernel
> will assume LOAD_PHYSICAL_ADDR as the minimal acceptable relocate address,
> but efi stub will end up relocating kernel below it.
>
> Then before the kernel decompressing. Kernel will do another relocation
> to address not lower than LOAD_PHYSICAL_ADDR, this time the relocate will
> over write the blockage at the default load address, which efi stub tried
> to avoid, and lead to unexpected behavior. Beside, the memory region it
> writes to is not allocated from EFI firmware, which is also wrong.
>
> To fix it, just don't let efi stub relocate the kernel to any address
> lower than lowest acceptable address.
>
> Signed-off-by: Kairui Song 
>

Hello Kairui,

This patch looks correct to me, but it needs an ack from the x86
maintainers, since the rules around LOAD_PHYSICAL_ADDR are specific to
the x86 architecture.


> ---
>
> Update from V1:
>  - Redo the commit message.
>
>  arch/x86/boot/compressed/eboot.c   |  8 +---
>  drivers/firmware/efi/libstub/arm32-stub.c  |  2 +-
>  drivers/firmware/efi/libstub/arm64-stub.c  |  2 +-
>  drivers/firmware/efi/libstub/efi-stub-helper.c | 12 
>  include/linux/efi.h|  5 +++--
>  5 files changed, 18 insertions(+), 11 deletions(-)
>
> diff --git a/arch/x86/boot/compressed/eboot.c 
> b/arch/x86/boot/compressed/eboot.c
> index 936bdb924ec2..8207e8aa297e 100644
> --- a/arch/x86/boot/compressed/eboot.c
> +++ b/arch/x86/boot/compressed/eboot.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "../string.h"
>  #include "eboot.h"
> @@ -432,7 +433,7 @@ struct boot_params *make_boot_params(struct efi_config *c)
> }
>
> status = efi_low_alloc(sys_table, 0x4000, 1,
> -  (unsigned long *)_params);
> +  (unsigned long *)_params, 0);
> if (status != EFI_SUCCESS) {
> efi_printk(sys_table, "Failed to allocate lowmem for boot 
> params\n");
> return NULL;
> @@ -817,7 +818,7 @@ efi_main(struct efi_config *c, struct boot_params 
> *boot_params)
>
> gdt->size = 0x800;
> status = efi_low_alloc(sys_table, gdt->size, 8,
> -  (unsigned long *)>address);
> +  (unsigned long *)>address, 0);
> if (status != EFI_SUCCESS) {
> efi_printk(sys_table, "Failed to allocate memory for 
> 'gdt'\n");
> goto fail;
> @@ -842,7 +843,8 @@ efi_main(struct efi_config *c, struct boot_params 
> *boot_params)
> status = efi_relocate_kernel(sys_table, _addr,
>  hdr->init_size, hdr->init_size,
>  hdr->pref_address,
> -hdr->kernel_alignment);
> +hdr->kernel_alignment,
> +LOAD_PHYSICAL_ADDR);
> if (status != EFI_SUCCESS) {
> efi_printk(sys_table, "efi_relocate_kernel() 
> failed!\n");
> goto fail;
> diff --git a/drivers/firmware/efi/libstub/arm32-stub.c 
> b/drivers/firmware/efi/libstub/arm32-stub.c
> index e8f7aefb6813..bf6f954d6afe 100644
> --- a/drivers/firmware/efi/libstub/arm32-stub.c
> +++ b/drivers/firmware/efi/libstub/arm32-stub.c
> @@ -220,7 +220,7 @@ efi_status_t handle_kernel_image(efi_system_table_t 
> *sys_table,
> *image_size = image->image_size;
> status = efi_relocate_kernel(sys_table, image_addr, *image_size,
>  *image_size,
> -dram_base + MAX_UNCOMP_KERNEL_SIZE, 0);
> +dram_base + MAX_UNCOMP_KERNEL_SIZE, 0, 
> 0);
> if (status != EFI_SUCCESS) {
> pr_efi_err(sys_table, "Failed to relocate kernel.\n");
> efi_free(sys_table, *reserve_size, *reserve_addr);
> diff --git 

Re: [PATCH] efi: make unexported efi_rci2_sysfs_init static

2019-09-25 Thread Ard Biesheuvel
On Wed, 25 Sep 2019 at 15:12, Ben Dooks  wrote:
>
> The efi_rci2_sysfs_init() is not used outside of rci2-table.c so
> make it static to silence the following sparse warning:
>
> drivers/firmware/efi/rci2-table.c:79:12: warning: symbol 
> 'efi_rci2_sysfs_init' was not declared. Should it be static?
>
> Signed-off-by: Ben Dooks 
> ---
>  drivers/firmware/efi/rci2-table.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/efi/rci2-table.c 
> b/drivers/firmware/efi/rci2-table.c
> index 3e290f96620a..76b0c354a027 100644
> --- a/drivers/firmware/efi/rci2-table.c
> +++ b/drivers/firmware/efi/rci2-table.c
> @@ -76,7 +76,7 @@ static u16 checksum(void)
> return chksum;
>  }
>
> -int __init efi_rci2_sysfs_init(void)
> +static int __init efi_rci2_sysfs_init(void)
>  {
> struct kobject *tables_kobj;
> int ret = -ENOMEM;
> --
> 2.23.0
>

Thanks Ben.

Queued in efi/urgent


Re: [PATCH v2 1/2] efi+tpm: Don't access event->count when it isn't mapped.

2019-09-25 Thread Ard Biesheuvel
On Wed, 25 Sep 2019 at 12:16, Jarkko Sakkinen
 wrote:
>
> From: Peter Jones 
>
> Some machines generate a lot of event log entries.  When we're
> iterating over them, the code removes the old mapping and adds a
> new one, so once we cross the page boundary we're unmapping the page
> with the count on it.  Hilarity ensues.
>
> This patch keeps the info from the header in local variables so we don't
> need to access that page again or keep track of if it's mapped.
>
> Fixes: 44038bc514a2 ("tpm: Abstract crypto agile event size calculations")
> Cc: linux-efi@vger.kernel.org
> Cc: linux-integr...@vger.kernel.org
> Cc: sta...@vger.kernel.org
> Signed-off-by: Peter Jones 
> Tested-by: Lyude Paul 
> Reviewed-by: Jarkko Sakkinen 
> Acked-by: Matthew Garrett 
> Acked-by: Ard Biesheuvel 
> Signed-off-by: Jarkko Sakkinen 

Thanks Jarkko.

Shall I take these through the EFI tree?


> ---
>  include/linux/tpm_eventlog.h | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/tpm_eventlog.h b/include/linux/tpm_eventlog.h
> index 63238c84dc0b..12584b69a3f3 100644
> --- a/include/linux/tpm_eventlog.h
> +++ b/include/linux/tpm_eventlog.h
> @@ -170,6 +170,7 @@ static inline int __calc_tpm2_event_size(struct 
> tcg_pcr_event2_head *event,
> u16 halg;
> int i;
> int j;
> +   u32 count, event_type;
>
> marker = event;
> marker_start = marker;
> @@ -190,16 +191,22 @@ static inline int __calc_tpm2_event_size(struct 
> tcg_pcr_event2_head *event,
> }
>
> event = (struct tcg_pcr_event2_head *)mapping;
> +   /*
> +* the loop below will unmap these fields if the log is larger than
> +* one page, so save them here for reference.
> +*/
> +   count = READ_ONCE(event->count);
> +   event_type = READ_ONCE(event->event_type);
>
> efispecid = (struct tcg_efi_specid_event_head *)event_header->event;
>
> /* Check if event is malformed. */
> -   if (event->count > efispecid->num_algs) {
> +   if (count > efispecid->num_algs) {
> size = 0;
> goto out;
> }
>
> -   for (i = 0; i < event->count; i++) {
> +   for (i = 0; i < count; i++) {
> halg_size = sizeof(event->digests[i].alg_id);
>
> /* Map the digest's algorithm identifier */
> @@ -256,8 +263,9 @@ static inline int __calc_tpm2_event_size(struct 
> tcg_pcr_event2_head *event,
> + event_field->event_size;
> size = marker - marker_start;
>
> -   if ((event->event_type == 0) && (event_field->event_size == 0))
> +   if (event_type == 0 && event_field->event_size == 0)
> size = 0;
> +
>  out:
> if (do_mapping)
> TPM_MEMUNMAP(mapping, mapping_size);
> --
> 2.20.1
>


Re: [PATCH v5 05/10] x86, efi: Add efi_fake_mem support for EFI_MEMORY_SP

2019-09-13 Thread Ard Biesheuvel
On Fri, 30 Aug 2019 at 03:07, Dan Williams  wrote:
>
...
> diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
> index 4ac2de4dfa72..d7a6db03ea79 100644
> --- a/drivers/firmware/efi/Makefile
> +++ b/drivers/firmware/efi/Makefile
> @@ -20,13 +20,16 @@ obj-$(CONFIG_UEFI_CPER) += cper.o
>  obj-$(CONFIG_EFI_RUNTIME_MAP)  += runtime-map.o
>  obj-$(CONFIG_EFI_RUNTIME_WRAPPERS) += runtime-wrappers.o
>  obj-$(CONFIG_EFI_STUB) += libstub/
> -obj-$(CONFIG_EFI_FAKE_MEMMAP)  += fake_mem.o
> +obj-$(CONFIG_EFI_FAKE_MEMMAP)  += fake_map.o
>  obj-$(CONFIG_EFI_BOOTLOADER_CONTROL)   += efibc.o
>  obj-$(CONFIG_EFI_TEST) += test/
>  obj-$(CONFIG_EFI_DEV_PATH_PARSER)  += dev-path-parser.o
>  obj-$(CONFIG_APPLE_PROPERTIES) += apple-properties.o
>  obj-$(CONFIG_EFI_RCI2_TABLE)   += rci2-table.o
>
> +fake_map-y += fake_mem.o
> +fake_map-$(CONFIG_X86) += x86-fake_mem.o
> +

Please use

fake-mem-$(CONFIG_X86) := x86-fake_mem.o
obj-$(CONFIG_EFI_FAKE_MEMMAP) += fake_mem.o $(fake-mem-y)

instead, and please use either - or _ in filenames, not both.


Re: [PATCH v5 04/10] x86, efi: Reserve UEFI 2.8 Specific Purpose Memory for dax

2019-09-13 Thread Ard Biesheuvel
On Fri, 13 Sep 2019 at 18:39, Ard Biesheuvel  wrote:
>
> On Fri, 13 Sep 2019 at 17:39, Dan Williams  wrote:
> >
> > On Fri, Sep 13, 2019 at 9:29 AM Ard Biesheuvel
> >  wrote:
> > >
> > > On Fri, 13 Sep 2019 at 17:22, Dan Williams  
> > > wrote:
> > > >
> > > > On Fri, Sep 13, 2019 at 6:00 AM Ard Biesheuvel
> > > >  wrote:
> ...
> > > > > > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> > > > > > index 363bb9d00fa5..6d54d5c74347 100644
> > > > > > --- a/drivers/firmware/efi/efi.c
> > > > > > +++ b/drivers/firmware/efi/efi.c
> > > > > > @@ -52,6 +52,9 @@ struct efi __read_mostly efi = {
> > > > > > .tpm_log= EFI_INVALID_TABLE_ADDR,
> > > > > > .tpm_final_log  = EFI_INVALID_TABLE_ADDR,
> > > > > > .mem_reserve= EFI_INVALID_TABLE_ADDR,
> > > > > > +#ifdef CONFIG_EFI_SOFT_RESERVE
> > > > > > +   .flags  = 1UL << EFI_MEM_SOFT_RESERVE,
> > > > > > +#endif
> > > > > >  };
> > > > > >  EXPORT_SYMBOL(efi);
> > > > > >
> > > > >
> > > > > I'd prefer it if we could call this EFI_MEM_NO_SOFT_RESERVE instead,
> > > > > and invert the meaning of the bit.
> > > >
> > > > ...but that would mean repeat occurrences of
> > > > "!efi_enabled(EFI_MEM_NO_SOFT_RESERVE)", doesn't the double negative
> > > > seem less readable to you?
> > > >
> > >
> > > One the one hand, yes. On the other hand, it is the only flag whose
> > > default is 'enabled' which is also less than ideal.
> >
> > Ok, I can get on board with "default 0" being the non exception state
> > of the flags.
> >
>
> In fact, let's just add something like
>
> static inline bool efi_soft_reserve_enabled(void)
> {
> return IS_ENABLED(CONFIG_EFI_SOFT_RESERVE) &&
>!efi_enabled(EFI_MEM_NO_SOFT_RESERVE);
> }
>
> to linux/efi.h and use that in the code?

Or even better, add just the declaration to linux.efi,h

bool __pure efi_soft_reserve_enabled(void);

and put one implementation in efi-stub-helper.c:

bool __pure efi_soft_reserve_enabled(void)
{
return IS_ENABLED(CONFIG_EFI_SOFT_RESERVE) &&
   !efi_nosoftreserve;
}

and the one above in drivers/firmware/efi/efi.c


Re: [PATCH v5 04/10] x86, efi: Reserve UEFI 2.8 Specific Purpose Memory for dax

2019-09-13 Thread Ard Biesheuvel
On Fri, 13 Sep 2019 at 17:39, Dan Williams  wrote:
>
> On Fri, Sep 13, 2019 at 9:29 AM Ard Biesheuvel
>  wrote:
> >
> > On Fri, 13 Sep 2019 at 17:22, Dan Williams  wrote:
> > >
> > > On Fri, Sep 13, 2019 at 6:00 AM Ard Biesheuvel
> > >  wrote:
...
> > > > > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> > > > > index 363bb9d00fa5..6d54d5c74347 100644
> > > > > --- a/drivers/firmware/efi/efi.c
> > > > > +++ b/drivers/firmware/efi/efi.c
> > > > > @@ -52,6 +52,9 @@ struct efi __read_mostly efi = {
> > > > > .tpm_log= EFI_INVALID_TABLE_ADDR,
> > > > > .tpm_final_log  = EFI_INVALID_TABLE_ADDR,
> > > > > .mem_reserve= EFI_INVALID_TABLE_ADDR,
> > > > > +#ifdef CONFIG_EFI_SOFT_RESERVE
> > > > > +   .flags  = 1UL << EFI_MEM_SOFT_RESERVE,
> > > > > +#endif
> > > > >  };
> > > > >  EXPORT_SYMBOL(efi);
> > > > >
> > > >
> > > > I'd prefer it if we could call this EFI_MEM_NO_SOFT_RESERVE instead,
> > > > and invert the meaning of the bit.
> > >
> > > ...but that would mean repeat occurrences of
> > > "!efi_enabled(EFI_MEM_NO_SOFT_RESERVE)", doesn't the double negative
> > > seem less readable to you?
> > >
> >
> > One the one hand, yes. On the other hand, it is the only flag whose
> > default is 'enabled' which is also less than ideal.
>
> Ok, I can get on board with "default 0" being the non exception state
> of the flags.
>

In fact, let's just add something like

static inline bool efi_soft_reserve_enabled(void)
{
return IS_ENABLED(CONFIG_EFI_SOFT_RESERVE) &&
   !efi_enabled(EFI_MEM_NO_SOFT_RESERVE);
}

to linux/efi.h and use that in the code?


Re: [PATCH v5 04/10] x86, efi: Reserve UEFI 2.8 Specific Purpose Memory for dax

2019-09-13 Thread Ard Biesheuvel
On Fri, 13 Sep 2019 at 17:22, Dan Williams  wrote:
>
> On Fri, Sep 13, 2019 at 6:00 AM Ard Biesheuvel
>  wrote:
> >
> > On Fri, 30 Aug 2019 at 03:06, Dan Williams  wrote:
> > >
> > > UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the
> > > interpretation of the EFI Memory Types as "reserved for a specific
> > > purpose".
> > >
> > > The proposed Linux behavior for specific purpose memory is that it is
> > > reserved for direct-access (device-dax) by default and not available for
> > > any kernel usage, not even as an OOM fallback.  Later, through udev
> > > scripts or another init mechanism, these device-dax claimed ranges can
> > > be reconfigured and hot-added to the available System-RAM with a unique
> > > node identifier. This device-dax management scheme implements "soft" in
> > > the "soft reserved" designation by allowing some or all of the
> > > reservation to be recovered as typical memory. This policy can be
> > > disabled at compile-time with CONFIG_EFI_SOFT_RESERVE=n, or runtime with
> > > efi=nosoftreserve.
> > >
> > > This patch introduces 2 new concepts at once given the entanglement
> > > between early boot enumeration relative to memory that can optionally be
> > > reserved from the kernel page allocator by default. The new concepts
> > > are:
> > >
> > > - E820_TYPE_SOFT_RESERVED: Upon detecting the EFI_MEMORY_SP
> > >   attribute on EFI_CONVENTIONAL memory, update the E820 map with this
> > >   new type. Only perform this classification if the
> > >   CONFIG_EFI_SOFT_RESERVE=y policy is enabled, otherwise treat it as
> > >   typical ram.
> > >
> > > - IORES_DESC_SOFT_RESERVED: Add a new I/O resource descriptor for
> > >   a device driver to search iomem resources for application specific
> > >   memory. Teach the iomem code to identify such ranges as "Soft Reserved".
> > >
> > > A follow-on change integrates parsing of the ACPI HMAT to identify the
> > > node and sub-range boundaries of EFI_MEMORY_SP designated memory. For
> > > now, just identify and reserve memory of this type.
> > >
> > > The translation of EFI_CONVENTIONAL_MEMORY + EFI_MEMORY_SP to "soft
> > > reserved" is x86/E820-only, but other archs could choose to publish
> > > IORES_DESC_SOFT_RESERVED resources from their platform-firmware memory
> > > map handlers. Other EFI-capable platforms would need to go audit their
> > > local usages of EFI_CONVENTIONAL_MEMORY to consider the soft reserved
> > > case.
> > >
> > > Cc: 
> > > Cc: Borislav Petkov 
> > > Cc: Ingo Molnar 
> > > Cc: "H. Peter Anvin" 
> > > Cc: Darren Hart 
> > > Cc: Andy Shevchenko 
> > > Cc: Andy Lutomirski 
> > > Cc: Peter Zijlstra 
> > > Cc: Thomas Gleixner 
> > > Cc: Ard Biesheuvel 
> > > Reported-by: kbuild test robot 
> > > Reviewed-by: Dave Hansen 
> > > Signed-off-by: Dan Williams 
> >
> > Hi Dan,
> >
> > I understand that non-x86 may be out of scope for you, but this patch
> > makes changes to x86 and generic code at the same time without regard
> > for other architectures.
>
> Yes, that did give me pause.
>
> > I'd prefer it if we could cover ARM cleanly as well right at the start.
>
> Let's do it.
>
> >
> > The first step would be to split out the EFI stub changes (i.e., to
> > avoid allocating memory from EFI_MEMORY_SP regions) and the EFI core
> > changes from the other changes. Then, I would like to ask for your
> > help to get the arm64 part implemented where EFI_MEMORY_SP memory gets
> > registered/reserved in a way that allows the HMAT code (which should
> > be arch agnostic) to operate in the same way as it does on x86. Would
> > it be enough to simply memblock_reserve() it and insert the iomem
> > resource with the soft_reserved attribute?
> >
> > Some more comments below.
> >
> > > ---
> > >  Documentation/admin-guide/kernel-parameters.txt |   19 +++--
> > >  arch/x86/Kconfig|   21 +
> > >  arch/x86/boot/compressed/eboot.c|7 +++
> > >  arch/x86/boot/compressed/kaslr.c|4 ++
> > >  arch/x86/include/asm/e820/types.h   |8 
> > >  arch/x86/include/asm/efi-stub.h |   11 +
> > >  arch/x86/kernel/e820.c  |   12 +
> &g

Re: [PATCH v5 05/10] x86, efi: Add efi_fake_mem support for EFI_MEMORY_SP

2019-09-13 Thread Ard Biesheuvel
On Fri, 30 Aug 2019 at 03:07, Dan Williams  wrote:
>
> Given that EFI_MEMORY_SP is platform BIOS policy descision for marking

decision

> memory ranges as "reserved for a specific purpose" there will inevitably
> be scenarios where the BIOS omits the attribute in situations where it
> is desired. Unlike other attributes if the OS wants to reserve this
> memory from the kernel the reservation needs to happen early in init. So
> early, in fact, that it needs to happen before e820__memblock_setup()
> which is a pre-requisite for efi_fake_memmap() that wants to allocate
> memory for the updated table.
>
> Introduce an x86 specific efi_fake_memmap_early() that can search for
> attempts to set EFI_MEMORY_SP via efi_fake_mem and update the e820 table
> accordingly.
>

Is this early enough? The EFI stub runs before this, and allocates
memory as well.

> The KASLR code that scans the command line looking for user-directed
> memory reservations also needs to be updated to consider
> "efi_fake_mem=nn@ss:0x4" requests.
>
> Cc: 
> Cc: Borislav Petkov 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: Thomas Gleixner 
> Cc: Ard Biesheuvel 
> Reviewed-by: Dave Hansen 
> Signed-off-by: Dan Williams 
> ---
>  arch/x86/boot/compressed/kaslr.c|   46 ---
>  arch/x86/include/asm/efi.h  |8 
>  arch/x86/platform/efi/efi.c |2 +
>  drivers/firmware/efi/Makefile   |5 ++-
>  drivers/firmware/efi/fake_mem.c |   24 ++--
>  drivers/firmware/efi/fake_mem.h |   10 +
>  drivers/firmware/efi/x86-fake_mem.c |   69 
> +++
>  7 files changed, 143 insertions(+), 21 deletions(-)
>  create mode 100644 drivers/firmware/efi/fake_mem.h
>  create mode 100644 drivers/firmware/efi/x86-fake_mem.c
>
> diff --git a/arch/x86/boot/compressed/kaslr.c 
> b/arch/x86/boot/compressed/kaslr.c
> index 093e84e28b7a..53ed3991f9a8 100644
> --- a/arch/x86/boot/compressed/kaslr.c
> +++ b/arch/x86/boot/compressed/kaslr.c
> @@ -133,8 +133,14 @@ char *skip_spaces(const char *str)
>  #include "../../../../lib/ctype.c"
>  #include "../../../../lib/cmdline.c"
>
> +enum parse_mode {
> +   PARSE_MEMMAP,
> +   PARSE_EFI,
> +};
> +
>  static int
> -parse_memmap(char *p, unsigned long long *start, unsigned long long *size)
> +parse_memmap(char *p, unsigned long long *start, unsigned long long *size,
> +   enum parse_mode mode)
>  {
> char *oldp;
>
> @@ -157,8 +163,33 @@ parse_memmap(char *p, unsigned long long *start, 
> unsigned long long *size)
> *start = memparse(p + 1, );
> return 0;
> case '@':
> -   /* memmap=nn@ss specifies usable region, should be skipped */
> -   *size = 0;
> +   if (mode == PARSE_MEMMAP) {
> +   /*
> +* memmap=nn@ss specifies usable region, should
> +* be skipped
> +*/
> +   *size = 0;
> +   } else {
> +   unsigned long long flags;
> +
> +   /*
> +* efi_fake_mem=nn@ss:attr the attr specifies
> +* flags that might imply a soft-reservation.
> +*/
> +   *start = memparse(p + 1, );
> +   if (p && *p == ':') {
> +   p++;
> +   oldp = p;
> +   flags = simple_strtoull(p, , 0);
> +   if (p == oldp)
> +   *size = 0;
> +   else if (flags & EFI_MEMORY_SP)
> +   return 0;
> +   else
> +   *size = 0;
> +   } else
> +   *size = 0;
> +   }
> /* Fall through */
> default:
> /*
> @@ -173,7 +204,7 @@ parse_memmap(char *p, unsigned long long *start, unsigned 
> long long *size)
> return -EINVAL;
>  }
>
> -static void mem_avoid_memmap(char *str)
> +static void mem_avoid_memmap(enum parse_mode mode, char *str)
>  {
> static int i;
>
> @@ -188,7 +219,7 @@ static void mem_avoid_memmap(char *str)
> if (k)
> *k++ = 0;
>
> -   rc = parse_memmap(str, , );
> +   rc = parse_memmap(str, , , mode);
>   

Re: [PATCH v5 04/10] x86, efi: Reserve UEFI 2.8 Specific Purpose Memory for dax

2019-09-13 Thread Ard Biesheuvel
On Fri, 30 Aug 2019 at 03:06, Dan Williams  wrote:
>
> UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the
> interpretation of the EFI Memory Types as "reserved for a specific
> purpose".
>
> The proposed Linux behavior for specific purpose memory is that it is
> reserved for direct-access (device-dax) by default and not available for
> any kernel usage, not even as an OOM fallback.  Later, through udev
> scripts or another init mechanism, these device-dax claimed ranges can
> be reconfigured and hot-added to the available System-RAM with a unique
> node identifier. This device-dax management scheme implements "soft" in
> the "soft reserved" designation by allowing some or all of the
> reservation to be recovered as typical memory. This policy can be
> disabled at compile-time with CONFIG_EFI_SOFT_RESERVE=n, or runtime with
> efi=nosoftreserve.
>
> This patch introduces 2 new concepts at once given the entanglement
> between early boot enumeration relative to memory that can optionally be
> reserved from the kernel page allocator by default. The new concepts
> are:
>
> - E820_TYPE_SOFT_RESERVED: Upon detecting the EFI_MEMORY_SP
>   attribute on EFI_CONVENTIONAL memory, update the E820 map with this
>   new type. Only perform this classification if the
>   CONFIG_EFI_SOFT_RESERVE=y policy is enabled, otherwise treat it as
>   typical ram.
>
> - IORES_DESC_SOFT_RESERVED: Add a new I/O resource descriptor for
>   a device driver to search iomem resources for application specific
>   memory. Teach the iomem code to identify such ranges as "Soft Reserved".
>
> A follow-on change integrates parsing of the ACPI HMAT to identify the
> node and sub-range boundaries of EFI_MEMORY_SP designated memory. For
> now, just identify and reserve memory of this type.
>
> The translation of EFI_CONVENTIONAL_MEMORY + EFI_MEMORY_SP to "soft
> reserved" is x86/E820-only, but other archs could choose to publish
> IORES_DESC_SOFT_RESERVED resources from their platform-firmware memory
> map handlers. Other EFI-capable platforms would need to go audit their
> local usages of EFI_CONVENTIONAL_MEMORY to consider the soft reserved
> case.
>
> Cc: 
> Cc: Borislav Petkov 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: Darren Hart 
> Cc: Andy Shevchenko 
> Cc: Andy Lutomirski 
> Cc: Peter Zijlstra 
> Cc: Thomas Gleixner 
> Cc: Ard Biesheuvel 
> Reported-by: kbuild test robot 
> Reviewed-by: Dave Hansen 
> Signed-off-by: Dan Williams 

Hi Dan,

I understand that non-x86 may be out of scope for you, but this patch
makes changes to x86 and generic code at the same time without regard
for other architectures.
I'd prefer it if we could cover ARM cleanly as well right at the start.

The first step would be to split out the EFI stub changes (i.e., to
avoid allocating memory from EFI_MEMORY_SP regions) and the EFI core
changes from the other changes. Then, I would like to ask for your
help to get the arm64 part implemented where EFI_MEMORY_SP memory gets
registered/reserved in a way that allows the HMAT code (which should
be arch agnostic) to operate in the same way as it does on x86. Would
it be enough to simply memblock_reserve() it and insert the iomem
resource with the soft_reserved attribute?

Some more comments below.

> ---
>  Documentation/admin-guide/kernel-parameters.txt |   19 +++--
>  arch/x86/Kconfig|   21 +
>  arch/x86/boot/compressed/eboot.c|7 +++
>  arch/x86/boot/compressed/kaslr.c|4 ++
>  arch/x86/include/asm/e820/types.h   |8 
>  arch/x86/include/asm/efi-stub.h |   11 +
>  arch/x86/kernel/e820.c  |   12 +
>  arch/x86/platform/efi/efi.c |   51 
> +--
>  drivers/firmware/efi/efi.c  |3 +
>  drivers/firmware/efi/libstub/efi-stub-helper.c  |   12 +
>  include/linux/efi.h |1
>  include/linux/ioport.h  |1
>  12 files changed, 139 insertions(+), 11 deletions(-)
>  create mode 100644 arch/x86/include/asm/efi-stub.h
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> b/Documentation/admin-guide/kernel-parameters.txt
> index 1c67acd1df65..dd28f0726309 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1152,7 +1152,8 @@
> Format: {"off" | "on" | "skip[mbr]"}
>
> efi=[EFI]
> -   Format: { "old_map", "nochunk", "noruntime",

Re: [PATCH v5 03/10] x86, efi: Push EFI_MEMMAP check into leaf routines

2019-09-13 Thread Ard Biesheuvel
On Fri, 30 Aug 2019 at 03:06, Dan Williams  wrote:
>
> In preparation for adding another EFI_MEMMAP dependent call that needs
> to occur before e820__memblock_setup() fixup the existing efi calls to
> check for EFI_MEMMAP internally. This ends up being cleaner than the
> alternative of checking EFI_MEMMAP multiple times in setup_arch().
>
> Cc: 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: Andy Lutomirski 
> Cc: Thomas Gleixner 
> Cc: Peter Zijlstra 
> Reviewed-by: Dave Hansen 
> Signed-off-by: Dan Williams 

I'd prefer it if the spurious whitespace changes could be dropped, but
otherwise, this looks fine to me, so I am not going to obsess about
it.

Reviewed-by: Ard Biesheuvel 


> ---
>  arch/x86/include/asm/efi.h  |9 -
>  arch/x86/kernel/setup.c |   19 +--
>  arch/x86/platform/efi/efi.c |3 +++
>  arch/x86/platform/efi/quirks.c  |3 +++
>  drivers/firmware/efi/esrt.c |3 +++
>  drivers/firmware/efi/fake_mem.c |2 +-
>  include/linux/efi.h |2 --
>  7 files changed, 27 insertions(+), 14 deletions(-)
>
> diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
> index 43a82e59c59d..45f853bce869 100644
> --- a/arch/x86/include/asm/efi.h
> +++ b/arch/x86/include/asm/efi.h
> @@ -140,7 +140,6 @@ extern void efi_delete_dummy_variable(void);
>  extern void efi_switch_mm(struct mm_struct *mm);
>  extern void efi_recover_from_page_fault(unsigned long phys_addr);
>  extern void efi_free_boot_services(void);
> -extern void efi_reserve_boot_services(void);
>
>  struct efi_setup_data {
> u64 fw_vendor;
> @@ -244,6 +243,8 @@ static inline bool efi_is_64bit(void)
>  extern bool efi_reboot_required(void);
>  extern bool efi_is_table_address(unsigned long phys_addr);
>
> +extern void efi_find_mirror(void);
> +extern void efi_reserve_boot_services(void);
>  #else
>  static inline void parse_efi_setup(u64 phys_addr, u32 data_len) {}
>  static inline bool efi_reboot_required(void)
> @@ -254,6 +255,12 @@ static inline  bool efi_is_table_address(unsigned long 
> phys_addr)
>  {
> return false;
>  }
> +static inline void efi_find_mirror(void)
> +{
> +}
> +static inline void efi_reserve_boot_services(void)
> +{
> +}
>  #endif /* CONFIG_EFI */
>
>  #endif /* _ASM_X86_EFI_H */
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index bbe35bf879f5..9bfecb542440 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -1118,21 +1118,20 @@ void __init setup_arch(char **cmdline_p)
> cleanup_highmap();
>
> memblock_set_current_limit(ISA_END_ADDRESS);
> +
> e820__memblock_setup();
>
> reserve_bios_regions();
>
> -   if (efi_enabled(EFI_MEMMAP)) {
> -   efi_fake_memmap();
> -   efi_find_mirror();
> -   efi_esrt_init();
> +   efi_fake_memmap();
> +   efi_find_mirror();
> +   efi_esrt_init();
>
> -   /*
> -* The EFI specification says that boot service code won't be
> -* called after ExitBootServices(). This is, in fact, a lie.
> -*/
> -   efi_reserve_boot_services();
> -   }
> +   /*
> +* The EFI specification says that boot service code won't be
> +* called after ExitBootServices(). This is, in fact, a lie.
> +*/
> +   efi_reserve_boot_services();
>
> /* preallocate 4k for mptable mpc */
> e820__memblock_alloc_reserved_mpc_new();
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index c202e1b07e29..0bb58eb33ca0 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -128,6 +128,9 @@ void __init efi_find_mirror(void)
> efi_memory_desc_t *md;
> u64 mirror_size = 0, total_size = 0;
>
> +   if (!efi_enabled(EFI_MEMMAP))
> +   return;
> +
> for_each_efi_memory_desc(md) {
> unsigned long long start = md->phys_addr;
> unsigned long long size = md->num_pages << EFI_PAGE_SHIFT;
> diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
> index 3b9fd679cea9..7675cf754d90 100644
> --- a/arch/x86/platform/efi/quirks.c
> +++ b/arch/x86/platform/efi/quirks.c
> @@ -320,6 +320,9 @@ void __init efi_reserve_boot_services(void)
>  {
> efi_memory_desc_t *md;
>
> +   if (!efi_enabled(EFI_MEMMAP))
> +   return;
> +
> for_each_efi_memory_desc(md) {
> u64 start = md->phys_addr;
> u64 size = md->num_pages << EFI_PAGE_SHI

Re: [PATCH] efi: don't iterate over EFI vars pointlessly if no SSDT override was specified

2019-09-12 Thread Ard Biesheuvel
On Thu, 12 Sep 2019 at 20:35, Scott Talbert  wrote:
>
> On Thu, 12 Sep 2019, Ard Biesheuvel wrote:
>
> > The kernel command line option efivar_ssdt= allows a EFI variable name
> > to be specified which contains an ACPI SSDT table that will be loaded
> > into memory by the OS.
> >
> > Currently, that code will always iterate over the EFI variables and
> > compare each name with the provided name, even if the command line
> > option wasn't set to begin with.
> >
> > So bail early when no variable name was provided.
> >
> > Cc: Scott Talbert 
> > Signed-off-by: Ard Biesheuvel 
> > ---
> > drivers/firmware/efi/efi.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> > index ad3b1f4866b3..8f020827cdd3 100644
> > --- a/drivers/firmware/efi/efi.c
> > +++ b/drivers/firmware/efi/efi.c
> > @@ -282,6 +282,9 @@ static __init int efivar_ssdt_load(void)
> >   void *data;
> >   int ret;
> >
> > + if (!efivar_ssdt[0])
> > + return 0;
> > +
> >   ret = efivar_init(efivar_ssdt_iter, , true, );
> >
> >   list_for_each_entry_safe(entry, aux, , list) {
>
> Thanks for the quick fix!
>
> I can confirm this fixes booting on my Mac Pro 2012 system when applied to
> 5.3-rc7.
>
> Whenever this makes it in, if it could be targeted for the stable kernels
> as well, that would be appreciated.
>

I'll send it out as a fix with a cc to -stable.

Thanks,
Ard.


[PATCH] efi: don't iterate over EFI vars pointlessly if no SSDT override was specified

2019-09-11 Thread Ard Biesheuvel
The kernel command line option efivar_ssdt= allows a EFI variable name
to be specified which contains an ACPI SSDT table that will be loaded
into memory by the OS.

Currently, that code will always iterate over the EFI variables and
compare each name with the provided name, even if the command line
option wasn't set to begin with.

So bail early when no variable name was provided.

Cc: Scott Talbert 
Signed-off-by: Ard Biesheuvel 
---
 drivers/firmware/efi/efi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index ad3b1f4866b3..8f020827cdd3 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -282,6 +282,9 @@ static __init int efivar_ssdt_load(void)
void *data;
int ret;
 
+   if (!efivar_ssdt[0])
+   return 0;
+
ret = efivar_init(efivar_ssdt_iter, , true, );
 
list_for_each_entry_safe(entry, aux, , list) {
-- 
2.17.1



Re: Boot regression in 4.8 for Mac Pro server

2019-09-11 Thread Ard Biesheuvel
On Wed, 11 Sep 2019 at 21:48, Scott Talbert  wrote:
>
> Hi,
>
> I just recently discovered a boot regression that occurred starting in 4.8
> on a Mac Pro Mid-2012 server (MacPro5,1).  Yes, I realize this problem is
> over 3 years old.  Obviously, I haven't been using Linux on this hardware
> in a while.  :-)  I bisected the regression to
> 475fb4e8b2fd1d7b406ff3a7d21bc89a1e6f "efi / ACPI: load SSTDs from EFI
> variables".  And indeed, v5.3-rc7 will boot if I comment out the
> efivar_ssdt_load() call, as in:
>
> $ git diff
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index ad3b1f4866b3..691a8671a2ba 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -364,8 +364,8 @@ static int __init efisubsys_init(void)
>  if (error)
>  goto err_put;
>
> -   if (efi_enabled(EFI_RUNTIME_SERVICES))
> -   efivar_ssdt_load();
> +   //if (efi_enabled(EFI_RUNTIME_SERVICES))
> +   //  efivar_ssdt_load();
>
>  error = sysfs_create_group(efi_kobj, _subsys_attr_group);
>  if (error) {
>
>
> Any thoughts on how to fix this?
>

Thanks for the report. It appears the SSDT loading code is slightly
broken, in the sense that it always iterates over all EFI variables
regardless of whether an SSDT override was actually requested on the
command line, which is silly.

I'll have a patch out shortly, and I'll put you on cc. Please test it
and report back.


Re: arm64/efistub boot error with CONFIG_GCC_PLUGIN_STACKLEAK

2019-09-04 Thread Ard Biesheuvel
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/Armada

Re: [PATCH] efi: cper: Fix endianness of PCIe class code

2019-09-01 Thread Ard Biesheuvel
On Sun, 25 Aug 2019 at 10:04, Lukas Wunner  wrote:
>
> The CPER parser assumes that the class code is big endian, but at least
> on this edk2-derived Intel Purley platform it's little endian:
>
> efi: EFI v2.50 by EDK II BIOS ID:PLYDCRB1.86B.0119.R05.1701181843
> DMI: Intel Corporation PURLEY/PURLEY, BIOS 
> PLYDCRB1.86B.0119.R05.1701181843 01/18/2017
>
> {1}[Hardware Error]:   device_id: :5d:00.0
> {1}[Hardware Error]:   slot: 0
> {1}[Hardware Error]:   secondary_bus: 0x5e
> {1}[Hardware Error]:   vendor_id: 0x8086, device_id: 0x2030
> {1}[Hardware Error]:   class_code: 000406
>^^ (should be 060400)
>
> Signed-off-by: Lukas Wunner 
> ---
>  drivers/firmware/efi/cper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
> index addf0749dd8b..b1af0de2e100 100644
> --- a/drivers/firmware/efi/cper.c
> +++ b/drivers/firmware/efi/cper.c
> @@ -381,7 +381,7 @@ static void cper_print_pcie(const char *pfx, const struct 
> cper_sec_pcie *pcie,
> printk("%s""vendor_id: 0x%04x, device_id: 0x%04x\n", pfx,
>pcie->device_id.vendor_id, pcie->device_id.device_id);
> p = pcie->device_id.class_code;
> -   printk("%s""class_code: %02x%02x%02x\n", pfx, p[0], p[1], 
> p[2]);
> +   printk("%s""class_code: %02x%02x%02x\n", pfx, p[2], p[1], 
> p[0]);
> }
> if (pcie->validation_bits & CPER_PCIE_VALID_SERIAL_NUMBER)
> printk("%s""serial number: 0x%04x, 0x%04x\n", pfx,

Class codes are always in that order, so the original code is simply wrong.

Acked-by: Ard Biesheuvel 

I'll get this queued shortly.

Thanks,


Re: [PATCH 2/2] efi+tpm: don't traverse an event log with no events

2019-08-31 Thread Ard Biesheuvel
On Mon, 26 Aug 2019 at 18:30, Peter Jones  wrote:
>
> When there are no entries to put into the final event log, some machines
> will return the template they would have populated anyway.  In this case
> the nr_events field is 0, but the rest of the log is just garbage.
>
> This patch stops us from trying to iterate the table with
> __calc_tpm2_event_size() when the number of events in the table is 0.
>
> Signed-off-by: Peter Jones 
> Tested-by: Lyude Paul 
> ---
>  drivers/firmware/efi/tpm.c | 14 +-
>  1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/firmware/efi/tpm.c b/drivers/firmware/efi/tpm.c
> index 1d3f5ca3eaa..be51ed17c6e 100644
> --- a/drivers/firmware/efi/tpm.c
> +++ b/drivers/firmware/efi/tpm.c
> @@ -75,11 +75,15 @@ int __init efi_tpm_eventlog_init(void)
> goto out;
> }
>
> -   tbl_size = tpm2_calc_event_log_size((void *)efi.tpm_final_log
> -   + sizeof(final_tbl->version)
> -   + sizeof(final_tbl->nr_events),
> -   final_tbl->nr_events,
> -   log_tbl->log);
> +   tbl_size = 0;
> +   if (final_tbl->nr_events != 0) {
> +   void *events = (void *)efi.tpm_final_log
> +   + sizeof(final_tbl->version)
> +       + sizeof(final_tbl->nr_events);

Please put a newline here

With that fixed,

Acked-by: Ard Biesheuvel 

> +   tbl_size = tpm2_calc_event_log_size(events,
> +   final_tbl->nr_events,
> +   log_tbl->log);
> +   }
> memblock_reserve((unsigned long)final_tbl,
>  tbl_size + sizeof(*final_tbl));
> early_memunmap(final_tbl, sizeof(*final_tbl));
> --
> 2.23.0.rc2
>


Re: [PATCH 1/2] efi+tpm: Don't access event->count when it isn't mapped.

2019-08-31 Thread Ard Biesheuvel
On Mon, 26 Aug 2019 at 18:30, Peter Jones  wrote:
>
> Some machines generate a lot of event log entries.  When we're
> iterating over them, the code removes the old mapping and adds a
> new one, so once we cross the page boundary we're unmapping the page
> with the count on it.  Hilarity ensues.
>
> This patch keeps the info from the header in local variables so we don't
> need to access that page again or keep track of if it's mapped.
>
> Signed-off-by: Peter Jones 
> Tested-by: Lyude Paul 
> ---
>  include/linux/tpm_eventlog.h | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/tpm_eventlog.h b/include/linux/tpm_eventlog.h
> index 63238c84dc0..549dab0b56b 100644
> --- a/include/linux/tpm_eventlog.h
> +++ b/include/linux/tpm_eventlog.h
> @@ -170,6 +170,7 @@ static inline int __calc_tpm2_event_size(struct 
> tcg_pcr_event2_head *event,
> u16 halg;
> int i;
> int j;
> +   u32 count, event_type;
>
> marker = event;
> marker_start = marker;
> @@ -190,16 +191,22 @@ static inline int __calc_tpm2_event_size(struct 
> tcg_pcr_event2_head *event,
> }
>
> event = (struct tcg_pcr_event2_head *)mapping;
> +   /*
> +* the loop below will unmap these fields if the log is larger than
> +* one page, so save them here for reference.
> +*/
> +   count = event->count;
> +   event_type = event->event_type;
>

These assignments should be using READ_ONCE(), since otherwise, the
compiler may reload these quantities from memory anyway.

With that fixed,

Acked-by: Ard Biesheuvel 

> efispecid = (struct tcg_efi_specid_event_head *)event_header->event;
>
> /* Check if event is malformed. */
> -   if (event->count > efispecid->num_algs) {
> +   if (count > efispecid->num_algs) {
> size = 0;
> goto out;
> }
>
> -   for (i = 0; i < event->count; i++) {
> +   for (i = 0; i < count; i++) {
> halg_size = sizeof(event->digests[i].alg_id);
>
> /* Map the digest's algorithm identifier */
> @@ -256,8 +263,9 @@ static inline int __calc_tpm2_event_size(struct 
> tcg_pcr_event2_head *event,
> + event_field->event_size;
> size = marker - marker_start;
>
> -   if ((event->event_type == 0) && (event_field->event_size == 0))
> +   if (event_type == 0 && event_field->event_size == 0)
> size = 0;
> +
>  out:
> if (do_mapping)
> TPM_MEMUNMAP(mapping, mapping_size);
> --
> 2.23.0.rc2
>


Re: [PATCH] efi/arm: fix allocation failure when reserving the kernel base

2019-08-21 Thread Ard Biesheuvel
On Wed, 21 Aug 2019 at 11:29, Mike Rapoport  wrote:
>
> On Wed, Aug 21, 2019 at 10:29:37AM +0300, Ard Biesheuvel wrote:
> > On Wed, 21 Aug 2019 at 10:11, Mike Rapoport  wrote:
> > >
...
> > > I think the only missing part here is to ensure that non-reserved memory 
> > > in
> > > bank 0 starts from a PMD-aligned address. I believe this could be done if
> > > EFI stub, but I'm not really familiar with it so this just a semi-educated
> > > guess :)
> > >
> >
> > Given that it is the ARM arch code that imposes this requirement, how
> > about adding something like this to adjust_lowmem_bounds():
> >
> > if (memblock_start_of_DRAM() % PMD_SIZE)
> > memblock_mark_nomap(memblock_start_of_DRAM(),
> > PMD_SIZE - (memblock_start_of_DRAM() % PMD_SIZE));
>
> memblock_start_of_DRAM() won't work here, as it returns the actual start of
> the DRAM including NOMAP regions. Moreover, as we cannot mark a region
> NOMAP inside for_each_memblock() this should be done beforehand.
>
> I think something like this could work:
>
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index 2f0f07e..f2b635b 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -1178,6 +1178,19 @@ void __init adjust_lowmem_bounds(void)
>  */
> vmalloc_limit = (u64)(uintptr_t)vmalloc_min - PAGE_OFFSET + 
> PHYS_OFFSET;
>
> +   /*
> +* The first usable region must be PMD aligned. Mark its start
> +* as MEMBLOCK_NOMAP if it isn't
> +*/
> +   for_each_memblock(memory, reg) {
> +   if (!memblock_is_nomap(reg) && (reg->base % PMD_SIZE)) {
> +   phys_addr_t size = PMD_SIZE - (reg->base % PMD_SIZE);
> +
> +   memblock_mark_nomap(reg->base, size);
> +   break;

We should break on the first !NOMAP memblock, even if it is already
PMD aligned, but beyond that, this looks ok to me.


Re: [PATCH] efi/arm: fix allocation failure when reserving the kernel base

2019-08-21 Thread Ard Biesheuvel
On Wed, 21 Aug 2019 at 10:11, Mike Rapoport  wrote:
>
> On Wed, Aug 21, 2019 at 09:35:16AM +0300, Ard Biesheuvel wrote:
> > On Wed, 21 Aug 2019 at 09:11, Chester Lin  wrote:
> > >
> > > On Tue, Aug 20, 2019 at 03:28:25PM +0300, Ard Biesheuvel wrote:
> > > > On Tue, 20 Aug 2019 at 14:56, Russell King - ARM Linux admin
> > > >  wrote:
> > > > >
> > > > > On Fri, Aug 02, 2019 at 05:38:54AM +, Chester Lin wrote:
> > > > > > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> > > > > > index f3ce34113f89..909b11ba48d8 100644
> > > > > > --- a/arch/arm/mm/mmu.c
> > > > > > +++ b/arch/arm/mm/mmu.c
> > > > > > @@ -1184,6 +1184,9 @@ void __init adjust_lowmem_bounds(void)
> > > > > >   phys_addr_t block_start = reg->base;
> > > > > >   phys_addr_t block_end = reg->base + reg->size;
> > > > > >
> > > > > > + if (memblock_is_nomap(reg))
> > > > > > + continue;
> > > > > > +
> > > > > >   if (reg->base < vmalloc_limit) {
> > > > > >   if (block_end > lowmem_limit)
> > > > > >   /*
> > > > >
> > > > > I think this hunk is sane - if the memory is marked nomap, then it 
> > > > > isn't
> > > > > available for the kernel's use, so as far as calculating where the
> > > > > lowmem/highmem boundary is, it effectively doesn't exist and should be
> > > > > skipped.
> > > > >
> > > >
> > > > I agree.
> > > >
> > > > Chester, could you explain what you need beyond this change (and my
> > > > EFI stub change involving TEXT_OFFSET) to make things work on the
> > > > RPi2?
> > > >
> > >
> > > Hi Ard,
> > >
> > > In fact I am working with Guillaume to try booting zImage kernel and 
> > > openSUSE
> > > from grub2.04 + arm32-efistub so that's why we get this issue on RPi2, 
> > > which is
> > > one of the test machines we have. However we want a better solution for 
> > > all
> > > cases but not just RPi2 since we don't want to affect other platforms as 
> > > well.
> > >
> >
> > Thanks Chester, but that doesn't answer my question.
> >
> > Your fix is a single patch that changes various things that are only
> > vaguely related. We have already identified that we need to take
> > TEXT_OFFSET (minus some space used by the swapper page tables) into
> > account into the EFI stub if we want to ensure compatibility with many
> > different platforms, and as it turns out, this applies not only to
> > RPi2 but to other platforms as well, most notably the ones that
> > require a TEXT_OFFSET of 0x208000, since they also have reserved
> > regions at the base of RAM.
> >
> > My question was what else we need beyond:
> > - the EFI stub TEXT_OFFSET fix [0]
> > - the change to disregard NOMAP memblocks in adjust_lowmem_bounds()
> > - what else???
>
> I think the only missing part here is to ensure that non-reserved memory in
> bank 0 starts from a PMD-aligned address. I believe this could be done if
> EFI stub, but I'm not really familiar with it so this just a semi-educated
> guess :)
>

Given that it is the ARM arch code that imposes this requirement, how
about adding something like this to adjust_lowmem_bounds():

if (memblock_start_of_DRAM() % PMD_SIZE)
memblock_mark_nomap(memblock_start_of_DRAM(),
PMD_SIZE - (memblock_start_of_DRAM() % PMD_SIZE));

(and introduce the nomap check into the loop)


Re: [PATCH] efi/arm: fix allocation failure when reserving the kernel base

2019-08-21 Thread Ard Biesheuvel
On Wed, 21 Aug 2019 at 09:11, Chester Lin  wrote:
>
> On Tue, Aug 20, 2019 at 03:28:25PM +0300, Ard Biesheuvel wrote:
> > On Tue, 20 Aug 2019 at 14:56, Russell King - ARM Linux admin
> >  wrote:
> > >
> > > On Fri, Aug 02, 2019 at 05:38:54AM +, Chester Lin wrote:
> > > > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> > > > index f3ce34113f89..909b11ba48d8 100644
> > > > --- a/arch/arm/mm/mmu.c
> > > > +++ b/arch/arm/mm/mmu.c
> > > > @@ -1184,6 +1184,9 @@ void __init adjust_lowmem_bounds(void)
> > > >   phys_addr_t block_start = reg->base;
> > > >   phys_addr_t block_end = reg->base + reg->size;
> > > >
> > > > + if (memblock_is_nomap(reg))
> > > > + continue;
> > > > +
> > > >   if (reg->base < vmalloc_limit) {
> > > >   if (block_end > lowmem_limit)
> > > >   /*
> > >
> > > I think this hunk is sane - if the memory is marked nomap, then it isn't
> > > available for the kernel's use, so as far as calculating where the
> > > lowmem/highmem boundary is, it effectively doesn't exist and should be
> > > skipped.
> > >
> >
> > I agree.
> >
> > Chester, could you explain what you need beyond this change (and my
> > EFI stub change involving TEXT_OFFSET) to make things work on the
> > RPi2?
> >
>
> Hi Ard,
>
> In fact I am working with Guillaume to try booting zImage kernel and openSUSE
> from grub2.04 + arm32-efistub so that's why we get this issue on RPi2, which 
> is
> one of the test machines we have. However we want a better solution for all
> cases but not just RPi2 since we don't want to affect other platforms as well.
>

Thanks Chester, but that doesn't answer my question.

Your fix is a single patch that changes various things that are only
vaguely related. We have already identified that we need to take
TEXT_OFFSET (minus some space used by the swapper page tables) into
account into the EFI stub if we want to ensure compatibility with many
different platforms, and as it turns out, this applies not only to
RPi2 but to other platforms as well, most notably the ones that
require a TEXT_OFFSET of 0x208000, since they also have reserved
regions at the base of RAM.

My question was what else we need beyond:
- the EFI stub TEXT_OFFSET fix [0]
- the change to disregard NOMAP memblocks in adjust_lowmem_bounds()
- what else???


[0] 
https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/commit/?h=next=0eb7bad595e52666b642a02862ad996a0f9bfcc0


Re: [PATCH] efi/arm: fix allocation failure when reserving the kernel base

2019-08-20 Thread Ard Biesheuvel
On Tue, 20 Aug 2019 at 14:56, Russell King - ARM Linux admin
 wrote:
>
> On Fri, Aug 02, 2019 at 05:38:54AM +, Chester Lin wrote:
> > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> > index f3ce34113f89..909b11ba48d8 100644
> > --- a/arch/arm/mm/mmu.c
> > +++ b/arch/arm/mm/mmu.c
> > @@ -1184,6 +1184,9 @@ void __init adjust_lowmem_bounds(void)
> >   phys_addr_t block_start = reg->base;
> >   phys_addr_t block_end = reg->base + reg->size;
> >
> > + if (memblock_is_nomap(reg))
> > + continue;
> > +
> >   if (reg->base < vmalloc_limit) {
> >   if (block_end > lowmem_limit)
> >   /*
>
> I think this hunk is sane - if the memory is marked nomap, then it isn't
> available for the kernel's use, so as far as calculating where the
> lowmem/highmem boundary is, it effectively doesn't exist and should be
> skipped.
>

I agree.

Chester, could you explain what you need beyond this change (and my
EFI stub change involving TEXT_OFFSET) to make things work on the
RPi2?


Re: [PATCH] efi/arm: fix allocation failure when reserving the kernel base

2019-08-20 Thread Ard Biesheuvel
On Tue, 20 Aug 2019 at 14:54, Russell King - ARM Linux admin
 wrote:
>
> On Sun, Aug 04, 2019 at 10:57:00AM +0300, Ard Biesheuvel wrote:
> > (The first TEXT_OFFSET bytes are no longer used in practice, which is
> > why putting a reserved region of 4 KB bytes works at the moment, but
> > this is fragile).
>
> That is not correct for 32-bit ARM.  The swapper page table is still
> located 16kiB below the kernel.
>

Right. So that means we can only permit reserved regions in the first
(TEXT_OFFSET - 16 kiB) bytes starting at the first 128 MiB aligned
address covered by system RAM, if we want to ensure that the
decompressor or the early kernel don't trample on it. (or TEXT_OFFSET
- 20 kiB for LPAE kernels)


Re: [PATCH] efi/arm: fix allocation failure when reserving the kernel base

2019-08-20 Thread Ard Biesheuvel
On Tue, 20 Aug 2019 at 10:49, Mike Rapoport  wrote:
>
> On Mon, Aug 19, 2019 at 05:56:51PM +0300, Ard Biesheuvel wrote:
> > On Mon, 19 Aug 2019 at 11:01, Chester Lin  wrote:
> > >
> > > Hi Mike and Ard,
> > >
> > > On Thu, Aug 15, 2019 at 04:37:39PM +0300, Mike Rapoport wrote:
> > > > On Thu, Aug 15, 2019 at 02:32:50PM +0300, Ard Biesheuvel wrote:
> > > > > (adding Mike)
> > > > >
>
> ...
>
> > > > > > In this case the kernel failed to reserve cma, which should hit the 
> > > > > > issue of
> > > > > > memblock_limit=0x1000 as I had mentioned in my patch description. 
> > > > > > The first
> > > > > > block [0-0xfff] was scanned in adjust_lowmem_bounds(), but it did 
> > > > > > not align
> > > > > > with PMD_SIZE so the cma reservation failed because the 
> > > > > > memblock.current_limit
> > > > > > was extremely low. That's why I expand the first reservation from 1 
> > > > > > PAGESIZE to
> > > > > > 1 PMD_SIZE in my patch in order to avoid this issue. Please kindly 
> > > > > > let me know
> > > > > > if any suggestion, thank you.
> > > >
> > > >
> > > > > This looks like it is a separate issue. The memblock/cma code should
> > > > > not choke on a reserved page of memory at 0x0.
> > > > >
> > > > > Perhaps Russell or Mike (cc'ed) have an idea how to address this?
> > > >
> > > > Presuming that the last memblock dump comes from the end of
> > > > arm_memblock_init() with the this memory map
> > > >
> > > > memory[0x0] [0x-0x0fff], 0x1000 
> > > > bytes flags: 0x4
> > > > memory[0x1] [0x1000-0x07ef5fff], 0x07ef5000 
> > > > bytes flags: 0x0
> > > > memory[0x2] [0x07ef6000-0x07f09fff], 0x00014000 
> > > > bytes flags: 0x4
> > > > memory[0x3] [0x07f0a000-0x3cb3efff], 0x34c35000 
> > > > bytes flags: 0x0
> > > >
> > > > adjust_lowmem_bounds() will set the memblock_limit (and respectively 
> > > > global
> > > > memblock.current_limit) to 0x1000 and any further memblock_alloc*() will
> > > > happily fail.
> > > >
> > > > I believe that the assumption for memblock_limit calculations was that 
> > > > the
> > > > first bank has several megs at least.
> > > >
> > > > I wonder if this hack would help:
> > > >
> > > > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> > > > index d9a0038..948e5b9 100644
> > > > --- a/arch/arm/mm/mmu.c
> > > > +++ b/arch/arm/mm/mmu.c
> > > > @@ -1206,7 +1206,7 @@ void __init adjust_lowmem_bounds(void)
> > > >* allocated when mapping the start of bank 0, 
> > > > which
> > > >* occurs before any free memory is mapped.
> > > >*/
> > > > - if (!memblock_limit) {
> > > > + if (memblock_limit < PMD_SIZE) {
> > > >   if (!IS_ALIGNED(block_start, PMD_SIZE))
> > > >   memblock_limit = block_start;
> > > >   else if (!IS_ALIGNED(block_end, PMD_SIZE))
> > > >
> > >
> > > I applied this patch as well and it works well on rpi-2 model B.
> > >
> >
> > Thanks, Chester, that is good to know.
> >
> > However, afaict, this only affects systems where physical memory
> > starts at address 0x0, so I think we need a better fix.
>
> This hack can be easily extended to handle systems with arbitrary start
> address, but it's still a hack...
>
> > I know Mike has been looking into the NOMAP stuff lately, and your
> > original patch contains a hunk that makes this code (?) disregard
> > nomap memblocks. That might be a better approach.
>
> I was actually looking how to replace NOMAP with something else to make
> memblock.memory consistent with actual physical memory banks. But this work
> is stashed for now.
>
> I'm not sure that skipping NOMAP regions would be good enough.
> If I understand corrrectly, with Chester's original patch the reservation
> of PMD aligned chunk of 32M for the kernel made the first conv-mem region
> PMD aligned and then memblock_limit will be set to the end of this region.
>
> Is there a reason for marking EFI_RESERVED_TYPE as NOMAP rather than simply
> reserve them with memblock_reserve()?
>

Yes.

On ARM systems, reserved memory regions should never be mapped by
default, since the cacheable mappings we use in the linear region may
conflict with the mapping attributes used by the firmware or driver
components that are using this memory.

In this particular case, we are talking about things like spin tables
and pens for secondaries that boot up with their caches disabled, and
having a cacheable mapping on the primary CPU might cause a loss of
coherency.


Re: [PATCH] efi/arm: fix allocation failure when reserving the kernel base

2019-08-19 Thread Ard Biesheuvel
On Mon, 19 Aug 2019 at 11:01, Chester Lin  wrote:
>
> Hi Mike and Ard,
>
> On Thu, Aug 15, 2019 at 04:37:39PM +0300, Mike Rapoport wrote:
> > On Thu, Aug 15, 2019 at 02:32:50PM +0300, Ard Biesheuvel wrote:
> > > (adding Mike)
> > >
> > > On Thu, 15 Aug 2019 at 14:28, Chester Lin  wrote:
> > > >
> > > > Hi Ard,
> > > >
> > > > On Thu, Aug 15, 2019 at 10:59:43AM +0300, Ard Biesheuvel wrote:
> > > > > On Sun, 4 Aug 2019 at 10:57, Ard Biesheuvel 
> > > > >  wrote:
> > > > > >
> > > > > > Hello Chester,
> > > > > >
> > > > > > On Fri, 2 Aug 2019 at 08:40, Chester Lin  wrote:
> > > > > > >
> > > > > > > In some cases the arm32 efistub could fail to allocate memory for
> > > > > > > uncompressed kernel. For example, we got the following error 
> > > > > > > message when
> > > > > > > verifying EFI stub on Raspberry Pi-2 [kernel-5.2.1 + grub-2.04] :
> > > > > > >
> > > > > > >   EFI stub: Booting Linux Kernel...
> > > > > > >   EFI stub: ERROR: Unable to allocate memory for uncompressed 
> > > > > > > kernel.
> > > > > > >   EFI stub: ERROR: Failed to relocate kernel
> > > > > > >
> > > > > > > After checking the EFI memory map we found that the first page [0 
> > > > > > > - 0xfff]
> > > > > > > had been reserved by Raspberry Pi-2's firmware, and the efistub 
> > > > > > > tried to
> > > > > > > set the dram base at 0, which was actually in a reserved region.
> > > > > > >
> > > > > >
> > > > > > This by itself is a violation of the Linux boot protocol for 32-bit
> > > > > > ARM when using the decompressor. The decompressor rounds down its 
> > > > > > own
> > > > > > base address to a multiple of 128 MB, and assumes the whole area is
> > > > > > available for the decompressed kernel and related data structures.
> > > > > > (The first TEXT_OFFSET bytes are no longer used in practice, which 
> > > > > > is
> > > > > > why putting a reserved region of 4 KB bytes works at the moment, but
> > > > > > this is fragile). Note that the decompressor does not look at any DT
> > > > > > or EFI provided memory maps *at all*.
> > > > > >
> > > > > > So unfortunately, this is not something we can fix in the kernel, 
> > > > > > but
> > > > > > we should fix it in the bootloader or in GRUB, so it does not put 
> > > > > > any
> > > > > > reserved regions in the first 128 MB of memory,
> > > > > >
> > > > >
> > > > > OK, perhaps we can fix this by taking TEXT_OFFSET into account. The
> > > > > ARM boot protocol docs are unclear about whether this memory should be
> > > > > used or not, but it is no longer used for its original purpose (page
> > > > > tables), and the RPi loader already keeps data there.
> > > > >
> > > > > Can you check whether the following patch works for you?
> > > > >
> > > > > diff --git a/drivers/firmware/efi/libstub/Makefile
> > > > > b/drivers/firmware/efi/libstub/Makefile
> > > > > index 0460c7581220..ee0661ddb25b 100644
> > > > > --- a/drivers/firmware/efi/libstub/Makefile
> > > > > +++ b/drivers/firmware/efi/libstub/Makefile
> > > > > @@ -52,6 +52,7 @@ lib-$(CONFIG_EFI_ARMSTUB) += arm-stub.o fdt.o
> > > > > string.o random.o \
> > > > >
> > > > >  lib-$(CONFIG_ARM)  += arm32-stub.o
> > > > >  lib-$(CONFIG_ARM64)+= arm64-stub.o
> > > > > +CFLAGS_arm32-stub.o:= -DTEXT_OFFSET=$(TEXT_OFFSET)
> > > > >  CFLAGS_arm64-stub.o:= -DTEXT_OFFSET=$(TEXT_OFFSET)
> > > > >
> > > > >  #
> > > > > diff --git a/drivers/firmware/efi/libstub/arm32-stub.c
> > > > > b/drivers/firmware/efi/libstub/arm32-stub.c
> > > > > index e8f7aefb6813..66ff0c8ec269 100644
> > > > > --- a/drivers/firmware/efi/libstub/arm32-stub.c
> > > > > +++ b/drivers/firmware/efi/libstub/arm32-stub.c
> > > > > @@ -204,7 +204,

Re: [PATCH] efi/arm: fix allocation failure when reserving the kernel base

2019-08-15 Thread Ard Biesheuvel
(adding Mike)

On Thu, 15 Aug 2019 at 14:28, Chester Lin  wrote:
>
> Hi Ard,
>
> On Thu, Aug 15, 2019 at 10:59:43AM +0300, Ard Biesheuvel wrote:
> > On Sun, 4 Aug 2019 at 10:57, Ard Biesheuvel  
> > wrote:
> > >
> > > Hello Chester,
> > >
> > > On Fri, 2 Aug 2019 at 08:40, Chester Lin  wrote:
> > > >
> > > > In some cases the arm32 efistub could fail to allocate memory for
> > > > uncompressed kernel. For example, we got the following error message 
> > > > when
> > > > verifying EFI stub on Raspberry Pi-2 [kernel-5.2.1 + grub-2.04] :
> > > >
> > > >   EFI stub: Booting Linux Kernel...
> > > >   EFI stub: ERROR: Unable to allocate memory for uncompressed kernel.
> > > >   EFI stub: ERROR: Failed to relocate kernel
> > > >
> > > > After checking the EFI memory map we found that the first page [0 - 
> > > > 0xfff]
> > > > had been reserved by Raspberry Pi-2's firmware, and the efistub tried to
> > > > set the dram base at 0, which was actually in a reserved region.
> > > >
> > >
> > > This by itself is a violation of the Linux boot protocol for 32-bit
> > > ARM when using the decompressor. The decompressor rounds down its own
> > > base address to a multiple of 128 MB, and assumes the whole area is
> > > available for the decompressed kernel and related data structures.
> > > (The first TEXT_OFFSET bytes are no longer used in practice, which is
> > > why putting a reserved region of 4 KB bytes works at the moment, but
> > > this is fragile). Note that the decompressor does not look at any DT
> > > or EFI provided memory maps *at all*.
> > >
> > > So unfortunately, this is not something we can fix in the kernel, but
> > > we should fix it in the bootloader or in GRUB, so it does not put any
> > > reserved regions in the first 128 MB of memory,
> > >
> >
> > OK, perhaps we can fix this by taking TEXT_OFFSET into account. The
> > ARM boot protocol docs are unclear about whether this memory should be
> > used or not, but it is no longer used for its original purpose (page
> > tables), and the RPi loader already keeps data there.
> >
> > Can you check whether the following patch works for you?
> >
> > diff --git a/drivers/firmware/efi/libstub/Makefile
> > b/drivers/firmware/efi/libstub/Makefile
> > index 0460c7581220..ee0661ddb25b 100644
> > --- a/drivers/firmware/efi/libstub/Makefile
> > +++ b/drivers/firmware/efi/libstub/Makefile
> > @@ -52,6 +52,7 @@ lib-$(CONFIG_EFI_ARMSTUB) += arm-stub.o fdt.o
> > string.o random.o \
> >
> >  lib-$(CONFIG_ARM)  += arm32-stub.o
> >  lib-$(CONFIG_ARM64)+= arm64-stub.o
> > +CFLAGS_arm32-stub.o:= -DTEXT_OFFSET=$(TEXT_OFFSET)
> >  CFLAGS_arm64-stub.o:= -DTEXT_OFFSET=$(TEXT_OFFSET)
> >
> >  #
> > diff --git a/drivers/firmware/efi/libstub/arm32-stub.c
> > b/drivers/firmware/efi/libstub/arm32-stub.c
> > index e8f7aefb6813..66ff0c8ec269 100644
> > --- a/drivers/firmware/efi/libstub/arm32-stub.c
> > +++ b/drivers/firmware/efi/libstub/arm32-stub.c
> > @@ -204,7 +204,7 @@ efi_status_t
> > handle_kernel_image(efi_system_table_t *sys_table,
> >  * loaded. These assumptions are made by the decompressor,
> >  * before any memory map is available.
> >  */
> > -   dram_base = round_up(dram_base, SZ_128M);
> > +   dram_base = round_up(dram_base, SZ_128M) + TEXT_OFFSET;
> >
> > status = reserve_kernel_base(sys_table, dram_base, reserve_addr,
> >  reserve_size);
> >
>
> I tried your patch on rpi2 and got the following panic. Just a reminder that I
> have replaced some log messages with ".." since it might be too long to
> post all.
>

OK. Good to know that this change helps you to get past the EFI stub boot issue.

> In this case the kernel failed to reserve cma, which should hit the issue of
> memblock_limit=0x1000 as I had mentioned in my patch description. The first
> block [0-0xfff] was scanned in adjust_lowmem_bounds(), but it did not align
> with PMD_SIZE so the cma reservation failed because the memblock.current_limit
> was extremely low. That's why I expand the first reservation from 1 PAGESIZE 
> to
> 1 PMD_SIZE in my patch in order to avoid this issue. Please kindly let me know
> if any suggestion, thank you.
>

This looks like it is a separate issue. The memblock/cma code should
not choke on a reserved page of memory 

Re: arm64/efistub boot error with CONFIG_GCC_PLUGIN_STACKLEAK

2019-08-15 Thread Ard Biesheuvel
On Thu, 15 Aug 2019 at 14:03, Mark Rutland  wrote:
>
> On Thu, Aug 15, 2019 at 05:56:27AM -0400, skodde wrote:
> > Hi,
> >
> > I've enabled CONFIG_GCC_PLUGIN_STACKLEAK on 5.2.8 for an arm64
> > macchiatobin board and I get the following error when loading the
> > kernel (using grub-efi on top of edk ii):
> >
> > EFI stub: Booting Linux Kernel...
> > EFI stub: ERROR: efi_get_random_bytes() failed
> > EFI stub: ERROR: Failed to relocate kernel
> >
> > 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.
>
> Are you certain that you're running the same kernel Image that you
> rebuilt?
>
> Ard, do you reckon it would be worth adding the UTS_RELEASE and
> UTS_VERSION to the " Booting Linux Kernel..." string? It would make
> debugging that potential issue easier.
>

Use of the UTS_xxx macros already triggers an annoying number of
object rebuilds every time you change anything entirely unrelated in
your kernel sources, so I'd prefer to avoid this tbh.

> > Let me know if I can provide more info or do some tests.
>
> 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?


Re: [PATCH] efi/arm: fix allocation failure when reserving the kernel base

2019-08-15 Thread Ard Biesheuvel
On Sun, 4 Aug 2019 at 10:57, Ard Biesheuvel  wrote:
>
> Hello Chester,
>
> On Fri, 2 Aug 2019 at 08:40, Chester Lin  wrote:
> >
> > In some cases the arm32 efistub could fail to allocate memory for
> > uncompressed kernel. For example, we got the following error message when
> > verifying EFI stub on Raspberry Pi-2 [kernel-5.2.1 + grub-2.04] :
> >
> >   EFI stub: Booting Linux Kernel...
> >   EFI stub: ERROR: Unable to allocate memory for uncompressed kernel.
> >   EFI stub: ERROR: Failed to relocate kernel
> >
> > After checking the EFI memory map we found that the first page [0 - 0xfff]
> > had been reserved by Raspberry Pi-2's firmware, and the efistub tried to
> > set the dram base at 0, which was actually in a reserved region.
> >
>
> This by itself is a violation of the Linux boot protocol for 32-bit
> ARM when using the decompressor. The decompressor rounds down its own
> base address to a multiple of 128 MB, and assumes the whole area is
> available for the decompressed kernel and related data structures.
> (The first TEXT_OFFSET bytes are no longer used in practice, which is
> why putting a reserved region of 4 KB bytes works at the moment, but
> this is fragile). Note that the decompressor does not look at any DT
> or EFI provided memory maps *at all*.
>
> So unfortunately, this is not something we can fix in the kernel, but
> we should fix it in the bootloader or in GRUB, so it does not put any
> reserved regions in the first 128 MB of memory,
>

OK, perhaps we can fix this by taking TEXT_OFFSET into account. The
ARM boot protocol docs are unclear about whether this memory should be
used or not, but it is no longer used for its original purpose (page
tables), and the RPi loader already keeps data there.

Can you check whether the following patch works for you?

diff --git a/drivers/firmware/efi/libstub/Makefile
b/drivers/firmware/efi/libstub/Makefile
index 0460c7581220..ee0661ddb25b 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -52,6 +52,7 @@ lib-$(CONFIG_EFI_ARMSTUB) += arm-stub.o fdt.o
string.o random.o \

 lib-$(CONFIG_ARM)  += arm32-stub.o
 lib-$(CONFIG_ARM64)+= arm64-stub.o
+CFLAGS_arm32-stub.o:= -DTEXT_OFFSET=$(TEXT_OFFSET)
 CFLAGS_arm64-stub.o:= -DTEXT_OFFSET=$(TEXT_OFFSET)

 #
diff --git a/drivers/firmware/efi/libstub/arm32-stub.c
b/drivers/firmware/efi/libstub/arm32-stub.c
index e8f7aefb6813..66ff0c8ec269 100644
--- a/drivers/firmware/efi/libstub/arm32-stub.c
+++ b/drivers/firmware/efi/libstub/arm32-stub.c
@@ -204,7 +204,7 @@ efi_status_t
handle_kernel_image(efi_system_table_t *sys_table,
 * loaded. These assumptions are made by the decompressor,
 * before any memory map is available.
 */
-   dram_base = round_up(dram_base, SZ_128M);
+   dram_base = round_up(dram_base, SZ_128M) + TEXT_OFFSET;

status = reserve_kernel_base(sys_table, dram_base, reserve_addr,
 reserve_size);

>
> >   grub> lsefimmap
> >   Type  Physical start  - end #PagesSize Attributes
> >   reserved  -0fff 0001  4KiB WB
> >   conv-mem  1000-07ef5fff 7ef5 130004KiB WB
> >   RT-data   07ef6000-07f09fff 0014 80KiB RT WB
> >   conv-mem  07f0a000-2d871fff 00025968 615840KiB WB
> >   .
> >
> > To avoid a reserved address, we have to ignore the memory regions which are
> > marked as EFI_RESERVED_TYPE, and only conventional memory regions can be
> > chosen. If the region before the kernel base is unaligned, it will be
> > marked as EFI_RESERVED_TYPE and let kernel ignore it so that memblock_limit
> > will not be sticked with a very low address such as 0x1000.
> >

This is a separate issue, so it should be handled in a separate patch.

> > Signed-off-by: Chester Lin 
> > ---
> >  arch/arm/mm/mmu.c |  3 ++
> >  drivers/firmware/efi/libstub/arm32-stub.c | 43 ++-
> >  2 files changed, 37 insertions(+), 9 deletions(-)
> >
> > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> > index f3ce34113f89..909b11ba48d8 100644
> > --- a/arch/arm/mm/mmu.c
> > +++ b/arch/arm/mm/mmu.c
> > @@ -1184,6 +1184,9 @@ void __init adjust_lowmem_bounds(void)
> > phys_addr_t block_start = reg->base;
> > phys_addr_t block_end = reg->base + reg->size;
> >
> > +   if (memblock_is_nomap(reg))
> > +   continue;
> > +
> > if (reg->base < vmalloc_limit) {
> > if (

[PATCH 2/5] efi/x86: move UV_SYSTAB handling into arch/x86

2019-08-12 Thread Ard Biesheuvel
The SGI UV UEFI machines are tightly coupled to the x86 architecture
so there is no need to keep any awareness of its existence in the
generic EFI layer, especially since we already have the infrastructure
to handle arch-specific configuration tables, and were even already
using it to some extent.

Signed-off-by: Ard Biesheuvel 
---
 arch/x86/include/asm/uv/uv.h   |  4 +++-
 arch/x86/platform/efi/efi.c|  6 --
 arch/x86/platform/uv/bios_uv.c | 10 ++
 drivers/firmware/efi/efi.c |  1 -
 include/linux/efi.h|  1 -
 5 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv.h b/arch/x86/include/asm/uv/uv.h
index e60c45fd3679..6bc6d89d8e2a 100644
--- a/arch/x86/include/asm/uv/uv.h
+++ b/arch/x86/include/asm/uv/uv.h
@@ -12,10 +12,12 @@ struct mm_struct;
 #ifdef CONFIG_X86_UV
 #include 
 
+extern unsigned long uv_systab_phys;
+
 extern enum uv_system_type get_uv_system_type(void);
 static inline bool is_early_uv_system(void)
 {
-   return !((efi.uv_systab == EFI_INVALID_TABLE_ADDR) || !efi.uv_systab);
+   return uv_systab_phys && uv_systab_phys != EFI_INVALID_TABLE_ADDR;
 }
 extern int is_uv_system(void);
 extern int is_uv_hubless(void);
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 8d9be97a5607..9866a3584765 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -59,7 +59,7 @@ static efi_system_table_t efi_systab __initdata;
 
 static efi_config_table_type_t arch_tables[] __initdata = {
 #ifdef CONFIG_X86_UV
-   {UV_SYSTEM_TABLE_GUID, "UVsystab", _systab},
+   {UV_SYSTEM_TABLE_GUID, "UVsystab", _systab_phys},
 #endif
{NULL_GUID, NULL, NULL},
 };
@@ -74,7 +74,9 @@ static const unsigned long * const efi_tables[] = {
_info,
,
,
-   _systab,
+#ifdef CONFIG_X86_UV
+   _systab_phys,
+#endif
_vendor,
,
_table,
diff --git a/arch/x86/platform/uv/bios_uv.c b/arch/x86/platform/uv/bios_uv.c
index 7c69652ffeea..c2ee31953372 100644
--- a/arch/x86/platform/uv/bios_uv.c
+++ b/arch/x86/platform/uv/bios_uv.c
@@ -14,6 +14,8 @@
 #include 
 #include 
 
+unsigned long uv_systab_phys __ro_after_init = EFI_INVALID_TABLE_ADDR;
+
 struct uv_systab *uv_systab;
 
 static s64 __uv_bios_call(enum uv_bios_cmd which, u64 a1, u64 a2, u64 a3,
@@ -185,13 +187,13 @@ EXPORT_SYMBOL_GPL(uv_bios_set_legacy_vga_target);
 void uv_bios_init(void)
 {
uv_systab = NULL;
-   if ((efi.uv_systab == EFI_INVALID_TABLE_ADDR) ||
-   !efi.uv_systab || efi_runtime_disabled()) {
+   if ((uv_systab_phys == EFI_INVALID_TABLE_ADDR) ||
+   !uv_systab_phys || efi_runtime_disabled()) {
pr_crit("UV: UVsystab: missing\n");
return;
}
 
-   uv_systab = ioremap(efi.uv_systab, sizeof(struct uv_systab));
+   uv_systab = ioremap(uv_systab_phys, sizeof(struct uv_systab));
if (!uv_systab || strncmp(uv_systab->signature, UV_SYSTAB_SIG, 4)) {
pr_err("UV: UVsystab: bad signature!\n");
iounmap(uv_systab);
@@ -203,7 +205,7 @@ void uv_bios_init(void)
int size = uv_systab->size;
 
iounmap(uv_systab);
-   uv_systab = ioremap(efi.uv_systab, size);
+   uv_systab = ioremap(uv_systab_phys, size);
if (!uv_systab) {
pr_err("UV: UVsystab: ioremap(%d) failed!\n", size);
return;
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index cbdbdbc8f9eb..4dfd873373bd 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -43,7 +43,6 @@ struct efi __read_mostly efi = {
.boot_info  = EFI_INVALID_TABLE_ADDR,
.hcdp   = EFI_INVALID_TABLE_ADDR,
.uga= EFI_INVALID_TABLE_ADDR,
-   .uv_systab  = EFI_INVALID_TABLE_ADDR,
.fw_vendor  = EFI_INVALID_TABLE_ADDR,
.runtime= EFI_INVALID_TABLE_ADDR,
.config_table   = EFI_INVALID_TABLE_ADDR,
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 60a6242765d8..171bb1005a10 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -988,7 +988,6 @@ extern struct efi {
unsigned long boot_info;/* boot info table */
unsigned long hcdp; /* HCDP table */
unsigned long uga;  /* UGA table */
-   unsigned long uv_systab;/* UV system table */
unsigned long fw_vendor;/* fw_vendor */
unsigned long runtime;  /* runtime table */
unsigned long config_table; /* config tables */
-- 
2.17.1



[PATCH 3/5] efi: ia64: move SAL systab handling out of generic EFI code

2019-08-12 Thread Ard Biesheuvel
The SAL systab is an Itanium specific EFI configuration table, so
move its handling into arch/ia64 where it belongs.

Cc; Tony Luck 
Cc: Fenghua Yu 
Cc: linux-i...@vger.kernel.org
Signed-off-by: Ard Biesheuvel 
---
 arch/ia64/include/asm/sal.h   | 1 +
 arch/ia64/include/asm/sn/sn_sal.h | 2 +-
 arch/ia64/kernel/efi.c| 3 +++
 arch/ia64/kernel/setup.c  | 2 +-
 arch/x86/platform/efi/efi.c   | 1 -
 drivers/firmware/efi/efi.c| 2 --
 include/linux/efi.h   | 1 -
 7 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/ia64/include/asm/sal.h b/arch/ia64/include/asm/sal.h
index 588f33156da6..08f5b6aaed73 100644
--- a/arch/ia64/include/asm/sal.h
+++ b/arch/ia64/include/asm/sal.h
@@ -43,6 +43,7 @@
 #include 
 #include 
 
+extern unsigned long sal_systab_phys;
 extern spinlock_t sal_lock;
 
 /* SAL spec _requires_ eight args for each call. */
diff --git a/arch/ia64/include/asm/sn/sn_sal.h 
b/arch/ia64/include/asm/sn/sn_sal.h
index 1f5ff470a5a1..5142c444652d 100644
--- a/arch/ia64/include/asm/sn/sn_sal.h
+++ b/arch/ia64/include/asm/sn/sn_sal.h
@@ -167,7 +167,7 @@
 static inline u32
 sn_sal_rev(void)
 {
-   struct ia64_sal_systab *systab = __va(efi.sal_systab);
+   struct ia64_sal_systab *systab = __va(sal_systab_phys);
 
return (u32)(systab->sal_b_rev_major << 8 | systab->sal_b_rev_minor);
 }
diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c
index 3795d18276c4..0a34dcc435c6 100644
--- a/arch/ia64/kernel/efi.c
+++ b/arch/ia64/kernel/efi.c
@@ -47,8 +47,11 @@
 
 static __initdata unsigned long palo_phys;
 
+unsigned long sal_systab_phys = EFI_INVALID_TABLE_ADDR;
+
 static __initdata efi_config_table_type_t arch_tables[] = {
{PROCESSOR_ABSTRACTION_LAYER_OVERWRITE_GUID, "PALO", _phys},
+   {SAL_SYSTEM_TABLE_GUID, "SALsystab", _systab_phys},
{NULL_GUID, NULL, 0},
 };
 
diff --git a/arch/ia64/kernel/setup.c b/arch/ia64/kernel/setup.c
index c9cfa760cd57..0e1b4eb149b4 100644
--- a/arch/ia64/kernel/setup.c
+++ b/arch/ia64/kernel/setup.c
@@ -572,7 +572,7 @@ setup_arch (char **cmdline_p)
find_memory();
 
/* process SAL system table: */
-   ia64_sal_init(__va(efi.sal_systab));
+   ia64_sal_init(__va(sal_systab_phys));
 
 #ifdef CONFIG_ITANIUM
ia64_patch_rse((u64) __start___rse_patchlist, (u64) 
__end___rse_patchlist);
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 9866a3584765..6697c109c449 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -70,7 +70,6 @@ static const unsigned long * const efi_tables[] = {
,
,
,
-   _systab,
_info,
,
,
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 4dfd873373bd..801925c5bcfb 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -39,7 +39,6 @@ struct efi __read_mostly efi = {
.acpi20 = EFI_INVALID_TABLE_ADDR,
.smbios = EFI_INVALID_TABLE_ADDR,
.smbios3= EFI_INVALID_TABLE_ADDR,
-   .sal_systab = EFI_INVALID_TABLE_ADDR,
.boot_info  = EFI_INVALID_TABLE_ADDR,
.hcdp   = EFI_INVALID_TABLE_ADDR,
.uga= EFI_INVALID_TABLE_ADDR,
@@ -456,7 +455,6 @@ static __initdata efi_config_table_type_t common_tables[] = 
{
{ACPI_TABLE_GUID, "ACPI", },
{HCDP_TABLE_GUID, "HCDP", },
{MPS_TABLE_GUID, "MPS", },
-   {SAL_SYSTEM_TABLE_GUID, "SALsystab", _systab},
{SMBIOS_TABLE_GUID, "SMBIOS", },
{SMBIOS3_TABLE_GUID, "SMBIOS 3.0", },
{UGA_IO_PROTOCOL_GUID, "UGA", },
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 171bb1005a10..f88318b85fb0 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -984,7 +984,6 @@ extern struct efi {
unsigned long acpi20;   /* ACPI table  (ACPI 2.0) */
unsigned long smbios;   /* SMBIOS table (32 bit entry point) */
unsigned long smbios3;  /* SMBIOS table (64 bit entry point) */
-   unsigned long sal_systab;   /* SAL system table */
unsigned long boot_info;/* boot info table */
unsigned long hcdp; /* HCDP table */
unsigned long uga;  /* UGA table */
-- 
2.17.1



[PATCH 5/5] efi: cper: print AER info of PCIe fatal error

2019-08-12 Thread Ard Biesheuvel
From: Xiaofei Tan 

AER info of PCIe fatal error is not printed in the current driver.
Because APEI driver will panic directly for fatal error, and can't
run to the place of printing AER info.

An example log is as following:
{763}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 
11
{763}[Hardware Error]: event severity: fatal
{763}[Hardware Error]:  Error 0, type: fatal
{763}[Hardware Error]:   section_type: PCIe error
{763}[Hardware Error]:   port_type: 0, PCIe end point
{763}[Hardware Error]:   version: 4.0
{763}[Hardware Error]:   command: 0x, status: 0x0010
{763}[Hardware Error]:   device_id: :82:00.0
{763}[Hardware Error]:   slot: 0
{763}[Hardware Error]:   secondary_bus: 0x00
{763}[Hardware Error]:   vendor_id: 0x8086, device_id: 0x10fb
{763}[Hardware Error]:   class_code: 02
Kernel panic - not syncing: Fatal hardware error!

This issue was imported by the patch, '37448adfc7ce ("aerdrv: Move
cper_print_aer() call out of interrupt context")'. To fix this issue,
this patch adds print of AER info in cper_print_pcie() for fatal error.

Here is the example log after this patch applied:
{24}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 10
{24}[Hardware Error]: event severity: fatal
{24}[Hardware Error]:  Error 0, type: fatal
{24}[Hardware Error]:   section_type: PCIe error
{24}[Hardware Error]:   port_type: 0, PCIe end point
{24}[Hardware Error]:   version: 4.0
{24}[Hardware Error]:   command: 0x0546, status: 0x4010
{24}[Hardware Error]:   device_id: :01:00.0
{24}[Hardware Error]:   slot: 0
{24}[Hardware Error]:   secondary_bus: 0x00
{24}[Hardware Error]:   vendor_id: 0x15b3, device_id: 0x1019
{24}[Hardware Error]:   class_code: 02
{24}[Hardware Error]:   aer_uncor_status: 0x0004, aer_uncor_mask: 0x
{24}[Hardware Error]:   aer_uncor_severity: 0x00062010
{24}[Hardware Error]:   TLP Header: 00c0 0101 0001 
Kernel panic - not syncing: Fatal hardware error!

Fixes: 37448adfc7ce ("aerdrv: Move cper_print_aer() call out of interrupt 
context")
Signed-off-by: Xiaofei Tan 
Reviewed-by: James Morse 
[ardb: put parens around terms of && operator]
Signed-off-by: Ard Biesheuvel 
---
 drivers/firmware/efi/cper.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
index 8fa977c7861f..addf0749dd8b 100644
--- a/drivers/firmware/efi/cper.c
+++ b/drivers/firmware/efi/cper.c
@@ -390,6 +390,21 @@ static void cper_print_pcie(const char *pfx, const struct 
cper_sec_pcie *pcie,
printk(
"%s""bridge: secondary_status: 0x%04x, control: 0x%04x\n",
pfx, pcie->bridge.secondary_status, pcie->bridge.control);
+
+   /* Fatal errors call __ghes_panic() before AER handler prints this */
+   if ((pcie->validation_bits & CPER_PCIE_VALID_AER_INFO) &&
+   (gdata->error_severity & CPER_SEV_FATAL)) {
+   struct aer_capability_regs *aer;
+
+   aer = (struct aer_capability_regs *)pcie->aer_info;
+   printk("%saer_uncor_status: 0x%08x, aer_uncor_mask: 0x%08x\n",
+  pfx, aer->uncor_status, aer->uncor_mask);
+   printk("%saer_uncor_severity: 0x%08x\n",
+  pfx, aer->uncor_severity);
+   printk("%sTLP Header: %08x %08x %08x %08x\n", pfx,
+  aer->header_log.dw0, aer->header_log.dw1,
+  aer->header_log.dw2, aer->header_log.dw3);
+   }
 }
 
 static void cper_print_tstamp(const char *pfx,
-- 
2.17.1



[PATCH 4/5] efi: Export Runtime Configuration Interface table to sysfs

2019-08-12 Thread Ard Biesheuvel
From: Narendra K 

System firmware advertises the address of the 'Runtime
Configuration Interface table version 2 (RCI2)' via
an EFI Configuration Table entry. This code retrieves the RCI2
table from the address and exports it to sysfs as a binary
attribute 'rci2' under /sys/firmware/efi/tables directory.
The approach adopted is similar to the attribute 'DMI' under
/sys/firmware/dmi/tables.

RCI2 table contains BIOS HII in XML format and is used to populate
BIOS setup page in Dell EMC OpenManage Server Administrator tool.
The BIOS setup page contains BIOS tokens which can be configured.

Signed-off-by: Narendra K 
Reviewed-by: Mario Limonciello 
Signed-off-by: Ard Biesheuvel 
---
 Documentation/ABI/testing/sysfs-firmware-efi |   8 +
 arch/x86/platform/efi/efi.c  |   3 +
 drivers/firmware/efi/Kconfig |  13 ++
 drivers/firmware/efi/Makefile|   1 +
 drivers/firmware/efi/efi.c   |   3 +
 drivers/firmware/efi/rci2-table.c| 147 +++
 include/linux/efi.h  |   5 +
 7 files changed, 180 insertions(+)
 create mode 100644 drivers/firmware/efi/rci2-table.c

diff --git a/Documentation/ABI/testing/sysfs-firmware-efi 
b/Documentation/ABI/testing/sysfs-firmware-efi
index e794eac32a90..5e4d0b27cdfe 100644
--- a/Documentation/ABI/testing/sysfs-firmware-efi
+++ b/Documentation/ABI/testing/sysfs-firmware-efi
@@ -28,3 +28,11 @@ Description: Displays the physical addresses of all EFI 
Configuration
versions are always printed first, i.e. ACPI20 comes
before ACPI.
 Users: dmidecode
+
+What:  /sys/firmware/efi/tables/rci2
+Date:  July 2019
+Contact:   Narendra K , linux-b...@dell.com
+Description:   Displays the content of the Runtime Configuration Interface
+   Table version 2 on Dell EMC PowerEdge systems in binary format
+Users: It is used by Dell EMC OpenManage Server Administrator tool to
+   populate BIOS setup page.
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 6697c109c449..c202e1b07e29 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -82,6 +82,9 @@ static const unsigned long * const efi_tables[] = {
,
_table,
_attr_table,
+#ifdef CONFIG_EFI_RCI2_TABLE
+   _table_phys,
+#endif
 };
 
 u64 efi_setup; /* efi setup_data physical address */
diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
index d4ea929e8b34..178ee8106828 100644
--- a/drivers/firmware/efi/Kconfig
+++ b/drivers/firmware/efi/Kconfig
@@ -180,6 +180,19 @@ config RESET_ATTACK_MITIGATION
  have been evicted, since otherwise it will trigger even on clean
  reboots.
 
+config EFI_RCI2_TABLE
+   bool "EFI Runtime Configuration Interface Table Version 2 Support"
+   help
+ Displays the content of the Runtime Configuration Interface
+ Table version 2 on Dell EMC PowerEdge systems as a binary
+ attribute 'rci2' under /sys/firmware/efi/tables directory.
+
+ RCI2 table contains BIOS HII in XML format and is used to populate
+ BIOS setup page in Dell EMC OpenManage Server Administrator tool.
+ The BIOS setup page contains BIOS tokens which can be configured.
+
+ Say Y here for Dell EMC PowerEdge systems.
+
 endmenu
 
 config UEFI_CPER
diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
index d2d0d2030620..4ac2de4dfa72 100644
--- a/drivers/firmware/efi/Makefile
+++ b/drivers/firmware/efi/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_EFI_BOOTLOADER_CONTROL)  += efibc.o
 obj-$(CONFIG_EFI_TEST) += test/
 obj-$(CONFIG_EFI_DEV_PATH_PARSER)  += dev-path-parser.o
 obj-$(CONFIG_APPLE_PROPERTIES) += apple-properties.o
+obj-$(CONFIG_EFI_RCI2_TABLE)   += rci2-table.o
 
 arm-obj-$(CONFIG_EFI)  := arm-init.o arm-runtime.o
 obj-$(CONFIG_ARM)  += $(arm-obj-y)
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 801925c5bcfb..8f1ab04f6743 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -465,6 +465,9 @@ static __initdata efi_config_table_type_t common_tables[] = 
{
{LINUX_EFI_TPM_EVENT_LOG_GUID, "TPMEventLog", _log},
{LINUX_EFI_TPM_FINAL_LOG_GUID, "TPMFinalLog", _final_log},
{LINUX_EFI_MEMRESERVE_TABLE_GUID, "MEMRESERVE", _reserve},
+#ifdef CONFIG_EFI_RCI2_TABLE
+   {DELLEMC_EFI_RCI2_TABLE_GUID, NULL, _table_phys},
+#endif
{NULL_GUID, NULL, NULL},
 };
 
diff --git a/drivers/firmware/efi/rci2-table.c 
b/drivers/firmware/efi/rci2-table.c
new file mode 100644
index ..3e290f96620a
--- /dev/null
+++ b/drivers/firmware/efi/rci2-table.c
@@ -0,0 +1,147 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Export Runtime Configuration Interface Table Version 2 (RCI2)
+ * to s

[GIT PULL 0/5] EFI updates for v5.4

2019-08-12 Thread Ard Biesheuvel
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:

  Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-next

for you to fetch changes up to b194a77fcc4001dc40aecdd15d249648e8a436d1:

  efi: cper: print AER info of PCIe fatal error (2019-08-12 12:06:23 +0300)


EFI changes for v5.4:
- Some refactoring of the EFI config table handling across architectures.
- Add support for the Dell EMC OEM config table.
- Include AER diagnostic output to CPER handling of fatal PCIe errors.


Ard Biesheuvel (3):
  efi: x86: move efi_is_table_address() into arch/x86
  efi/x86: move UV_SYSTAB handling into arch/x86
  efi: ia64: move SAL systab handling out of generic EFI code

Narendra K (1):
  efi: Export Runtime Configuration Interface table to sysfs

Xiaofei Tan (1):
  efi: cper: print AER info of PCIe fatal error

 Documentation/ABI/testing/sysfs-firmware-efi |   8 ++
 arch/ia64/include/asm/sal.h  |   1 +
 arch/ia64/include/asm/sn/sn_sal.h|   2 +-
 arch/ia64/kernel/efi.c   |   3 +
 arch/ia64/kernel/setup.c |   2 +-
 arch/x86/include/asm/efi.h   |   5 +
 arch/x86/include/asm/uv/uv.h |   4 +-
 arch/x86/mm/ioremap.c|   1 +
 arch/x86/platform/efi/efi.c  |  39 ++-
 arch/x86/platform/uv/bios_uv.c   |  10 +-
 drivers/firmware/efi/Kconfig |  13 +++
 drivers/firmware/efi/Makefile|   1 +
 drivers/firmware/efi/cper.c  |  15 +++
 drivers/firmware/efi/efi.c   |  39 +--
 drivers/firmware/efi/rci2-table.c| 147 +++
 include/linux/efi.h  |  14 +--
 16 files changed, 251 insertions(+), 53 deletions(-)
 create mode 100644 drivers/firmware/efi/rci2-table.c


[PATCH 1/5] efi: x86: move efi_is_table_address() into arch/x86

2019-08-12 Thread Ard Biesheuvel
The function efi_is_table_address() and the associated array of table
pointers is specific to x86. Since we will be adding some more x86
specific tables, let's move this code out of the generic code first.

Signed-off-by: Ard Biesheuvel 
---
 arch/x86/include/asm/efi.h  |  5 +
 arch/x86/mm/ioremap.c   |  1 +
 arch/x86/platform/efi/efi.c | 33 +
 drivers/firmware/efi/efi.c  | 33 -
 include/linux/efi.h |  7 ---
 5 files changed, 39 insertions(+), 40 deletions(-)

diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 606a4b6a9812..43a82e59c59d 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -242,6 +242,7 @@ static inline bool efi_is_64bit(void)
__efi_early()->runtime_services), __VA_ARGS__)
 
 extern bool efi_reboot_required(void);
+extern bool efi_is_table_address(unsigned long phys_addr);
 
 #else
 static inline void parse_efi_setup(u64 phys_addr, u32 data_len) {}
@@ -249,6 +250,10 @@ static inline bool efi_reboot_required(void)
 {
return false;
 }
+static inline  bool efi_is_table_address(unsigned long phys_addr)
+{
+   return false;
+}
 #endif /* CONFIG_EFI */
 
 #endif /* _ASM_X86_EFI_H */
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 63e99f15d7cf..a39dcdb5ae34 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -19,6 +19,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index a7189a3b4d70..8d9be97a5607 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -64,6 +64,25 @@ static efi_config_table_type_t arch_tables[] __initdata = {
{NULL_GUID, NULL, NULL},
 };
 
+static const unsigned long * const efi_tables[] = {
+   ,
+   ,
+   ,
+   ,
+   ,
+   _systab,
+   _info,
+   ,
+   ,
+   _systab,
+   _vendor,
+   ,
+   _table,
+   ,
+   _table,
+   _attr_table,
+};
+
 u64 efi_setup; /* efi setup_data physical address */
 
 static int add_efi_memmap __initdata;
@@ -1049,3 +1068,17 @@ static int __init arch_parse_efi_cmdline(char *str)
return 0;
 }
 early_param("efi", arch_parse_efi_cmdline);
+
+bool efi_is_table_address(unsigned long phys_addr)
+{
+   unsigned int i;
+
+   if (phys_addr == EFI_INVALID_TABLE_ADDR)
+   return false;
+
+   for (i = 0; i < ARRAY_SIZE(efi_tables); i++)
+   if (*(efi_tables[i]) == phys_addr)
+   return true;
+
+   return false;
+}
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index ad3b1f4866b3..cbdbdbc8f9eb 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -57,25 +57,6 @@ struct efi __read_mostly efi = {
 };
 EXPORT_SYMBOL(efi);
 
-static unsigned long *efi_tables[] = {
-   ,
-   ,
-   ,
-   ,
-   ,
-   _systab,
-   _info,
-   ,
-   ,
-   _systab,
-   _vendor,
-   ,
-   _table,
-   ,
-   _table,
-   _attr_table,
-};
-
 struct mm_struct efi_mm = {
.mm_rb  = RB_ROOT,
.mm_users   = ATOMIC_INIT(2),
@@ -964,20 +945,6 @@ int efi_status_to_err(efi_status_t status)
return err;
 }
 
-bool efi_is_table_address(unsigned long phys_addr)
-{
-   unsigned int i;
-
-   if (phys_addr == EFI_INVALID_TABLE_ADDR)
-   return false;
-
-   for (i = 0; i < ARRAY_SIZE(efi_tables); i++)
-   if (*(efi_tables[i]) == phys_addr)
-   return true;
-
-   return false;
-}
-
 static DEFINE_SPINLOCK(efi_mem_reserve_persistent_lock);
 static struct linux_efi_memreserve *efi_memreserve_root __ro_after_init;
 
diff --git a/include/linux/efi.h b/include/linux/efi.h
index f87fabea4a85..60a6242765d8 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -1211,8 +1211,6 @@ static inline bool efi_enabled(int feature)
return test_bit(feature, ) != 0;
 }
 extern void efi_reboot(enum reboot_mode reboot_mode, const char *__unused);
-
-extern bool efi_is_table_address(unsigned long phys_addr);
 #else
 static inline bool efi_enabled(int feature)
 {
@@ -1226,11 +1224,6 @@ efi_capsule_pending(int *reset_type)
 {
return false;
 }
-
-static inline bool efi_is_table_address(unsigned long phys_addr)
-{
-   return false;
-}
 #endif
 
 extern int efi_status_to_err(efi_status_t status);
-- 
2.17.1



[GIT PULL 0/1] EFI fix for v5.3-rc4

2019-08-12 Thread Ard Biesheuvel
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:

  Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git efi-urgent

for you to fetch changes up to b61fbc887af7a13a1c90c84c1feaeb4c9780e1e2:

  efi-stub: Fix get_efi_config_table on mixed-mode setups (2019-08-12 11:58:35 
+0300)


A single EFI fix for v5.3:
- Fix mixed mode breakage in EFI config table handling for TPM.


Hans de Goede (1):
  efi-stub: Fix get_efi_config_table on mixed-mode setups

 drivers/firmware/efi/libstub/efi-stub-helper.c | 38 ++
 1 file changed, 27 insertions(+), 11 deletions(-)


[PATCH 1/1] efi-stub: Fix get_efi_config_table on mixed-mode setups

2019-08-12 Thread Ard Biesheuvel
From: Hans de Goede 

Fix get_efi_config_table using the wrong structs when booting a
64 bit kernel on 32 bit firmware.

Fixes: 82d736ac56d7 ("Abstract out support for locating an EFI config table")
Signed-off-by: Hans de Goede 
Acked-By: Matthew Garrett 
Reviewed-by: Ard Biesheuvel 
Acked-by: Jarkko Sakkinen 
Signed-off-by: Ard Biesheuvel 
---
 .../firmware/efi/libstub/efi-stub-helper.c| 38 +--
 1 file changed, 27 insertions(+), 11 deletions(-)

diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c 
b/drivers/firmware/efi/libstub/efi-stub-helper.c
index 1db780c0f07b..3caae7f2cf56 100644
--- a/drivers/firmware/efi/libstub/efi-stub-helper.c
+++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
@@ -927,17 +927,33 @@ efi_status_t efi_exit_boot_services(efi_system_table_t 
*sys_table_arg,
return status;
 }
 
+#define GET_EFI_CONFIG_TABLE(bits) \
+static void *get_efi_config_table##bits(efi_system_table_t *_sys_table,
\
+   efi_guid_t guid)\
+{  \
+   efi_system_table_##bits##_t *sys_table; \
+   efi_config_table_##bits##_t *tables;\
+   int i;  \
+   \
+   sys_table = (typeof(sys_table))_sys_table;  \
+   tables = (typeof(tables))(unsigned long)sys_table->tables;  \
+   \
+   for (i = 0; i < sys_table->nr_tables; i++) {\
+   if (efi_guidcmp(tables[i].guid, guid) != 0) \
+   continue;   \
+   \
+   return (void *)(unsigned long)tables[i].table;  \
+   }   \
+   \
+   return NULL;\
+}
+GET_EFI_CONFIG_TABLE(32)
+GET_EFI_CONFIG_TABLE(64)
+
 void *get_efi_config_table(efi_system_table_t *sys_table, efi_guid_t guid)
 {
-   efi_config_table_t *tables = (efi_config_table_t *)sys_table->tables;
-   int i;
-
-   for (i = 0; i < sys_table->nr_tables; i++) {
-   if (efi_guidcmp(tables[i].guid, guid) != 0)
-   continue;
-
-   return (void *)tables[i].table;
-   }
-
-   return NULL;
+   if (efi_is_64bit())
+   return get_efi_config_table64(sys_table, guid);
+   else
+   return get_efi_config_table32(sys_table, guid);
 }
-- 
2.17.1



Re: [PATCH v1] Export Runtime Configuration Interface table to sysfs

2019-08-08 Thread Ard Biesheuvel
On Wed, 7 Aug 2019 at 16:09,  wrote:
>
> On Thu, Jul 11, 2019 at 11:00:37PM +, Limonciello, Mario wrote:
> > > -Original Message-
> > > From: K, Narendra
> > > Sent: Wednesday, July 10, 2019 11:59 AM
> > > To: linux-efi@vger.kernel.org; ard.biesheu...@linaro.org; 
> > > pjo...@redhat.com
> > > Cc: K, Narendra; Hayes, Stuart; Limonciello, Mario
> > > Subject: [PATCH v1] Export Runtime Configuration Interface table to sysfs
> > >
> > > From: Narendra K 
> > >
> > > System firmware advertises the address of the 'Runtime Configuration 
> > > Interface
> > > table version 2 (RCI2)' via an EFI Configuration Table entry. This code 
> > > retrieves
> > > the RCI2 table from the address and exports it to sysfs as a binary 
> > > attribute 'rci2'
> > > under /sys/firmware/efi/tables directory.
> > > The approach adopted is similar to the attribute 'DMI' under
> > > /sys/firmware/dmi/tables.
> > >
> > > RCI2 table contains BIOS HII in XML format and is used to populate BIOS 
> > > setup
> > > page in Dell EMC OpenManage Server Administrator tool.
> > > The BIOS setup page contains BIOS tokens which can be configured.
> > >
> > > Signed-off-by: Narendra K 
> >
> > Reviewed-by: Mario Limonciello 
>
> Hi Ard,
>
> Does the version 1 of the patch look good ? Please share your thoughts.
>

Thanks Narendra,

The patch looks mostly fine. I have pushed it to my efi/next branch,
and I will let you know if the autobuilders find any problems.

One possible enhancement would be to defer the second memremap() call
until the first call to raw_table_read(), so the mapping only exists
if you are actually interested in the contents of the table. If you do
decide to make any followup changes, please send them as delta patches
against https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/log/?h=next

Thanks,
Ard.




> >
> > > ---
> > > Hi Ard, the review comment in the v0 version of the patch suggested that 
> > > the
> > > kconfig symbol be set to Y for X86. I made a change to the suggestion.
> > > In the v1 version, I have set the symbol to N by default and added a note 
> > > to the
> > > help section to make it Y for Dell EMC PowerEdge systems. If it needs to 
> > > be
> > > changed, I will resubmit the patch after changing it to implement the 
> > > suggestion.
> > >
> > > The patch is created on 'next' branch of efi tree.
> > >
> > > v0 -> v1:
> > > - Introduced a new Kconfig symbol CONFIG_EFI_RCI2_TABLE and compile
> > > RCI2 table support if it is set. Set the symbol to N by default.
> > > - Removed calling 'efi_rci2_sysfs_init' from drivers/firmware/efi/efi.c 
> > > and made
> > > it a 'late_initcall' in drivers/firmware/efi/rci2_table.c.
> > > Removed the function declaration from include/linux/efi.h.
> > >
> > > RFC -> v0:
> > > - Removed rci2 table from struct efi and defined it in rci2_table.c 
> > > similar to the
> > > way uv_systab_phys is defined in arch/x86/platform/uv/bios_uv.c
> > > - Removed the oem_tables array and added rci2 to common_tables array
> > > - Removed the string 'rci2' from the common_tables array so that it is not
> > > printed in dmesg.
> > > - Merged function 'efi_rci2_table_init' into 'efi_rci2_sysfs_init' 
> > > function to avoid
> > > calling early_memremap/unmap functions.
>
> --
> With regards,
> Narendra K


Re: [PATCH 5.3 regression fix] efi-stub: Fix get_efi_config_table on mixed-mode setups

2019-08-08 Thread Ard Biesheuvel
On Thu, 8 Aug 2019 at 02:03, Matthew Garrett  wrote:
>
> On Wed, Aug 7, 2019 at 2:59 PM Hans de Goede  wrote:
> >
> > Fix get_efi_config_table using the wrong structs when booting a
> > 64 bit kernel on 32 bit firmware.
> >
> > Cc: Matthew Garrett 
> > Cc: Ard Biesheuvel 
> > Cc: Jarkko Sakkinen 
> > Fixes: 82d736ac56d7 ("Abstract out support for locating an EFI config 
> > table")
> > Signed-off-by: Hans de Goede 
>
> Acked-By: Matthew Garrett 
>

Thanks for fixing this, Hans.

Reviewed-by: Ard Biesheuvel 

> Good catch. I think fixing this is preferable to reverting - the
> duplicate events are visible to userland, so there's a risk that apps
> will end up depending on them if there's a release that behaves that
> way.

Agreed, I will send this out as a fix.

> Presumably mixed mode isn't a thing on ARM?

Nope. I should have realised this when we made this routine generic,
but I failed to spot it. ARM is either strictly 32-bit or strictly
64-bit.


Re: 5.3 boot regression caused by 5.3 TPM changes

2019-08-05 Thread Ard Biesheuvel
On Sun, 4 Aug 2019 at 19:12, Hans de Goede  wrote:
>
> Hi,
>
> On 04-08-19 17:33, Ard Biesheuvel wrote:
> > Hi Hans,
> >
> > On Sun, 4 Aug 2019 at 13:00, Hans de Goede  wrote:
> >>
> >> Hi All,
> >>
> >> While testing 5.3-rc2 on an Irbis TW90 Intel Cherry Trail based
> >> tablet I noticed that it does not boot on this device.
> >>
> >> A git bisect points to commit 166a2809d65b ("tpm: Don't duplicate
> >> events from the final event log in the TCG2 log")
> >>
> >> And I can confirm that reverting just that single commit makes
> >> the TW90 boot again.
> >>
> >> This machine uses AptIO firmware with base component versions
> >> of: UEFI 2.4 PI 1.3. I've tried to reproduce the problem on
> >> a Teclast X80 Pro which is also CHT based and also uses AptIO
> >> firmware with the same base components. But it does not reproduce
> >> there. Neither does the problem reproduce on a CHT tablet using
> >> InsideH20 based firmware.
> >>
> >> Note that these devices have a software/firmware TPM-2.0
> >> implementation, they do not have an actual TPM chip.
> >>
> >> Comparing TPM firmware setting between the 2 AptIO based
> >> tablets the settings are identical, but the troublesome
> >> TW90 does have some more setting then the X80, it has
> >> the following settings which are not shown on the X80:
> >>
> >> Active PCR banks:   SHA-1 (read only)
> >> Available PCR banks:SHA-1,SHA256  (read only)
> >> TPM2.0 UEFI SPEC version:   TCG_2 (other possible setting: TCG_1_2
> >> Physical Presence SPEC ver: 1.2   (other possible setting: 1.3)
> >>
> >> I have the feeling that at least the first 2 indicate that
> >> the previous win10 installation has actually used the
> >> TPM, where as on the X80 the TPM is uninitialized.
> >> Note this is just a hunch I could be completely wrong.
> >>
> >> I would be happy to run any commands to try and debug this
> >> or to build a kernel with some patches to gather more info.
> >>
> >> Note any kernel patches to printk some debug stuff need
> >> to be based on 5.3 with 166a2809d65b reverted, without that
> >> reverted the device will not boot, and thus I cannot collect
> >> logs without it reverted.
> >>
> >
> > Are you booting a 64-bit kernel on 32-bit firmware?
>
> Yes you are right, I must say that this is somewhat surprising
> most Cherry Trail devices do use 64 bit firmware (where as Bay Trail
> typically uses 32 bit). But I just checked efibootmgr output and it
> says it is booting: \EFI\FEDORA\SHIMIA32.EFI so yeah 32 bit firmware.
>
> Recent Fedora releases take care of this so seamlessly I did not
> even realize...
>

OK, so we'll have to find out how this patch affects 64-bit code
running on 32-bit firmware. The only EFI call in that patch is
get_config_table(), which is not actually a EFI boot service call but
a EFI stub helper that parses the config table array in the EFI system
table.


Re: 5.3 boot regression caused by 5.3 TPM changes

2019-08-04 Thread Ard Biesheuvel
Hi Hans,

On Sun, 4 Aug 2019 at 13:00, Hans de Goede  wrote:
>
> Hi All,
>
> While testing 5.3-rc2 on an Irbis TW90 Intel Cherry Trail based
> tablet I noticed that it does not boot on this device.
>
> A git bisect points to commit 166a2809d65b ("tpm: Don't duplicate
> events from the final event log in the TCG2 log")
>
> And I can confirm that reverting just that single commit makes
> the TW90 boot again.
>
> This machine uses AptIO firmware with base component versions
> of: UEFI 2.4 PI 1.3. I've tried to reproduce the problem on
> a Teclast X80 Pro which is also CHT based and also uses AptIO
> firmware with the same base components. But it does not reproduce
> there. Neither does the problem reproduce on a CHT tablet using
> InsideH20 based firmware.
>
> Note that these devices have a software/firmware TPM-2.0
> implementation, they do not have an actual TPM chip.
>
> Comparing TPM firmware setting between the 2 AptIO based
> tablets the settings are identical, but the troublesome
> TW90 does have some more setting then the X80, it has
> the following settings which are not shown on the X80:
>
> Active PCR banks:   SHA-1 (read only)
> Available PCR banks:SHA-1,SHA256  (read only)
> TPM2.0 UEFI SPEC version:   TCG_2 (other possible setting: TCG_1_2
> Physical Presence SPEC ver: 1.2   (other possible setting: 1.3)
>
> I have the feeling that at least the first 2 indicate that
> the previous win10 installation has actually used the
> TPM, where as on the X80 the TPM is uninitialized.
> Note this is just a hunch I could be completely wrong.
>
> I would be happy to run any commands to try and debug this
> or to build a kernel with some patches to gather more info.
>
> Note any kernel patches to printk some debug stuff need
> to be based on 5.3 with 166a2809d65b reverted, without that
> reverted the device will not boot, and thus I cannot collect
> logs without it reverted.
>

Are you booting a 64-bit kernel on 32-bit firmware?


Re: [PATCH] efi/arm: fix allocation failure when reserving the kernel base

2019-08-04 Thread Ard Biesheuvel
Hello Chester,

On Fri, 2 Aug 2019 at 08:40, Chester Lin  wrote:
>
> In some cases the arm32 efistub could fail to allocate memory for
> uncompressed kernel. For example, we got the following error message when
> verifying EFI stub on Raspberry Pi-2 [kernel-5.2.1 + grub-2.04] :
>
>   EFI stub: Booting Linux Kernel...
>   EFI stub: ERROR: Unable to allocate memory for uncompressed kernel.
>   EFI stub: ERROR: Failed to relocate kernel
>
> After checking the EFI memory map we found that the first page [0 - 0xfff]
> had been reserved by Raspberry Pi-2's firmware, and the efistub tried to
> set the dram base at 0, which was actually in a reserved region.
>

This by itself is a violation of the Linux boot protocol for 32-bit
ARM when using the decompressor. The decompressor rounds down its own
base address to a multiple of 128 MB, and assumes the whole area is
available for the decompressed kernel and related data structures.
(The first TEXT_OFFSET bytes are no longer used in practice, which is
why putting a reserved region of 4 KB bytes works at the moment, but
this is fragile). Note that the decompressor does not look at any DT
or EFI provided memory maps *at all*.

So unfortunately, this is not something we can fix in the kernel, but
we should fix it in the bootloader or in GRUB, so it does not put any
reserved regions in the first 128 MB of memory,


>   grub> lsefimmap
>   Type  Physical start  - end #PagesSize Attributes
>   reserved  -0fff 0001  4KiB WB
>   conv-mem  1000-07ef5fff 7ef5 130004KiB WB
>   RT-data   07ef6000-07f09fff 0014 80KiB RT WB
>   conv-mem  07f0a000-2d871fff 00025968 615840KiB WB
>   .
>
> To avoid a reserved address, we have to ignore the memory regions which are
> marked as EFI_RESERVED_TYPE, and only conventional memory regions can be
> chosen. If the region before the kernel base is unaligned, it will be
> marked as EFI_RESERVED_TYPE and let kernel ignore it so that memblock_limit
> will not be sticked with a very low address such as 0x1000.
>
> Signed-off-by: Chester Lin 
> ---
>  arch/arm/mm/mmu.c |  3 ++
>  drivers/firmware/efi/libstub/arm32-stub.c | 43 ++-
>  2 files changed, 37 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index f3ce34113f89..909b11ba48d8 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -1184,6 +1184,9 @@ void __init adjust_lowmem_bounds(void)
> phys_addr_t block_start = reg->base;
> phys_addr_t block_end = reg->base + reg->size;
>
> +   if (memblock_is_nomap(reg))
> +   continue;
> +
> if (reg->base < vmalloc_limit) {
> if (block_end > lowmem_limit)
> /*
> diff --git a/drivers/firmware/efi/libstub/arm32-stub.c 
> b/drivers/firmware/efi/libstub/arm32-stub.c
> index e8f7aefb6813..10d33d36df00 100644
> --- a/drivers/firmware/efi/libstub/arm32-stub.c
> +++ b/drivers/firmware/efi/libstub/arm32-stub.c
> @@ -128,7 +128,7 @@ static efi_status_t 
> reserve_kernel_base(efi_system_table_t *sys_table_arg,
>
> for (l = 0; l < map_size; l += desc_size) {
> efi_memory_desc_t *desc;
> -   u64 start, end;
> +   u64 start, end, spare, kernel_base;
>
> desc = (void *)memory_map + l;
> start = desc->phys_addr;
> @@ -144,27 +144,52 @@ static efi_status_t 
> reserve_kernel_base(efi_system_table_t *sys_table_arg,
> case EFI_BOOT_SERVICES_DATA:
> /* Ignore types that are released to the OS anyway */
> continue;
> -
> +   case EFI_RESERVED_TYPE:
> +   /* Ignore reserved regions */
> +   continue;
> case EFI_CONVENTIONAL_MEMORY:
> /*
>  * Reserve the intersection between this entry and the
>  * region.
>  */
> start = max(start, (u64)dram_base);
> -   end = min(end, (u64)dram_base + 
> MAX_UNCOMP_KERNEL_SIZE);
> +   kernel_base = round_up(start, PMD_SIZE);
> +   spare = kernel_base - start;
> +   end = min(end, kernel_base + MAX_UNCOMP_KERNEL_SIZE);
> +
> +   status = efi_call_early(allocate_pages,
> +   EFI_ALLOCATE_ADDRESS,
> +   EFI_LOADER_DATA,
> +   MAX_UNCOMP_KERNEL_SIZE / 
> EFI_PAGE_SIZE,
> +   _base);
> +   if (status != EFI_SUCCESS) {
> +   pr_efi_err(sys_table_arg,
> +

Re: [PATCH v0] Export Runtime Configuration Interface table to sysfs

2019-07-02 Thread Ard Biesheuvel
On Sat, 29 Jun 2019 at 13:23,  wrote:
>
> From: Narendra K 
>
> System firmware advertises the address of the 'Runtime
> Configuration Interface table version 2 (RCI2)' via
> an EFI Configuration Table entry. This code retrieves the RCI2
> table from the address and exports it to sysfs as a binary
> attribute 'rci2' under /sys/firmware/efi/tables directory.
> The approach adopted is similar to the attribute 'DMI' under
> /sys/firmware/dmi/tables.
>
> RCI2 table contains BIOS HII in XML format and is used to populate
> BIOS setup page in Dell EMC OpenManage Server Administrator tool.
> The BIOS setup page contains BIOS tokens which can be configured.
>
> Signed-off-by: Narendra K 
> ---
> RFC -> v0:
>
> - Removed rci2 table from struct efi and defined it in rci2_table.c similar to
> the way uv_systab_phys is define in dmesg.
> - Removed the oem_tables array and added rci2 to common_tables array
> - Removed the string 'rci2' from the common_tables array so that it is
> not printed in dmesg.
> - Merged function 'efi_rci2_table_init' into 'efi_rci2_sysfs_init' function to
> avoid calling early_memremap/unmap functions.
>
> Also, a note unrelated to this patch - compilation error is observed when
> testing with make defconfig related to uv_systab_phys in
> arch/x86/platform/efi/efi.c. It seems like it needs to be protected with
> CONFIG_X86_UV in efi_tables array.
>

Yes, I noticed this as well. This has been fixed now

>
>  Documentation/ABI/testing/sysfs-firmware-efi |   8 +
>  arch/x86/platform/efi/efi.c  |   1 +
>  drivers/firmware/efi/Makefile|   2 +-
>  drivers/firmware/efi/efi.c   |   4 +
>  drivers/firmware/efi/rci2_table.c| 147 +++
>  include/linux/efi.h  |   6 +
>  6 files changed, 167 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/firmware/efi/rci2_table.c
>
> diff --git a/Documentation/ABI/testing/sysfs-firmware-efi 
> b/Documentation/ABI/testing/sysfs-firmware-efi
> index e794eac32a90..f7822c522a46 100644
> --- a/Documentation/ABI/testing/sysfs-firmware-efi
> +++ b/Documentation/ABI/testing/sysfs-firmware-efi
> @@ -28,3 +28,11 @@ Description: Displays the physical addresses of all EFI 
> Configuration
> versions are always printed first, i.e. ACPI20 comes
> before ACPI.
>  Users: dmidecode
> +
> +What:  /sys/firmware/efi/tables/rci2
> +Date:  June 2019
> +Contact:   Narendra K , linux-b...@dell.com
> +Description:   Displays the content of the Runtime Configuration Interface
> +   Table version 2 on Dell EMC PowerEdge systems in binary format
> +Users: It is used by Dell EMC OpenManage Server Administrator tool to
> +   populate BIOS setup page.
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 002078645969..6e1c1b0ce015 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -80,6 +80,7 @@ static const unsigned long * const efi_tables[] = {
> ,
> _table,
> _attr_table,
> +   _table_phys,

Put #ifdef CONFIG_EFI_RCI2 around this line ^^^

>  };
>
>  u64 efi_setup; /* efi setup_data physical address */
> diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
> index d2d0d2030620..db07828ca1ed 100644
> --- a/drivers/firmware/efi/Makefile
> +++ b/drivers/firmware/efi/Makefile
> @@ -11,7 +11,7 @@
>  KASAN_SANITIZE_runtime-wrappers.o  := n
>
>  obj-$(CONFIG_ACPI_BGRT)+= efi-bgrt.o
> -obj-$(CONFIG_EFI)  += efi.o vars.o reboot.o memattr.o 
> tpm.o
> +obj-$(CONFIG_EFI)  += efi.o vars.o reboot.o memattr.o 
> tpm.o rci2_table.o

Please introduce a kconfig symbol CONFIG_EFI_RCI2 for this, and only
include this file when the symbol is set. You can make it default to y
on X86, but for other architectures, it does not make a lot of sense
to include this by default.

>  obj-$(CONFIG_EFI)  += capsule.o memmap.o
>  obj-$(CONFIG_EFI_VARS) += efivars.o
>  obj-$(CONFIG_EFI_ESRT) += esrt.o
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index d082d5b2fb84..429c676f53fb 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -363,6 +363,9 @@ static int __init efisubsys_init(void)
> goto err_remove_group;
> }
>
> +   if (efi_rci2_sysfs_init() != 0)
> +   pr_debug("efi rci2: sysfs attribute creation under 
> /sys/firmware/efi/ failed");
> +

Please drop this. You can use a late_initcall() in rci2_table.c instead

> return 0;
>
>  err_remove_group:
> @@ -463,6 +466,7 @@ static __initdata efi_config_table_type_t common_tables[] 
> = {
> {LINUX_EFI_RANDOM_SEED_TABLE_GUID, "RNG", _seed},
> {LINUX_EFI_TPM_EVENT_LOG_GUID, "TPMEventLog", _log},
> {LINUX_EFI_MEMRESERVE_TABLE_GUID, 

Re: [4.19.y PATCH 1/3] efi/x86/Add missing error handling to old_memmap 1:1 mapping code

2019-06-29 Thread Ard Biesheuvel
On Sat, 29 Jun 2019 at 11:11, Greg KH  wrote:
>
> On Sat, Jun 29, 2019 at 10:47:00AM +0200, Ard Biesheuvel wrote:
> > On Sat, 29 Jun 2019 at 08:57, Greg KH  wrote:
> > >
> > > On Fri, Jun 28, 2019 at 11:42:13AM -0700, Srivatsa S. Bhat wrote:
> > > > From: Gen Zhang 
> > > >
> > > > commit 4e78921ba4dd0aca1cc89168f45039add4183f8e upstream.
> > > >
> > > > The old_memmap flow in efi_call_phys_prolog() performs numerous memory
> > > > allocations, and either does not check for failure at all, or it does
> > > > but fails to propagate it back to the caller, which may end up calling
> > > > into the firmware with an incomplete 1:1 mapping.
> > > >
> > > > So let's fix this by returning NULL from efi_call_phys_prolog() on
> > > > memory allocation failures only, and by handling this condition in the
> > > > caller. Also, clean up any half baked sets of page tables that we may
> > > > have created before returning with a NULL return value.
> > > >
> > > > Note that any failure at this level will trigger a panic() two levels
> > > > up, so none of this makes a huge difference, but it is a nice cleanup
> > > > nonetheless.
> > >
> > > With a description like this, why is this needed in a stable kernel if
> > > it does not really fix anything useful?
> > >
> >
> > Because it fixes a 'CVE', remember? :-)
>
> No, I don't remember that at all.
>
> Remember, I get 1000+ emails a day to do something with, and hence, have
> the short-term memory of prior emails of a squirrel.
>
> Also, CVEs mean nothing, anyone can get one and they are impossible to
> revoke, so don't treat them like they are "authoritative" at all.
>

To refresh your memory: I already nacked this backport once before, on
the grounds that the CVE is completely bogus.


Re: [4.19.y PATCH 1/3] efi/x86/Add missing error handling to old_memmap 1:1 mapping code

2019-06-29 Thread Ard Biesheuvel
On Sat, 29 Jun 2019 at 08:57, Greg KH  wrote:
>
> On Fri, Jun 28, 2019 at 11:42:13AM -0700, Srivatsa S. Bhat wrote:
> > From: Gen Zhang 
> >
> > commit 4e78921ba4dd0aca1cc89168f45039add4183f8e upstream.
> >
> > The old_memmap flow in efi_call_phys_prolog() performs numerous memory
> > allocations, and either does not check for failure at all, or it does
> > but fails to propagate it back to the caller, which may end up calling
> > into the firmware with an incomplete 1:1 mapping.
> >
> > So let's fix this by returning NULL from efi_call_phys_prolog() on
> > memory allocation failures only, and by handling this condition in the
> > caller. Also, clean up any half baked sets of page tables that we may
> > have created before returning with a NULL return value.
> >
> > Note that any failure at this level will trigger a panic() two levels
> > up, so none of this makes a huge difference, but it is a nice cleanup
> > nonetheless.
>
> With a description like this, why is this needed in a stable kernel if
> it does not really fix anything useful?
>

Because it fixes a 'CVE', remember? :-)


Re: [RFC PATCH] Export Runtime Configuration Interface table to sysfs

2019-06-26 Thread Ard Biesheuvel
On Wed, 26 Jun 2019 at 14:17,  wrote:
>
> On Tue, Jun 25, 2019 at 04:21:33PM +0200, Ard Biesheuvel wrote:
> [...]
> > > > > --- a/drivers/firmware/efi/efi.c
> > > > > +++ b/drivers/firmware/efi/efi.c
> > > > > @@ -53,6 +53,7 @@ struct efi __read_mostly efi = {
> > > > > .rng_seed   = EFI_INVALID_TABLE_ADDR,
> > > > > .tpm_log= EFI_INVALID_TABLE_ADDR,
> > > > > .mem_reserve= EFI_INVALID_TABLE_ADDR,
> > > > > +   .rci2   = EFI_INVALID_TABLE_ADDR,
> > > >
> > > > Does this really need to live in the efi struct?
> > >
> > > It probably need not be part of struct efi. We could define a struct of
> > > type 'efi_config_table_type_t' in the rci2_table.c. Did you have a
> > > similar idea in mind ? If yes, I will modify and test this idea.
> > >
> >
> > Yes, I'd like to start keeping these things separate.
> >
> > I pushed a branch here
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/log/?h=next
> >
> > that changes the way uv_systab is handled, and moves it into arch/x86.
> > Please follow that pattern instead.
>
> Okay. Thank you for the guidance. I will make this change in the next version.
>
> >
> > > >
> > > > >  };
> > > > >  EXPORT_SYMBOL(efi);
> > > > >
> > > > > @@ -73,6 +74,7 @@ static unsigned long *efi_tables[] = {
> > > > > ,
> > > > > _table,
> > > > > _attr_table,
> > > > > +   ,
> > > > >  };
> > > > >
> > > >
> > > > AFAICT, this table is only used by memremap_is_efi_data() to decide
> > > > whether a page should be map as unencrypted, and if the address is in
> > > > boot services data or runtime services data, the test will already
> > > > success, regardless of whether it appears in this enumeration.
> > >
> > > Yes. Before 'memremap_is_efi_data()' checks if the memory type is boot
> > > services data for runtime services data, it checks if the address is a
> > > 'table' address in 'efi_is_table_address'. I added it because of this
> > > check. Since the memory type used for the table is efi reserved type, we
> > > need to add the table address to 'efi_tables' array so that it could be
> > > checked in 'efi_is_table_address'. Please share your thought on this.
> > >
> >
> > OK. My branch ^^^ moves this into arch/x86 as well, please add it there
>
> I have a query related to this change. I will discuss it in next section
> below as it helps provide complete context.
>
> > > > > @@ -488,6 +493,12 @@ static __initdata efi_config_table_type_t 
> > > > > common_tables[] = {
> > > > > {NULL_GUID, NULL, NULL},
> > > > >  };
> > > > >
> > > > > +/* OEM Tables */
> > > > > +static __initdata efi_config_table_type_t oem_tables[] = {
> > > > > +   {DELLEMC_EFI_RCI2_TABLE_GUID, "RCI2", },
> > > >
> > > > Please drop the string. We don't have to print the presence of this
> > > > table in the bootlog since it has no significance to the OS itself.
> > >
> > > Okay. I will drop this in the next version of the patch.
> > >
> > > >
> > > > > +   {NULL_GUID, NULL, NULL},
> > > > > +};
> > > > > +
> > > >
> > > > Do we really need a separate oem_tables[] array?
> > >
> > > The RCI2 table did not seem to be part of the group of common tables
> > > such as SMBIOS and ACPI. To indicate this, I created a separate array.
> > > It seems like it is not required. Having the array allows to leverage
> > > the table matching code in 'match_config_table' function. Would you prefer
> > > to have this entry added to the 'common_tables' array ?
> > >
> >
> > Please add it to the arch_tables array in arch/x86 (if my assumption
> > is correct that this is x86-only)
>
> The table is used on x86. But it is not specific to x86 and is
> independent of the architecture. Because of this detail, my thinking is
> to keep the rci2_table.c and related changes in generic efi layer
> drivers/firmware/efi/. If we keep the changes in drivers/firmware/efi/,
> then two options are
>
> 1. Retain the oem_tables array and add rci2 table address to this array
> 2. Add rci2 table address to common_tables array
>
> Does this detail sound correct ?
>

Yes, and I'd prefer the latter.

> Also, since the 'efi_is_table_address' function and efi_tables array are moved
> to arch/x86, for rci2 table address to be detected as a table address, it 
> needs to be
> added to 'efi_tables' array. Would it be correct to add rci2 table
> address to this array with rest of the changes residing in the generic efi
> layer ?
>

Yes.

> Please share your thoughts on the two details.
>
> [...]
> > > Would you prefer to merge this function into 'efi_rci2_sysfs_init' 
> > > function ?
> > >
> >
> > Yes. Only user space needs to access this, so we can defer this to
> > later, when the normal memremap() functions are available.
> >
>
> Okay, I will make this change in the next version.
>
> --
> With regards,
> Narendra K


Re: [PATCH V34 28/29] efi: Restrict efivar_ssdt_load when the kernel is locked down

2019-06-25 Thread Ard Biesheuvel
On Sat, 22 Jun 2019 at 02:05, Matthew Garrett  wrote:
>
> efivar_ssdt_load allows the kernel to import arbitrary ACPI code from an
> EFI variable, which gives arbitrary code execution in ring 0. Prevent
> that when the kernel is locked down.
>
> Signed-off-by: Matthew Garrett 
> Cc: Ard Biesheuvel 
> Cc: linux-efi@vger.kernel.org

Acked-by: Ard Biesheuvel 

> ---
>  drivers/firmware/efi/efi.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index 55b77c576c42..9f92a013ab27 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>
> @@ -242,6 +243,11 @@ static void generic_ops_unregister(void)
>  static char efivar_ssdt[EFIVAR_SSDT_NAME_MAX] __initdata;
>  static int __init efivar_ssdt_setup(char *str)
>  {
> +   int ret = security_locked_down(LOCKDOWN_ACPI_TABLES);
> +
> +   if (ret)
> +   return ret;
> +
> if (strlen(str) < sizeof(efivar_ssdt))
> memcpy(efivar_ssdt, str, strlen(str));
> else
> --
> 2.22.0.410.gd8fdbe21b5-goog
>


Re: [RFC PATCH] Export Runtime Configuration Interface table to sysfs

2019-06-25 Thread Ard Biesheuvel
On Tue, 25 Jun 2019 at 14:10,  wrote:
>
> On Fri, Jun 21, 2019 at 06:35:42PM +0200, Ard Biesheuvel wrote:
> > (+ Peter)
> >
> > On Mon, 17 Jun 2019 at 12:11,  wrote:
> > >
> > > From: Narendra K 
> > >
> > > System firmware advertises the address of the 'Runtime
> > > Configuration Interface table version 2 (RCI2)' via
> > > an EFI Configuration Table entry. This code retrieves the RCI2
> > > table from the address and exports it to sysfs as a binary
> > > attribute 'rci2' under /sys/firmware/efi/tables directory.
> > > The approach adopted is similar to the attribute 'DMI' under
> > > /sys/firmware/dmi/tables.
> [...]
> > > ---
> > > Hi, the patch is created on kernel version 5.2-rc4. It applies to
> > > 5.2-rc5 also. If the approach looks correct, I will resubmit with RFC
> > > tag removed.
> > >
>
> Hi Ard,
>
> Thank you for the review comments.
>
> > Unfortunately, we cannot implement a  generic interface for dumping
> > config tables, since there is no generic method to record the length.
> > So I don't have any problems with doing it this way.
> >
> > I do have some comments, though.
> >
> > First of all, do you know which memory type is used for this table? (more 
> > below)
>
> The memory type used for the table is EfiReservedMemoryType.
>

OK

> [...]
> > > +obj-$(CONFIG_EFI)  += efi.o vars.o reboot.o 
> > > memattr.o tpm.o rci2_table.o
> > >  obj-$(CONFIG_EFI)  += capsule.o memmap.o
> > >  obj-$(CONFIG_EFI_VARS) += efivars.o
> > >  obj-$(CONFIG_EFI_ESRT) += esrt.o
> > > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> > > index 16b2137d117c..2fe114ff8149 100644
> > > --- a/drivers/firmware/efi/efi.c
> > > +++ b/drivers/firmware/efi/efi.c
> > > @@ -53,6 +53,7 @@ struct efi __read_mostly efi = {
> > > .rng_seed   = EFI_INVALID_TABLE_ADDR,
> > > .tpm_log= EFI_INVALID_TABLE_ADDR,
> > > .mem_reserve= EFI_INVALID_TABLE_ADDR,
> > > +   .rci2   = EFI_INVALID_TABLE_ADDR,
> >
> > Does this really need to live in the efi struct?
>
> It probably need not be part of struct efi. We could define a struct of
> type 'efi_config_table_type_t' in the rci2_table.c. Did you have a
> similar idea in mind ? If yes, I will modify and test this idea.
>

Yes, I'd like to start keeping these things separate.

I pushed a branch here

https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/log/?h=next

that changes the way uv_systab is handled, and moves it into arch/x86.
Please follow that pattern instead.

> >
> > >  };
> > >  EXPORT_SYMBOL(efi);
> > >
> > > @@ -73,6 +74,7 @@ static unsigned long *efi_tables[] = {
> > > ,
> > > _table,
> > > _attr_table,
> > > +   ,
> > >  };
> > >
> >
> > AFAICT, this table is only used by memremap_is_efi_data() to decide
> > whether a page should be map as unencrypted, and if the address is in
> > boot services data or runtime services data, the test will already
> > success, regardless of whether it appears in this enumeration.
>
> Yes. Before 'memremap_is_efi_data()' checks if the memory type is boot
> services data for runtime services data, it checks if the address is a
> 'table' address in 'efi_is_table_address'. I added it because of this
> check. Since the memory type used for the table is efi reserved type, we
> need to add the table address to 'efi_tables' array so that it could be
> checked in 'efi_is_table_address'. Please share your thought on this.
>

OK. My branch ^^^ moves this into arch/x86 as well, please add it there


> >
> > >  struct mm_struct efi_mm = {
> > > @@ -384,6 +386,9 @@ static int __init efisubsys_init(void)
> > > goto err_remove_group;
> > > }
> > >
> > > +   if (efi_rci2_sysfs_init() != 0)
> > > +   pr_debug("efi rci2: sysfs attribute creation under 
> > > /sys/firmware/efi/ failed");
> > > +
> > > return 0;
> > >
> > >  err_remove_group:
> > > @@ -488,6 +493,12 @@ static __initdata efi_config_table_type_t 
> > > common_tables[] = {
> > > {NULL_GUID, NULL, NULL},
> > >  };
> > >
> > > +/* OEM Tables */
> > > +static __initdata efi_config_table_type_t oem_tables[] = {
> &g

[PATCH 4/4] efibc: Replace variable set function in notifier call

2019-06-22 Thread Ard Biesheuvel
From: Tian Baofeng 

Replace the variable set function from "efivar_entry_set" to
"efivar_entry_set_safe" in efibc panic notifier.
In safe function parameter "block" will set to false
and will call "efivar_entry_set_nonblocking"to set efi variables.
efivar_entry_set_nonblocking is guaranteed to
not block and is suitable for calling from crash/panic handlers.
In UEFI android platform, when warm reset happens,
with this change, efibc will not block the reboot process.
Otherwise, set variable will call queue work and send to other offlined
cpus then cause another panic, finally will cause reboot failure.

Signed-off-by: Tian Baofeng 
Signed-off-by: Luo XinanX 
Signed-off-by: Ard Biesheuvel 
---
 drivers/firmware/efi/efibc.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/firmware/efi/efibc.c b/drivers/firmware/efi/efibc.c
index 61e099826cbb..35dccc88ac0a 100644
--- a/drivers/firmware/efi/efibc.c
+++ b/drivers/firmware/efi/efibc.c
@@ -43,11 +43,13 @@ static int efibc_set_variable(const char *name, const char 
*value)
efibc_str_to_str16(value, (efi_char16_t *)entry->var.Data);
memcpy(>var.VendorGuid, , sizeof(guid));
 
-   ret = efivar_entry_set(entry,
-  EFI_VARIABLE_NON_VOLATILE
-  | EFI_VARIABLE_BOOTSERVICE_ACCESS
-  | EFI_VARIABLE_RUNTIME_ACCESS,
-  size, entry->var.Data, NULL);
+   ret = efivar_entry_set_safe(entry->var.VariableName,
+   entry->var.VendorGuid,
+   EFI_VARIABLE_NON_VOLATILE
+   | EFI_VARIABLE_BOOTSERVICE_ACCESS
+   | EFI_VARIABLE_RUNTIME_ACCESS,
+   false, size, entry->var.Data);
+
if (ret)
pr_err("failed to set %s EFI variable: 0x%x\n",
   name, ret);
-- 
2.20.1



[PATCH 1/4] efi/memreserve: deal with memreserve entries in unmapped memory

2019-06-22 Thread Ard Biesheuvel
Ensure that the EFI memreserve entries can be accessed, even if they
are located in memory that the kernel (e.g., a crashkernel) omits from
the linear map.

Fixes: 80424b02d42b ("efi: Reduce the amount of memblock reservations ...")
Cc:  # 5.0+
Reported-by: Jonathan Richardson 
Reviewed-by: Jonathan Richardson 
Tested-by: Jonathan Richardson 
Signed-off-by: Ard Biesheuvel 
---
 drivers/firmware/efi/efi.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 16b2137d117c..4b7cf7bc0ded 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -1009,14 +1009,16 @@ int __ref efi_mem_reserve_persistent(phys_addr_t addr, 
u64 size)
 
/* first try to find a slot in an existing linked list entry */
for (prsv = efi_memreserve_root->next; prsv; prsv = rsv->next) {
-   rsv = __va(prsv);
+   rsv = memremap(prsv, sizeof(*rsv), MEMREMAP_WB);
index = atomic_fetch_add_unless(>count, 1, rsv->size);
if (index < rsv->size) {
rsv->entry[index].base = addr;
rsv->entry[index].size = size;
 
+   memunmap(rsv);
return 0;
}
+   memunmap(rsv);
}
 
/* no slot found - allocate a new linked list entry */
@@ -1024,7 +1026,13 @@ int __ref efi_mem_reserve_persistent(phys_addr_t addr, 
u64 size)
if (!rsv)
return -ENOMEM;
 
-   rsv->size = EFI_MEMRESERVE_COUNT(PAGE_SIZE);
+   /*
+* The memremap() call above assumes that a linux_efi_memreserve entry
+* never crosses a page boundary, so let's ensure that this remains true
+* even when kexec'ing a 4k pages kernel from a >4k pages kernel, by
+* using SZ_4K explicitly in the size calculation below.
+*/
+   rsv->size = EFI_MEMRESERVE_COUNT(SZ_4K);
atomic_set(>count, 1);
rsv->entry[0].base = addr;
rsv->entry[0].size = size;
-- 
2.20.1



[PATCH 3/4] x86/efi: fix a -Wtype-limits compilation warning

2019-06-22 Thread Ard Biesheuvel
From: Qian Cai 

Compiling a kernel with W=1 generates this warning,

arch/x86/platform/efi/quirks.c:731:16: warning: comparison of unsigned
expression >= 0 is always true [-Wtype-limits]

Fixes: 3425d934fc03 ("efi/x86: Handle page faults occurring while running ...")
Signed-off-by: Qian Cai 
Acked-by: "Prakhya, Sai Praneeth" 
Signed-off-by: Ard Biesheuvel 
---
 arch/x86/platform/efi/quirks.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
index 632b83885867..3b9fd679cea9 100644
--- a/arch/x86/platform/efi/quirks.c
+++ b/arch/x86/platform/efi/quirks.c
@@ -728,7 +728,7 @@ void efi_recover_from_page_fault(unsigned long phys_addr)
 * Address range 0x - 0x0fff is always mapped in the efi_pgd, so
 * page faulting on these addresses isn't expected.
 */
-   if (phys_addr >= 0x && phys_addr <= 0x0fff)
+   if (phys_addr <= 0x0fff)
return;
 
/*
-- 
2.20.1



[GIT PULL 0/4] EFI fixes for v5.2

2019-06-22 Thread Ard Biesheuvel
The following changes since commit d1fdb6d8f6a4109a4263176c84b899076a5f8008:

  Linux 5.2-rc4 (2019-06-08 20:24:46 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-urgent

for you to fetch changes up to 975a6166a8584ee4a1b8bd93098e49dc101d7171:

  efibc: Replace variable set function in notifier call (2019-06-22 10:24:57 
+0200)


Another handful of EFI fixes for v5.2:
- fix a potential crash after kexec on arm64 with GICv3
- fix a build warning on x86
- stop policing the BGRT feature flags
- use a non-blocking version of SetVariable() in the boot control driver


Ard Biesheuvel (1):
  efi/memreserve: deal with memreserve entries in unmapped memory

Hans de Goede (1):
  efi/bgrt: Drop BGRT status field reserved bits check

Qian Cai (1):
  x86/efi: fix a -Wtype-limits compilation warning

Tian Baofeng (1):
  efibc: Replace variable set function in notifier call

 arch/x86/platform/efi/quirks.c  |  2 +-
 drivers/firmware/efi/efi-bgrt.c |  5 -
 drivers/firmware/efi/efi.c  | 12 ++--
 drivers/firmware/efi/efibc.c| 12 +++-
 4 files changed, 18 insertions(+), 13 deletions(-)


[PATCH 2/4] efi/bgrt: Drop BGRT status field reserved bits check

2019-06-22 Thread Ard Biesheuvel
From: Hans de Goede 

Starting with ACPI 6.2 bits 1 and 2 of the BGRT status field are no longer
reserved. These bits are now used to indicate if the image needs to be
rotated before being displayed.

The first device using these bits has now shown up (the GPD MicroPC) and
the reserved bits check causes us to reject the valid BGRT table on this
device.

Rather then changing the reserved bits check, allowing only the 2 new bits,
instead just completely remove it so that we do not end up with a similar
problem when more bits are added in the future.

Signed-off-by: Hans de Goede 
Signed-off-by: Ard Biesheuvel 
---
 drivers/firmware/efi/efi-bgrt.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/firmware/efi/efi-bgrt.c b/drivers/firmware/efi/efi-bgrt.c
index a2384184a7de..b07c17643210 100644
--- a/drivers/firmware/efi/efi-bgrt.c
+++ b/drivers/firmware/efi/efi-bgrt.c
@@ -47,11 +47,6 @@ void __init efi_bgrt_init(struct acpi_table_header *table)
   bgrt->version);
goto out;
}
-   if (bgrt->status & 0xfe) {
-   pr_notice("Ignoring BGRT: reserved status bits are non-zero 
%u\n",
-  bgrt->status);
-   goto out;
-   }
if (bgrt->image_type != 0) {
pr_notice("Ignoring BGRT: invalid image type %u (expected 0)\n",
   bgrt->image_type);
-- 
2.20.1



Re: [RFC PATCH] Export Runtime Configuration Interface table to sysfs

2019-06-21 Thread Ard Biesheuvel
(+ Peter)

On Mon, 17 Jun 2019 at 12:11,  wrote:
>
> From: Narendra K 
>
> System firmware advertises the address of the 'Runtime
> Configuration Interface table version 2 (RCI2)' via
> an EFI Configuration Table entry. This code retrieves the RCI2
> table from the address and exports it to sysfs as a binary
> attribute 'rci2' under /sys/firmware/efi/tables directory.
> The approach adopted is similar to the attribute 'DMI' under
> /sys/firmware/dmi/tables.
>
> RCI2 table contains BIOS HII in XML format and is used to populate
> BIOS setup page in Dell EMC OpenManage Server Administrator tool.
> The BIOS setup page contains BIOS tokens which can be configured.
>
> Signed-off-by: Narendra K 
> ---
> Hi, the patch is created on kernel version 5.2-rc4. It applies to
> 5.2-rc5 also. If the approach looks correct, I will resubmit with RFC
> tag removed.
>

Unfortunately, we cannot implement a  generic interface for dumping
config tables, since there is no generic method to record the length.
So I don't have any problems with doing it this way.

I do have some comments, though.

First of all, do you know which memory type is used for this table? (more below)


>  Documentation/ABI/testing/sysfs-firmware-efi |   9 ++
>  drivers/firmware/efi/Makefile|   2 +-
>  drivers/firmware/efi/efi.c   |  20 ++-
>  drivers/firmware/efi/rci2_table.c| 148 +++
>  include/linux/efi.h  |   7 +
>  5 files changed, 184 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/firmware/efi/rci2_table.c
>
> diff --git a/Documentation/ABI/testing/sysfs-firmware-efi 
> b/Documentation/ABI/testing/sysfs-firmware-efi
> index e794eac32a90..cb887b5e10cb 100644
> --- a/Documentation/ABI/testing/sysfs-firmware-efi
> +++ b/Documentation/ABI/testing/sysfs-firmware-efi
> @@ -28,3 +28,12 @@ Description: Displays the physical addresses of all EFI 
> Configuration
> versions are always printed first, i.e. ACPI20 comes
> before ACPI.
>  Users: dmidecode
> +
> +What:  /sys/firmware/efi/tables/rci2
> +Date:  June 2019
> +Contact:   Narendra K , linux-b...@dell.com
> +Description:   Displays the content of the Runtime Configuration Interface
> +   Table version 2 on Dell EMC PowerEdge systems in binary format
> +Users: It is used by Dell EMC OpenManage Server Administrator tool to
> +   populate BIOS setup page.
> +
> diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
> index d2d0d2030620..db07828ca1ed 100644
> --- a/drivers/firmware/efi/Makefile
> +++ b/drivers/firmware/efi/Makefile
> @@ -11,7 +11,7 @@
>  KASAN_SANITIZE_runtime-wrappers.o  := n
>
>  obj-$(CONFIG_ACPI_BGRT)+= efi-bgrt.o
> -obj-$(CONFIG_EFI)  += efi.o vars.o reboot.o memattr.o 
> tpm.o
> +obj-$(CONFIG_EFI)  += efi.o vars.o reboot.o memattr.o 
> tpm.o rci2_table.o
>  obj-$(CONFIG_EFI)  += capsule.o memmap.o
>  obj-$(CONFIG_EFI_VARS) += efivars.o
>  obj-$(CONFIG_EFI_ESRT) += esrt.o
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index 16b2137d117c..2fe114ff8149 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -53,6 +53,7 @@ struct efi __read_mostly efi = {
> .rng_seed   = EFI_INVALID_TABLE_ADDR,
> .tpm_log= EFI_INVALID_TABLE_ADDR,
> .mem_reserve= EFI_INVALID_TABLE_ADDR,
> +   .rci2   = EFI_INVALID_TABLE_ADDR,

Does this really need to live in the efi struct?

>  };
>  EXPORT_SYMBOL(efi);
>
> @@ -73,6 +74,7 @@ static unsigned long *efi_tables[] = {
> ,
> _table,
> _attr_table,
> +   ,
>  };
>

AFAICT, this table is only used by memremap_is_efi_data() to decide
whether a page should be map as unencrypted, and if the address is in
boot services data or runtime services data, the test will already
success, regardless of whether it appears in this enumeration.

>  struct mm_struct efi_mm = {
> @@ -384,6 +386,9 @@ static int __init efisubsys_init(void)
> goto err_remove_group;
> }
>
> +   if (efi_rci2_sysfs_init() != 0)
> +   pr_debug("efi rci2: sysfs attribute creation under 
> /sys/firmware/efi/ failed");
> +
> return 0;
>
>  err_remove_group:
> @@ -488,6 +493,12 @@ static __initdata efi_config_table_type_t 
> common_tables[] = {
> {NULL_GUID, NULL, NULL},
>  };
>
> +/* OEM Tables */
> +static __initdata efi_config_table_type_t oem_tables[] = {
> +   {DELLEMC_EFI_RCI2_TABLE_GUID, "RCI2", },

Please drop the string. We don't have to print the presence of this
table in the bootlog since it has no significance to the OS itself.

> +   {NULL_GUID, NULL, NULL},
> +};
> +

Do we really need a separate oem_tables[] array?

>  static __init int 

Re: [[efi boot control]] efibc: Replace variable set function in notifier call

2019-06-21 Thread Ard Biesheuvel
On Wed, 12 Jun 2019 at 10:20,  wrote:
>
> From: Tian Baofeng 
>
> Replace the variable set function from "efivar_entry_set" to
> "efivar_entry_set_safe" in efibc panic notifier.
> In safe function parameter "block" will set to false
> and will call "efivar_entry_set_nonblocking"to set efi variables.
> efivar_entry_set_nonblocking is guaranteed to
> not block and is suitable for calling from crash/panic handlers.
> In UEFI android platform, when warm reset happens,
> with this change, efibc will not block the reboot process.
> Otherwise, set variable will call queue work and send to other offlined
> cpus then cause another panic, finally will cause reboot failure.
>
> Signed-off-by: Tian Baofeng 
> Signed-off-by: Luo XinanX 

Queued as a fix in efi/urgent

Thanks

> ---
>  drivers/firmware/efi/efibc.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/firmware/efi/efibc.c b/drivers/firmware/efi/efibc.c
> index 61e099826cbb..35dccc88ac0a 100644
> --- a/drivers/firmware/efi/efibc.c
> +++ b/drivers/firmware/efi/efibc.c
> @@ -43,11 +43,13 @@ static int efibc_set_variable(const char *name, const 
> char *value)
> efibc_str_to_str16(value, (efi_char16_t *)entry->var.Data);
> memcpy(>var.VendorGuid, , sizeof(guid));
>
> -   ret = efivar_entry_set(entry,
> -  EFI_VARIABLE_NON_VOLATILE
> -  | EFI_VARIABLE_BOOTSERVICE_ACCESS
> -  | EFI_VARIABLE_RUNTIME_ACCESS,
> -  size, entry->var.Data, NULL);
> +   ret = efivar_entry_set_safe(entry->var.VariableName,
> +   entry->var.VendorGuid,
> +   EFI_VARIABLE_NON_VOLATILE
> +   | EFI_VARIABLE_BOOTSERVICE_ACCESS
> +   | EFI_VARIABLE_RUNTIME_ACCESS,
> +   false, size, entry->var.Data);
> +
> if (ret)
> pr_err("failed to set %s EFI variable: 0x%x\n",
>name, ret);
> --
> 2.21.0
>


Re: [PATCH v2] x86/efi: fix a -Wtype-limits compilation warning

2019-06-21 Thread Ard Biesheuvel
On Wed, 19 Jun 2019 at 19:53, Prakhya, Sai Praneeth
 wrote:
>
> > Compiling a kernel with W=1 generates this warning,
> >
> > arch/x86/platform/efi/quirks.c:731:16: warning: comparison of unsigned
> > expression >= 0 is always true [-Wtype-limits]
> >
> > Fixes: 3425d934fc03 ("efi/x86: Handle page faults occurring while running 
> > EFI
> > runtime services")
> > Signed-off-by: Qian Cai 
> > ---
> >
> > v2: Add a "Fixes" tag.
>
> Makes sense.
> Thanks for the fix Qian Cai.
>

Queued as a fix with Sai's ack

Thanks,


Re: [PATCH] drivers: firmware: efi: fix gcc warning -Wint-conversion

2019-06-19 Thread Ard Biesheuvel
(+ Jarkko, tpmdd, Matthew)

On Sat, 15 Jun 2019 at 06:02, Hariprasad Kelam
 wrote:
>
> This patch fixes below warning
>
> drivers/firmware/efi/tpm.c:78:38: warning: passing argument 1 of
> ‘tpm2_calc_event_log_size’ makes pointer from integer without a cast
> [-Wint-conversion]
>
> Signed-off-by: Hariprasad Kelam 

I think we already have a fix queued for this, no?

> ---
>  drivers/firmware/efi/tpm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/efi/tpm.c b/drivers/firmware/efi/tpm.c
> index 74d0cd1..1d3f5ca 100644
> --- a/drivers/firmware/efi/tpm.c
> +++ b/drivers/firmware/efi/tpm.c
> @@ -75,7 +75,7 @@ int __init efi_tpm_eventlog_init(void)
> goto out;
> }
>
> -   tbl_size = tpm2_calc_event_log_size(efi.tpm_final_log
> +   tbl_size = tpm2_calc_event_log_size((void *)efi.tpm_final_log
> + sizeof(final_tbl->version)
> + sizeof(final_tbl->nr_events),
> final_tbl->nr_events,
> --
> 2.7.4
>


Re: [PATCH V2 2/2] tpm: Don't duplicate events from the final event log in the TCG2 log

2019-06-13 Thread Ard Biesheuvel
On Thu, 13 Jun 2019 at 16:06, Jarkko Sakkinen
 wrote:
>
> On Fri, Jun 07, 2019 at 11:11:21PM +0200, Ard Biesheuvel wrote:
> > Acked-by: Ard Biesheuvel 
>
> Ard, is it cool if I include these to my next TPM PR along with the
> other Matthew's changes? Just sanity checking given that crossing
> subsystems...
>

Yes, that is fine.


Re: [PATCH] efi/bgrt: Drop BGRT status field reserved bits check

2019-06-10 Thread Ard Biesheuvel
On Wed, 29 May 2019 at 15:28, Hans de Goede  wrote:
>
> Starting with ACPI 6.2 bits 1 and 2 of the BGRT status field are no longer
> reserved. These bits are now used to indicate if the image needs to be
> rotated before being displayed.
>
> The first device using these bits has now shown up (the GPD MicroPC) and
> the reserved bits check causes us to reject the valid BGRT table on this
> device.
>
> Rather then changing the reserved bits check, allowing only the 2 new bits,
> instead just completely remove it so that we do not end up with a similar
> problem when more bits are added in the future.
>
> Signed-off-by: Hans de Goede 

Thanks, Hans. I'll take this as a fix.

> ---
>  drivers/firmware/efi/efi-bgrt.c | 5 -
>  1 file changed, 5 deletions(-)
>
> diff --git a/drivers/firmware/efi/efi-bgrt.c b/drivers/firmware/efi/efi-bgrt.c
> index a2384184a7de..b07c17643210 100644
> --- a/drivers/firmware/efi/efi-bgrt.c
> +++ b/drivers/firmware/efi/efi-bgrt.c
> @@ -47,11 +47,6 @@ void __init efi_bgrt_init(struct acpi_table_header *table)
>bgrt->version);
> goto out;
> }
> -   if (bgrt->status & 0xfe) {
> -   pr_notice("Ignoring BGRT: reserved status bits are non-zero 
> %u\n",
> -  bgrt->status);
> -   goto out;
> -   }
> if (bgrt->image_type != 0) {
> pr_notice("Ignoring BGRT: invalid image type %u (expected 
> 0)\n",
>bgrt->image_type);
> --
> 2.21.0
>


[PATCH] efi/memreserve: deal with memreserve entries in unmapped memory

2019-06-10 Thread Ard Biesheuvel
Ensure that the EFI memreserve entries can be accessed, even if they
are located in memory that the kernel (e.g., a crashkernel) omits from
the linear map.

Reported-by: Jonathan Richardson 
Signed-off-by: Ard Biesheuvel 
---
 drivers/firmware/efi/efi.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 16b2137d117c..4b7cf7bc0ded 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -1009,14 +1009,16 @@ int __ref efi_mem_reserve_persistent(phys_addr_t addr, 
u64 size)
 
/* first try to find a slot in an existing linked list entry */
for (prsv = efi_memreserve_root->next; prsv; prsv = rsv->next) {
-   rsv = __va(prsv);
+   rsv = memremap(prsv, sizeof(*rsv), MEMREMAP_WB);
index = atomic_fetch_add_unless(>count, 1, rsv->size);
if (index < rsv->size) {
rsv->entry[index].base = addr;
rsv->entry[index].size = size;
 
+   memunmap(rsv);
return 0;
}
+   memunmap(rsv);
}
 
/* no slot found - allocate a new linked list entry */
@@ -1024,7 +1026,13 @@ int __ref efi_mem_reserve_persistent(phys_addr_t addr, 
u64 size)
if (!rsv)
return -ENOMEM;
 
-   rsv->size = EFI_MEMRESERVE_COUNT(PAGE_SIZE);
+   /*
+* The memremap() call above assumes that a linux_efi_memreserve entry
+* never crosses a page boundary, so let's ensure that this remains true
+* even when kexec'ing a 4k pages kernel from a >4k pages kernel, by
+* using SZ_4K explicitly in the size calculation below.
+*/
+   rsv->size = EFI_MEMRESERVE_COUNT(SZ_4K);
atomic_set(>count, 1);
rsv->entry[0].base = addr;
rsv->entry[0].size = size;
-- 
2.20.1



Re: [PATCH AUTOSEL 4.19 17/49] efi/x86/Add missing error handling to old_memmap 1:1 mapping code

2019-06-09 Thread Ard Biesheuvel
On Sat, 8 Jun 2019 at 13:43, Sasha Levin  wrote:
>
> From: Gen Zhang 
>
> [ Upstream commit 4e78921ba4dd0aca1cc89168f45039add4183f8e ]
>
> The old_memmap flow in efi_call_phys_prolog() performs numerous memory
> allocations, and either does not check for failure at all, or it does
> but fails to propagate it back to the caller, which may end up calling
> into the firmware with an incomplete 1:1 mapping.
>
> So let's fix this by returning NULL from efi_call_phys_prolog() on
> memory allocation failures only, and by handling this condition in the
> caller. Also, clean up any half baked sets of page tables that we may
> have created before returning with a NULL return value.
>
> Note that any failure at this level will trigger a panic() two levels
> up, so none of this makes a huge difference, but it is a nice cleanup
> nonetheless.
>
> [ardb: update commit log, add efi_call_phys_epilog() call on error path]
>
> Signed-off-by: Gen Zhang 
> Signed-off-by: Ard Biesheuvel 
> Cc: Linus Torvalds 
> Cc: Peter Zijlstra 
> Cc: Rob Bradford 
> Cc: Thomas Gleixner 
> Cc: linux-efi@vger.kernel.org
> Link: http://lkml.kernel.org/r/20190525112559.7917-2-ard.biesheu...@linaro.org
> Signed-off-by: Ingo Molnar 
> Signed-off-by: Sasha Levin 

This was already discussed in the thread that proposed this patch for
stable: please don't queue this right now, the patches are more likely
to harm than hurt, and they certainly don't fix a security
vulnerability, as has been claimed.


> ---
>  arch/x86/platform/efi/efi.c| 2 ++
>  arch/x86/platform/efi/efi_64.c | 9 ++---
>  2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 9061babfbc83..353019d4e6c9 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -86,6 +86,8 @@ static efi_status_t __init phys_efi_set_virtual_address_map(
> pgd_t *save_pgd;
>
> save_pgd = efi_call_phys_prolog();
> +   if (!save_pgd)
> +   return EFI_ABORTED;
>
> /* Disable interrupts around EFI calls: */
> local_irq_save(flags);
> diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
> index ee5d08f25ce4..dfc809b31c7c 100644
> --- a/arch/x86/platform/efi/efi_64.c
> +++ b/arch/x86/platform/efi/efi_64.c
> @@ -84,13 +84,15 @@ pgd_t * __init efi_call_phys_prolog(void)
>
> if (!efi_enabled(EFI_OLD_MEMMAP)) {
> efi_switch_mm(_mm);
> -   return NULL;
> +   return efi_mm.pgd;
> }
>
> early_code_mapping_set_exec(1);
>
> n_pgds = DIV_ROUND_UP((max_pfn << PAGE_SHIFT), PGDIR_SIZE);
> save_pgd = kmalloc_array(n_pgds, sizeof(*save_pgd), GFP_KERNEL);
> +   if (!save_pgd)
> +   return NULL;
>
> /*
>  * Build 1:1 identity mapping for efi=old_map usage. Note that
> @@ -138,10 +140,11 @@ pgd_t * __init efi_call_phys_prolog(void)
> pgd_offset_k(pgd * PGDIR_SIZE)->pgd &= ~_PAGE_NX;
> }
>
> -out:
> __flush_tlb_all();
> -
> return save_pgd;
> +out:
> +   efi_call_phys_epilog(save_pgd);
> +   return NULL;
>  }
>
>  void __init efi_call_phys_epilog(pgd_t *save_pgd)
> --
> 2.20.1
>


Re: [PATCH v2 4/8] x86, efi: Reserve UEFI 2.8 Specific Purpose Memory for dax

2019-06-08 Thread Ard Biesheuvel
On Fri, 7 Jun 2019 at 19:34, Dan Williams  wrote:
>
> On Fri, Jun 7, 2019 at 8:23 AM Dan Williams  wrote:
> >
> > On Fri, Jun 7, 2019 at 5:29 AM Ard Biesheuvel  
> > wrote:
> [..]
> > > > #ifdef CONFIG_EFI_APPLICATION_RESERVED
> > > > static inline bool is_efi_application_reserved(efi_memory_desc_t *md)
> > > > {
> > > > return md->type == EFI_CONVENTIONAL_MEMORY
> > > > && (md->attribute & EFI_MEMORY_SP);
> > > > }
> > > > #else
> > > > static inline bool is_efi_application_reserved(efi_memory_desc_t *md)
> > > > {
> > > > return false;
> > > > }
> > > > #endif
> > >
> > > I think this policy decision should not live inside the EFI subsystem.
> > > EFI just gives you the memory map, and mangling that information
> > > depending on whether you think a certain memory attribute should be
> > > ignored is the job of the MM subsystem.
> >
> > The problem is that we don't have an mm subsystem at the time a
> > decision needs to be made. The reservation policy needs to be deployed
> > before even memblock has been initialized in order to keep kernel
> > allocations out of the reservation. I agree with the sentiment I just
> > don't see how to practically achieve an optional "System RAM" vs
> > "Application Reserved" routing decision without an early (before
> > e820__memblock_setup()) conditional branch.
>
> I can at least move it out of include/linux/efi.h and move it to
> arch/x86/include/asm/efi.h since it is an x86 specific policy decision
> / implementation for now.

No, that doesn't make sense to me. If it must live in the EFI
subsystem, I'd prefer it to be in the core code, not in x86 specific
code, since there is nothing x86 specific about it.

Perhaps a efi=xxx command line option would be in order to influence
the builtin default, but it can be a followup patch independent of
this series.


Re: [PATCH V2 2/2] tpm: Don't duplicate events from the final event log in the TCG2 log

2019-06-07 Thread Ard Biesheuvel
og_location,
> +  false);
> +   final_events_size += event_size;
> +   i--;
> +   }
> +   }
> +
> memset(log_tbl, 0, sizeof(*log_tbl) + log_size);
> log_tbl->size = log_size;
> +   log_tbl->final_events_preboot_size = final_events_size;
> log_tbl->version = version;
> memcpy(log_tbl->log, (void *) first_entry_addr, log_size);
>
> diff --git a/drivers/firmware/efi/tpm.c b/drivers/firmware/efi/tpm.c
> index 2c912ea08166..0bdceb5913aa 100644
> --- a/drivers/firmware/efi/tpm.c
> +++ b/drivers/firmware/efi/tpm.c
> @@ -76,7 +76,7 @@ int __init efi_tpm_eventlog_init(void)
> goto out;
> }
>
> -   tbl_size = tpm2_calc_event_log_size(efi.tpm_final_log
> +   tbl_size = tpm2_calc_event_log_size((void *)efi.tpm_final_log
> + sizeof(final_tbl->version)
> + sizeof(final_tbl->nr_events),
>         final_tbl->nr_events,
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index e33c70a52a9d..2a26004a9bdb 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -1703,6 +1703,7 @@ struct linux_efi_random_seed {
>
>  struct linux_efi_tpm_eventlog {
> u32 size;
> +   u32 final_events_preboot_size;
> u8  version;
> u8  log[];
>  };

Acked-by: Ard Biesheuvel 


Re: [PATCH V2 1/2] Abstract out support for locating an EFI config table

2019-06-07 Thread Ard Biesheuvel
On Fri, 7 Jun 2019 at 22:52, Matthew Garrett  wrote:
>
> We want to grab a pointer to the TPM final events table, so abstract out
> the existing code for finding an FDT table and make it generic.
>
> Signed-off-by: Matthew Garrett 
> ---
>  .../firmware/efi/libstub/efi-stub-helper.c| 15 +++
>  drivers/firmware/efi/libstub/efistub.h|  2 ++
>  drivers/firmware/efi/libstub/fdt.c| 27 +++
>  3 files changed, 26 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c 
> b/drivers/firmware/efi/libstub/efi-stub-helper.c
> index e4610e72b78f..1db780c0f07b 100644
> --- a/drivers/firmware/efi/libstub/efi-stub-helper.c
> +++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
> @@ -926,3 +926,18 @@ efi_status_t efi_exit_boot_services(efi_system_table_t 
> *sys_table_arg,
>  fail:
> return status;
>  }
> +
> +void *get_efi_config_table(efi_system_table_t *sys_table, efi_guid_t guid)
> +{
> +   efi_config_table_t *tables = (efi_config_table_t *)sys_table->tables;
> +   int i;
> +
> +   for (i = 0; i < sys_table->nr_tables; i++) {
> +   if (efi_guidcmp(tables[i].guid, guid) != 0)
> +   continue;
> +
> +   return (void *)tables[i].table;
> +   }
> +
> +   return NULL;
> +}
> diff --git a/drivers/firmware/efi/libstub/efistub.h 
> b/drivers/firmware/efi/libstub/efistub.h
> index 1b1dfcaa6fb9..7f1556fd867d 100644
> --- a/drivers/firmware/efi/libstub/efistub.h
> +++ b/drivers/firmware/efi/libstub/efistub.h
> @@ -65,6 +65,8 @@ efi_status_t check_platform_features(efi_system_table_t 
> *sys_table_arg);
>
>  efi_status_t efi_random_get_seed(efi_system_table_t *sys_table_arg);
>
> +void *get_efi_config_table(efi_system_table_t *sys_table, efi_guid_t guid);
> +
>  /* Helper macros for the usual case of using simple C variables: */
>  #ifndef fdt_setprop_inplace_var
>  #define fdt_setprop_inplace_var(fdt, node_offset, name, var) \
> diff --git a/drivers/firmware/efi/libstub/fdt.c 
> b/drivers/firmware/efi/libstub/fdt.c
> index 5440ba17a1c5..0bf0190917e0 100644
> --- a/drivers/firmware/efi/libstub/fdt.c
> +++ b/drivers/firmware/efi/libstub/fdt.c
> @@ -363,26 +363,17 @@ efi_status_t 
> allocate_new_fdt_and_exit_boot(efi_system_table_t *sys_table,
>
>  void *get_fdt(efi_system_table_t *sys_table, unsigned long *fdt_size)
>  {
> -   efi_guid_t fdt_guid = DEVICE_TREE_GUID;
> -   efi_config_table_t *tables;
> -   int i;
> +   void *fdt;
>
> -   tables = (efi_config_table_t *)sys_table->tables;
> +   fdt = get_efi_config_table(sys_table, DEVICE_TREE_GUID);
>
> -   for (i = 0; i < sys_table->nr_tables; i++) {
> -   void *fdt;
> +   if (!fdt)
> +   return NULL;
>
> -   if (efi_guidcmp(tables[i].guid, fdt_guid) != 0)
> -   continue;
> -
> -   fdt = (void *)tables[i].table;
> -   if (fdt_check_header(fdt) != 0) {
> -   pr_efi_err(sys_table, "Invalid header detected on 
> UEFI supplied FDT, ignoring ...\n");
> -   return NULL;
> -   }
> -   *fdt_size = fdt_totalsize(fdt);
> -   return fdt;
> +   if (fdt_check_header(fdt) != 0) {
> +   pr_efi_err(sys_table, "Invalid header detected on UEFI 
> supplied FDT, ignoring ...\n");
> +   return NULL;
> }
> -
> -   return NULL;
> +   *fdt_size = fdt_totalsize(fdt);
> +   return fdt;
>  }

Reviewed-by: Ard Biesheuvel 


Re: [PATCH v2 4/8] x86, efi: Reserve UEFI 2.8 Specific Purpose Memory for dax

2019-06-07 Thread Ard Biesheuvel
On Sat, 1 Jun 2019 at 06:26, Dan Williams  wrote:
>
> On Fri, May 31, 2019 at 8:30 AM Ard Biesheuvel
>  wrote:
> >
> > On Fri, 31 May 2019 at 17:28, Dan Williams  wrote:
> > >
> > > On Fri, May 31, 2019 at 1:30 AM Ard Biesheuvel
> > >  wrote:
> > > >
> > > > (cc Mike for memblock)
> > > >
> > > > On Fri, 31 May 2019 at 01:13, Dan Williams  
> > > > wrote:
> > > > >
> > > > > UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the
> > > > > interpretation of the EFI Memory Types as "reserved for a special
> > > > > purpose".
> > > > >
> > > > > The proposed Linux behavior for specific purpose memory is that it is
> > > > > reserved for direct-access (device-dax) by default and not available 
> > > > > for
> > > > > any kernel usage, not even as an OOM fallback. Later, through udev
> > > > > scripts or another init mechanism, these device-dax claimed ranges can
> > > > > be reconfigured and hot-added to the available System-RAM with a 
> > > > > unique
> > > > > node identifier.
> > > > >
> > > > > This patch introduces 3 new concepts at once given the entanglement
> > > > > between early boot enumeration relative to memory that can optionally 
> > > > > be
> > > > > reserved from the kernel page allocator by default. The new concepts
> > > > > are:
> > > > >
> > > > > - E820_TYPE_SPECIFIC: Upon detecting the EFI_MEMORY_SP attribute on
> > > > >   EFI_CONVENTIONAL memory, update the E820 map with this new type. 
> > > > > Only
> > > > >   perform this classification if the CONFIG_EFI_SPECIFIC_DAX=y policy 
> > > > > is
> > > > >   enabled, otherwise treat it as typical ram.
> > > > >
> > > >
> > > > OK, so now we have 'special purpose', 'specific' and 'app specific'
> > > > [below]. Do they all mean the same thing?
> > >
> > > I struggled with separating the raw-EFI-type name from the name of the
> > > Linux specific policy. Since the reservation behavior is optional I
> > > was thinking there should be a distinct Linux kernel name for that
> > > policy. I did try to go back and change all occurrences of "special"
> > > to "specific" from the RFC to this v2, but seems I missed one.
> > >
> >
> > OK
>
> I'll go ahead and use "application reserved" terminology consistently
> throughout the code to distinguish that Linux translation from the raw
> "EFI specific purpose" attribute.
>

OK

> >
> > > >
> > > > > - IORES_DESC_APPLICATION_RESERVED: Add a new I/O resource descriptor 
> > > > > for
> > > > >   a device driver to search iomem resources for application specific
> > > > >   memory. Teach the iomem code to identify such ranges as "Application
> > > > >   Reserved".
> > > > >
> > > > > - MEMBLOCK_APP_SPECIFIC: Given the memory ranges can fallback to the
> > > > >   traditional System RAM pool the expectation is that they will have
> > > > >   typical SRAT entries. In order to support a policy of device-dax by
> > > > >   default with the option to hotplug later, the numa initialization 
> > > > > code
> > > > >   is taught to avoid marking online MEMBLOCK_APP_SPECIFIC regions.
> > > > >
> > > >
> > > > Can we move the generic memblock changes into a separate patch please?
> > >
> > > Yeah, that can move to a lead-in patch.
> > >
> > > [..]
> > > > > diff --git a/include/linux/efi.h b/include/linux/efi.h
> > > > > index 91368f5ce114..b57b123cbdf9 100644
> > > > > --- a/include/linux/efi.h
> > > > > +++ b/include/linux/efi.h
> > > > > @@ -129,6 +129,19 @@ typedef struct {
> > > > > u64 attribute;
> > > > >  } efi_memory_desc_t;
> > > > >
> > > > > +#ifdef CONFIG_EFI_SPECIFIC_DAX
> > > > > +static inline bool is_efi_dax(efi_memory_desc_t *md)
> > > > > +{
> > > > > +   return md->type == EFI_CONVENTIONAL_MEMORY
> > > > > +   && (md->attribute & EFI_MEMORY_SP);
> > > > > +}
>

Re: gicv3-its driver crashes in crash dump kernel

2019-06-07 Thread Ard Biesheuvel
0063c2: allocated 65536 Devices @fd48 
> >> (flat, esz 8, psz 64K, shr 0)
> >> [ 0.00] ITS: using cache flushing for cmd queue
> >> [ 0.00] Unable to handle kernel paging request at virtual address 
> >> 800975c36004
> >> [ 0.00] Mem abort info:
> >> [ 0.00] ESR = 0x9605
> >> [ 0.00] Exception class = DABT (current EL), IL = 32 bits
> >> [ 0.00] SET = 0, FnV = 0
> >> [ 0.00] EA = 0, S1PTW = 0
> >> [ 0.00] Data abort info:
> >> [ 0.00] ISV = 0, ISS = 0x0005
> >> [ 0.00] CM = 0, WnR = 0
> >> [ 0.00] swapper pgtable: 4k pages, 48-bit VAs, pgdp = (ptrval)
> >> [ 0.00] [800975c36004] pgd=ffdf8003, pud=
> >> [ 0.00] Internal error: Oops: 9605 [#1] SMP
> >> [ 0.00] Modules linked in:
> >> [ 0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.0.0 #1
> >> [ 0.00] Hardware name: Stingray PS1100R (BCM958804A8040) (DT)
> >> [ 0.00] pstate: 6085 (nZCv daIf -PAN -UAO)
> >> [ 0.00] pc : efi_mem_reserve_persistent+0x60/0x1b8
> >> [ 0.00] lr : efi_mem_reserve_persistent+0x1a0/0x1b8
> >> [ 0.00] sp : 10dd3c30
> >> [ 0.00] x29: 10dd3c30 x28: 80007d409200
> >> [ 0.00] x27: 10eca000 x26: 0008
> >> [ 0.00] x25: 1006 x24: 
> >> [ 0.00] x23: 0001 x22: 10c96000
> >> [ 0.00] x21: fd45 x20: 0001
> >> [ 0.00] x19: 10eca000 x18: 
> >> [ 0.00] x17:  x16: 
> >> [ 0.00] x15: 10ddc688 x14: 80007d4334b5
> >> [ 0.00] x13: 10c96000 x12: 10005fff
> >> [ 0.00] x11: 10005000 x10: 85f84000
> >> [ 0.00] x9 :  x8 : 0041
> >> [ 0.00] x7 : 10005000 x6 : 10c96000
> >> [ 0.00] x5 : 80007fdfd408 x4 : 10005fff
> >> [ 0.00] x3 : 800975c36000 x2 : 8000
> >> [ 0.00] x1 : 10005018 x0 : 
> >> [ 0.00] Process swapper/0 (pid: 0, stack limit = 0x(ptrval))
> >> [ 0.00] Call trace:
> >> [ 0.00] efi_mem_reserve_persistent+0x60/0x1b8
> >> [ 0.00] its_init+0xa58/0xe98
> >> [ 0.00] gic_of_init+0x478/0x4d4
> >> [ 0.00] of_irq_init+0x19c/0x2f4
> >> [ 0.00] irqchip_init+0x14/0x1c
> >> [ 0.00] init_IRQ+0xe4/0x118
> >> [ 0.00] start_kernel+0x274/0x3ec
> >> [ 0.00] Code: b40002c3 f940b8c2 cb020063 b2514063 (b9400461)
> >> [ 0.00] ---[ end trace b6cc692d2bc7d1fd ]---
> >> [ 0.00] Kernel panic - not syncing: Attempted to kill the idle task!
> >> [ 0.00] ---[ end Kernel panic - not syncing: Attempted to kill the 
> >> idle task! ]---
> >>
> >> This commit changes to efi_mem_reserve_peristent() which causes the 
> >> problem we're seeing:
> >>
> >> commit 80424b02d42bb22f8ff8839cb93a84ade53b39c0
> >>
> >> Author: Ard Biesheuvel 
> >> Date:   Thu Nov 29 18:12:29 2018 +0100
> >>
> >> efi: Reduce the amount of memblock reservations for persistent 
> >> allocations
> >>
> >> The current implementation of efi_mem_reserve_persistent() is rather
> >> naive, in the sense that for each invocation, it creates a separate
> >> linked list entry to describe the reservation. Since the linked list
> >> entries themselves need to persist across subsequent kexec reboots,
> >> every reservation created this way results in two memblock_reserve()
> >> calls at the next boot.
> >>
> >> On first boot, a physical address from DT gets added to the mem_reserve 
> >> list, 0xc3836000.
> >>
> >> [0.00] GICv3: GIC: Using split EOI/Deactivate mode
> >> [0.00] GICv3: Distributor has no Range Selector support
> >> [0.00] GICv3: no VLPI support, no direct LPI support
> >> [0.00] GICv3: CPU0: found redistributor 0 region 
> >> 0:0x63e0
> >> [0.00] ITS [mem 0x63c2-0x63c2]
> >> [0.00] ITS@0x63c2: allocated 32768 Devices @a3c388 
> >> (flat, esz 8, psz 64K, shr 0)
> >> [0.00] ITS: using cache flushing for cmd queue
> >> [0.00] GICv3: using LPI property table @0x00a3c385
> >&g

Re: [PATCH] efi: Fix TPM code build failure on ARM

2019-06-07 Thread Ard Biesheuvel
On Thu, 6 Jun 2019 at 18:04, Matthew Garrett  wrote:
>
> On Thu, Jun 6, 2019 at 4:39 AM Ard Biesheuvel  
> wrote:
> >
> > On Wed, 5 Jun 2019 at 20:11, Matthew Garrett  
> > wrote:
> > >
> > > asm/early_ioremap.h needs to be #included before tpm_eventlog.h in order
> > > to ensure that early_memremap is available.
> > >
> >
> > Doesn't that make it tpm_eventlog.h's job to #include it?
>
> tpm_eventlog.h doesn't use early_memremap directly, it's expanded from
> the macros declared in tpm.c .

Fair enough

Acked-by: Ard Biesheuvel 


Re: [PATCH V2] tpm: Don't duplicate events from the final event log in the TCG2 log

2019-06-07 Thread Ard Biesheuvel
On Wed, 5 Jun 2019 at 20:05, Matthew Garrett  wrote:
>
> After the first call to GetEventLog() on UEFI systems using the TCG2
> crypto agile log format, any further log events (other than those
> triggered by ExitBootServices()) will be logged in both the main log and
> also in the Final Events Log. While the kernel only calls GetEventLog()
> immediately before ExitBootServices(), we can't control whether earlier
> parts of the boot process have done so. This will result in log entries
> that exist in both logs, and so the current approach of simply appending
> the Final Event Log to the main log will result in events being
> duplicated.
>
> We can avoid this problem by looking at the size of the Final Event Log
> just before we call ExitBootServices() and exporting this to the main
> kernel. The kernel can then skip over all events that occured before
> ExitBootServices() and only append events that were not also logged to
> the main log.
>
> Signed-off-by: Matthew Garrett 
> Reported-by: Joe Richey 
> Suggested-by: Joe Richey 
> ---
>
> Unmodified other than changing the name of final_events_early_size to
> final_events_preboot_size.
>
>  drivers/char/tpm/eventlog/efi.c   | 11 ++-
>  .../firmware/efi/libstub/efi-stub-helper.c| 15 ++
>  drivers/firmware/efi/libstub/efistub.h|  2 ++
>  drivers/firmware/efi/libstub/fdt.c| 27 ++---
>  drivers/firmware/efi/libstub/tpm.c| 30 +++
>  drivers/firmware/efi/tpm.c|  2 +-
>  include/linux/efi.h   |  1 +
>  7 files changed, 68 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/char/tpm/eventlog/efi.c b/drivers/char/tpm/eventlog/efi.c
> index 9179cf6bdee9..be6540f2cb3d 100644
> --- a/drivers/char/tpm/eventlog/efi.c
> +++ b/drivers/char/tpm/eventlog/efi.c
> @@ -80,6 +80,8 @@ int tpm_read_log_efi(struct tpm_chip *chip)
> goto out;
> }
>
> +   efi_tpm_final_log_size -= log_tbl->final_events_preboot_size;
> +
> tmp = krealloc(log->bios_event_log,
>log_size + efi_tpm_final_log_size,
>GFP_KERNEL);
> @@ -90,8 +92,15 @@ int tpm_read_log_efi(struct tpm_chip *chip)
> }
>
> log->bios_event_log = tmp;
> +
> +   /*
> +* Copy any of the final events log that didn't also end up in the
> +* main log. Events can be logged in both if events are generated
> +* between GetEventLog() and ExitBootServices().
> +*/
> memcpy((void *)log->bios_event_log + log_size,
> -  final_tbl->events, efi_tpm_final_log_size);
> +  final_tbl->events + log_tbl->final_events_preboot_size,
> +  efi_tpm_final_log_size);
> log->bios_event_log_end = log->bios_event_log +
> log_size + efi_tpm_final_log_size;
>
> diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c 
> b/drivers/firmware/efi/libstub/efi-stub-helper.c
> index e4610e72b78f..1db780c0f07b 100644
> --- a/drivers/firmware/efi/libstub/efi-stub-helper.c
> +++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
> @@ -926,3 +926,18 @@ efi_status_t efi_exit_boot_services(efi_system_table_t 
> *sys_table_arg,
>  fail:
> return status;
>  }
> +
> +void *get_efi_config_table(efi_system_table_t *sys_table, efi_guid_t guid)
> +{
> +   efi_config_table_t *tables = (efi_config_table_t *)sys_table->tables;
> +   int i;
> +
> +   for (i = 0; i < sys_table->nr_tables; i++) {
> +   if (efi_guidcmp(tables[i].guid, guid) != 0)
> +   continue;
> +
> +   return (void *)tables[i].table;
> +   }
> +
> +   return NULL;
> +}

Please create a separate patch that factors out this code from get_fdt().


> diff --git a/drivers/firmware/efi/libstub/efistub.h 
> b/drivers/firmware/efi/libstub/efistub.h
> index 1b1dfcaa6fb9..7f1556fd867d 100644
> --- a/drivers/firmware/efi/libstub/efistub.h
> +++ b/drivers/firmware/efi/libstub/efistub.h
> @@ -65,6 +65,8 @@ efi_status_t check_platform_features(efi_system_table_t 
> *sys_table_arg);
>
>  efi_status_t efi_random_get_seed(efi_system_table_t *sys_table_arg);
>
> +void *get_efi_config_table(efi_system_table_t *sys_table, efi_guid_t guid);
> +
>  /* Helper macros for the usual case of using simple C variables: */
>  #ifndef fdt_setprop_inplace_var
>  #define fdt_setprop_inplace_var(fdt, node_offset, name, var) \
> diff --git a/drivers/firmware/efi/libstub/fdt.c 
> b/drivers/firmware/efi/libstub/fdt.c
> index 5440ba17a1c5..0bf0190917e0 100644
> --- a/drivers/firmware/efi/libstub/fdt.c
> +++ b/drivers/firmware/efi/libstub/fdt.c
> @@ -363,26 +363,17 @@ efi_status_t 
> allocate_new_fdt_and_exit_boot(efi_system_table_t *sys_table,
>
>  void *get_fdt(efi_system_table_t *sys_table, unsigned long *fdt_size)
>  {
> -   efi_guid_t fdt_guid = DEVICE_TREE_GUID;
> -   efi_config_table_t *tables;
> -   int i;
> +   void *fdt;
>
> 

Re: [PATCH for-4.9-stable] efi/libstub: Unify command line param parsing

2019-06-07 Thread Ard Biesheuvel
On Thu, 6 Jun 2019 at 17:26, Greg KH  wrote:
>
> On Thu, Jun 06, 2019 at 12:25:13PM +0200, Ard Biesheuvel wrote:
> > Commit 60f38de7a8d4e816100ceafd1b382df52527bd50 upstream.
> >
> > Merge the parsing of the command line carried out in arm-stub.c with
> > the handling in efi_parse_options(). Note that this also fixes the
> > missing handling of CONFIG_CMDLINE_FORCE=y, in which case the builtin
> > command line should supersede the one passed by the firmware.
> >
> > Signed-off-by: Ard Biesheuvel 
> > Cc: Linus Torvalds 
> > Cc: Matt Fleming 
> > Cc: Peter Zijlstra 
> > Cc: Thomas Gleixner 
> > Cc: b...@redhat.com
> > Cc: bhsha...@redhat.com
> > Cc: b...@alien8.de
> > Cc: eug...@hp.com
> > Cc: evgeny.kalu...@intel.com
> > Cc: jh...@codeaurora.org
> > Cc: leif.lindh...@linaro.org
> > Cc: linux-efi@vger.kernel.org
> > Cc: mark.rutl...@arm.com
> > Cc: roy.fr...@cavium.com
> > Cc: rruig...@codeaurora.org
> > Link: 
> > http://lkml.kernel.org/r/20170404160910.28115-1-ard.biesheu...@linaro.org
> > Signed-off-by: Ingo Molnar 
> > [ardb: fix up merge conflicts with 4.9.180]
> > Signed-off-by: Ard Biesheuvel 
> > ---
> > This fixes the GCC build issue reported by Eike.
> >
> > Note that testing of arm64 stable kernels should cover 
> > CONFIG_RANDOMIZE_BASE,
> > since it has a profound impact on how the kernel binary gets put together.
>
> Good idea.  Is that in any arm64 stable kernel configuration?  If not, I
> can ask the Linaro build/test people to add it there.
>

It is not in the defconfig, so it probably doesn't get a lot of coverage.

> And isn't it part of kernel.ci already?  We get the results of that for
> stable releases.
>

kernelci has lost its usefulness for me, since i have to wade through
pages and pages of mips and riscv results before i get to the meat.

> Anyway, thanks for the patch, now queued up.
>
> thanks,
>
> greg k-h


Re: gicv3-its driver crashes in crash dump kernel

2019-06-06 Thread Ard Biesheuvel
On Thu, 6 Jun 2019 at 16:32, Marc Zyngier  wrote:
>
> Hi Jonathan,
>
> On 05/06/2019 23:14, Jonathan Richardson wrote:
> > Hi,
> >
> > As of the 5.0 kernel we're seeing the crash dump kernel crash when the 
> > gicv3-its driver calls gic_reserve_range():
>
> [...]
>
> > On crash dump boot, gic calls the same function, 
> > efi_mem_reserve_persistent, finds the entry that was on initial boot 
> > (0xc3836000), converts it to a va, and then crashes when it's used on this 
> > line:
> > atomic_fetch_add_unless(>count
> >
> > In the previous revision of this file, kmalloc was called and this worked 
> > fine.
> >
> > [0.00] GICv3: GIC: Using split EOI/Deactivate mode
> > [0.00] GICv3: Distributor has no Range Selector support
> > [0.00] GICv3: no VLPI support, no direct LPI support
> > [0.00] GICv3: CPU0: found redistributor 1 region 
> > 0:0x63e2
> > [0.00] ITS [mem 0x63c2-0x63c2]
> > [0.00] ITS@0x63c2: allocated 32768 Devices @fd48 
> > (flat, esz 8, psz 64K, shr 0)
> > [0.00] ITS: using cache flushing for cmd queue
> > [0.00] iter: prsv = 0xc3836000
> > [0.00] rsv = 0x43836000
> > [0.00] Unable to handle kernel paging request at virtual address 
> > 80a343836004
> > [0.00] Mem abort info:
> > [0.00]   ESR = 0x9604
> > [0.00]   Exception class = DABT (current EL), IL = 32 bits
> >
> > int __ref efi_mem_reserve_persistent(phys_addr_t addr, u64 size)
> > {
> > 
> > for (prsv = efi_memreserve_root->next; prsv; prsv = rsv->next) {
> > printk("iter: prsv = 0x%x\n", prsv);
> > rsv = __va(prsv);
> > printk("rsv = 0x%x\n", rsv);
> > index = atomic_fetch_add_unless(>count, 1, rsv->size);
> > if (index < rsv->size) {
> > rsv->entry[index].base = addr;
> > rsv->entry[index].size = size;
> > 
> >
> > It looks like the change has broken crash dump kernel, but I'm not
> > sure what it should be doing instead. Has anyone used gicv3-its with
> > crash dump kernel after this change?
>
> I've definitely used kexec/kdump since, both in VMs and bare-metal.
> Other than __va() going horribly wrong, I have no idea.
>
> Ard, do you have any suggestion?
>

Not sure. It would be helpful to have the entire log, though.
including the normal kernel boot. I can take a look tomorrow.


Re: [PATCH for-4.9-stable] efi/libstub: Unify command line param parsing

2019-06-06 Thread Ard Biesheuvel
On Thu, 6 Jun 2019 at 15:22, Sasha Levin  wrote:
>
> On Thu, Jun 06, 2019 at 12:25:13PM +0200, Ard Biesheuvel wrote:
> >Commit 60f38de7a8d4e816100ceafd1b382df52527bd50 upstream.
> >
> >Merge the parsing of the command line carried out in arm-stub.c with
> >the handling in efi_parse_options(). Note that this also fixes the
> >missing handling of CONFIG_CMDLINE_FORCE=y, in which case the builtin
> >command line should supersede the one passed by the firmware.
> >
> >Signed-off-by: Ard Biesheuvel 
> >Cc: Linus Torvalds 
> >Cc: Matt Fleming 
> >Cc: Peter Zijlstra 
> >Cc: Thomas Gleixner 
> >Cc: b...@redhat.com
> >Cc: bhsha...@redhat.com
> >Cc: b...@alien8.de
> >Cc: eug...@hp.com
> >Cc: evgeny.kalu...@intel.com
> >Cc: jh...@codeaurora.org
> >Cc: leif.lindh...@linaro.org
> >Cc: linux-efi@vger.kernel.org
> >Cc: mark.rutl...@arm.com
> >Cc: roy.fr...@cavium.com
> >Cc: rruig...@codeaurora.org
> >Link: 
> >http://lkml.kernel.org/r/20170404160910.28115-1-ard.biesheu...@linaro.org
> >Signed-off-by: Ingo Molnar 
> >[ardb: fix up merge conflicts with 4.9.180]
> >Signed-off-by: Ard Biesheuvel 
> >---
> >This fixes the GCC build issue reported by Eike.
> >
> >Note that testing of arm64 stable kernels should cover CONFIG_RANDOMIZE_BASE,
> >since it has a profound impact on how the kernel binary gets put together.
>
> Should this fix be applied to 4.9 as well?
>
> I see it in 4.14+
>

I don't understand this question. The fix is proposed for v4.9 because
it fixes a build error with GCC that was caused by a backport of one
of the clang enablement patches.


  1   2   3   4   5   6   7   8   9   10   >