linux-kernel - Re: [PATCH] x86/alternatives: Fix optimize

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]

Date:   Wed, 10 Jan 2018 21:05:19 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     David Woodhouse <dwmw2@...radead.org>,
        Andi Kleen <andi@...stfloor.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        the arch/x86 maintainers <x86@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Paul Turner <pjt@...gle.com>,
        Andrew Lutomirski <luto@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Tom Lendacky <thomas.lendacky@....com>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Greg Kroah-Hartman <gregkh@...ux-foundation.org>,
        Dave Hansen <dave.hansen@...el.com>,
        Jiri Kosina <jikos@...nel.org>, Andi Kleen <ak@...ux.intel.com>
Subject: Re: [PATCH] x86/alternatives: Fix optimize_nops() checking

On Wed, Jan 10, 2018 at 11:38:36AM -0800, Linus Torvalds wrote:
> Can we also add compile-time checking (presumably in objtool, but who
> knows) that there are no relocations in the alternative section?

Well, so we do fail the build if the jmp's offset doesn't fit in s32:

Makefile:996: recipe for target 'vmlinux' failed

arch/x86/kernel/cpu/amd.o:(.altinstr_replacement+0x4): relocation truncated to fit: R_X86_64_32 against `.altinstr_replacement'
make: *** [vmlinux] Error 1

I did this:

        alternative("", "xor %%rdi, %%rdi; .byte 0xe9; .long 2f; 2: jmp startup_64", X86_FEATURE_K8);

And I was thinking whether it would make sense to beef up
recompute_jump() to be smart enough to massage the JMPs into jumping to
the right place.

Because in the example above, I'm basically jumping to the label 2: but
since the .altinstr_replacement is so far away, it fails the build due
to the reloc.

Even though it shouldn't have because when we patch, that label is
immediately following the JMP. And probably it wouldn't need a reloc
either. Whether that sequence makes sense is another story...

Anyway, I asked a gcc person and we'll see what we could do.

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.