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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87d01rtmj8.fsf@nanos.tec.linutronix.de>
Date:   Fri, 09 Oct 2020 18:02:51 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Jason Gunthorpe <jgg@...dia.com>
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 11:52, Jason Gunthorpe wrote:
> 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.

Yeah. I looked at doing it similar to the callback I added for
retrieving the shadow storage pointer, but the PASID is not necessarily
established at that point.

>> 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

It's an obfuscated way to make obfuscated hardware supported :)

Thanks,

        tglx