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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 28 Jul 2020 01:07:14 +0000
From:   Jianyong Wu <Jianyong.Wu@....com>
To:     Will Deacon <will@...nel.org>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "yangbo.lu@....com" <yangbo.lu@....com>,
        "john.stultz@...aro.org" <john.stultz@...aro.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "sean.j.christopherson@...el.com" <sean.j.christopherson@...el.com>,
        "maz@...nel.org" <maz@...nel.org>,
        "richardcochran@...il.com" <richardcochran@...il.com>,
        Mark Rutland <Mark.Rutland@....com>,
        Suzuki Poulose <Suzuki.Poulose@....com>,
        Steven Price <Steven.Price@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "kvmarm@...ts.cs.columbia.edu" <kvmarm@...ts.cs.columbia.edu>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        Steve Capper <Steve.Capper@....com>,
        Kaly Xin <Kaly.Xin@....com>, Justin He <Justin.He@....com>,
        Wei Chen <Wei.Chen@....com>, nd <nd@....com>
Subject: RE: [PATCH v13 2/9] arm/arm64: KVM: Advertise KVM UID to guests via
 SMCCC



> -----Original Message-----
> From: Will Deacon <will@...nel.org>
> Sent: Monday, July 27, 2020 7:38 PM
> To: Jianyong Wu <Jianyong.Wu@....com>
> Cc: netdev@...r.kernel.org; yangbo.lu@....com; john.stultz@...aro.org;
> tglx@...utronix.de; pbonzini@...hat.com; sean.j.christopherson@...el.com;
> maz@...nel.org; richardcochran@...il.com; Mark Rutland
> <Mark.Rutland@....com>; Suzuki Poulose <Suzuki.Poulose@....com>;
> Steven Price <Steven.Price@....com>; linux-kernel@...r.kernel.org; linux-
> arm-kernel@...ts.infradead.org; kvmarm@...ts.cs.columbia.edu;
> kvm@...r.kernel.org; Steve Capper <Steve.Capper@....com>; Kaly Xin
> <Kaly.Xin@....com>; Justin He <Justin.He@....com>; Wei Chen
> <Wei.Chen@....com>; nd <nd@....com>
> Subject: Re: [PATCH v13 2/9] arm/arm64: KVM: Advertise KVM UID to guests
> via SMCCC
> 
> On Mon, Jul 27, 2020 at 03:45:37AM +0000, Jianyong Wu wrote:
> > > From: Will Deacon <will@...nel.org>
> > >
> > > We can advertise ourselves to guests as KVM and provide a basic
> > > features bitmap for discoverability of future hypervisor services.
> > >
> > > Cc: Marc Zyngier <maz@...nel.org>
> > > Signed-off-by: Will Deacon <will@...nel.org>
> > > Signed-off-by: Jianyong Wu <jianyong.wu@....com>
> > > ---
> > >  arch/arm64/kvm/hypercalls.c | 29 +++++++++++++++++++----------
> > >  1 file changed, 19 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/arch/arm64/kvm/hypercalls.c
> > > b/arch/arm64/kvm/hypercalls.c index 550dfa3e53cd..db6dce3d0e23
> > > 100644
> > > --- a/arch/arm64/kvm/hypercalls.c
> > > +++ b/arch/arm64/kvm/hypercalls.c
> > > @@ -12,13 +12,13 @@
> > >  int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)  {
> > >  	u32 func_id = smccc_get_function(vcpu);
> > > -	long val = SMCCC_RET_NOT_SUPPORTED;
> > > +	u32 val[4] = {SMCCC_RET_NOT_SUPPORTED};
> >
> > There is a risk as this u32 value will return here and a u64 value
> > will be obtained in guest. For example, The val[0] is initialized as
> > -1 of 0xffffffff and the guest get 0xffffffff then it will be compared
> > with -1 of 0xffffffffffffffff Also this problem exists for the
> > transfer of address in u64 type. So the following assignment to "val"
> > should be split into two
> > u32 value and assign to val[0] and val[1] respectively.
> > WDYT?
> 
> Yes, I think you're right that this is a bug, but isn't the solution just to make
> that an array of 'long'?
> 
> 	long val [4];
> 
> That will sign-extend the negative error codes as required, while leaving the
> explicitly unsigned UID constants alone.

Ok, that's much better. I will fix it at next version.

By the way, I wonder when will you update this patch set. I see someone like me
adopt this patch set as code base and need rebase it every time, so expect your update.

Thanks
Jianyong 
> 
> Will

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ