Re: [Xen-devel] [PATCH 2/2] x86/AMD: Fix handling of x87 exception pointers on Fam17h hardware

[Jan Beulich <jbeulich@xxxxxxxx>]

On 02.09.2019 16:15, Andrew Cooper wrote:
> On 29/08/2019 13:56, Jan Beulich wrote:
>> On 19.08.2019 20:26, Andrew Cooper wrote:
>>> AMD Pre-Fam17h CPUs "optimise" {F,}X{SAVE,RSTOR} by not saving/restoring
>>> FOP/FIP/FDP if an x87 exception isn't pending.  This causes an information
>>> leak, CVE-2006-1056, and worked around by several OSes, including Xen.  AMD
>>> Fam17h CPUs no longer have this leak, and advertise so in a CPUID bit.
>>>
>>> Introduce the RSTR_FP_ERR_PTRS feature, as specified by AMD, and expose to 
>>> all
>>> guests by default.  While adjusting libxl's cpuid table, add CLZERO which
>>> looks to have been omitted previously.
>>>
>>> Also introduce an X86_BUG bit to trigger the (F)XRSTOR workaround, and set 
>>> it
>>> on AMD hardware where RSTR_FP_ERR_PTRS is not advertised.  Optimise the
>>> workaround path by dropping the data-dependent unpredictable conditions 
>>> which
>>> will evalute to true for all 64bit OSes and most 32bit ones.
>> I definitely don't buy the "all 64bit OSes" part here: Anyone doing
>> full 80-bit FP operations will have to use the FPU, and hence may
>> want to have some unmasked exceptions.
> 
> And all 0 people doing that is still 0.
> 
> Yes I'm being a little facetious, but there is exceedingly little
> software which uses 80-bit FPU operations these days, as it has been
> superseded by SSE.

Just for your amusement, I run such software myself. When computing
fractals the extra bits of precision may matter quite a lot. Granted
I don't fancy running something like this on top of Xen.

>>  I'm also not sure why you
>> call them "unpredictable": If all (or most) cases match, the branch
>> there could be pretty well predicted (subject of course to capacity).
> 
> Data-dependent branches which have no correlation to pattern history, of
> which this is an example, are frequently mispredicted because they are
> inherently unstable.
> 
> In this case, you're trading off the fact that an unmasked exception is
> basically never pending, against the cost of mispredicts in the context
> switch path.

For

    if ( !(fpu_ctxt->fsw & ~fpu_ctxt->fcw & 0x003f) &&

you're claiming it to be true most of the time. How could the
predictor be mislead if whenever this is encountered the result
of the double & is zero?

>> All in all I'd prefer if the conditions remained in place; my minimal
>> request would be for there to be a comment why there's no evaluation
>> of FSW/FCW.
>>
>>> --- a/xen/arch/x86/i387.c
>>> +++ b/xen/arch/x86/i387.c
>>> @@ -43,20 +43,17 @@ static inline void fpu_fxrstor(struct vcpu *v)
>>>      const typeof(v->arch.xsave_area->fpu_sse) *fpu_ctxt = v->arch.fpu_ctxt;
>>>  
>>>      /*
>>> -     * AMD CPUs don't save/restore FDP/FIP/FOP unless an exception
>>> +     * Some CPUs don't save/restore FDP/FIP/FOP unless an exception
>> Are there any non-AMD CPUs known to have this issue? If not, is
>> there a particular reason you don't say "Some AMD CPUs ..."?
> 
> I'm not aware of any, but leaving it as "Some AMD" might become stale if
> others do surface.
> 
> Information about which CPUs are affected should exclusively be
> determined by the logic which sets cpu_bug_fpu_ptr_leak, which won't be
> stale.

Well, okay then.

>>>       * is pending. Clear the x87 state here by setting it to fixed
>>>       * values. The hypervisor data segment can be sometimes 0 and
>>>       * sometimes new user value. Both should be ok. Use the FPU saved
>>>       * data block as a safe address because it should be in L1.
>>>       */
>>> -    if ( !(fpu_ctxt->fsw & ~fpu_ctxt->fcw & 0x003f) &&
>>> -         boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
>>> -    {
>>> +    if ( cpu_bug_fpu_ptr_leak )
>>>          asm volatile ( "fnclex\n\t"
>>>                         "ffree %%st(7)\n\t" /* clear stack tag */
>>>                         "fildl %0"          /* load to clear state */
>>>                         : : "m" (*fpu_ctxt) );
>> If here and in the respective xsave instance you'd use alternatives
>> patching, I wouldn't mind the use of a X86_BUG_* for this (as made
>> possible by patch 1).
> 
> a) this should probably be a static branch if/when we gain that
> infrastructure, but ...
> 
>> But as said before, just like for synthetic
>> features I strongly think we should use simple boolean variables
>> when using them only in if()-s. Use of the feature(/bug) machinery
>> is needed only to not further complicate alternatives patching.
> 
> ... b)
> 
> I see I'm going to have to repeat myself, which is time I can't really
> afford to waste.
> 
> x86_capabilities is not, and has never been, "just for alternatives". 
> It is also not how it is currently used in Xen.

And I've not been claiming this. Nevertheless my opinion is that it
shouldn't be needlessly abused beyond its main purpose. I.e. deriving
cpu_has_* flags from it because features flags get collected this way
is certainly fine. But introducing artificial extensions is (imo) not.
I thought I had successfully convinced you of not adding synthetic
feature (non-bug) flags either anymore, unless needed for alternatives
patching.

Anyway - in the interest of forward progress, yet without being
convinced at all, I'll (as in so many earlier cases) give in here and
see about acking patch 1 then.

> I also don't agree with the general suggestion because amongst other
> things, there is a factor of 8 storage difference between one extra bit
> in x86_capabilities[] and using scattered booleans.

While a valid argument at the first glance, there's nothing keeping
us from having a feature flag independent bitmap. Correct my if I'm
wrong, but I've gained the impression that you want this mainly
because Linux does it this way.

> This series, and a number of related series, have been overdue for more
> than a year now, partly because of speculative preemption, but also
> partly because of attempted scope creep such as this.  Scope creep is
> having a catastrophic effect on the productivity of submissions to Xen,
> and most not continue like this the Xen community is to survive.

Judging from what I guess "scope creep" means, I'd say there would
have been less (rather than more) work for you if you hadn't made
patch 1 a prereq for this one.

As to the more general statement here - I'm afraid we're both guilty
of this, to a varying degree. Yet I think that it's mutually the
case because in such situations we sincerely think that things would
be done better a different way, perhaps in a number of cases e.g. to
avoid having to touch the same code later again.

>>  With this, keying the return to cpu_bug_* also doesn't
>> look very nice, but I admit I can't suggest a better alternative
>> (other than leaving the vendor check in place and checking the
>> X86_FEATURE_RSTR_FP_ERR_PTRS bit).
>>
>> An option might be to give the construct a different name, without
>> "leak" in it (NO_FP_ERR_PTRS?).
> 
> This name also isn't ideal, because its not always that there are no
> error pointers.
> 
> X86_BUG_FPU_PTRS might be best, as it is neutral as to precisely what is
> buggy with them.

Well, okay, let's use that one then and hope we won't learn of a 2nd
FPU_PTRS bug later on.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel