CHANGELOG.md | 4 +++ xen/arch/x86/hvm/hvm.c | 25 +++---------- xen/arch/x86/hvm/svm/svm.c | 46 +++++++++++------------- xen/arch/x86/hvm/svm/vmcb.c | 3 ++ xen/arch/x86/hvm/vmx/vmx.c | 4 +-- xen/arch/x86/include/asm/hvm/svm-types.h | 10 ------ xen/arch/x86/msr.c | 6 ++-- xen/lib/x86/policy.c | 3 +- 8 files changed, 38 insertions(+), 63 deletions(-)
pipeline: https://gitlab.com/xen-project/people/agvallejo/xen/-/pipelines/2277124833
(pipeline differs with the CHANGELOG patch being separate. Nothing functional)
As discussed in a prior RFC (https://lore.kernel.org/xen-devel/dc68b9ce-38aa-4949-b3e7-a7c0a7ee9a25@citrix.com/)
this series drops cross-vendor support. It includes the policy check that
was there and adds this on top:
* Eliminates #UD handler when HVM_FEP is disabled.
* Removes the cross-vendor checks from MSR handlers.
* Eliminate Intel-behaviour hacks for SYSENTER on AMD handlers and drop
intercept for SYSENTER.
Open question unrelated to the series: Does it make sense to conditionalise the
MSR handlers for non intercepted MSRs on HVM_FEP?
Cheers,
Alejandro
Alejandro Vallejo (4):
x86: Reject CPU policies with vendors other than the host's
x86/hvm: Disable non-FEP cross-vendor handling in #UD handler
x86/hvm: Remove cross-vendor checks from MSR handlers.
x86/svm: Drop emulation of Intel's SYSENTER behaviour
CHANGELOG.md | 4 +++
xen/arch/x86/hvm/hvm.c | 25 +++----------
xen/arch/x86/hvm/svm/svm.c | 46 +++++++++++-------------
xen/arch/x86/hvm/svm/vmcb.c | 3 ++
xen/arch/x86/hvm/vmx/vmx.c | 4 +--
xen/arch/x86/include/asm/hvm/svm-types.h | 10 ------
xen/arch/x86/msr.c | 6 ++--
xen/lib/x86/policy.c | 3 +-
8 files changed, 38 insertions(+), 63 deletions(-)
base-commit: 3001d9a19592bb4f12dab33f161ab2148513e30a
--
2.43.0
On 22/01/2026 4:49 pm, Alejandro Vallejo wrote: > Open question unrelated to the series: Does it make sense to conditionalise the > MSR handlers for non intercepted MSRs on HVM_FEP? I'm not quite sure what you're asking here. ~Andrew
On Thu Jan 22, 2026 at 6:10 PM CET, Andrew Cooper wrote: > On 22/01/2026 4:49 pm, Alejandro Vallejo wrote: >> Open question unrelated to the series: Does it make sense to conditionalise the >> MSR handlers for non intercepted MSRs on HVM_FEP? > > I'm not quite sure what you're asking here. > > ~Andrew The handlers for LSTAR and the like are dead code with !CONFIG_HVM_FEP as far as I can tell. The question I'm asking is whether there is another code path that might invoke MSR handlers for non-intercepted MSRs. I can't see it, but I'm not sure. If there isn't I'm considering (conditionally) getting rid of them. Cheers, Alejandro
On 22/01/2026 5:42 pm, Alejandro Vallejo wrote: > On Thu Jan 22, 2026 at 6:10 PM CET, Andrew Cooper wrote: >> On 22/01/2026 4:49 pm, Alejandro Vallejo wrote: >>> Open question unrelated to the series: Does it make sense to conditionalise the >>> MSR handlers for non intercepted MSRs on HVM_FEP? >> I'm not quite sure what you're asking here. >> >> ~Andrew > The handlers for LSTAR and the like are dead code with !CONFIG_HVM_FEP as far > as I can tell. The question I'm asking is whether there is another code path > that might invoke MSR handlers for non-intercepted MSRs. I can't see it, but > I'm not sure. > > If there isn't I'm considering (conditionally) getting rid of them. Introspection can (and HVMI does) hook them. Changes to LSTAR during runtime is usually an exploit in progress. Nested virt also makes it far more complicated to reason about "intercepted or not", given that there are multiple opinions merged together. ~Andrew
On Thu Jan 22, 2026 at 7:19 PM CET, Andrew Cooper wrote: > On 22/01/2026 5:42 pm, Alejandro Vallejo wrote: >> On Thu Jan 22, 2026 at 6:10 PM CET, Andrew Cooper wrote: >>> On 22/01/2026 4:49 pm, Alejandro Vallejo wrote: >>>> Open question unrelated to the series: Does it make sense to conditionalise the >>>> MSR handlers for non intercepted MSRs on HVM_FEP? >>> I'm not quite sure what you're asking here. >>> >>> ~Andrew >> The handlers for LSTAR and the like are dead code with !CONFIG_HVM_FEP as far >> as I can tell. The question I'm asking is whether there is another code path >> that might invoke MSR handlers for non-intercepted MSRs. I can't see it, but >> I'm not sure. >> >> If there isn't I'm considering (conditionally) getting rid of them. > > Introspection can (and HVMI does) hook them. Changes to LSTAR during > runtime is usually an exploit in progress. > > Nested virt also makes it far more complicated to reason about > "intercepted or not", given that there are multiple opinions merged > together. > > ~Andrew nSVM definitely would trigger those, ta. Conditionally removing nSVM is in our roadmap, and VMI is already gated on ALTP2M. I'll put this on the pile somewhere. Cheers, Alejandro
Le 22/01/2026 à 18:44, Alejandro Vallejo a écrit : > On Thu Jan 22, 2026 at 6:10 PM CET, Andrew Cooper wrote: >> On 22/01/2026 4:49 pm, Alejandro Vallejo wrote: >>> Open question unrelated to the series: Does it make sense to conditionalise the >>> MSR handlers for non intercepted MSRs on HVM_FEP? >> >> I'm not quite sure what you're asking here. >> >> ~Andrew > > The handlers for LSTAR and the like are dead code with !CONFIG_HVM_FEP as far > as I can tell. The question I'm asking is whether there is another code path > that might invoke MSR handlers for non-intercepted MSRs. I can't see it, but > I'm not sure. > > If there isn't I'm considering (conditionally) getting rid of them. > I think you can enter this path by making the guest execute directly or indirectly a rdmsr in a emulated path (there are some cases like certain cases of real mode or maybe vm introspection). I don't think that FEP is the only way to do that. > Cheers, > Alejandro > -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech
On Thu Jan 22, 2026 at 7:16 PM CET, Teddy Astie wrote:
> Le 22/01/2026 à 18:44, Alejandro Vallejo a écrit :
>> On Thu Jan 22, 2026 at 6:10 PM CET, Andrew Cooper wrote:
>>> On 22/01/2026 4:49 pm, Alejandro Vallejo wrote:
>>>> Open question unrelated to the series: Does it make sense to conditionalise the
>>>> MSR handlers for non intercepted MSRs on HVM_FEP?
>>>
>>> I'm not quite sure what you're asking here.
>>>
>>> ~Andrew
>>
>> The handlers for LSTAR and the like are dead code with !CONFIG_HVM_FEP as far
>> as I can tell. The question I'm asking is whether there is another code path
>> that might invoke MSR handlers for non-intercepted MSRs. I can't see it, but
>> I'm not sure.
>>
>> If there isn't I'm considering (conditionally) getting rid of them.
>>
>
> I think you can enter this path by making the guest execute directly or
> indirectly a rdmsr in a emulated path (there are some cases like certain
> cases of real mode or maybe vm introspection). I don't think that FEP is
> the only way to do that.
For the emulation path, I think HVM_FEP is the only means to trigger it, as
neither {rd,wr}msr access memory. VMI (as you mention) and nSVM (as Andrew did)
do make sense, but I don't see any others. I don't see how real mode could cause
anything (I'm fuzzy on VMX, but I _think_ instructions do execute, just in
a weird paging-on mode akin to v8086).
I'll munch on the idea I bit longer. If I can't come up with any other cases
I'll send something to remove that dead code for the cases in which it's truly
dead.
Cheers,
Alejandro
On 23.01.2026 13:10, Alejandro Vallejo wrote:
> On Thu Jan 22, 2026 at 7:16 PM CET, Teddy Astie wrote:
>> Le 22/01/2026 à 18:44, Alejandro Vallejo a écrit :
>>> On Thu Jan 22, 2026 at 6:10 PM CET, Andrew Cooper wrote:
>>>> On 22/01/2026 4:49 pm, Alejandro Vallejo wrote:
>>>>> Open question unrelated to the series: Does it make sense to conditionalise the
>>>>> MSR handlers for non intercepted MSRs on HVM_FEP?
>>>>
>>>> I'm not quite sure what you're asking here.
>>>>
>>>> ~Andrew
>>>
>>> The handlers for LSTAR and the like are dead code with !CONFIG_HVM_FEP as far
>>> as I can tell. The question I'm asking is whether there is another code path
>>> that might invoke MSR handlers for non-intercepted MSRs. I can't see it, but
>>> I'm not sure.
>>>
>>> If there isn't I'm considering (conditionally) getting rid of them.
>>>
>>
>> I think you can enter this path by making the guest execute directly or
>> indirectly a rdmsr in a emulated path (there are some cases like certain
>> cases of real mode or maybe vm introspection). I don't think that FEP is
>> the only way to do that.
>
> For the emulation path, I think HVM_FEP is the only means to trigger it, as
> neither {rd,wr}msr access memory. VMI (as you mention) and nSVM (as Andrew did)
> do make sense, but I don't see any others. I don't see how real mode could cause
> anything (I'm fuzzy on VMX, but I _think_ instructions do execute, just in
> a weird paging-on mode akin to v8086).
Iirc there's still the situation where for PAE shadow code tries to emulate up
to 4 insns in a row, in the hope to find the other half of a full PTE update.
Jan
On Fri Jan 23, 2026 at 3:05 PM CET, Jan Beulich wrote:
> On 23.01.2026 13:10, Alejandro Vallejo wrote:
>> On Thu Jan 22, 2026 at 7:16 PM CET, Teddy Astie wrote:
>>> Le 22/01/2026 à 18:44, Alejandro Vallejo a écrit :
>>>> On Thu Jan 22, 2026 at 6:10 PM CET, Andrew Cooper wrote:
>>>>> On 22/01/2026 4:49 pm, Alejandro Vallejo wrote:
>>>>>> Open question unrelated to the series: Does it make sense to conditionalise the
>>>>>> MSR handlers for non intercepted MSRs on HVM_FEP?
>>>>>
>>>>> I'm not quite sure what you're asking here.
>>>>>
>>>>> ~Andrew
>>>>
>>>> The handlers for LSTAR and the like are dead code with !CONFIG_HVM_FEP as far
>>>> as I can tell. The question I'm asking is whether there is another code path
>>>> that might invoke MSR handlers for non-intercepted MSRs. I can't see it, but
>>>> I'm not sure.
>>>>
>>>> If there isn't I'm considering (conditionally) getting rid of them.
>>>>
>>>
>>> I think you can enter this path by making the guest execute directly or
>>> indirectly a rdmsr in a emulated path (there are some cases like certain
>>> cases of real mode or maybe vm introspection). I don't think that FEP is
>>> the only way to do that.
>>
>> For the emulation path, I think HVM_FEP is the only means to trigger it, as
>> neither {rd,wr}msr access memory. VMI (as you mention) and nSVM (as Andrew did)
>> do make sense, but I don't see any others. I don't see how real mode could cause
>> anything (I'm fuzzy on VMX, but I _think_ instructions do execute, just in
>> a weird paging-on mode akin to v8086).
>
> Iirc there's still the situation where for PAE shadow code tries to emulate up
> to 4 insns in a row, in the hope to find the other half of a full PTE update.
>
> Jan
That's a rather obscure optimisation, thanks for bringing it up.
multi.c:sh_page_fault() is rather... opaque to just look at it and expect to
find anything.
Cheers,
Alejandro
On 23/01/2026 3:45 pm, Alejandro Vallejo wrote:
> On Fri Jan 23, 2026 at 3:05 PM CET, Jan Beulich wrote:
>> On 23.01.2026 13:10, Alejandro Vallejo wrote:
>>> On Thu Jan 22, 2026 at 7:16 PM CET, Teddy Astie wrote:
>>>> Le 22/01/2026 à 18:44, Alejandro Vallejo a écrit :
>>>>> On Thu Jan 22, 2026 at 6:10 PM CET, Andrew Cooper wrote:
>>>>>> On 22/01/2026 4:49 pm, Alejandro Vallejo wrote:
>>>>>>> Open question unrelated to the series: Does it make sense to conditionalise the
>>>>>>> MSR handlers for non intercepted MSRs on HVM_FEP?
>>>>>> I'm not quite sure what you're asking here.
>>>>>>
>>>>>> ~Andrew
>>>>> The handlers for LSTAR and the like are dead code with !CONFIG_HVM_FEP as far
>>>>> as I can tell. The question I'm asking is whether there is another code path
>>>>> that might invoke MSR handlers for non-intercepted MSRs. I can't see it, but
>>>>> I'm not sure.
>>>>>
>>>>> If there isn't I'm considering (conditionally) getting rid of them.
>>>>>
>>>> I think you can enter this path by making the guest execute directly or
>>>> indirectly a rdmsr in a emulated path (there are some cases like certain
>>>> cases of real mode or maybe vm introspection). I don't think that FEP is
>>>> the only way to do that.
>>> For the emulation path, I think HVM_FEP is the only means to trigger it, as
>>> neither {rd,wr}msr access memory. VMI (as you mention) and nSVM (as Andrew did)
>>> do make sense, but I don't see any others. I don't see how real mode could cause
>>> anything (I'm fuzzy on VMX, but I _think_ instructions do execute, just in
>>> a weird paging-on mode akin to v8086).
>> Iirc there's still the situation where for PAE shadow code tries to emulate up
>> to 4 insns in a row, in the hope to find the other half of a full PTE update.
>>
>> Jan
> That's a rather obscure optimisation, thanks for bringing it up.
> multi.c:sh_page_fault() is rather... opaque to just look at it and expect to
> find anything.
Shadow's hvm_shadow_emulator_ops doesn't fill in the MSR hooks, so
should at least abort when encountering this case.
But there are a lot of instructions which can fit in the restriction to
simple read/write/cmpxchg.
~Andrew
© 2016 - 2026 Red Hat, Inc.