linux-kernel - Re: [PATCH 5.4 18/43] arm64: entry: Add macro for reading symbol addresses from the trampoline

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bc35996d-ec18-1923-38f4-81d16ed98b7a@arm.com>
Date:   Fri, 18 Mar 2022 12:11:32 +0000
From:   James Morse <james.morse@....com>
To:     Florian Fainelli <f.fainelli@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org
Cc:     stable@...r.kernel.org, Catalin Marinas <catalin.marinas@....com>,
        Sasha Levin <sashal@...nel.org>
Subject: Re: [PATCH 5.4 18/43] arm64: entry: Add macro for reading symbol
 addresses from the trampoline

Hi Florian,

On 3/17/22 8:48 PM, Florian Fainelli wrote:
> On 3/17/22 5:45 AM, Greg Kroah-Hartman wrote:
>> From: James Morse <james.morse@....com>
>>
>> commit b28a8eebe81c186fdb1a0078263b30576c8e1f42 upstream.
>>
>> The trampoline code needs to use the address of symbols in the wider
>> kernel, e.g. vectors. PC-relative addressing wouldn't work as the
>> trampoline code doesn't run at the address the linker expected.
>>
>> tramp_ventry uses a literal pool, unless CONFIG_RANDOMIZE_BASE is
>> set, in which case it uses the data page as a literal pool because
>> the data page can be unmapped when running in user-space, which is
>> required for CPUs vulnerable to meltdown.
>>
>> Pull this logic out as a macro, instead of adding a third copy
>> of it.
>>
>> Reviewed-by: Catalin Marinas <catalin.marinas@....com>
>> Signed-off-by: James Morse <james.morse@....com>
>> Signed-off-by: Sasha Levin <sashal@...nel.org>
> 
> This commit causes a linking failure with CONFIG_ARM_SDE_INTERFACE=y
> enabled in the kernel:
> 
>    LD      .tmp_vmlinux.kallsyms1
> /local/users/fainelli/buildroot/output/arm64/host/bin/aarch64-linux-ld:
> arch/arm64/kernel/entry.o: in function `__sdei_asm_exit_trampoline':
> /local/users/fainelli/buildroot/output/arm64/build/linux-custom/arch/arm64/kernel/entry.S:1352:
> undefined reference to `__sdei_asm_trampoline_next_handler'
> make[2]: *** [Makefile:1100: vmlinux] Error 1
> make[1]: *** [package/pkg-generic.mk:295:
> /local/users/fainelli/buildroot/output/arm64/build/linux-custom/.stamp_built]
> Error 2
> make: *** [Makefile:27: _all] Error 2

... and with CONFIG_RANDOMIZE_BASE turned off, which is why allyesconfig didn't catch it.
This is because I kept the next_handler bit of the label when it conflicted, which isn't needed
because the __entry_tramp bit added by the macro serves the same purpose.

The below diff fixes it:
----------%<----------
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index e4b5a15c2e2e..cfc0bb6c49f7 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -1190,7 +1190,7 @@ __entry_tramp_data_start:
  __entry_tramp_data_vectors:
         .quad   vectors
  #ifdef CONFIG_ARM_SDE_INTERFACE
-__entry_tramp_data___sdei_asm_trampoline_next_handler:
+__entry_tramp_data___sdei_asm_handler:
         .quad   __sdei_asm_handler
  #endif /* CONFIG_ARM_SDE_INTERFACE */
         .popsection                             // .rodata
@@ -1319,7 +1319,7 @@ ENTRY(__sdei_asm_entry_trampoline)
          */
  1:     str     x4, [x1, #(SDEI_EVENT_INTREGS + S_ORIG_ADDR_LIMIT)]
  
-       tramp_data_read_var     x4, __sdei_asm_trampoline_next_handler
+       tramp_data_read_var     x4, __sdei_asm_handler
         br      x4
  ENDPROC(__sdei_asm_entry_trampoline)
  NOKPROBE(__sdei_asm_entry_trampoline)
----------%<----------

Good news - this didn't happen with v5.10.

I don't see this in v5.4.185 yet.

Greg/Sasha, what is least work for you?:
A new version of this patch,
A fixup on top of the series,
Reposting the series with this fixed.


Thanks for catching this!

James