Re: Save a WRMSR GS.base?

[H. Peter Anvin]

On June 4, 2026 9:38:46 PM PDT, Borislav Petkov <bp@xxxxxxxxx> wrote:
>On Thu, Jun 04, 2026 at 09:30:33PM -0700, H. Peter Anvin wrote:
>> On June 4, 2026 9:26:52 PM PDT, Borislav Petkov <bp@xxxxxxxxx> wrote:
>> >On Thu, Jun 04, 2026 at 08:20:57PM -0700, H. Peter Anvin wrote:
>> >> I guess the question is why there is a "first" one.
>> >
>> >That happens when we do:
>> >
>> >x86_fsgsbase_load()
>> >
>> >	loadseg(GS) -> load_gs_index() -> native_load_gs_index() ->
>> >	  if (cpu_feature_enabled(X86_FEATURE_LKGS))
>> >                native_lkgs(selector);
>> >
>> >then back in x86_fsgsbase_load() we do:
>> >
>> >	__wrgsbase_inactive(next->gsbase);
>> >
>> >which does
>> >
>> >	wrmsrq(MSR_KERNEL_GS_BASE, gsbase);
>> >
>> >on FRED.
>> >
>> >But LKGS already wrote MSR_KERNEL_GS_BASE...
>> >
>> >> Logically the sequence should be LKGS first, if needed; then WRMSR(NS). LKGS
>> >> can be replaced with swapgs/mov gs/swapgs on legacy.
>> >
>> >Right.
>> >
>> >I think avoiding that second WRMSR(MSR_KERNEL_GS_BASE) should give some perf
>> >back...
>> >
>> >Although, I need to think how to make it pretty...
>> >
>> 
>> Should be doing wrmsrns...
>
>No, I think that second WRMSR* should not happen at all if we have executed
>LKGS which has already written MSR_KERNEL_GS_BASE, right?
>
>

You can't do that (at least not without further checks) if user space has WRGSBASE enabled, since you have no guarantee that the active GS.base is consistent with GS.selector.

Since GS > 3 is pretty rare in 64-bit code at least, it doesn't seem to be a code path that needs to be that heavily optimized.