[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ff342ae6-67ef-370d-5c84-19cd0ed69711@intel.com>
Date: Thu, 26 Oct 2017 07:13:32 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Brian Gerst <brgerst@...il.com>, Andy Lutomirski <luto@...nel.org>
Cc: X86 ML <x86@...nel.org>, Borislav Petkov <bpetkov@...e.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 03/18] x86/asm/64: Move SWAPGS into the common
iret-to-usermode path
On 10/26/2017 06:52 AM, Brian Gerst wrote:
> On Thu, Oct 26, 2017 at 4:26 AM, Andy Lutomirski <luto@...nel.org> wrote:
>> All of the code paths that ended up doing IRET to usermode did
>> SWAPGS immediately beforehand. Move the SWAPGS into the common
>> code.
>>
>> Signed-off-by: Andy Lutomirski <luto@...nel.org>
>
>> +GLOBAL(swapgs_restore_regs_and_return_to_usermode)
>
> Is adding swapgs to the label really necessary? It's redundant with
> the usermode part. I'm noticing a trend towards absurdly verbose
> labels lately.
I kinda appreciate the verbosity. When I see a jump to such a label, I
know explicitly what the jumper has to do. While it's possible that
every "return to usermode" spot in the kernel does a swapgs, it's not
patently obvious to me that every last one does that in every last
situation.
There are also places where we do register restoring after swapgs and
then return to userspace. It's nice to know what mode we are in and
what we are supposed to to just from the label.
Powered by blists - more mailing lists