linux-kernel - Re: [RFC] x86_64: A real proposal for iret-less return to kernel

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]

Message-ID: <537D30B1.9030407@zytor.com>
Date:	Wed, 21 May 2014 16:03:13 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Andy Lutomirski <luto@...capital.net>
CC:	Steven Rostedt <rostedt@...dmis.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Borislav Petkov <bp@...en8.de>,
	Andi Kleen <andi@...stfloor.org>
Subject: Re: [RFC] x86_64: A real proposal for iret-less return to kernel

On 05/21/2014 03:41 PM, Andy Lutomirski wrote:
>>
>> I think you are onto something here.
>>
>> In particular, the key observation here is that inside the kernel, we
>> can never *both* have an invalid stack *and* be inside an NMI, #MC or
>> #DB handler, even if nested.
> 
> Except for espfix :)

Argh.  Yes, I got that wrong... it isn't really about being inside NMI,
#MC or #DB, but rather being on those respective stacks.  If you are on
the espfix stack you are on your way back to userspace OR (and this gets
really, really ugly) you took an NMI/MC/DB after a SYSCALL executed in
16-bit mode, but even then you are in the kernel entry/exit code and
re-enabling NMI is fine.

>> Now, does this prevent us from using RET in the common case?  I'm not
>> sure it is a huge loss since kernel-to-kernel is relatively rare.
> 
> I don't think so.  The most common case should be plain old interrupts
> and I suspect that #PF is a distant second.
> 
> In any event, plain old interrupts and #PF are non-IST interrupts and
> they should be unconditionally safe for RET

	-hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/