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:   Tue, 11 Jul 2017 10:21:52 +0200
From:   Christian Borntraeger <borntraeger@...ibm.com>
To:     Gleb Fotengauer-Malinovskiy <glebfm@...linux.org>
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Claudio Imbrenda <imbrenda@...ux.vnet.ibm.com>,
        "Dmitry V. Levin" <ldv@...linux.org>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] KVM: s390: Fix KVM_S390_GET_CMMA_BITS ioctl definition

On 07/10/2017 11:23 PM, Gleb Fotengauer-Malinovskiy wrote:
> On Mon, Jul 10, 2017 at 08:43:12PM +0200, Christian Borntraeger wrote:
>> On 07/10/2017 04:44 PM, Gleb Fotengauer-Malinovskiy wrote:
>>> This ioctl actually writes to parameter too.
>>
>> Maybe rephrase that to:
>> The kernel does not only read struct kvm_s390_cmma_log for KVM_S390_GET_CMMA_BITS,
>> it also writes back a return value making this _IOWR instead of _IOW.
> 
> Ok, see v2.
> 
>>> Fixes: 4036e387 ("KVM: s390: ioctls to get and set guest storage attributes")
>>> Signed-off-by: Gleb Fotengauer-Malinovskiy <glebfm@...linux.org>
>> Acked-by: Christian Borntraeger <borntraeger@...ibm.com>
>>
>>
>> Out of curiosity, how did you notice that? 
> 
> I regenerated strace's ioctl lists.  It was obvious from the diff that
> *GET* and *SET* could not be both _IOC_WRITE.
> 

In fact we do have multiple GET/SET ioctls in KVM, where both provide a control
block that is _IOC_WRITE only. That control block then has an address that will 
be read/written to depending on get/set. 
E.g. look at 
#define KVM_SET_DEVICE_ATTR       _IOW(KVMIO,  0xe1, struct kvm_device_attr)
#define KVM_GET_DEVICE_ATTR       _IOW(KVMIO,  0xe2, struct kvm_device_attr)

but as far as I understand, the direction hints only qualify the referenced
struct and not the side effects. So for KVM_*_DEVICE_ATTR it is correct to have
IOW for both cases.

But for GET_CMMA we do indeed write back data. 

Paolo, Radim,

if we want to fix the direction hint, it would be good to merge this in as soon
as possible. The new interface was added during this merge window.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ