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]
Date:	Wed, 23 Jul 2008 19:47:03 -0400
From:	Prarit Bhargava <prarit@...hat.com>
To:	joro@...tes.org
CC:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
	linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
	jbarnes@...tuousgeek.org, ed.pollard@....com, epollard@...hat.com
Subject: Re: [PATCH]: PCI: GART iommu alignment fixes [v2]


>> Interesting. Have you experienced any problems because of that
>> misbehavior in the GART code? AMD IOMMU currently also violates this
>> requirement. I will send a patch to fix that there too.
>>     
>
>   

Joerg,  yes I can see misbehavior caused by this code.  O/w I wouldn't 
be spending my time fixing it :) :)

See below ....

> IIRC, only PARISC and POWER IOMMUs follow the above rule. So I also
> wondered what problem he hit.
>   

I wonder if IBM's Calgary IOMMU needs this fix? ... I've added Ed 
Pollard to find out.

On big memory footprint (16G or above) systems it is possible that the 
e820 map reserves most of the lower 4G of memory for system use*.  So 
it's possible that the 4G region is almost completely reserved at boot 
time and so the kernel starts using the IOMMU for DMA (see 
dma_alloc_coherent()).  The addresses returned are not properly aligned, 
and this causes serious problems for some drivers that require a 
physical aligned address for the device.

P.

* I have one large system with 64G of memory on which I can reproduce 
this issue very quickly.  Even booting the system with mem=16G seems to 
cause the problem, although I did have to load a module that reserved a 
few M of DMA addresses before I started alloc'ing from the IOMMU.

I also reproduced this on a smaller system by loading one module that 
reserved as much DMA-able region as possible, and then loaded another 
module that reserved from the IOMMU.  While this situation is a bit 
contrived the bug still hit -- the returned addresses are not properly 
aligned.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ