gicv3-its driver crashes in crash dump kernel
Hi, As of the 5.0 kernel we're seeing the crash dump kernel crash when the gicv3-its driver calls gic_reserve_range(): root@bcm958804a8040c:~# echo c > /proc/sysrq-trigger [ 2285.405357] sysrq: SysRq : Trigger a crash [ 2285.409592] Kernel panic - not syncing: sysrq triggered crash [ 2285.415521] CPU: 0 PID: 4064 Comm: sh Kdump: loaded Tainted: G O 5.0.0 #1 [ 2285.423867] Hardware name: BRCM BRCM-SR/BRCM-SR, BIOS 0.1 Apr 26 2019 [ 2285.430510] Call trace: [ 2285.433041] dump_backtrace+0x0/0x1a0 [ 2285.436818] show_stack+0x14/0x20 [ 2285.440237] dump_stack+0x90/0xb4 [ 2285.443657] panic+0x13c/0x2ec [ 2285.446807] sysrq_handle_crash+0x14/0x18 [ 2285.450942] __handle_sysrq+0xa4/0x190 [ 2285.454808] write_sysrq_trigger+0x64/0x80 [ 2285.459034] proc_reg_write+0x60/0xa8 [ 2285.462812] __vfs_write+0x30/0x180 [ 2285.466409] vfs_write+0xa4/0x1b8 [ 2285.469827] ksys_write+0x60/0xd8 [ 2285.473246] __arm64_sys_write+0x14/0x20 [ 2285.477292] el0_svc_common+0x60/0x100 [ 2285.481158] el0_svc_handler+0x2c/0x88 [ 2285.485025] el0_svc+0x8/0xc [ 2285.488001] SMP: stopping secondary CPUs [ 2285.492349] Starting crashdump kernel... [ 2285.496395] Bye! [ 0.00] Booting Linux on physical CPU 0x00 [0x410fd083] [ 0.00] Linux version 5.0.0 (oe-user@oe-host) (gcc version 7.3.0 (GCC)) #1 SMP Fri Apr 26 03:06:15 UTC9 [ 0.00] Machine model: Stingray PS1100R (BCM958804A8040) [ 0.00] earlycon: uart8250_log0 at MMIO32 0x68a1 (options '') [ 0.00] printk: bootconsole [uart8250_log0] enabled [ 0.00] Malformed early option 'loglevel' [ 0.00] efi: Getting EFI parameters from FDT: [ 0.00] efi: EFI v2.70 by EDK II [ 0.00] efi: SMBIOS=0x85cd SMBIOS 3.0=0x85a2 ACPI 2.0=0x85d9 MEMATTR=0x89352018 MEMRE [ 0.00] cannot allocate crashkernel (size:0x2000) [ 0.00] Reserving 2KB of memory at 0xffdff000 for elfcorehdr [ 0.00] cma: Failed to reserve 1024 MiB [ 0.00] psci: probing for conduit method from DT. I: GICv3 without legacy support detected. ARM GICV3 driver initialized in EL3 0.00] psci: PSCIv1.1 detected in firmware. [ 0.00] psci: Using standard PSCI v0.2 function IDs [ 0.00] psci: MIGRATE_INFO_TYPE not supported. [ 0.00] psci: SMC Calling Convention v1.1 [ 0.00] random: get_random_bytes called from start_kernel+0xa8/0x3ec with crng_init=0 [ 0.00] percpu: Embedded 23 pages/cpu @(ptrval) s53784 r8192 d32232 u94208 [ 0.00] Detected PIPT I-cache on CPU0 [ 0.00] CPU features: detected: EL2 vector hardening [ 0.00] Speculative Store Bypass Disable mitigation not required [ 0.00] Built 1 zonelists, mobility grouping on. Total pages: 130974 [ 0.00] Kernel command line: FS2:\Image.1 root=/dev/mmcblk0p3 rw rootwait earlycon=uart8250_log,mmio1 [ 0.00] Dentry cache hash table entries: 65536 (order: 7, 524288 bytes) [ 0.00] Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) [ 0.00] Memory: 472776K/532212K available (9340K kernel code, 734K rwdata, 3412K rodata, 832K init, 35) [ 0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1 [ 0.00] rcu: Hierarchical RCU implementation. [ 0.00] rcu: RCU event tracing is enabled. [ 0.00] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies. [ 0.00] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0 [ 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 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:
Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')
On Wed, Jun 5, 2019 at 11:42 AM Ard Biesheuvel wrote: > For the record, this is an example of why I think backporting those > clang enablement patches is a bad idea. There's always a risk involved with backports of any kind; more CI coverage can help us mitigate some of these risks in an automated fashion before we get user reports like this. I meet with the KernelCI folks weekly, so I'll double check on the coverage of the stable tree's branches. The 0day folks are also very responsive and I've spoken with them a few times, so I'll try to get to the bottom of why this wasn't reported by either of those. Also, these patches help keep Android, CrOS, and Google internal production kernels closer to their upstream sources. > We can't actually build those > kernels with clang, can we? So what is the point? Here's last night's build: https://travis-ci.com/ClangBuiltLinux/continuous-integration/builds/114388434 Also, Android and CrOS have shipped X million devices w/ 4.9 kernels built with Clang. I think this number will grow at least one order of magnitude imminently. > Alternatively, we can just revert this patch from 4.9 That would break at least the above devices next time Android and CrOS pulled from stable. > It would be helpful to get a relocation dump (objdump -r) of > arm64-stub.o to figure out which symbol needs a 'hidden' annotation to > prevent GCC from emitting it as a PIC reference requiring a GOT. Sounds like the best way forward, as well as having more info on which config/toolchain reliably reproduces the issue. -- Thanks, ~Nick Desaulniers
Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')
On Wed, Jun 05, 2019 at 08:42:32PM +0200, Ard Biesheuvel wrote: > On Wed, 5 Jun 2019 at 18:26, Greg KH wrote: > > > > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > > > I decided to dig out a toy project which uses a DragonBoard 410c. This has > > > been "running" with kernel 4.9, which I would keep this way for unrelated > > > reasons. The vanilla 4.9 kernel wasn't bootable back then, but it was > > > buildable, which was good enough. > > > > > > Upgrading the kernel to 4.9.180 caused the boot to suddenly fail: > > > > > > aarch64-unknown-linux-gnueabi-ld: > > > ./drivers/firmware/efi/libstub/lib.a(arm64- > > > stub.stub.o): in function `handle_kernel_image': > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63: > > > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_' > > > aarch64-unknown-linux-gnueabi-ld: > > > ./drivers/firmware/efi/libstub/lib.a(arm64- > > > stub.stub.o): relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol > > > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can not be > > > used > > > when making a shared object; recompile with -fPIC > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63: > > > (.init.text+0xc): dangerous relocation: unsupported relocation > > > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target 'vmlinux' > > > failed > > > -make[1]: *** [vmlinux] Error 1 > > > > > > This is caused by commit 27b5ebf61818749b3568354c64a8ec2d9cd5ecca from > > > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be), reverting > > > this commit fixes the build. > > > > > > This happens with vanilla binutils 2.32 and gcc 8.3.0 as well as 9.1.0. > > > See > > > the attached .config for reference. > > > > > > If you have questions or patches just ping me. > > > > Does Linus's latest tree also fail for you (or 5.1)? > > > > Nick, do we need to add another fix that is in mainline for this to work > > properly? > > > > For the record, this is an example of why I think backporting those > clang enablement patches is a bad idea. We can't actually build those > kernels with clang, can we? So what is the point? Yes "we" can. I do. Why can't you? And lots of devices rely on clang support for their kernels, as much as I would like to ignore them, I can't :( thanks, greg k-h
Re: [PATCH v2 4/8] x86, efi: Reserve UEFI 2.8 Specific Purpose Memory for dax
On Sun, Jun 2, 2019 at 10:42 PM Mike Rapoport wrote:
>
> Hi Dan,
>
> On Thu, May 30, 2019 at 03:59:43PM -0700, 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.
> >
> > - 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.
>
> I'd appreciate a more elaborate description how this flag is going to be
> used.
This flag is only there to communicate to the numa code what ranges of
"conventional memory" should be skipped for onlining and reserved for
device-dax to consume. However, now that I say that out loud I realize
I might be able to get away with just using a plain entry
memblock.reserved. I'll take a look.
>
> > 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: Thomas Gleixner
> > Cc: Ard Biesheuvel
> > Reported-by: kbuild test robot
> > Signed-off-by: Dan Williams
> > ---
> > arch/x86/Kconfig | 20
> > arch/x86/boot/compressed/eboot.c |5 -
> > arch/x86/boot/compressed/kaslr.c |2 +-
> > arch/x86/include/asm/e820/types.h |9 +
> > arch/x86/kernel/e820.c|9 +++--
> > arch/x86/kernel/setup.c |1 +
> > arch/x86/platform/efi/efi.c | 37
> > +
> > drivers/acpi/numa.c | 15 ++-
> > include/linux/efi.h | 14 ++
> > include/linux/ioport.h|1 +
> > include/linux/memblock.h |7 +++
> > mm/memblock.c |4
> > 12 files changed, 115 insertions(+), 9 deletions(-)
>
> ...
>
> > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> > index 08a5f4a131f5..ddde1c7b1f9a 100644
> > --- a/arch/x86/kernel/setup.c
> > +++ b/arch/x86/kernel/setup.c
> > @@ -1109,6 +1109,7 @@ void __init setup_arch(char **cmdline_p)
> >
> > if (efi_enabled(EFI_MEMMAP)) {
> > efi_fake_memmap();
> > + efi_find_app_specific();
> > efi_find_mirror();
> > efi_esrt_init();
> >
> > diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> > index e1cb01a22fa8..899f1305c77a 100644
> > --- a/arch/x86/platform/efi/efi.c
> > +++ b/arch/x86/platform/efi/efi.c
> > @@ -123,10 +123,15 @@ void __init efi_find_mirror(void)
> > * more than the max 128 entries that can fit in the e820 legacy
> > * (zeropage) memory map.
> > */
> > +enum add_efi_mode {
> > + ADD_EFI_ALL,
> > + ADD_EFI_APP_SPECIFIC,
> > +};
> >
> > -static void __init do_add_efi_memmap(void)
> > +static void __init do_add_efi_memmap(enum add_efi_mode mode)
> > {
> > efi_memory_desc_t *md;
> > + int add = 0;
> >
> > for_each_efi_memory_desc(md) {
> > unsigned long long start = md->phys_addr;
> > @@ -139,7 +144,9 @@ static void __init do_add_efi_memmap(void)
> > case EFI_BOOT_SERVICES_CODE:
> > case EFI_BOOT_SERVICES_DATA:
> > case EFI_CONVENTIONAL_MEMORY:
> > - if (md->attribute & EFI_MEMORY_WB)
> > + if (is_efi_dax(md))
> > + e820_type = E820_TYPE_SPECIFIC;
Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')
On Wed, 5 Jun 2019 at 18:26, Greg KH wrote: > > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > > I decided to dig out a toy project which uses a DragonBoard 410c. This has > > been "running" with kernel 4.9, which I would keep this way for unrelated > > reasons. The vanilla 4.9 kernel wasn't bootable back then, but it was > > buildable, which was good enough. > > > > Upgrading the kernel to 4.9.180 caused the boot to suddenly fail: > > > > aarch64-unknown-linux-gnueabi-ld: > > ./drivers/firmware/efi/libstub/lib.a(arm64- > > stub.stub.o): in function `handle_kernel_image': > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63: > > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_' > > aarch64-unknown-linux-gnueabi-ld: > > ./drivers/firmware/efi/libstub/lib.a(arm64- > > stub.stub.o): relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol > > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can not be used > > when making a shared object; recompile with -fPIC > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63: > > (.init.text+0xc): dangerous relocation: unsupported relocation > > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target 'vmlinux' > > failed > > -make[1]: *** [vmlinux] Error 1 > > > > This is caused by commit 27b5ebf61818749b3568354c64a8ec2d9cd5ecca from > > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be), reverting > > this commit fixes the build. > > > > This happens with vanilla binutils 2.32 and gcc 8.3.0 as well as 9.1.0. See > > the attached .config for reference. > > > > If you have questions or patches just ping me. > > Does Linus's latest tree also fail for you (or 5.1)? > > Nick, do we need to add another fix that is in mainline for this to work > properly? > For the record, this is an example of why I think backporting those clang enablement patches is a bad idea. We can't actually build those kernels with clang, can we? So what is the point? It would be helpful to get a relocation dump (objdump -r) of arm64-stub.o to figure out which symbol needs a 'hidden' annotation to prevent GCC from emitting it as a PIC reference requiring a GOT. Alternatively, we can just revert this patch from 4.9
[PATCH] efi: Fix TPM code build failure on ARM
asm/early_ioremap.h needs to be #included before tpm_eventlog.h in order to ensure that early_memremap is available. Signed-off-by: Matthew Garrett --- drivers/firmware/efi/tpm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/firmware/efi/tpm.c b/drivers/firmware/efi/tpm.c index 0bdceb5913aa..1d3f5ca3eaaf 100644 --- a/drivers/firmware/efi/tpm.c +++ b/drivers/firmware/efi/tpm.c @@ -7,13 +7,12 @@ #define TPM_MEMREMAP(start, size) early_memremap(start, size) #define TPM_MEMUNMAP(start, size) early_memunmap(start, size) +#include #include #include #include #include -#include - int efi_tpm_final_log_size; EXPORT_SYMBOL(efi_tpm_final_log_size); -- 2.22.0.rc1.311.g5d7573a151-goog
[PATCH V2] tpm: Don't duplicate events from the final event log in the TCG2 log
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;
+}
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;
Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')
On Wed, Jun 5, 2019 at 10:27 AM Nick Desaulniers
wrote:
>
> On Wed, Jun 5, 2019 at 9:26 AM Greg KH wrote:
> >
> > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote:
> > > I decided to dig out a toy project which uses a DragonBoard 410c. This has
> > > been "running" with kernel 4.9, which I would keep this way for unrelated
> > > reasons. The vanilla 4.9 kernel wasn't bootable back then, but it was
> > > buildable, which was good enough.
> > >
> > > Upgrading the kernel to 4.9.180 caused the boot to suddenly fail:
> > >
> > > aarch64-unknown-linux-gnueabi-ld:
> > > ./drivers/firmware/efi/libstub/lib.a(arm64-
> > > stub.stub.o): in function `handle_kernel_image':
> > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63:
> > > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_'
> > > aarch64-unknown-linux-gnueabi-ld:
> > > ./drivers/firmware/efi/libstub/lib.a(arm64-
> > > stub.stub.o): relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol
> > > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can not be
> > > used
> > > when making a shared object; recompile with -fPIC
> > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63:
> > > (.init.text+0xc): dangerous relocation: unsupported relocation
> > > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target 'vmlinux'
> > > failed
> > > -make[1]: *** [vmlinux] Error 1
> > >
> > > This is caused by commit 27b5ebf61818749b3568354c64a8ec2d9cd5ecca from
> > > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be), reverting
> > > this commit fixes the build.
> > >
> > > This happens with vanilla binutils 2.32 and gcc 8.3.0 as well as 9.1.0.
> > > See
> > > the attached .config for reference.
> > >
> > > If you have questions or patches just ping me.
> >
> > Does Linus's latest tree also fail for you (or 5.1)?
> >
> > Nick, do we need to add another fix that is in mainline for this to work
> > properly?
> >
> > thanks,
> >
> > greg k-h
>
> Doesn't immediately ring any bells for me.
Upstream commits:
dd6846d77469 ("arm64: drop linker script hack to hide __efistub_ symbols")
1212f7a16af4 ("scripts/kallsyms: filter arm64's __efistub_ symbols")
Look related to __efistub__ prefixes on symbols and aren't in stable
4.9 (maybe Rolf can try cherry picks of those).
--
Thanks,
~Nick Desaulniers
Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')
On Wed, Jun 5, 2019 at 9:26 AM Greg KH wrote: > > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > > I decided to dig out a toy project which uses a DragonBoard 410c. This has > > been "running" with kernel 4.9, which I would keep this way for unrelated > > reasons. The vanilla 4.9 kernel wasn't bootable back then, but it was > > buildable, which was good enough. > > > > Upgrading the kernel to 4.9.180 caused the boot to suddenly fail: > > > > aarch64-unknown-linux-gnueabi-ld: > > ./drivers/firmware/efi/libstub/lib.a(arm64- > > stub.stub.o): in function `handle_kernel_image': > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63: > > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_' > > aarch64-unknown-linux-gnueabi-ld: > > ./drivers/firmware/efi/libstub/lib.a(arm64- > > stub.stub.o): relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol > > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can not be used > > when making a shared object; recompile with -fPIC > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63: > > (.init.text+0xc): dangerous relocation: unsupported relocation > > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target 'vmlinux' > > failed > > -make[1]: *** [vmlinux] Error 1 > > > > This is caused by commit 27b5ebf61818749b3568354c64a8ec2d9cd5ecca from > > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be), reverting > > this commit fixes the build. > > > > This happens with vanilla binutils 2.32 and gcc 8.3.0 as well as 9.1.0. See > > the attached .config for reference. > > > > If you have questions or patches just ping me. > > Does Linus's latest tree also fail for you (or 5.1)? > > Nick, do we need to add another fix that is in mainline for this to work > properly? > > thanks, > > greg k-h Doesn't immediately ring any bells for me. +mka@ who helped test 91ee5b21ee026c49e4e7483de69b55b8b47042be. Nothing in that series (https://lore.kernel.org/lkml/20170818194947.19347-5-ard.biesheu...@linaro.org/T/#u) is immediately obvious. Rolf, can you please email me your config so I can see if I can reproduce? Also, which version of GCC are you using, and binutils? (would be good to know if you hit this in mainline too, as if not maybe there's an existing fix to be backported to stable). -- Thanks, ~Nick Desaulniers
Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')
On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > I decided to dig out a toy project which uses a DragonBoard 410c. This has > been "running" with kernel 4.9, which I would keep this way for unrelated > reasons. The vanilla 4.9 kernel wasn't bootable back then, but it was > buildable, which was good enough. > > Upgrading the kernel to 4.9.180 caused the boot to suddenly fail: > > aarch64-unknown-linux-gnueabi-ld: ./drivers/firmware/efi/libstub/lib.a(arm64- > stub.stub.o): in function `handle_kernel_image': > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63: > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_' > aarch64-unknown-linux-gnueabi-ld: ./drivers/firmware/efi/libstub/lib.a(arm64- > stub.stub.o): relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can not be used > when making a shared object; recompile with -fPIC > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63: > (.init.text+0xc): dangerous relocation: unsupported relocation > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target 'vmlinux' failed > -make[1]: *** [vmlinux] Error 1 > > This is caused by commit 27b5ebf61818749b3568354c64a8ec2d9cd5ecca from > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be), reverting > this commit fixes the build. > > This happens with vanilla binutils 2.32 and gcc 8.3.0 as well as 9.1.0. See > the attached .config for reference. > > If you have questions or patches just ping me. Does Linus's latest tree also fail for you (or 5.1)? Nick, do we need to add another fix that is in mainline for this to work properly? thanks, greg k-h
Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')
I decided to dig out a toy project which uses a DragonBoard 410c. This has been "running" with kernel 4.9, which I would keep this way for unrelated reasons. The vanilla 4.9 kernel wasn't bootable back then, but it was buildable, which was good enough. Upgrading the kernel to 4.9.180 caused the boot to suddenly fail: aarch64-unknown-linux-gnueabi-ld: ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): in function `handle_kernel_image': /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63: undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_' aarch64-unknown-linux-gnueabi-ld: ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can not be used when making a shared object; recompile with -fPIC /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63: (.init.text+0xc): dangerous relocation: unsupported relocation /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target 'vmlinux' failed -make[1]: *** [vmlinux] Error 1 This is caused by commit 27b5ebf61818749b3568354c64a8ec2d9cd5ecca from linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be), reverting this commit fixes the build. This happens with vanilla binutils 2.32 and gcc 8.3.0 as well as 9.1.0. See the attached .config for reference. If you have questions or patches just ping me. Greetings, Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source# # Automatically generated file; DO NOT EDIT. # Linux/arm64 4.9.39 Kernel Configuration # CONFIG_ARM64=y CONFIG_64BIT=y CONFIG_ARCH_PHYS_ADDR_T_64BIT=y CONFIG_MMU=y CONFIG_DEBUG_RODATA=y CONFIG_ARM64_PAGE_SHIFT=12 CONFIG_ARM64_CONT_SHIFT=4 CONFIG_ARCH_MMAP_RND_BITS_MIN=18 CONFIG_ARCH_MMAP_RND_BITS_MAX=24 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=11 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16 CONFIG_STACKTRACE_SUPPORT=y CONFIG_ILLEGAL_POINTER_VALUE=0xdead CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CSUM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ZONE_DMA=y CONFIG_HAVE_GENERIC_RCU_GUP=y CONFIG_ARCH_DMA_ADDR_T_64BIT=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_SMP=y CONFIG_SWIOTLB=y CONFIG_IOMMU_HELPER=y CONFIG_KERNEL_MODE_NEON=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_PGTABLE_LEVELS=3 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y # CONFIG_USELIB is not set # CONFIG_AUDIT is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_SHOW_LEVEL=y CONFIG_GENERIC_IRQ_MIGRATION=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_GENERIC_MSI_IRQ=y CONFIG_GENERIC_MSI_IRQ_DOMAIN=y CONFIG_HANDLE_DOMAIN_IRQ=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_ARCH_HAS_TICK_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y # CONFIG_NO_HZ_FULL is not set # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y # # RCU Subsystem # CONFIG_PREEMPT_RCU=y # CONFIG_RCU_EXPERT is not set CONFIG_SRCU=y # CONFIG_TASKS_RCU is not set CONFIG_RCU_STALL_COMMON=y # CONFIG_TREE_RCU_TRACE is not set # CONFIG_RCU_EXPEDITE_BOOT is not set CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=14 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 CONFIG_GENERIC_SCHED_CLOCK=y CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_CGROUPS=y CONFIG_PAGE_COUNTER=y CONFIG_MEMCG=y CONFIG_MEMCG_SWAP=y CONFIG_MEMCG_SWAP_ENABLED=y CONFIG_BLK_CGROUP=y # CONFIG_DEBUG_BLK_CGROUP is not set CONFIG_CGROUP_WRITEBACK=y CONFIG_CGROUP_SCHED=y
Re: [PATCH 1/1] tpm: Don't dereference event after it's unmapped in __calc_tpm2_event_size
On Wed, Jun 05, 2019 at 12:04:33AM +0100, Chris Coulson wrote: > The pointer to the event header is dereferenced on each loop iteration in > order to obtain the digest count, but when called from > tpm2_calc_event_log_size, the event header is unmapped on the first > iteration of the loop. This results in an invalid access for on subsequent > loop iterations for log entries that have more than one digest. > > Signed-off-by: Chris Coulson Reviewed-by: Jarkko Sakkinen /Jarkko
Re: [PATCH 0/1] Fix crash in __calc_tpm2_event_size
On Wed, Jun 05, 2019 at 12:04:32AM +0100, Chris Coulson wrote: > I've been testing the latest code in the linux-tpmdd branch and I'm > experiencing a crash in __calc_tpm2_event_size when it's called to > calculate the size of events in the final log. I hope I'm not stepping on > anyone's toes, but this small change seems to fix it. Oh no, thank you for reporting this. /Jarkko
Re: [PATCH] tpm: Don't duplicate events from the final event log in the TCG2 log
On Tue, Jun 04, 2019 at 12:35:11PM -0700, 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. Sounds flakky how UEFI firmaware works. Wonder why the ignition of the final events log is bound to the invokation of GetEventLog() in the first place. > 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 Rename final_events_early_size as final_events_preboot_size because it is a bit more descriptive name. Other than that looks good to me. /Jarkko
Quation needed For June Inquiry
Hello dear, We are in the market for your products after meeting at your stand during last expo. Please kindly send us your latest catalog and price list so as to start a new project/order as promised during the exhibition. I would appreciate your response about the above details required so we can revert back to you asap. Kind regards Rhema Zoeh
