linux-kernel - Re: [PATCH v7 3/4] iommufd: Add IOMMU_GET_HW

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]

Message-ID: <ZNu2XWS0BERqykIA@Asurada-Nvidia>
Date:   Tue, 15 Aug 2023 10:31:09 -0700
From:   Nicolin Chen <nicolinc@...dia.com>
To:     Jason Gunthorpe <jgg@...dia.com>
CC:     Yi Liu <yi.l.liu@...el.com>, <joro@...tes.org>,
        <alex.williamson@...hat.com>, <kevin.tian@...el.com>,
        <robin.murphy@....com>, <baolu.lu@...ux.intel.com>,
        <cohuck@...hat.com>, <eric.auger@...hat.com>,
        <kvm@...r.kernel.org>, <mjrosato@...ux.ibm.com>,
        <chao.p.peng@...ux.intel.com>, <yi.y.sun@...ux.intel.com>,
        <peterx@...hat.com>, <jasowang@...hat.com>,
        <shameerali.kolothum.thodi@...wei.com>, <lulu@...hat.com>,
        <suravee.suthikulpanit@....com>, <iommu@...ts.linux.dev>,
        <linux-kernel@...r.kernel.org>, <linux-kselftest@...r.kernel.org>,
        <zhenzhong.duan@...el.com>
Subject: Re: [PATCH v7 3/4] iommufd: Add IOMMU_GET_HW_INFO

On Tue, Aug 15, 2023 at 01:32:01PM -0300, Jason Gunthorpe wrote:
> On Fri, Aug 11, 2023 at 12:15:00AM -0700, Yi Liu wrote:
> 
> > +static int iommufd_get_hw_info(struct iommufd_ucmd *ucmd)
> > +{
> > +	struct iommu_hw_info *cmd = ucmd->cmd;
> > +	unsigned int length = cmd->data_len;
> > +	struct iommufd_device *idev;
> > +	void __user *user_ptr;
> > +	u32 hw_info_type;
> > +	int rc = 0;
> > +
> > +	if (cmd->flags || cmd->__reserved || !cmd->data_len)
> > +		return -EOPNOTSUPP;
> 
> Is there a reason to block 0 data_len? I think this should work. The
> code looks OK?

I did a quick test passing !data_len and !data_ptr. And it works
by returning the type only.

Yet, in that case, should we mention this in the uAPI kdoc? It
feels to me that the uAPI always expects user space to read out
a length of data.

Thanks
Nic