* [PATCH] x86/vmlinux: Fix linker fill bytes for ld.lld
@ 2023-09-06 17:52 Song Liu
2023-09-06 18:06 ` Kees Cook
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Song Liu @ 2023-09-06 17:52 UTC (permalink / raw)
To: linux-kernel; +Cc: kernel-team, Song Liu, Kees Cook, x86
With ":text =0xcccc", ld.lld fills unused text area with 0xcccc0000.
Example objdump -D output:
ffffffff82b04203: 00 00 add %al,(%rax)
ffffffff82b04205: cc int3
ffffffff82b04206: cc int3
ffffffff82b04207: 00 00 add %al,(%rax)
ffffffff82b04209: cc int3
ffffffff82b0420a: cc int3
Replace it with ":text =0xcccccccc", so we get the following instead:
ffffffff82b04203: cc int3
ffffffff82b04204: cc int3
ffffffff82b04205: cc int3
ffffffff82b04206: cc int3
ffffffff82b04207: cc int3
ffffffff82b04208: cc int3
gcc/ld doesn't seem to have the same issue. The generated code stays the
same for gcc/ld.
Cc: Kees Cook <keescook@chromium.org>
Cc: x86@kernel.org
Signed-off-by: Song Liu <song@kernel.org>
---
arch/x86/kernel/vmlinux.lds.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index 83d41c2601d7..41d56fb9bf92 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -156,7 +156,7 @@ SECTIONS
ALIGN_ENTRY_TEXT_END
*(.gnu.warning)
- } :text =0xcccc
+ } :text =0xcccccccc
/* End of text section, which should occupy whole number of pages */
_etext = .;
--
2.34.1
^ permalink raw reply related [flat|nested] 7+ messages in thread* Re: [PATCH] x86/vmlinux: Fix linker fill bytes for ld.lld 2023-09-06 17:52 [PATCH] x86/vmlinux: Fix linker fill bytes for ld.lld Song Liu @ 2023-09-06 18:06 ` Kees Cook 2023-09-06 18:16 ` Song Liu 2023-09-06 19:58 ` Peter Zijlstra 2023-09-06 21:57 ` [tip: x86/urgent] x86/build: Fix linker fill bytes quirk/incompatibility " tip-bot2 for Song Liu 2 siblings, 1 reply; 7+ messages in thread From: Kees Cook @ 2023-09-06 18:06 UTC (permalink / raw) To: Song Liu, Fangrui Song Cc: linux-kernel, kernel-team, x86, clang-built-linux, linux-hardening On Wed, Sep 06, 2023 at 10:52:15AM -0700, Song Liu wrote: > With ":text =0xcccc", ld.lld fills unused text area with 0xcccc0000. > Example objdump -D output: > > ffffffff82b04203: 00 00 add %al,(%rax) > ffffffff82b04205: cc int3 > ffffffff82b04206: cc int3 > ffffffff82b04207: 00 00 add %al,(%rax) > ffffffff82b04209: cc int3 > ffffffff82b0420a: cc int3 > > Replace it with ":text =0xcccccccc", so we get the following instead: > > ffffffff82b04203: cc int3 > ffffffff82b04204: cc int3 > ffffffff82b04205: cc int3 > ffffffff82b04206: cc int3 > ffffffff82b04207: cc int3 > ffffffff82b04208: cc int3 > > gcc/ld doesn't seem to have the same issue. The generated code stays the > same for gcc/ld. > > Cc: Kees Cook <keescook@chromium.org> > Cc: x86@kernel.org > Signed-off-by: Song Liu <song@kernel.org> Ah! Thanks for the catch... I wonder if ld.lld should be fixed too? My understanding was that ":text =...." was defined as being explicitly u16? Reviewed-by: Kees Cook <keescook@chromium.org> -- Kees Cook ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] x86/vmlinux: Fix linker fill bytes for ld.lld 2023-09-06 18:06 ` Kees Cook @ 2023-09-06 18:16 ` Song Liu 2023-09-06 18:27 ` Fangrui Song 0 siblings, 1 reply; 7+ messages in thread From: Song Liu @ 2023-09-06 18:16 UTC (permalink / raw) To: Kees Cook Cc: Song Liu, Fangrui Song, LKML, Kernel Team, x86@kernel.org, clang-built-linux, linux-hardening@vger.kernel.org > On Sep 6, 2023, at 11:06 AM, Kees Cook <keescook@chromium.org> wrote: > > On Wed, Sep 06, 2023 at 10:52:15AM -0700, Song Liu wrote: >> With ":text =0xcccc", ld.lld fills unused text area with 0xcccc0000. >> Example objdump -D output: >> >> ffffffff82b04203: 00 00 add %al,(%rax) >> ffffffff82b04205: cc int3 >> ffffffff82b04206: cc int3 >> ffffffff82b04207: 00 00 add %al,(%rax) >> ffffffff82b04209: cc int3 >> ffffffff82b0420a: cc int3 >> >> Replace it with ":text =0xcccccccc", so we get the following instead: >> >> ffffffff82b04203: cc int3 >> ffffffff82b04204: cc int3 >> ffffffff82b04205: cc int3 >> ffffffff82b04206: cc int3 >> ffffffff82b04207: cc int3 >> ffffffff82b04208: cc int3 >> >> gcc/ld doesn't seem to have the same issue. The generated code stays the >> same for gcc/ld. >> >> Cc: Kees Cook <keescook@chromium.org> >> Cc: x86@kernel.org >> Signed-off-by: Song Liu <song@kernel.org> > > Ah! Thanks for the catch... I wonder if ld.lld should be fixed too? My > understanding was that ":text =...." was defined as being explicitly > u16? Per my experiment, gcc/ld gives same output for :text =0xcc, :text =0xcccc, and :text =0xcccccccc; while ld.lld handles :text = as u32, so :text =0xcc with ld.lld gives: ffffffff82b042a1: 00 cc add %cl,%ah ffffffff82b042a3: 00 00 add %al,(%rax) ffffffff82b042a5: 00 cc add %cl,%ah ffffffff82b042a7: 00 00 add %al,(%rax) ffffffff82b042a9: 00 cc add %cl,%ah ffffffff82b042ab: 00 00 add %al,(%rax) I am not sure what the right behavior is per specification. Thanks, Song ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] x86/vmlinux: Fix linker fill bytes for ld.lld 2023-09-06 18:16 ` Song Liu @ 2023-09-06 18:27 ` Fangrui Song 0 siblings, 0 replies; 7+ messages in thread From: Fangrui Song @ 2023-09-06 18:27 UTC (permalink / raw) To: Song Liu Cc: Kees Cook, Song Liu, LKML, Kernel Team, x86@kernel.org, clang-built-linux, linux-hardening@vger.kernel.org On Wed, Sep 6, 2023 at 11:16 AM Song Liu <songliubraving@meta.com> wrote: > > > > > On Sep 6, 2023, at 11:06 AM, Kees Cook <keescook@chromium.org> wrote: > > > > On Wed, Sep 06, 2023 at 10:52:15AM -0700, Song Liu wrote: > >> With ":text =0xcccc", ld.lld fills unused text area with 0xcccc0000. > >> Example objdump -D output: > >> > >> ffffffff82b04203: 00 00 add %al,(%rax) > >> ffffffff82b04205: cc int3 > >> ffffffff82b04206: cc int3 > >> ffffffff82b04207: 00 00 add %al,(%rax) > >> ffffffff82b04209: cc int3 > >> ffffffff82b0420a: cc int3 > >> > >> Replace it with ":text =0xcccccccc", so we get the following instead: > >> > >> ffffffff82b04203: cc int3 > >> ffffffff82b04204: cc int3 > >> ffffffff82b04205: cc int3 > >> ffffffff82b04206: cc int3 > >> ffffffff82b04207: cc int3 > >> ffffffff82b04208: cc int3 > >> > >> gcc/ld doesn't seem to have the same issue. The generated code stays the > >> same for gcc/ld. > >> > >> Cc: Kees Cook <keescook@chromium.org> > >> Cc: x86@kernel.org > >> Signed-off-by: Song Liu <song@kernel.org> > > > > Ah! Thanks for the catch... I wonder if ld.lld should be fixed too? My > > understanding was that ":text =...." was defined as being explicitly > > u16? > > Per my experiment, gcc/ld gives same output for :text =0xcc, :text =0xcccc, > and :text =0xcccccccc; while ld.lld handles :text = as u32, so :text =0xcc > with ld.lld gives: > > ffffffff82b042a1: 00 cc add %cl,%ah > ffffffff82b042a3: 00 00 add %al,(%rax) > ffffffff82b042a5: 00 cc add %cl,%ah > ffffffff82b042a7: 00 00 add %al,(%rax) > ffffffff82b042a9: 00 cc add %cl,%ah > ffffffff82b042ab: 00 00 add %al,(%rax) > > I am not sure what the right behavior is per specification. > > Thanks, > Song AFAIK GNU ld's behavior is not documented here https://sourceware.org/binutils/docs/ld/Output-Section-Fill.html The Output Section Fill syntax allows an expression. It seems that if you use =0xcc+0, GNU ld will use a 4-byte filler as well, similar to gold and ld.lld. Frankly, I feel that GNU ld behavior should not be relied upon. lld's comment states that it is a deliberate choice to follow gold instead of GNU ld here. I'll elaborate a bit and add this discrepancy to my https://maskray.me/blog/2020-12-19-lld-and-gnu-linker-incompatibilities :) -- 宋方睿 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] x86/vmlinux: Fix linker fill bytes for ld.lld 2023-09-06 17:52 [PATCH] x86/vmlinux: Fix linker fill bytes for ld.lld Song Liu 2023-09-06 18:06 ` Kees Cook @ 2023-09-06 19:58 ` Peter Zijlstra 2023-09-06 20:02 ` Song Liu 2023-09-06 21:57 ` [tip: x86/urgent] x86/build: Fix linker fill bytes quirk/incompatibility " tip-bot2 for Song Liu 2 siblings, 1 reply; 7+ messages in thread From: Peter Zijlstra @ 2023-09-06 19:58 UTC (permalink / raw) To: Song Liu; +Cc: linux-kernel, kernel-team, Kees Cook, x86 On Wed, Sep 06, 2023 at 10:52:15AM -0700, Song Liu wrote: > With ":text =0xcccc", ld.lld fills unused text area with 0xcccc0000. > Example objdump -D output: > > ffffffff82b04203: 00 00 add %al,(%rax) > ffffffff82b04205: cc int3 > ffffffff82b04206: cc int3 > ffffffff82b04207: 00 00 add %al,(%rax) > ffffffff82b04209: cc int3 > ffffffff82b0420a: cc int3 > > Replace it with ":text =0xcccccccc", so we get the following instead: > > ffffffff82b04203: cc int3 > ffffffff82b04204: cc int3 > ffffffff82b04205: cc int3 > ffffffff82b04206: cc int3 > ffffffff82b04207: cc int3 > ffffffff82b04208: cc int3 > > gcc/ld doesn't seem to have the same issue. The generated code stays the > same for gcc/ld. > > Cc: Kees Cook <keescook@chromium.org> > Cc: x86@kernel.org > Signed-off-by: Song Liu <song@kernel.org> Please provide a Fixes tag, I'm thinking this (otherwise trivial commit) wants to be backported for sanity. Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> > --- > arch/x86/kernel/vmlinux.lds.S | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S > index 83d41c2601d7..41d56fb9bf92 100644 > --- a/arch/x86/kernel/vmlinux.lds.S > +++ b/arch/x86/kernel/vmlinux.lds.S > @@ -156,7 +156,7 @@ SECTIONS > ALIGN_ENTRY_TEXT_END > *(.gnu.warning) > > - } :text =0xcccc > + } :text =0xcccccccc > > /* End of text section, which should occupy whole number of pages */ > _etext = .; > -- > 2.34.1 > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] x86/vmlinux: Fix linker fill bytes for ld.lld 2023-09-06 19:58 ` Peter Zijlstra @ 2023-09-06 20:02 ` Song Liu 0 siblings, 0 replies; 7+ messages in thread From: Song Liu @ 2023-09-06 20:02 UTC (permalink / raw) To: Peter Zijlstra; +Cc: linux-kernel, kernel-team, Kees Cook, x86 On Wed, Sep 6, 2023 at 12:58 PM Peter Zijlstra <peterz@infradead.org> wrote: > > On Wed, Sep 06, 2023 at 10:52:15AM -0700, Song Liu wrote: > > With ":text =0xcccc", ld.lld fills unused text area with 0xcccc0000. > > Example objdump -D output: > > > > ffffffff82b04203: 00 00 add %al,(%rax) > > ffffffff82b04205: cc int3 > > ffffffff82b04206: cc int3 > > ffffffff82b04207: 00 00 add %al,(%rax) > > ffffffff82b04209: cc int3 > > ffffffff82b0420a: cc int3 > > > > Replace it with ":text =0xcccccccc", so we get the following instead: > > > > ffffffff82b04203: cc int3 > > ffffffff82b04204: cc int3 > > ffffffff82b04205: cc int3 > > ffffffff82b04206: cc int3 > > ffffffff82b04207: cc int3 > > ffffffff82b04208: cc int3 > > > > gcc/ld doesn't seem to have the same issue. The generated code stays the > > same for gcc/ld. > > > > Cc: Kees Cook <keescook@chromium.org> > > Cc: x86@kernel.org > > Signed-off-by: Song Liu <song@kernel.org> > > Please provide a Fixes tag, I'm thinking this (otherwise trivial commit) > wants to be backported for sanity. I guess we need: Fixes: 7705dc855797 ("x86/vmlinux: Use INT3 instead of NOP for linker fill bytes") Thanks, Song > > Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> ^ permalink raw reply [flat|nested] 7+ messages in thread
* [tip: x86/urgent] x86/build: Fix linker fill bytes quirk/incompatibility for ld.lld 2023-09-06 17:52 [PATCH] x86/vmlinux: Fix linker fill bytes for ld.lld Song Liu 2023-09-06 18:06 ` Kees Cook 2023-09-06 19:58 ` Peter Zijlstra @ 2023-09-06 21:57 ` tip-bot2 for Song Liu 2 siblings, 0 replies; 7+ messages in thread From: tip-bot2 for Song Liu @ 2023-09-06 21:57 UTC (permalink / raw) To: linux-tip-commits Cc: Song Liu, Ingo Molnar, Kees Cook, Peter Zijlstra (Intel), x86, linux-kernel The following commit has been merged into the x86/urgent branch of tip: Commit-ID: 65e710899fd19f435f40268f3a92dfaa11f14470 Gitweb: https://git.kernel.org/tip/65e710899fd19f435f40268f3a92dfaa11f14470 Author: Song Liu <song@kernel.org> AuthorDate: Wed, 06 Sep 2023 10:52:15 -07:00 Committer: Ingo Molnar <mingo@kernel.org> CommitterDate: Wed, 06 Sep 2023 23:49:12 +02:00 x86/build: Fix linker fill bytes quirk/incompatibility for ld.lld With ":text =0xcccc", ld.lld fills unused text area with 0xcccc0000. Example objdump -D output: ffffffff82b04203: 00 00 add %al,(%rax) ffffffff82b04205: cc int3 ffffffff82b04206: cc int3 ffffffff82b04207: 00 00 add %al,(%rax) ffffffff82b04209: cc int3 ffffffff82b0420a: cc int3 Replace it with ":text =0xcccccccc", so we get the following instead: ffffffff82b04203: cc int3 ffffffff82b04204: cc int3 ffffffff82b04205: cc int3 ffffffff82b04206: cc int3 ffffffff82b04207: cc int3 ffffffff82b04208: cc int3 gcc/ld doesn't seem to have the same issue. The generated code stays the same for gcc/ld. Signed-off-by: Song Liu <song@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Fixes: 7705dc855797 ("x86/vmlinux: Use INT3 instead of NOP for linker fill bytes") Link: https://lore.kernel.org/r/20230906175215.2236033-1-song@kernel.org --- arch/x86/kernel/vmlinux.lds.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S index 83d41c2..f15fb71 100644 --- a/arch/x86/kernel/vmlinux.lds.S +++ b/arch/x86/kernel/vmlinux.lds.S @@ -156,7 +156,7 @@ SECTIONS ALIGN_ENTRY_TEXT_END *(.gnu.warning) - } :text =0xcccc + } :text = 0xcccccccc /* End of text section, which should occupy whole number of pages */ _etext = .; ^ permalink raw reply related [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-09-06 21:57 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-09-06 17:52 [PATCH] x86/vmlinux: Fix linker fill bytes for ld.lld Song Liu 2023-09-06 18:06 ` Kees Cook 2023-09-06 18:16 ` Song Liu 2023-09-06 18:27 ` Fangrui Song 2023-09-06 19:58 ` Peter Zijlstra 2023-09-06 20:02 ` Song Liu 2023-09-06 21:57 ` [tip: x86/urgent] x86/build: Fix linker fill bytes quirk/incompatibility " tip-bot2 for Song Liu
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.