> On Jun 5, 2023, at 12:35 PM, Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote:
>
> On Mon, Jun 05, 2023 at 02:29:02PM +0000, Jon Kohler wrote:
>>
>>
>>> On Jun 1, 2023, at 12:23 AM, Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote:
>>>
>>> On Wed, May 31, 2023 at 06:24:29PM -0700, Pawan Gupta wrote:
>>>
>>> ## 2023-05-31
>>>> On Thu, Jun 01, 2023 at 01:50:48AM +0100, Andrew Cooper wrote:
>>>>> On 01/06/2023 1:42 am, Josh Poimboeuf wrote:
>>>>>> So each LFENCE has a distinct purpose. That said, there are no indirect
>>>>>> branches or unbalanced RETs between them.
>>>>>
>>>>> How lucky are you feeling?
>>>>>
>>>>> You're in C at this point, which means the compiler could have emitted a
>>>>> call to mem{cpy,cmp}() in place of a simple assignment/comparison.
>>>>
>>>> Moving the second LFENCE to the else part of WRMSR should be possible?
>>>> So that the serialization can be achived either by WRMSR or LFENCE. This
>>>> saves an LFENCE when host and guest value of MSR_SPEC_CTRL differ.
>>>
>>> Yes. Though in practice it might not make much of a difference. With
>>> wrmsr+lfence, the lfence has nothing to do so it might be almost
>>> instantaneous anyway.
>>>
>>> --
>>> Josh
>>
>> Coming back to this, what if we hoisted call vmx_spec_ctrl_restore_host above
>> FILL_RETURN_BUFFER, and dropped this LFENCE as I did here?
>>
>> That way, we wouldn’t have to mess with the internal LFENCE in nospec-branch.h,
>> and that would act as the “final line of defense” LFENCE.
>>
>> Would that be acceptable? Or does FILL_RETURN_BUFFER *need* to occur
>> before any sort of calls no matter what?
>
> If we go by Intel's statement that only unbalanced RETs are a concern,
> that *might* be ok as long as there's a nice comment above the
> FILL_RETURN_BUFFER usage site describing the two purposes for the
> LFENCE.
>
> However, based on Andy's concerns, which I've discussed with him
> privately (but I'm not qualified to agree or disagree with), we may want
> to just convert vmx_spec_ctrl_restore_host() to asm. Better safe than
> sorry. My original implementation of that function was actually asm. I
> can try to dig up that code.
>
> --
> Josh
RE ASM - that’d be nice, given that the restore guest pre-vmentry is now ASM,
would match nicely. Then all the code is in one spot, in one file, in one language.
If you could dig that up so we didn’t have to start from scratch, that’d be great (imho).
Jon
