linux-kernel - Re: [PATCH v3 11/18] dmaengine: idxd: ims setup for the vdcm

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: <20201009145236.GM4734@nvidia.com>
Date:   Fri, 9 Oct 2020 11:52:36 -0300
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Thomas Gleixner <tglx@...utronix.de>
CC:     Dave Jiang <dave.jiang@...el.com>, <vkoul@...nel.org>,
        <megha.dey@...el.com>, <maz@...nel.org>, <bhelgaas@...gle.com>,
        <alex.williamson@...hat.com>, <jacob.jun.pan@...el.com>,
        <ashok.raj@...el.com>, <yi.l.liu@...el.com>, <baolu.lu@...el.com>,
        <kevin.tian@...el.com>, <sanjay.k.kumar@...el.com>,
        <tony.luck@...el.com>, <jing.lin@...el.com>,
        <dan.j.williams@...el.com>, <kwankhede@...dia.com>,
        <eric.auger@...hat.com>, <parav@...lanox.com>, <rafael@...nel.org>,
        <netanelg@...lanox.com>, <shahafs@...lanox.com>,
        <yan.y.zhao@...ux.intel.com>, <pbonzini@...hat.com>,
        <samuel.ortiz@...el.com>, <mona.hossain@...el.com>,
        <dmaengine@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <x86@...nel.org>, <linux-pci@...r.kernel.org>,
        <kvm@...r.kernel.org>
Subject: Re: [PATCH v3 11/18] dmaengine: idxd: ims setup for the vdcm

On Fri, Oct 09, 2020 at 04:44:27PM +0200, Thomas Gleixner wrote:
> > This is really not that different from what I was describing for queue
> > contexts - the queue context needs to be assigned to the irq # before
> > it can be used in the irq chip other wise there is no idea where to
> > write the msg to. Just like pasid here.
> 
> Not really. In the IDXD case the storage is known when the host device
> and the irq domain is initialized which is not the case for your variant
> and it neither needs to send a magic command to the device to update the
> data.

I mean, needing the PASID vs needing the memory address before the IRQ
can be use are basically the same issue. Data needs to be attached to
the IRQ before it can be programmed.. In this case programming with
the wrong PASID could lead to a security issue.

> All the IDXD driver has to do is:
> 
>    auxval = ims_ctrl_pasid_aux(pasid, enabled);
>    irq_set_auxdata(irqnr, IMS_AUXDATA_CONTROL_WORD, auxval);
> 
> I agree that irq_set_auxdata() is not the most elegant thing, but the
> alternative solutions I looked at are just worse.

It seems reasonable, but quite an obfuscated way to tell a driver they
need to hold irq_get_desc_buslock() when touching data shared with the
irqchip ops.. Not that I have a better suggestion

Jason