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: <MN2PR05MB6141B6D7E28A146EBF9CE79FA1470@MN2PR05MB6141.namprd05.prod.outlook.com>
Date:   Thu, 28 Nov 2019 08:02:16 +0000
From:   Thomas Hellstrom <thellstrom@...are.com>
To:     "hch@....de" <hch@....de>
CC:     "thomas.lendacky@....com" <thomas.lendacky@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "christian.koenig@....com" <christian.koenig@....com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Subject: Re: [PATCH 2/2] dma-mapping: force unencryped devices are always
 addressing limited

On 11/28/19 8:51 AM, hch@....de wrote:
> On Wed, Nov 27, 2019 at 06:22:57PM +0000, Thomas Hellstrom wrote:
>>>  bool dma_addressing_limited(struct device *dev)
>>>  {
>>> +	if (force_dma_unencrypted(dev))
>>> +		return true;
>>>  	return min_not_zero(dma_get_mask(dev), dev->bus_dma_limit) <
>>>  			    dma_get_required_mask(dev);
>>>  }
>> Any chance to have the case
>>
>> (swiotlb_force == SWIOTLB_FORCE)
>>
>> also included?
> We have a hard time handling that in generic code.  Do we have any
> good use case for SWIOTLB_FORCE not that we have force_dma_unencrypted?
> I'd love to be able to get rid of it..
>
IIRC the justification for it is debugging. Drivers that don't do
syncing correctly or have incorrect assumptions of initialization of DMA
memory will not work properly when SWIOTLB is forced. We recently found
a vmw_pvscsi device flaw that way...

/Thomas



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ