linux-kernel - Re: [PATCH v2] x86: Return to kernel without IRET

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 3 May 2014 17:31:41 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	X86 ML <x86@...nel.org>, Gleb Natapov <gleb@...nel.org>,
	Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: [PATCH v2] x86: Return to kernel without IRET

On Sat, May 3, 2014 at 4:51 PM, Andy Lutomirski <luto@...capital.net> wrote:
> On Sat, May 3, 2014 at 3:19 PM, H. Peter Anvin <hpa@...or.com> wrote:
>> On 05/03/2014 04:24 AM, Steven Rostedt wrote:
>>> On Fri, 02 May 2014 21:03:10 -0700
>>> "H. Peter Anvin" <hpa@...or.com> wrote:
>>>
>>>>
>>>> I'd really like to see a workload which would genuinely benefit before
>>>> adding more complexity.  Now... if we can determine that it doesn't harm
>>>> anything and would solve the NMI nesting problem cleaner than the
>>>> current solution, that would justify things, too...
>>>>
>>>
>>> As I stated before. It doesn't solve the NMI nesting problem. It only
>>> handles page faults. We would have to implement this for breakpoint
>>> return paths too. Is that a plan as well?
>>>
>>
>> I would assume we would do it for *ALL* the IRETs.  There are only three
>> IRETs in the kernel last I checked...
>
> I think we should carefully avoid doing it for returns from NMI, though :)
>
> If you want a realistic benchmark that will speed up, packet
> forwarding might be a good place to look.

Hmm.  I think my patch will blow up with EFI mixed mode if any EFI
functions are called with interrupts enabled.  It may also blow up
with when suspending or doing other BIOS things like that.  It should
probably check the actual value of CS as opposed to just the CPL.

I'm not sure what's happening with the alternate GDT in the EFI stuff.

--Andy
--
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/