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]
Message-ID: <398dce4b-9290-0b14-28b1-e521331ec309@redhat.com>
Date:   Thu, 17 Oct 2019 10:33:59 +0800
From:   Jason Wang <jasowang@...hat.com>
To:     Christoph Hellwig <hch@....de>, Ram Pai <linuxram@...ibm.com>
Cc:     linux-kernel@...r.kernel.org, iommu@...ts.linux-foundation.org,
        linuxppc-dev@...ts.ozlabs.org,
        virtualization@...ts.linux-foundation.org,
        benh@...nel.crashing.org, david@...son.dropbear.id.au,
        mpe@...erman.id.au, paulus@...abs.org, mdroth@...ux.vnet.ibm.com,
        aik@...ux.ibm.com, paul.burton@...s.com, robin.murphy@....com,
        b.zolnierkie@...sung.com, m.szyprowski@...sung.com,
        andmike@...ibm.com, sukadev@...ux.vnet.ibm.com
Subject: Re: [PATCH 2/2] virtio_ring: Use DMA API if memory is encrypted


On 2019/10/15 下午3:35, Christoph Hellwig wrote:
> On Fri, Oct 11, 2019 at 06:25:19PM -0700, Ram Pai wrote:
>> From: Thiago Jung Bauermann <bauerman@...ux.ibm.com>
>>
>> Normally, virtio enables DMA API with VIRTIO_F_IOMMU_PLATFORM, which must
>> be set by both device and guest driver. However, as a hack, when DMA API
>> returns physical addresses, guest driver can use the DMA API; even though
>> device does not set VIRTIO_F_IOMMU_PLATFORM and just uses physical
>> addresses.
> Sorry, but this is a complete bullshit hack.  Driver must always use
> the DMA API if they do DMA, and if virtio devices use physical addresses
> that needs to be returned through the platform firmware interfaces for
> the dma setup.  If you don't do that yet (which based on previous
> informations you don't), you need to fix it, and we can then quirk
> old implementations that already are out in the field.
>
> In other words: we finally need to fix that virtio mess and not pile
> hacks on top of hacks.


I agree, the only reason for IOMMU_PLATFORM is to make sure guest works 
for some old and buggy qemu when vIOMMU is enabled which seems useless 
(note we don't even support vIOMMU migration in that case).

Thanks

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ