linux-kernel - Re: [PATCH v2] hypervisor/x86/xen: Unset X86_BUG_SYSRET_SS

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] [day] [month] [year] [list]

Date:	Tue, 05 May 2015 10:21:28 -0400
From:	Boris Ostrovsky <boris.ostrovsky@...cle.com>
To:	Andy Lutomirski <luto@...capital.net>
CC:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	David Vrabel <david.vrabel@...rix.com>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>,
	linux@...elenboom.it
Subject: Re: [PATCH v2] hypervisor/x86/xen: Unset X86_BUG_SYSRET_SS_ATTRS
 on Xen PV guests

On 05/05/2015 09:51 AM, Andy Lutomirski wrote:
> On Mon, May 4, 2015 at 8:02 AM, Boris Ostrovsky
> <boris.ostrovsky@...cle.com> wrote:
>> Commit 61f01dd941ba ("x86_64, asm: Work around AMD SYSRET SS descriptor
>> attribute issue") makes AMD processors set SS to __KERNEL_DS in
>> __switch_to() to deal with cases when SS is NULL.
>>
>> This breaks Xen PV guests who do not want to load SS with__KERNEL_DS.
>>
>> Since the problem that the commit is trying to address would have to be
>> fixed in the hypervisor (if it in fact exists under Xen) there is no
>> reason to set X86_BUG_SYSRET_SS_ATTRS flag for PV VPCUs here.
>>
>> This can be easily achieved by adding x86_hyper_xen_hvm.set_cpu_features
>> op which will clear this flag. (And since this structure is no longer
>> HVM-specific we should do some renaming).
> Looks good to me, but:
>
>>   static void __init xen_hvm_guest_init(void)
>>   {
>> +       if (xen_pv_domain())
>> +               return;
>> +
> How can a platform be "hvm" and "pv"?  Is that the PVHVM thing?

No, this is meant for "true" PV guest not to go through HVM-specific 
initialization.

We have to do it since now x86_hyper_xen_hvm (renamed to x86_hyper_xen) 
will have init_platform() op and so init_hypervisor_platform() will call 
it obviously without knowing the type of the guest.

>
>> +static void xen_set_cpu_features(struct cpuinfo_x86 *c)
>> +{
>> +       if (xen_pv_domain())
>> +               clear_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS);
>> +}
> I haven't followed all the twists and turns, but, if the guest
> platform is such that the guest kernel is really executing SYSRET and
> we're on AMD, then we have the sysret_ss_attrs bug.  If PVHVM has
> xen_pv_domain() returning true but also uses SYSRET for real, then
> this looks wrong.

HVM guests execute SYSRET and they will continue having 
X86_BUG_SYSRET_SS_ATTRS flag on. PV guests OTOH don't do SYSRET, the 
hypervisor does (which is why if this issue is to be fixed it would have 
to be done in the hypervisor).

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