[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v9 06/11] x86/entry: Organise the use of MSR_SPEC_CTRL at each entry/exit point



>>> On 19.01.18 at 14:36, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 19/01/18 11:43, Jan Beulich wrote:
>>>>> On 18.01.18 at 16:46, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> @@ -729,6 +760,9 @@ ENTRY(nmi)
>>>  handle_ist_exception:
>>>          SAVE_ALL CLAC
>>>  
>>> +        SPEC_CTRL_ENTRY_FROM_INTR /* Req: %rsp=regs, Clob: acd */
>>> +        /* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */
>> Following my considerations towards alternative patching to
>> eliminate as much overhead as possible from the Meltdown
>> band-aid in case it is being disabled, I'm rather hesitant to see any
>> patchable code being introduced into the NMI/#MC entry paths
>> without the patching logic first being made safe in this regard.
>> Exceptions coming here aren't very frequent (except perhaps on
>> hardware about to die), so the path isn't performance critical.
>> Therefore I think we should try to avoid any patching here, and
>> just conditionals instead. This in fact is one of the reasons why I
>> didn't want to macro-ize the assembly additions done in the
>> Meltdown band-aid.
>>
>> I do realize that this then also affects the exit-to-Xen path,
>> which I agree is less desirable to use conditionals on.
> 
> While I agree that our lack of IST-safe patching is a problem, these
> alternative points are already present on the NMI and MCE paths, and
> need to be.  As a result, the DF handler is in no worse of a position. 
> As a perfect example, observe the CLAC in context.

Oh, indeed. We should change that.

> I could perhaps be talked into making a SPEC_CTRL_ENTRY_FROM_IST variant
> which doesn't use alternatives (but IMO this is pointless in the
> presence of CLAC), but still don't think it is reasonable to treat DF
> differently to NMI/MCE.

#DF is debatable: On one hand I can see that if things go wrong,
it can equally be raised at any time. Otoh #MC and even more so
NMI can be raised _without_ things going (fatally) wrong, i.e. the
patching may break a boot which would otherwise have succeeded
(whereas the #DF would make the boot fail anyway).

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.