Messages in this thread | | | From | Song Liu <> | Subject | Re: [PATCH] x86/vmlinux: Fix linker fill bytes for ld.lld | Date | Wed, 6 Sep 2023 18:16:48 +0000 |
| |
> 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
| |