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: <CAKv+Gu9QhknPp9k5X77vbbtELWqUzHLO26hpiv+rab5zjtHtOw@mail.gmail.com>
Date:   Tue, 18 Oct 2016 14:15:15 +0100
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Mike Travis <travis@....com>
Cc:     Takashi Iwai <tiwai@...e.de>, alsa-devel@...a-project.org,
        perex@...ex.cz,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ALSA: hda - allow 40 bit DMA mask for NVidia devices

On 18 October 2016 at 14:04, Mike Travis <travis@....com> wrote:
>
>
> On 10/18/2016 5:49 AM, Ard Biesheuvel wrote:
>> On 18 October 2016 at 13:46, Mike Travis <travis@....com> wrote:
>>>
>>> Have you tested this change on a system which has physical
>>> addressing > 40 bits to insure that addresses > 40 bits are
>>> not simply truncated to an incorrect (mod 40) address?
>>
>> The device should never see addresses > 40 bits, given that the DMA
>> mask is set to 40 bits not 64.
>
> I agree that the device should never see that.  But how is that
> restriction imposed?  If a user presents an buffer address > 40 bits
> how would that be converted to useful buffer at <= 40 bits?
>
> I believe I tried this (at the time the kernel was at version 2.6)
> and it did not work.  Since audio I/O was such a low (relative)
> bandwidth, it was not worth the effort to rework the audio code
> to allow buffers > 32 bits but <= 40 bits.  It may have changed
> since then?
>

This is very platform dependent. Note that the 40 bit DMA mask
describes the memory view from the PCI side, which may not be mapped
1:1 with system memory (although it usually is on x86)

In general, a platform will wire up the device to a struct dma_map_ops
{} instance that describes how DMA is performed for this particular
device on this platform. Whether it resorts to bounce buffering or
simply maps the buffer into the device accessible window using an
IOMMU is thus also platform dependent. But in general, all these
drivers ensure that the device address that results from a mapping
adheres to the DMA mask that has been set at probe time.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ