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]
Message-ID: <CALCETrXZyJx_5nMvW273gLJX+PROZpY3L5Wy_cwj=mK=6fSCJQ@mail.gmail.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ