On Thu, Jan 25, 2024, Brilliant Hanabi wrote:
> As the kvm api(https://docs.kernel.org/virt/kvm/api.html) reads,
> KVM_CREATE_PIT2 call is only valid after enabling in-kernel irqchip
> support via KVM_CREATE_IRQCHIP.
>
> Without this check, I can create PIT first and enable irqchip-split
> then, which may cause the PIT invalid because of lacking of in-kernel
> PIC to inject the interrupt.
Does this cause actual problems beyond the PIT not working for the guest? E.g.
does it put the host kernel at risk? If the only problem is that the PIT doesn't
work as expected, I'm tempted to tweak the docs to say that KVM's PIT emulation
won't work without an in-kernel I/O APIC. Rejecting the ioctl could theoertically
break misconfigured setups that happen to work, e.g. because the guest never uses
the PIT.
> Signed-off-by: Brilliant Hanabi <[email protected]>
> ---
> arch/x86/kvm/x86.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 27e23714e960..3edc8478310f 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -7016,6 +7016,8 @@ int kvm_arch_vm_ioctl(struct file *filp, unsigned int ioctl, unsigned long arg)
> r = -EEXIST;
> if (kvm->arch.vpit)
> goto create_pit_unlock;
> + if (!pic_in_kernel(kvm))
> + goto create_pit_unlock;
-EEXIST is not an appropriate errno.
> r = -ENOMEM;
> kvm->arch.vpit = kvm_create_pit(kvm, u.pit_config.flags);
> if (kvm->arch.vpit)
> --
> 2.39.3
>
> On Thu, Jan 25, 2024, Brilliant Hanabi wrote:
> > As the kvm api(https://docs.kernel.org/virt/kvm/api.html) reads,
> > KVM_CREATE_PIT2 call is only valid after enabling in-kernel irqchip
> > support via KVM_CREATE_IRQCHIP.
> >
> > Without this check, I can create PIT first and enable irqchip-split
> > then, which may cause the PIT invalid because of lacking of in-kernel
> > PIC to inject the interrupt.
>
> Does this cause actual problems beyond the PIT not working for the guest? E.g.
> does it put the host kernel at risk? If the only problem is that the PIT doesn't
> work as expected, I'm tempted to tweak the docs to say that KVM's PIT emulation
> won't work without an in-kernel I/O APIC. Rejecting the ioctl could theoertically
> break misconfigured setups that happen to work, e.g. because the guest never uses
> the PIT.
I don't think it will put the host kernel at risk. But that's exactly what
kvmtool does: it creates in-kernel PIT first and set KVM_CREATE_IRQCHIP then.
I found this problem because I was working on implementing a userspace PIC
and PIT in kvmtool. As I planned, I'm going to commit a related patch to
kvmtool if this patch will be applied.
> > Signed-off-by: Brilliant Hanabi <[email protected]>
> > ---
> > arch/x86/kvm/x86.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index 27e23714e960..3edc8478310f 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -7016,6 +7016,8 @@ int kvm_arch_vm_ioctl(struct file *filp, unsigned int ioctl, unsigned long arg)
> > r = -EEXIST;
> > if (kvm->arch.vpit)
> > goto create_pit_unlock;
> > + if (!pic_in_kernel(kvm))
> > + goto create_pit_unlock;
>
> -EEXIST is not an appropriate errno.
Which errno do you think is better?
> > r = -ENOMEM;
> > kvm->arch.vpit = kvm_create_pit(kvm, u.pit_config.flags);
> > if (kvm->arch.vpit)
> > --
> > 2.39.3
> >
On Thu, Jan 25, 2024, moehanabi wrote:
> > On Thu, Jan 25, 2024, Brilliant Hanabi wrote:
> > > As the kvm api(https://docs.kernel.org/virt/kvm/api.html) reads,
> > > KVM_CREATE_PIT2 call is only valid after enabling in-kernel irqchip
> > > support via KVM_CREATE_IRQCHIP.
> > >
> > > Without this check, I can create PIT first and enable irqchip-split
> > > then, which may cause the PIT invalid because of lacking of in-kernel
> > > PIC to inject the interrupt.
> >
> > Does this cause actual problems beyond the PIT not working for the guest? E.g.
> > does it put the host kernel at risk? If the only problem is that the PIT doesn't
> > work as expected, I'm tempted to tweak the docs to say that KVM's PIT emulation
> > won't work without an in-kernel I/O APIC. Rejecting the ioctl could theoertically
> > break misconfigured setups that happen to work, e.g. because the guest never uses
> > the PIT.
>
> I don't think it will put the host kernel at risk. But that's exactly what
> kvmtool does: it creates in-kernel PIT first and set KVM_CREATE_IRQCHIP then.
Right. My concern, which could be unfounded paranoia, is that rejecting an ioctl()
that used to succeed could break existing setups. E.g. if a userspace VMM creates
a PIT and checks the ioctl() result, but its guest(s) never actually use the PIT
and so don't care that the PIT is busted.
> I found this problem because I was working on implementing a userspace PIC
> and PIT in kvmtool. As I planned, I'm going to commit a related patch to
> kvmtool if this patch will be applied.
>
> > > Signed-off-by: Brilliant Hanabi <[email protected]>
> > > ---
> > > arch/x86/kvm/x86.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > > index 27e23714e960..3edc8478310f 100644
> > > --- a/arch/x86/kvm/x86.c
> > > +++ b/arch/x86/kvm/x86.c
> > > @@ -7016,6 +7016,8 @@ int kvm_arch_vm_ioctl(struct file *filp, unsigned int ioctl, unsigned long arg)
> > > r = -EEXIST;
> > > if (kvm->arch.vpit)
> > > goto create_pit_unlock;
> > > + if (!pic_in_kernel(kvm))
> > > + goto create_pit_unlock;
> >
> > -EEXIST is not an appropriate errno.
>
> Which errno do you think is better?
Maybe ENOENT?
> On Thu, Jan 25, 2024, moehanabi wrote:
> > > On Thu, Jan 25, 2024, Brilliant Hanabi wrote:
> > > > As the kvm api(https://docs.kernel.org/virt/kvm/api.html) reads,
> > > > KVM_CREATE_PIT2 call is only valid after enabling in-kernel irqchip
> > > > support via KVM_CREATE_IRQCHIP.
> > > >
> > > > Without this check, I can create PIT first and enable irqchip-split
> > > > then, which may cause the PIT invalid because of lacking of in-kernel
> > > > PIC to inject the interrupt.
> > >
> > > Does this cause actual problems beyond the PIT not working for the guest? E.g.
> > > does it put the host kernel at risk? If the only problem is that the PIT doesn't
> > > work as expected, I'm tempted to tweak the docs to say that KVM's PIT emulation
> > > won't work without an in-kernel I/O APIC. Rejecting the ioctl could theoertically
> > > break misconfigured setups that happen to work, e.g. because the guest never uses
> > > the PIT.
> >
> > I don't think it will put the host kernel at risk. But that's exactly what
> > kvmtool does: it creates in-kernel PIT first and set KVM_CREATE_IRQCHIP then.
>
> Right. My concern, which could be unfounded paranoia, is that rejecting an ioctl()
> that used to succeed could break existing setups. E.g. if a userspace VMM creates
> a PIT and checks the ioctl() result, but its guest(s) never actually use the PIT
> and so don't care that the PIT is busted.
Thanks for your review. In my opinion, it is better to avoid
potential bugs which is difficult to detect, as long as you can
return errors to let developers know about them in advance, although
the kernel is not to blame for this bug.
> > I found this problem because I was working on implementing a userspace PIC
> > and PIT in kvmtool. As I planned, I'm going to commit a related patch to
> > kvmtool if this patch will be applied.
> >
> > > > Signed-off-by: Brilliant Hanabi <[email protected]>
> > > > ---
> > > > arch/x86/kvm/x86.c | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > > > index 27e23714e960..3edc8478310f 100644
> > > > --- a/arch/x86/kvm/x86.c
> > > > +++ b/arch/x86/kvm/x86.c
> > > > @@ -7016,6 +7016,8 @@ int kvm_arch_vm_ioctl(struct file *filp, unsigned int ioctl, unsigned long arg)
> > > > r = -EEXIST;
> > > > if (kvm->arch.vpit)
> > > > goto create_pit_unlock;
> > > > + if (!pic_in_kernel(kvm))
> > > > + goto create_pit_unlock;
> > >
> > > -EEXIST is not an appropriate errno.
> >
> > Which errno do you think is better?
>
> Maybe ENOENT?
>
I'm glad to send a new version patch if you're willing to accept the
patch.
On Thu, Jan 25, 2024, Brilliant Hanabi wrote:
> > On Thu, Jan 25, 2024, moehanabi wrote:
> > > > On Thu, Jan 25, 2024, Brilliant Hanabi wrote:
> > > > > As the kvm api(https://docs.kernel.org/virt/kvm/api.html) reads,
> > > > > KVM_CREATE_PIT2 call is only valid after enabling in-kernel irqchip
> > > > > support via KVM_CREATE_IRQCHIP.
> > > > >
> > > > > Without this check, I can create PIT first and enable irqchip-split
> > > > > then, which may cause the PIT invalid because of lacking of in-kernel
> > > > > PIC to inject the interrupt.
> > > >
> > > > Does this cause actual problems beyond the PIT not working for the guest? E.g.
> > > > does it put the host kernel at risk? If the only problem is that the PIT doesn't
> > > > work as expected, I'm tempted to tweak the docs to say that KVM's PIT emulation
> > > > won't work without an in-kernel I/O APIC. Rejecting the ioctl could theoertically
> > > > break misconfigured setups that happen to work, e.g. because the guest never uses
> > > > the PIT.
> > >
> > > I don't think it will put the host kernel at risk. But that's exactly what
> > > kvmtool does: it creates in-kernel PIT first and set KVM_CREATE_IRQCHIP then.
> >
> > Right. My concern, which could be unfounded paranoia, is that rejecting an ioctl()
> > that used to succeed could break existing setups. E.g. if a userspace VMM creates
> > a PIT and checks the ioctl() result, but its guest(s) never actually use the PIT
> > and so don't care that the PIT is busted.
>
> Thanks for your review. In my opinion, it is better to avoid potential bugs
> which is difficult to detect, as long as you can return errors to let
> developers know about them in advance, although the kernel is not to blame
> for this bug.
Oh, I completely agree that explict errors are far better. My only concern is
that there's a teeny tiny chance that rejecting an ioctl() that used to work
could break userspace.
> > > I found this problem because I was working on implementing a userspace PIC
> > > and PIT in kvmtool. As I planned, I'm going to commit a related patch to
> > > kvmtool if this patch will be applied.
> > >
> > > > > Signed-off-by: Brilliant Hanabi <[email protected]>
> > > > > ---
> > > > > arch/x86/kvm/x86.c | 2 ++
> > > > > 1 file changed, 2 insertions(+)
> > > > >
> > > > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > > > > index 27e23714e960..3edc8478310f 100644
> > > > > --- a/arch/x86/kvm/x86.c
> > > > > +++ b/arch/x86/kvm/x86.c
> > > > > @@ -7016,6 +7016,8 @@ int kvm_arch_vm_ioctl(struct file *filp, unsigned int ioctl, unsigned long arg)
> > > > > r = -EEXIST;
> > > > > if (kvm->arch.vpit)
> > > > > goto create_pit_unlock;
> > > > > + if (!pic_in_kernel(kvm))
> > > > > + goto create_pit_unlock;
> > > >
> > > > -EEXIST is not an appropriate errno.
> > >
> > > Which errno do you think is better?
> >
> > Maybe ENOENT?
> >
>
> I'm glad to send a new version patch if you're willing to accept the
> patch.
Go ahead and send v2. I'll get Paolo's thoughts on whether or not this is likely
to break userspace and we can go from there.
As the kvm api(https://docs.kernel.org/virt/kvm/api.html) reads,
KVM_CREATE_PIT2 call is only valid after enabling in-kernel irqchip
support via KVM_CREATE_IRQCHIP.
Without this check, I can create PIT first and enable irqchip-split
then, which may cause the PIT invalid because of lacking of in-kernel
PIC to inject the interrupt.
Signed-off-by: Tengfei Yu <[email protected]>
---
v1 -> v2: Change errno from -EEXIST to -ENOENT.
v1 link: https://lore.kernel.org/lkml/[email protected]/
arch/x86/kvm/x86.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 27e23714e960..c1e3aecd627f 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -7016,6 +7016,9 @@ int kvm_arch_vm_ioctl(struct file *filp, unsigned int ioctl, unsigned long arg)
r = -EEXIST;
if (kvm->arch.vpit)
goto create_pit_unlock;
+ r = -ENOENT;
+ if (!pic_in_kernel(kvm))
+ goto create_pit_unlock;
r = -ENOMEM;
kvm->arch.vpit = kvm_create_pit(kvm, u.pit_config.flags);
if (kvm->arch.vpit)
--
2.39.3
On Thu, Jan 25, 2024 at 12:59 AM Sean Christopherson <seanjc@googlecom> wrote:
> On Thu, Jan 25, 2024, Brilliant Hanabi wrote:
> > Thanks for your review. In my opinion, it is better to avoid potential bugs
> > which is difficult to detect, as long as you can return errors to let
> > developers know about them in advance, although the kernel is not to blame
> > for this bug.
>
> Oh, I completely agree that explict errors are far better. My only concern is
> that there's a teeny tiny chance that rejecting an ioctl() that used to work
> could break userspace.
>
> Go ahead and send v2. I'll get Paolo's thoughts on whether or not this is likely
> to break userspace and we can go from there.
I share the same worry but I agree it's quite unlikely. Let's just do
it, and if someone complains we'll revert it.
Paolo
On Thu, Jan 25, 2024 at 6:09 AM Tengfei Yu <[email protected]> wrote:
>
> As the kvm api(https://docs.kernel.org/virt/kvm/api.html) reads,
> KVM_CREATE_PIT2 call is only valid after enabling in-kernel irqchip
> support via KVM_CREATE_IRQCHIP.
>
> Without this check, I can create PIT first and enable irqchip-split
> then, which may cause the PIT invalid because of lacking of in-kernel
> PIC to inject the interrupt.
>
> Signed-off-by: Tengfei Yu <[email protected]>
Queued, thanks.
Paolo
> ---
> v1 -> v2: Change errno from -EEXIST to -ENOENT.
> v1 link: https://lore.kernel.org/lkml/[email protected]/
>
> arch/x86/kvm/x86.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 27e23714e960..c1e3aecd627f 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -7016,6 +7016,9 @@ int kvm_arch_vm_ioctl(struct file *filp, unsigned int ioctl, unsigned long arg)
> r = -EEXIST;
> if (kvm->arch.vpit)
> goto create_pit_unlock;
> + r = -ENOENT;
> + if (!pic_in_kernel(kvm))
> + goto create_pit_unlock;
> r = -ENOMEM;
> kvm->arch.vpit = kvm_create_pit(kvm, u.pit_config.flags);
> if (kvm->arch.vpit)
> --
> 2.39.3
>