[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFzMzBwtfO1e=eC6oCx9mMMXPoRko0FvKKJrriUGqyQtEg@mail.gmail.com>
Date: Wed, 10 Jan 2018 12:26:25 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Josh Poimboeuf <jpoimboe@...hat.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Borislav Petkov <bp@...en8.de>,
David Woodhouse <dwmw2@...radead.org>,
Andi Kleen <andi@...stfloor.org>,
"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 12:15 PM, Josh Poimboeuf <jpoimboe@...hat.com> wrote:
>
> I think .altinstruction relocations *do* work if they're for the first
> instruction, and it's a jump or a call.
Yes - for the alternative that is in-line - not in the "altinstruction" section.
Because then the alternative is in the right spot at link-time already.
But the "altinstruction" section definitely should not have
relocations. I guess you could hack them up by hand by explicitly
trying to take the difference between the non-altinstruction and the
altinstruction into account, but it would be error-prone and fragile
as hell.
> I think Boris had a patch floating around to add an instruction decoder
> to alternatives, so you can do a call/jmp anywhere.
.. and no, we're not doing that. Christ.
People, we need to try to be *robust* here. That's doubly (triply!)
true of things like altinstructions where people - very much by design
- won't even *test* the alternatives very much, because very much by
design the altinstructions are only used on certain architectures or
in certain situations.
And we almost certainly don't actuially _need_ relocations. But we
need to protect against the "oops, I didn't realize" issue, exactly
because testing won't actually catch the odd cases.
Because we don't want to be in the situation where some random poor
user hits it because they have an old CPU that no developer has, and
then the relocation will basically do completely random things.
Imagine just how crazy that would be to debug. You'd be basically
executing insane code, and looking at the sources - or even the
binaries - it would _look_ completely sane.
Linus
Powered by blists - more mailing lists