[PATCH v2 4/5] KVM: arm64: Prevent host from managing timer offsets for protected VMs
Fuad Tabba
tabba at google.com
Sun Nov 9 11:51:21 PST 2025
Hi Oliver,
On Fri, 7 Nov 2025 at 23:21, Oliver Upton <oupton at kernel.org> wrote:
>
> On Thu, Nov 06, 2025 at 02:44:16PM +0000, Fuad Tabba wrote:
> > For protected VMs, the guest's timer offset state is private and must
> > not be controlled by the host. Protected VMs must always run with a
> > virtual counter offset of 0.
> >
> > The existing timer logic allowed the host to set and manage the timer
> > counter offsets (voffset and poffset) for protected VMs.
> >
> > This patch disables all host-side management of timer offsets for
> > protected VMs by adding checks in the relevant code paths.
>
> "This patch ..." is generally discouraged in changelogs, just state what
> you're doing in an imperative tone.
Ack.
> > Signed-off-by: Fuad Tabba <tabba at google.com>
> > ---
> > arch/arm64/kvm/arch_timer.c | 18 +++++++++++++-----
> > arch/arm64/kvm/sys_regs.c | 6 ++++--
> > 2 files changed, 17 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/arch_timer.c b/arch/arm64/kvm/arch_timer.c
> > index 3f675875abea..69f5631ebf84 100644
> > --- a/arch/arm64/kvm/arch_timer.c
> > +++ b/arch/arm64/kvm/arch_timer.c
> > @@ -1056,10 +1056,14 @@ static void timer_context_init(struct kvm_vcpu *vcpu, int timerid)
> >
> > ctxt->timer_id = timerid;
> >
> > - if (timerid == TIMER_VTIMER)
> > - ctxt->offset.vm_offset = &kvm->arch.timer_data.voffset;
> > - else
> > - ctxt->offset.vm_offset = &kvm->arch.timer_data.poffset;
> > + if (!kvm_vm_is_protected(vcpu->kvm)) {
> > + if (timerid == TIMER_VTIMER)
> > + ctxt->offset.vm_offset = &kvm->arch.timer_data.voffset;
> > + else
> > + ctxt->offset.vm_offset = &kvm->arch.timer_data.poffset;
> > + } else {
> > + ctxt->offset.vm_offset = NULL;
> > + }
> >
> > hrtimer_setup(&ctxt->hrtimer, kvm_hrtimer_expire, CLOCK_MONOTONIC, HRTIMER_MODE_ABS_HARD);
> >
> > @@ -1083,7 +1087,8 @@ void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu)
> > timer_context_init(vcpu, i);
> >
> > /* Synchronize offsets across timers of a VM if not already provided */
> > - if (!test_bit(KVM_ARCH_FLAG_VM_COUNTER_OFFSET, &vcpu->kvm->arch.flags)) {
> > + if (!vcpu_is_protected(vcpu) &&
> > + !test_bit(KVM_ARCH_FLAG_VM_COUNTER_OFFSET, &vcpu->kvm->arch.flags)) {
> > timer_set_offset(vcpu_vtimer(vcpu), kvm_phys_timer_read());
> > timer_set_offset(vcpu_ptimer(vcpu), 0);
> > }
> > @@ -1687,6 +1692,9 @@ int kvm_vm_ioctl_set_counter_offset(struct kvm *kvm,
> > if (offset->reserved)
> > return -EINVAL;
> >
> > + if (kvm_vm_is_protected(kvm))
> > + return -EBUSY;
> > +
>
> This should be -EINVAL as pVMs do not even advertise the capability.
>
> Since we already have a generic helper for filtering KVM_CAPs, I'd
> prefer that we have a similar thing for enforcing ioctl limitations too.
>
> For example, you could maintain the ioctl => KVM_CAP mapping in a table
> and use kvm_pvm_ext_allowed() as the source of truth.
Yes, it makes more sense to consolidate these checks. Will do this
when I respin.
> > mutex_lock(&kvm->lock);
> >
> > if (!kvm_trylock_all_vcpus(kvm)) {
> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> > index e67eb39ddc11..3329a8f03436 100644
> > --- a/arch/arm64/kvm/sys_regs.c
> > +++ b/arch/arm64/kvm/sys_regs.c
> > @@ -1606,11 +1606,13 @@ static int arch_timer_set_user(struct kvm_vcpu *vcpu,
> > val &= ~ARCH_TIMER_CTRL_IT_STAT;
> > break;
> > case SYS_CNTVCT_EL0:
> > - if (!test_bit(KVM_ARCH_FLAG_VM_COUNTER_OFFSET, &vcpu->kvm->arch.flags))
> > + if (!vcpu_is_protected(vcpu) &&
> > + !test_bit(KVM_ARCH_FLAG_VM_COUNTER_OFFSET, &vcpu->kvm->arch.flags))
> > timer_set_offset(vcpu_vtimer(vcpu), kvm_phys_timer_read() - val);
> > return 0;
> > case SYS_CNTPCT_EL0:
> > - if (!test_bit(KVM_ARCH_FLAG_VM_COUNTER_OFFSET, &vcpu->kvm->arch.flags))
> > + if (!vcpu_is_protected(vcpu) &&
> > + !test_bit(KVM_ARCH_FLAG_VM_COUNTER_OFFSET, &vcpu->kvm->arch.flags))
> > timer_set_offset(vcpu_ptimer(vcpu), kvm_phys_timer_read() - val);
>
> Isn't there a general expectation that userspace not have access to the
> vCPU state of a pVM? That should be the mechanism of enforcement instead
> of special-casing these registers.
I thought I had a good reason for these checks, but now I cannot
remember what it was, nor can I see that there is a good reason, since
like you said, they are not accessible.
I'll remove them,
Cheers,
/fuad
> Thanks,
> Oliver
More information about the linux-arm-kernel
mailing list