"Synchronous Exception at..." when booting arm64 kernel built with CONFIG_LTO_CLANG_THIN=y #1782

nathanchance · 2023-01-07T00:05:14Z

On my new Ampere Altra system, I cannot boot a CONFIG_LTO_CLANG_THIN=y kernel at next-20230106. My Honeycomb boots fine with LTO at the same revision.

Without LTO, I see

  Booting `Fedora Linux (6.2.0-rc2-next-20230106-no-lto) 37 (Server Edition)'

EFI stub: Booting Linux Kernel...
EFI stub: WARNING: Working around broken SetVirtualAddressMap()
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services...
PROGRESS CODE: V03101019 I0
[    0.000000] Booting Linux on physical CPU 0x0000120000 [0x413fd0c1]
[    0.000000] Linux version 6.2.0-rc2-next-20230106-no-lto (nathan@dev-arch.thelio-3990X) (ClangBuiltLinux clang version 16.0.0 (https://github.com/llvm/llvm-project d9899501576e7b3b8ec4a3f0f855a6bfe68cef88), LLD 16.0.0) #1 SMP PREEMPT_DYNAMIC Fri Jan  6 14:59:21 MST 2023
...

then normal kernel boot after that.

With CONFIG_LTO_CLANG_THIN=y (i.e, this is the diff between the two configurations):

diff --git a/config-good b/config-bad
index f15bfe5..a29fdfc 100644
--- a/config-good
+++ b/config-bad
@@ -781,12 +781,14 @@ CONFIG_HAVE_STACKPROTECTOR=y
 # CONFIG_STACKPROTECTOR is not set
 CONFIG_ARCH_SUPPORTS_SHADOW_CALL_STACK=y
 # CONFIG_SHADOW_CALL_STACK is not set
+CONFIG_LTO=y
+CONFIG_LTO_CLANG=y
 CONFIG_ARCH_SUPPORTS_LTO_CLANG=y
 CONFIG_ARCH_SUPPORTS_LTO_CLANG_THIN=y
 CONFIG_HAS_LTO_CLANG=y
-CONFIG_LTO_NONE=y
+# CONFIG_LTO_NONE is not set
 # CONFIG_LTO_CLANG_FULL is not set
-# CONFIG_LTO_CLANG_THIN is not set
+CONFIG_LTO_CLANG_THIN=y
 CONFIG_ARCH_SUPPORTS_CFI_CLANG=y
 # CONFIG_CFI_CLANG is not set
 CONFIG_HAVE_CONTEXT_TRACKING_USER=y

I only see

  Booting `Fedora Linux (6.2.0-rc2-next-20230106-lto) 37 (Server Edition)'

EFI stub: Booting Linux Kernel...
EFI stub: WARNING: Working around broken SetVirtualAddressMap()


Synchronous Exception at 0x00000000F7219888


Synchronous Exception at 0x00000000F7219888

so I assume something went wrong the firmware, if I understand the "Synchronous Exception" messages correctly?

This does not appear to be a recent regression on either the Linux or LLVM side, as I can reproduce this on Linux 5.15 (first revision with CONFIG_LTO_CLANG_THIN=y) with LLVM 14.0.6 (my distro LLVM version):

  Booting `Fedora Linux (5.15.0-lto) 37 (Server Edition)'

EFI stub: Booting Linux Kernel...


Synchronous Exception at 0x00000000F73674D4


Synchronous Exception at 0x00000000F73674D4

vs.

  Booting `Fedora Linux (5.15.0-no-lto) 37 (Server Edition)'

EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services...
PROGRESS CODE: V03101019 I0
[    0.000000] Booting Linux on physical CPU 0x0000120000 [0x413fd0c1]
[    0.000000] Linux version 5.15.0-no-lto (nathan@dev-arch.thelio-3990X) (clang version 14.0.6, LLD 14.0.6) #1 SMP Fri Jan 6 16:53:52 MST 2023

I am already hooked up to this machine via the serial console so I am not sure how to get any more information about why the machine is having issues booting. I could very well be holding something wrong.

cc @ardbiesheuvel and @samitolvanen, in case you have ever seen this.

The text was updated successfully, but these errors were encountered:

samitolvanen · 2023-01-07T00:24:10Z

Sorry, I don't remember seeing this before, but perhaps Ard has some ideas for debugging this? That's really cool hardware btw!

nathanchance · 2023-01-07T00:41:19Z

Sorry, I don't remember seeing this before, but perhaps Ard has some ideas for debugging this?

No worries, thanks for taking a look!

That's really cool hardware btw!

Thanks, I am quite excited to run it through its paces :) I just wasn't expecting to have any problems when I installed a kernel on it :P

ardbiesheuvel · 2023-01-07T08:54:44Z

Please grab this file, drop it in the ESP (/boot/efi/) and install it from the UEFI shell using

bcfg driver add 0 fs0:\ArmCrashDumpDxe.efi crashdump

Hopefully, we will get some better diagnostics. If we do, please try to cross-reference the backtrace with your kernel image so we know which firmware call faulted.

nathanchance · 2023-01-07T15:41:23Z

Okay, we get some more output!

EFI stub: Booting Linux Kernel...
EFI stub: WARNING: Working around broken SetVirtualAddressMap()


Synchronous Exception at 0x00000000F7209888
PC 0x0000F7209888
PC 0x0000F7209858
PC 0x0000F7203150
PC 0x0000F72020D8
PC 0x081FFFDCE690
PC 0x081FFFDCCB6C
PC 0x081FFFDCCC00
PC 0x081FFFFD7064
PC 0x081FFFFD76B8
PC 0x081FFFFD7784
PC 0x081FFFF51868
PC 0x081FFFF5251C
PC 0x081FFFF5373C
PC 0x081FFFF537A0
PC 0x081FFFF4BA04
PC 0x081FFFED4154
PC 0x081FFFF662C0
PC 0x081FFFF65AE4
PC 0x081FFFF6646C
PC 0x081FFFF65AE4
PC 0x081FFFF669A0
PC 0x081FFFF62838
PC 0x081FFFF4B5D8
PC 0x081FFFF4B960
PC 0x081FFFF4BAD8
PC 0x081FFFF4BD34
PC 0x081FFFF4BED4
PC 0x081FFFF4BF24
PC 0x0000F80FA3D8
PC 0x0000F80FAF38
PC 0x0000F80FB14C
PC 0x0000F880E288
PC 0x0000F880E338
PC 0x0000F880F1B4
PC 0x0000F880C030
PC 0x0000BFAF3D04 (0x0000BFAE0000+0x00013D04) [ 1] DxeCore.dll
PC 0x0000F943604C (0x0000F942C000+0x0000A04C) [ 2] BdsDxe.dll
PC 0x0000F943B58C (0x0000F942C000+0x0000F58C) [ 2] BdsDxe.dll
PC 0x0000BFAF5CA4 (0x0000BFAE0000+0x00015CA4) [ 3] DxeCore.dll
[ 1] /home/pxing/edk2_aadp_204_update/Build/ComHpcAlt/RELEASE_GCC5/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
[ 2] /home/pxing/edk2_aadp_204_update/Build/ComHpcAlt/RELEASE_GCC5/AARCH64/MdeModulePkg/Universal/BdsDxe/BdsDxe/DEBUG/BdsDxe.dll
[ 3] /home/pxing/edk2_aadp_204_update/Build/ComHpcAlt/RELEASE_GCC5/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll

  X0 0x0000000000000000   X1 0x00000000FFFD185B   X2 0x0000000000000004   X3 0xFFFFFFFFBFB0D7F1
  X4 0x00000000FFFD185F   X5 0x00000000BFADF050   X6 0x0000000000000022   X7 0x0000000000000022
  X8 0x00000000FFFD181F   X9 0x00000000FFFD181B  X10 0x42BE7455607F766C  X11 0x4943ECA2B7799CB0
 X12 0x00000000FFF40018  X13 0x0000000000000008  X14 0x0000000000000808  X15 0x00000000000001A8
 X16 0x0000000000000000  X17 0x0000000000000020  X18 0x000000000000D800  X19 0x00000000FFFD0000
 X20 0x0000080724FB0000  X21 0x00000000FFFD1817  X22 0x0000000000000001  X23 0x00000000FFFEF898
 X24 0x00000000F74BA000  X25 0x00000000F88A13B8  X26 0x00000000F88A13C0  X27 0x00000000F88A13C8
 X28 0x00000000F88A13D0   FP 0x00000000BFADF130   LR 0x00000000F7209858

  V0 0x0000000000000000 0000000000000008   V1 0x0000000000000000 0000000000000013
  V2 0x6D63202C003D6772 61202C00746C7561   V3 0x0000000000000000 0000000000000000
  V4 0x0000000000000000 0000000000000000   V5 0x4010040140100401 4010040140100401
  V6 0x0000000000000000 0000000000000000   V7 0x0000000000000000 0000000000000000
  V8 0x0000000000000000 00000000FFEF2018   V9 0x0000000000000000 00000000C0000000
 V10 0x0000000000000000 0000000000000000  V11 0x0000000000000000 0000000000000000
 V12 0x0000000000000000 0000000000000000  V13 0x0000000000000000 0000000000000000
 V14 0x0000000000000000 0000000000000000  V15 0x0000000000000000 0000000000000000
 V16 0x0000000000000000 0000000000000000  V17 0x0000000000000000 0000000000000000
 V18 0x0000000000000000 0000000000000000  V19 0x0000000000000000 0000000000000000
 V20 0x0000000000000000 0000000000000000  V21 0x0000000000000000 0000000000000000
 V22 0x0000000000000000 0000000000000000  V23 0x0000000000000000 0000000000000000
 V24 0x0000000000000000 0000000000000000  V25 0x0000000000000000 0000000000000000
 V26 0x0000000000000000 0000000000000000  V27 0x0000000000000000 0000000000000000
 V28 0x0000000000000000 0000000000000000  V29 0x0000000000000000 0000000000000000
 V30 0x0000000000000000 0000000000000000  V31 0x0000000000000000 0000000000000000

  SP 0x00000000BFADF0A0  ELR 0x00000000F7209888  SPSR 0x20000309  FPSR 0x00000010
 ESR 0x96000021          FAR 0x00000000FFFD181F

 ESR : EC 0x25  IL 0x1  ISS 0x00000021

Data abort: Alignment fault

Stack dump:
  00000BFADEFA0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
  00000BFADEFC0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
  00000BFADEFE0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
  00000BFADF000: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
  00000BFADF020: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
  00000BFADF040: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
  00000BFADF060: 0000000000000000 0000000000000000 00000000FAAF140C 0000000000000308
  00000BFADF080: 0000000000000010 0000000096000021 00000000FFFD181F 00000002FA069E98
> 00000BFADF0A0: 800000000000000E 00000000BFADF0DC 00000000BFADF130 00000000F7204BD4
  00000BFADF0C0: 4DC13F279000469A 00000000F74BA000 00000000FA028240 0000000000000000
  00000BFADF0E0: 0000000000000000 00000000FFFD1817 00000000FFFD0000 4943ECA2B7799CB0
  00000BFADF100: FA47B707AE1F6796 42BE7455607F766C 0F72B26DD7E40B93 0000000000000000
  00000BFADF120: 0000000000000000 0000000000000000 00000000BFADF1B0 00000000F7203150
  00000BFADF140: 00000000F88A13D0 00000000F88A13C8 00000000F88A13C0 00000000F88A13B8
  00000BFADF160: 00000000F74BA000 00000000FFFEF898 00000000F92D7B18 00000000F92D7140
  00000BFADF180: 0000080724FB0000 00000000F89DA098 0A89C1488697BBB6 4A3823DC9042A9DE
ASSERT [ArmCrashDumpDxe] /home/ard/build/edk2/ArmPkg/Library/DefaultExceptionHandlerLib/AArch64/DefaultExceptionHandler.c(333): ((BOOLEAN)(0==1))

Is that useful? I do not see any information about what firmware call caused this but I could be missing something

ardbiesheuvel · 2023-01-07T16:32:26Z

Worth rebuilding your kernel with CONFIG_DEBUG_EFI, that should give you a better view on where vmlinux lives in the EFI mapping, although I'm pretty sure 0x081FFFF4BF24 coincides with efi_pe_entry()

So it looks like the EFI stub is calling into another binary, which does not have the filename metadata either, so I wonder if this is GRUB. If so, which version are you using? Another thing to try is booting with noinitrd, just to eliminate it from the set of potential culprits.

ardbiesheuvel · 2023-01-07T17:07:57Z

Actually, if you are booting using shim as well as GRUB, 0x081FFFF4BF24 would coincide with GRUB's entrypoint, and the exception occurs in the EFI stub, which is much more likely come to think of it. In that case, efi_pe_entry() should coincide with 0x0000F72020D8, and you can work your way back from there.

nathanchance · 2023-01-07T20:03:21Z

I went ahead and built with CONFIG_DEBUG_EFI but it does not change anything about the output that I get, is that expected?

Here is my grub information but it does not sound like that will be too relevant now.

$ dnf list --installed | rg grub2
grub2-common.noarch                                1:2.06-72.fc37                      @updates
grub2-efi-aa64.aarch64                             1:2.06-72.fc37                      @updates
grub2-tools.aarch64                                1:2.06-72.fc37                      @updates
grub2-tools-minimal.aarch64                        1:2.06-72.fc37                      @updates

... you can work your way back from there

How exactly do I go about doing that? Apologies, I am rather out of my element here :) I tried looking through vmlinux and System.map but those addresses don't seem to be there, although I suppose that is expected with KASLR, which appears to have run at this point? Should I be booting with nokaslr?

ardbiesheuvel · 2023-01-07T21:47:09Z

I went ahead and built with CONFIG_DEBUG_EFI but it does not change anything about the output that I get, is that expected?

Shame. I was hoping it would help us pin down which of these address ranges represent the kernel.

How exactly do I go about doing that? Apologies, I am rather out of my element here :) I tried looking through vmlinux and System.map but those addresses don't seem to be there, although I suppose that is expected with KASLR, which appears to have run at this point? Should I be booting with nokaslr?

Boot with nokaslr and find the entry that corresponds with efi_pe_entry modulo 2 MiB? (I.e. have the same 5 trailing hex digits)

ardbiesheuvel · 2023-01-08T22:47:18Z

I went ahead and built with CONFIG_DEBUG_EFI but it does not change anything about the output that I get, is that expected?

Shame. I was hoping it would help us pin down which of these address ranges represent the kernel.

How exactly do I go about doing that? Apologies, I am rather out of my element here :) I tried looking through vmlinux and System.map but those addresses don't seem to be there, although I suppose that is expected with KASLR, which appears to have run at this point? Should I be booting with nokaslr?

Boot with nokaslr and find the entry that corresponds with efi_pe_entry modulo 2 MiB? (I.e. have the same 5 trailing hex digits)

Another thing to try is booting the kernel (built with CONFIG_DEBUG_EFI) straight from the UEFI Shell. You will have to gunzip it first, but you can just run it as Image (or fs0:\Image), and pass arguments on the kernel command line. efi=debug will give you a dump of the EFI memory map in the kernel log, which may help us narrow down the nature of the faulting address (FAR in the crash dump)

A misalignment fault is unusual, given that unaligned accesses are permitted on normal memory, and so the faulting address in question is likely something else, such as peripheral MMIO address.

nathanchance · 2023-01-09T00:32:55Z

I was going to double check all of my debugging tomorrow morning, just to make sure this is actually related to LTO, but I got some time just now to try your suggestion of just booting Image directly. Unfortunately, it seems to make it out of the boot services without the issue (i.e., I see EFI stub: Exiting boot services...), so I guess that might tell us that grub is messing something up? I do not see anything else but I think that is just because I have not set up my initramfs correctly or something.

I had some time yesterday to just do some rudimentary efi_info() debugging and it seems like (again, going to double check tomorrow when I have more time) there is something going wrong in this block of code based on this patch, which makes me think that something could be up with the TPM?

https://github.com/torvalds/linux/blob/1fe4fd6f5cad346e598593af36caeadc4f5d4fa9/drivers/firmware/efi/libstub/tpm.c#L92-L113

diff --git a/drivers/firmware/efi/libstub/tpm.c b/drivers/firmware/efi/libstub/tpm.c
index 5c096a96b385..5a50b97b7444 100644
--- a/drivers/firmware/efi/libstub/tpm.c
+++ b/drivers/firmware/efi/libstub/tpm.c
@@ -88,6 +88,8 @@ void efi_retrieve_tpm2_eventlog(void)

        first_entry_addr = (unsigned long) log_location;

+       efi_info("efi_retrieve_tpm2_eventlog(): passed first_entry_addr assignment\n");
+
        /*
         * We populate the EFI table even if the logs are empty.
         */
@@ -95,6 +97,9 @@ void efi_retrieve_tpm2_eventlog(void)
                log_size = 0;
        } else {
                last_entry_addr = (unsigned long) log_last_entry;
+
+               efi_info("efi_retrieve_tpm2_eventlog(): passed last_entry_addr assignment\n");
+
                /*
                 * get_event_log only returns the address of the last entry.
                 * We need to calculate its size to deduce the full size of
@@ -117,9 +122,14 @@ void efi_retrieve_tpm2_eventlog(void)
                        last_entry_size = sizeof(struct tcpa_event) +
                           ((struct tcpa_event *) last_entry_addr)->event_size;
                }
+
+               efi_info("efi_retrieve_tpm2_eventlog(): passed last_entry_size assignment\n");
+
                log_size = log_last_entry - log_location + last_entry_size;
        }

+       efi_info("efi_retrieve_tpm2_eventlog(): passed log_size assignment\n");
+
        /* Allocate space for the logs and copy them. */
        status = efi_bs_call(allocate_pool, EFI_LOADER_DATA,
                             sizeof(*log_tbl) + log_size, (void **)&log_tbl);

  Booting `Fedora Linux (6.2.0-rc2-lto-00285-g5710b4c27bec) 37 (Server Edition)'

EFI stub: Booting Linux Kernel...
EFI stub: WARNING: Working around broken SetVirtualAddressMap()
EFI stub: passed check_platform_features()
EFI stub: passed setup_graphics()
EFI stub: efi_retrieve_tpm2_eventlog(): passed locate_protocol
EFI stub: efi_retrieve_tpm2_eventlog(): passed tcg2_protocol with EFI_TCG2_EVENT_LOG_FORMAT_TCG_2
EFI stub: efi_retrieve_tpm2_eventlog(): passed first_entry_addr assignment
EFI stub: efi_retrieve_tpm2_eventlog(): passed last_entry_addr assignment


Synchronous Exception at 0x00000000F7129964

Does that at all sound plausible? I still have no idea what it actually going wrong but I was just curious if that makes any sense so far.

ardbiesheuvel · 2023-01-09T09:17:29Z

I managed to reproduce this on QEMU - it turns out that READ_ONCE() gets upgraded to LDAR on arm64 when LTO is in effect, and the TPM code uses READ_ONCE() to access firmware tables where some fields may appear misaligned. Given that LDAR supports aligned accesses only, an exception is triggered resulting in the crash.

The code in question lives in __calc_tpm2_event_size(), which gets included by the EFI stub as well as the kernel proper, which is why it uses READ_ONCE() in the first place (the EFI stub generally doesn't need to handle concurrency explicitly)

ardbiesheuvel · 2023-01-09T10:16:42Z

Fix sent to the list

https://lore.kernel.org/linux-efi/20230109095948.2471205-1-ardb@kernel.org/T/#u

nathanchance · 2023-01-09T18:17:42Z

Now in the EFI tree: https://git.kernel.org/efi/efi/c/7b817a99509125ee1337888ec453a76ce5937ae8

Nathan reports that recent kernels built with LTO will crash when doing EFI boot using Fedora's GRUB and SHIM. The culprit turns out to be a misaligned load from the TPM event log, which is annotated with READ_ONCE(), and under LTO, this gets translated into a LDAR instruction which does not tolerate misaligned accesses. Interestingly, this does not happen when booting the same kernel straight from the UEFI shell, and so the fact that the event log may appear misaligned in memory may be caused by a bug in GRUB or SHIM. However, using READ_ONCE() to access firmware tables is slightly unusual in any case, and here, we only need to ensure that 'event' is not dereferenced again after it gets unmapped, but this is already taken care of by the implicit barrier() semantics of the early_memunmap() call. Cc: <stable@vger.kernel.org> Cc: Peter Jones <pjones@redhat.com> Cc: Jarkko Sakkinen <jarkko@kernel.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Reported-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Link: ClangBuiltLinux#1782 Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

nathanchance · 2023-01-14T05:37:00Z

Now in mainline: https://git.kernel.org/linus/d3f450533bbcb6dd4d7d59cadc9b61b7321e4ac1

commit d3f4505 upstream. Nathan reports that recent kernels built with LTO will crash when doing EFI boot using Fedora's GRUB and SHIM. The culprit turns out to be a misaligned load from the TPM event log, which is annotated with READ_ONCE(), and under LTO, this gets translated into a LDAR instruction which does not tolerate misaligned accesses. Interestingly, this does not happen when booting the same kernel straight from the UEFI shell, and so the fact that the event log may appear misaligned in memory may be caused by a bug in GRUB or SHIM. However, using READ_ONCE() to access firmware tables is slightly unusual in any case, and here, we only need to ensure that 'event' is not dereferenced again after it gets unmapped, but this is already taken care of by the implicit barrier() semantics of the early_memunmap() call. Cc: <stable@vger.kernel.org> Cc: Peter Jones <pjones@redhat.com> Cc: Jarkko Sakkinen <jarkko@kernel.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Reported-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Link: ClangBuiltLinux/linux#1782 Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d3f4505 upstream. Nathan reports that recent kernels built with LTO will crash when doing EFI boot using Fedora's GRUB and SHIM. The culprit turns out to be a misaligned load from the TPM event log, which is annotated with READ_ONCE(), and under LTO, this gets translated into a LDAR instruction which does not tolerate misaligned accesses. Interestingly, this does not happen when booting the same kernel straight from the UEFI shell, and so the fact that the event log may appear misaligned in memory may be caused by a bug in GRUB or SHIM. However, using READ_ONCE() to access firmware tables is slightly unusual in any case, and here, we only need to ensure that 'event' is not dereferenced again after it gets unmapped, but this is already taken care of by the implicit barrier() semantics of the early_memunmap() call. Cc: <stable@vger.kernel.org> Cc: Peter Jones <pjones@redhat.com> Cc: Jarkko Sakkinen <jarkko@kernel.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Reported-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Link: ClangBuiltLinux#1782 Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d3f4505 upstream. Nathan reports that recent kernels built with LTO will crash when doing EFI boot using Fedora's GRUB and SHIM. The culprit turns out to be a misaligned load from the TPM event log, which is annotated with READ_ONCE(), and under LTO, this gets translated into a LDAR instruction which does not tolerate misaligned accesses. Interestingly, this does not happen when booting the same kernel straight from the UEFI shell, and so the fact that the event log may appear misaligned in memory may be caused by a bug in GRUB or SHIM. However, using READ_ONCE() to access firmware tables is slightly unusual in any case, and here, we only need to ensure that 'event' is not dereferenced again after it gets unmapped, but this is already taken care of by the implicit barrier() semantics of the early_memunmap() call. Cc: <stable@vger.kernel.org> Cc: Peter Jones <pjones@redhat.com> Cc: Jarkko Sakkinen <jarkko@kernel.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Reported-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Link: ClangBuiltLinux/linux#1782 Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d3f4505 upstream. Nathan reports that recent kernels built with LTO will crash when doing EFI boot using Fedora's GRUB and SHIM. The culprit turns out to be a misaligned load from the TPM event log, which is annotated with READ_ONCE(), and under LTO, this gets translated into a LDAR instruction which does not tolerate misaligned accesses. Interestingly, this does not happen when booting the same kernel straight from the UEFI shell, and so the fact that the event log may appear misaligned in memory may be caused by a bug in GRUB or SHIM. However, using READ_ONCE() to access firmware tables is slightly unusual in any case, and here, we only need to ensure that 'event' is not dereferenced again after it gets unmapped, but this is already taken care of by the implicit barrier() semantics of the early_memunmap() call. Cc: <stable@vger.kernel.org> Cc: Peter Jones <pjones@redhat.com> Cc: Jarkko Sakkinen <jarkko@kernel.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Reported-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Link: ClangBuiltLinux/linux#1782 Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 24176bf2a1452d58b8677982a8b3a72f01d3e8ad) Signed-off-by: Jack Vogel <jack.vogel@oracle.com>

commit d3f4505 upstream. Nathan reports that recent kernels built with LTO will crash when doing EFI boot using Fedora's GRUB and SHIM. The culprit turns out to be a misaligned load from the TPM event log, which is annotated with READ_ONCE(), and under LTO, this gets translated into a LDAR instruction which does not tolerate misaligned accesses. Interestingly, this does not happen when booting the same kernel straight from the UEFI shell, and so the fact that the event log may appear misaligned in memory may be caused by a bug in GRUB or SHIM. However, using READ_ONCE() to access firmware tables is slightly unusual in any case, and here, we only need to ensure that 'event' is not dereferenced again after it gets unmapped, but this is already taken care of by the implicit barrier() semantics of the early_memunmap() call. Cc: <stable@vger.kernel.org> Cc: Peter Jones <pjones@redhat.com> Cc: Jarkko Sakkinen <jarkko@kernel.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Reported-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Link: ClangBuiltLinux/linux#1782 Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 3ed183074c20ca47d123d20aadf17331c59b15be) Signed-off-by: Sherry Yang <sherry.yang@oracle.com>

Source: Kernel.org MR: 125008 Type: Integration Disposition: Backport from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable linux-5.10.y ChangeID: 38c4a17c6b32f7c6679b30de390c466c7367fe6b Description: commit d3f4505 upstream. Nathan reports that recent kernels built with LTO will crash when doing EFI boot using Fedora's GRUB and SHIM. The culprit turns out to be a misaligned load from the TPM event log, which is annotated with READ_ONCE(), and under LTO, this gets translated into a LDAR instruction which does not tolerate misaligned accesses. Interestingly, this does not happen when booting the same kernel straight from the UEFI shell, and so the fact that the event log may appear misaligned in memory may be caused by a bug in GRUB or SHIM. However, using READ_ONCE() to access firmware tables is slightly unusual in any case, and here, we only need to ensure that 'event' is not dereferenced again after it gets unmapped, but this is already taken care of by the implicit barrier() semantics of the early_memunmap() call. Cc: <stable@vger.kernel.org> Cc: Peter Jones <pjones@redhat.com> Cc: Jarkko Sakkinen <jarkko@kernel.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Reported-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Link: ClangBuiltLinux/linux#1782 Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster@mvista.com>

Source: Kernel.org MR: 125058 Type: Integration Disposition: Backport from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable linux-5.4.y ChangeID: 3ed183074c20ca47d123d20aadf17331c59b15be Description: commit d3f4505 upstream. Nathan reports that recent kernels built with LTO will crash when doing EFI boot using Fedora's GRUB and SHIM. The culprit turns out to be a misaligned load from the TPM event log, which is annotated with READ_ONCE(), and under LTO, this gets translated into a LDAR instruction which does not tolerate misaligned accesses. Interestingly, this does not happen when booting the same kernel straight from the UEFI shell, and so the fact that the event log may appear misaligned in memory may be caused by a bug in GRUB or SHIM. However, using READ_ONCE() to access firmware tables is slightly unusual in any case, and here, we only need to ensure that 'event' is not dereferenced again after it gets unmapped, but this is already taken care of by the implicit barrier() semantics of the early_memunmap() call. Cc: <stable@vger.kernel.org> Cc: Peter Jones <pjones@redhat.com> Cc: Jarkko Sakkinen <jarkko@kernel.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Reported-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Link: ClangBuiltLinux/linux#1782 Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster@mvista.com>

BugLink: https://bugs.launchpad.net/bugs/2003914 commit d3f450533bbcb6dd4d7d59cadc9b61b7321e4ac1 upstream. Nathan reports that recent kernels built with LTO will crash when doing EFI boot using Fedora's GRUB and SHIM. The culprit turns out to be a misaligned load from the TPM event log, which is annotated with READ_ONCE(), and under LTO, this gets translated into a LDAR instruction which does not tolerate misaligned accesses. Interestingly, this does not happen when booting the same kernel straight from the UEFI shell, and so the fact that the event log may appear misaligned in memory may be caused by a bug in GRUB or SHIM. However, using READ_ONCE() to access firmware tables is slightly unusual in any case, and here, we only need to ensure that 'event' is not dereferenced again after it gets unmapped, but this is already taken care of by the implicit barrier() semantics of the early_memunmap() call. Cc: <stable@vger.kernel.org> Cc: Peter Jones <pjones@redhat.com> Cc: Jarkko Sakkinen <jarkko@kernel.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Reported-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Link: ClangBuiltLinux/linux#1782 Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/2008929 commit d3f4505 upstream. Nathan reports that recent kernels built with LTO will crash when doing EFI boot using Fedora's GRUB and SHIM. The culprit turns out to be a misaligned load from the TPM event log, which is annotated with READ_ONCE(), and under LTO, this gets translated into a LDAR instruction which does not tolerate misaligned accesses. Interestingly, this does not happen when booting the same kernel straight from the UEFI shell, and so the fact that the event log may appear misaligned in memory may be caused by a bug in GRUB or SHIM. However, using READ_ONCE() to access firmware tables is slightly unusual in any case, and here, we only need to ensure that 'event' is not dereferenced again after it gets unmapped, but this is already taken care of by the implicit barrier() semantics of the early_memunmap() call. Cc: <stable@vger.kernel.org> Cc: Peter Jones <pjones@redhat.com> Cc: Jarkko Sakkinen <jarkko@kernel.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Reported-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Link: ClangBuiltLinux/linux#1782 Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

commit d3f450533bbcb6dd4d7d59cadc9b61b7321e4ac1 upstream. Nathan reports that recent kernels built with LTO will crash when doing EFI boot using Fedora's GRUB and SHIM. The culprit turns out to be a misaligned load from the TPM event log, which is annotated with READ_ONCE(), and under LTO, this gets translated into a LDAR instruction which does not tolerate misaligned accesses. Interestingly, this does not happen when booting the same kernel straight from the UEFI shell, and so the fact that the event log may appear misaligned in memory may be caused by a bug in GRUB or SHIM. However, using READ_ONCE() to access firmware tables is slightly unusual in any case, and here, we only need to ensure that 'event' is not dereferenced again after it gets unmapped, but this is already taken care of by the implicit barrier() semantics of the early_memunmap() call. Cc: <stable@vger.kernel.org> Cc: Peter Jones <pjones@redhat.com> Cc: Jarkko Sakkinen <jarkko@kernel.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Reported-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Link: ClangBuiltLinux/linux#1782 Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

stable inclusion from stable-v5.10.164 commit 38c4a17c6b32f7c6679b30de390c466c7367fe6b category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7T7G4 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=38c4a17c6b32f7c6679b30de390c466c7367fe6b -------------------------------- commit d3f4505 upstream. Nathan reports that recent kernels built with LTO will crash when doing EFI boot using Fedora's GRUB and SHIM. The culprit turns out to be a misaligned load from the TPM event log, which is annotated with READ_ONCE(), and under LTO, this gets translated into a LDAR instruction which does not tolerate misaligned accesses. Interestingly, this does not happen when booting the same kernel straight from the UEFI shell, and so the fact that the event log may appear misaligned in memory may be caused by a bug in GRUB or SHIM. However, using READ_ONCE() to access firmware tables is slightly unusual in any case, and here, we only need to ensure that 'event' is not dereferenced again after it gets unmapped, but this is already taken care of by the implicit barrier() semantics of the early_memunmap() call. Cc: <stable@vger.kernel.org> Cc: Peter Jones <pjones@redhat.com> Cc: Jarkko Sakkinen <jarkko@kernel.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Reported-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Link: ClangBuiltLinux/linux#1782 Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: sanglipeng <sanglipeng1@jd.com>

stable inclusion from stable-v5.10.164 commit 38c4a17c6b32f7c6679b30de390c466c7367fe6b category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7T7G4 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=38c4a17c6b32f7c6679b30de390c466c7367fe6b -------------------------------- commit d3f4505 upstream. Nathan reports that recent kernels built with LTO will crash when doing EFI boot using Fedora's GRUB and SHIM. The culprit turns out to be a misaligned load from the TPM event log, which is annotated with READ_ONCE(), and under LTO, this gets translated into a LDAR instruction which does not tolerate misaligned accesses. Interestingly, this does not happen when booting the same kernel straight from the UEFI shell, and so the fact that the event log may appear misaligned in memory may be caused by a bug in GRUB or SHIM. However, using READ_ONCE() to access firmware tables is slightly unusual in any case, and here, we only need to ensure that 'event' is not dereferenced again after it gets unmapped, but this is already taken care of by the implicit barrier() semantics of the early_memunmap() call. Cc: <stable@vger.kernel.org> Cc: Peter Jones <pjones@redhat.com> Cc: Jarkko Sakkinen <jarkko@kernel.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Reported-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Link: ClangBuiltLinux/linux#1782 Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: sanglipeng <sanglipeng1@jd.com> (cherry picked from commit 7af99be)

nathanchance added [BUG] Untriaged Something isn't working [ARCH] arm64 This bug impacts ARCH=arm64 [FEATURE] LTO Related to building the kernel with LLVM Link Time Optimization labels Jan 7, 2023

nathanchance added [PATCH] Accepted A submitted patch has been accepted upstream and removed [BUG] Untriaged Something isn't working labels Jan 9, 2023

nathanchance added the [BUG] linux A bug that should be fixed in the mainline kernel. label Jan 11, 2023

nathanchance closed this as completed Jan 14, 2023

nathanchance added [FIXED][LINUX] 6.2 This bug was fixed in Linux 6.2 and removed [PATCH] Accepted A submitted patch has been accepted upstream labels Jan 14, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

"Synchronous Exception at..." when booting arm64 kernel built with CONFIG_LTO_CLANG_THIN=y #1782

"Synchronous Exception at..." when booting arm64 kernel built with CONFIG_LTO_CLANG_THIN=y #1782

nathanchance commented Jan 7, 2023

samitolvanen commented Jan 7, 2023

nathanchance commented Jan 7, 2023

ardbiesheuvel commented Jan 7, 2023 •

edited

Loading

nathanchance commented Jan 7, 2023

ardbiesheuvel commented Jan 7, 2023

ardbiesheuvel commented Jan 7, 2023

nathanchance commented Jan 7, 2023

ardbiesheuvel commented Jan 7, 2023

ardbiesheuvel commented Jan 8, 2023

nathanchance commented Jan 9, 2023

ardbiesheuvel commented Jan 9, 2023 •

edited

Loading

ardbiesheuvel commented Jan 9, 2023

nathanchance commented Jan 9, 2023

nathanchance commented Jan 14, 2023

"Synchronous Exception at..." when booting arm64 kernel built with CONFIG_LTO_CLANG_THIN=y #1782

"Synchronous Exception at..." when booting arm64 kernel built with CONFIG_LTO_CLANG_THIN=y #1782

Comments

nathanchance commented Jan 7, 2023

samitolvanen commented Jan 7, 2023

nathanchance commented Jan 7, 2023

ardbiesheuvel commented Jan 7, 2023 • edited Loading

nathanchance commented Jan 7, 2023

ardbiesheuvel commented Jan 7, 2023

ardbiesheuvel commented Jan 7, 2023

nathanchance commented Jan 7, 2023

ardbiesheuvel commented Jan 7, 2023

ardbiesheuvel commented Jan 8, 2023

nathanchance commented Jan 9, 2023

ardbiesheuvel commented Jan 9, 2023 • edited Loading

ardbiesheuvel commented Jan 9, 2023

nathanchance commented Jan 9, 2023

nathanchance commented Jan 14, 2023

ardbiesheuvel commented Jan 7, 2023 •

edited

Loading

ardbiesheuvel commented Jan 9, 2023 •

edited

Loading