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

2019-08-19 Thread Matthew Garrett
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 
Acked-by: Ard Biesheuvel 
Reviewed-by: Kees Cook 
Cc: Ard Biesheuvel 
Cc: linux-efi@vger.kernel.org
Signed-off-by: James Morris 
---
 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 4b7cf7bc0ded..5f98374f77f4 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -241,6 +242,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.23.0.rc1.153.gdeed80330f-goog



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,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 

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

2019-08-19 Thread Chester Lin
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,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 at 0x0.
> > 
> > Perhaps