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]
Date:	Tue, 15 Dec 2015 13:27:05 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Andrew Cooper <andrew.cooper3@...rix.com>
Cc:	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linux Virtualization <virtualization@...ts.linux-foundation.org>,
	Ingo Molnar <mingo@...hat.com>,
	David Vrabel <david.vrabel@...rix.com>,
	Andrew Lutomirski <luto@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	"xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Borislav Petkov <bp@...e.de>
Subject: Re: [Xen-devel] [PATCH v2 0/3] Fix and cleanup for 32-bit PV sysexit

On Tue, Dec 15, 2015 at 12:40 PM, Andrew Cooper
<andrew.cooper3@...rix.com> wrote:
> On 19/11/15 22:07, Andy Lutomirski wrote:
>> On Thu, Nov 19, 2015 at 1:55 PM, Boris Ostrovsky
>> <boris.ostrovsky@...cle.com> wrote:
>>> The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike the
>>> earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit
>>> (and sysret32 in compat mode) pv ops, as suggested by Andy.
>>>
>>> As result of this patch irq_enable_sysexit and usergs_sysret32 pv ops are not
>>> used anymore by anyone and so can be removed.
>> This whole series is:
>>
>> Acked-by: Andy Lutomirski <luto@...nel.org>
>>
>> Now I just have to sucker someone into getting rid of
>> PARAVIRT_ADJUST_EXCEPTION_FRAME (by using stub entries) and the
>> overcomplicated syscall entry stuff.  :)
>
> Looking at this, it should be quite easy now.
>
> ALTERNATIVE "", "pop %rcx; %pop %11", X86_FEATURE_XENPV
>
> (Completely untested)

Can't we do one better, though?  Generate a pile of stubs that do the
pops and jump into the normal native asm path.  Admittedly, that's a
lot more work, and I think that the ALTERNATIVE thing you're
suggesting would be a nice improvement.

>
>> And whoever gets rid of
>> PARAVIRT_ADJUST_EXCEPTION_FRAME gets to wonder why it doesn't crash
>> and burn for NMIs on Xen, since I'm reasonably confident that it can't
>> possibly be correct.
>
> The Xen PV ABI only has a single kernel stack pointer which may be
> registered.  There is no equivalent of an IST, so if a second fault
> occurs, it is delivered normally on the current stack.
>
> By the looks of it, the other NMI handling is ambivalent to the fact
> that it isn't really on an IST stack under Xen.

I'll try to find some time to look at it.

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