All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juergen Gross <jgross@suse.com>
To: Borislav Petkov <bp@alien8.de>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org, mingo@redhat.com,
	hpa@zytor.com, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero
Date: Tue, 25 Apr 2017 20:34:34 +0200	[thread overview]
Message-ID: <f3cf034d-1a26-cfce-cf67-ebaa3b377cfc__27492.3041499735$1493145336$gmane$org@suse.com> (raw)
In-Reply-To: <20170425182443.3ab75tkfosol2yk4@pd.tnic>

On 25/04/17 20:24, Borislav Petkov wrote:
> On Tue, Apr 25, 2017 at 08:00:14PM +0200, Juergen Gross wrote:
>> When running as Xen pv guest X86_BUG_SYSRET_SS_ATTRS must not be set
>> on AMD cpus. Xen will disable this via setup_clear_cpu_cap(), so test
>> cpu_caps_cleared to not have disabled this bit.
>>
>> This bug/feature bit is kind of special as it will be used very early
>> when switching threads. Setting the bit and clearing it a little bit
>> later leaves a critical window where things can go wrong. This time
>> window has enlarged a little bit by using setup_clear_cpu_cap() instead
>> of the hypervisor's set_cpu_features callback. It seems this larger
>> window now makes it rather easy to hit the problem.
>>
>> The proper solution is to never set the bit in case of Xen.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>>  arch/x86/kernel/cpu/amd.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
>> index c36140d788fe..f659b6f534b7 100644
>> --- a/arch/x86/kernel/cpu/amd.c
>> +++ b/arch/x86/kernel/cpu/amd.c
>> @@ -800,7 +800,9 @@ static void init_amd(struct cpuinfo_x86 *c)
>>  			set_cpu_cap(c, X86_FEATURE_3DNOWPREFETCH);
>>  
>>  	/* AMD CPUs don't reset SS attributes on SYSRET */
>> -	set_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS);
>> +	if (!test_bit(X86_BUG_SYSRET_SS_ATTRS,
>> +		      (unsigned long *)cpu_caps_cleared))
>> +		set_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS);
>>  }
> 
> Hold on, AFAICT we have this order:
> 
> c_init() -> init_amd() sets X86_BUG_SYSRET_SS_ATTRS

And what happens when there is a scheduling event right here?
__switch_to() will see X86_BUG_SYSRET_SS_ATTRS set and take a wrong
path.

> init_hypervisor->x86_hyper->set_cpu_features-> clear_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS);

And now (with setup_clear_cpu_cap()) the bit is cleared a little bit
later. And all should be good. But it isn't.

> 
> and all is good.
> 
> And I remember seeing a patchset doing some xen cpuid cleanup so I'm
> assuming you're doing setup_clear_cpu_cap() now? And now we have to wag
> the dog?

No, now the time window with X86_BUG_SYSRET_SS_ATTRS set is so long we
actually see the problem happening.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  parent reply	other threads:[~2017-04-25 18:34 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-25 18:00 [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero Juergen Gross
2017-04-25 18:24 ` Borislav Petkov
2017-04-25 18:24 ` Borislav Petkov
2017-04-25 18:34   ` Juergen Gross
2017-04-25 19:18     ` Borislav Petkov
2017-04-25 20:17       ` [Xen-devel] " Andrew Cooper
2017-04-25 20:27         ` Borislav Petkov
2017-04-25 20:27         ` [Xen-devel] " Borislav Petkov
2017-04-25 20:17       ` Andrew Cooper
2017-04-26  4:45       ` Juergen Gross
2017-04-26  6:35         ` Borislav Petkov
2017-04-26  6:35         ` Borislav Petkov
2017-04-26 18:24           ` Juergen Gross
2017-04-26 18:24           ` Juergen Gross
2017-04-26 22:04             ` Borislav Petkov
2017-04-26 22:04             ` Borislav Petkov
2017-04-27  4:44               ` Juergen Gross
2017-04-27  4:44               ` Juergen Gross
2017-04-26  4:45       ` Juergen Gross
2017-04-25 19:18     ` Borislav Petkov
2017-04-25 18:34   ` Juergen Gross [this message]
2017-04-25 18:00 Juergen Gross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='f3cf034d-1a26-cfce-cf67-ebaa3b377cfc__27492.3041499735$1493145336$gmane$org@suse.com' \
    --to=jgross@suse.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.