linux-kernel - Re: [Xen-devel] [PATCH 1/1] XEN: Use correct masking in xen_swiotlb_alloc

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:	Tue, 4 Sep 2012 17:44:46 +0100
From:	David Vrabel <david.vrabel@...rix.com>
To:	Stefano Panella <stefano.panella@...rix.com>
CC:	David Vrabel <david.vrabel@...rix.com>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Subject: Re: [Xen-devel] [PATCH 1/1] XEN: Use correct masking in	xen_swiotlb_alloc_coherent.

On 04/09/12 16:12, Stefano Panella wrote:
> On 09/04/2012 03:55 PM, David Vrabel wrote:
>> On 04/09/12 15:37, Konrad Rzeszutek Wilk wrote:
>>> On Tue, Sep 04, 2012 at 03:07:42PM +0100, Stefano Panella wrote:
>>>> So if hwdev->coherent_dma_mask is set to 0xffffffffffffffff our
>>>> dma_mask will
>>>> be u64 set to 0xffffffffffffffff even if we set it to
>>>> DMA_BIT_MASK(32) previously.
>>> That is what I was missing. Let me include that in the git commit and
>>> also
>>> put this patch on the stable tree.
>> Note that this appears to be a work around for a bug in the sound system
>> or Intel HDA device driver which is incorrectly truncating a dma_addr_t
>> to a u32.  So by ensuring a DMA_BIT_MASK(32) when the dma_addr_t is
>> truncated it still works.
>>
>> David
> Sorry David, I am not completely sure I understand your argument in
> favour of a bug in the
> sound system or Intel HDA device driver. Could you please elaborate more
> in detail about this?

The HDA driver claims to support 64-bit DMA addresses, so it should be
perfectly fine for the Xen DMA mapping/allocation functions to return
DMA addresses > 4 GiB.  For most devices this seems to work just fine.

I think that somewhere between the buffer being mapped or allocated and
the address being programmed into the hardware, the 64-bit dma_addr_t
value is being truncated to 32 bits giving an invalid DMA address.

The patch would avoid this by setting the DMA mask to 32-bit and only
returning DMA address < 4 GiB which can quite happily be stuffed into a
u32 without losing bits.

I think it would be useful (without the patch applied) to print the DMA
addresses returned by the allocate/mapping functions and the address
programmed into the hardware.  It will be easily to spot if it got
truncated or not.

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