lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 25 Jan 2024 03:01:58 +0800
From: Brilliant Hanabi <moehanabichan@...il.com>
To: seanjc@...gle.com
Cc: bp@...en8.de,
	dave.hansen@...ux.intel.com,
	hpa@...or.com,
	kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	mingo@...hat.com,
	moehanabichan@...il.com,
	pbonzini@...hat.com,
	tglx@...utronix.de,
	x86@...nel.org
Subject: Re: Re: Re: [PATCH] KVM: x86: Check irqchip mode before create PIT

> 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 <moehanabichan@...il.com>
> > > > ---
> > > >  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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ