linux-kernel - Re: [BUG] pgprot_noncached() is -NOT- safe for mapping vmalloc buffers into userspace

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:	Fri, 25 Mar 2011 20:15:33 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Takashi Iwai <tiwai@...e.de>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
	linux-arch@...r.kernel.org, Matthew Evans <matt.evans@....ibm.com>
Subject: Re: [BUG] pgprot_noncached() is -NOT- safe for mapping vmalloc
 buffers into userspace

On Fri, 2011-03-25 at 09:01 +0100, Takashi Iwai wrote:
> > In fact, cache coherent architectures often don't support mapping memory
> > uncached -at-all- so something like snd_pcm_lib_mmap_noncached()
> > shouldn't exist, or at least be under arch control. There's no case
> > where it's "always safe". There will almost always be a cache alias in
> > the linear mapping unless special arch specific sauce has been applied.
> 
> I see.  I'll take your removal patch.
> It should be applied to stable kernel, too, right?

I suppose so :-)

> > Now, there's another problem on top of that, which is that
> > snd_pcm_default_mmap() will not work properly the "other way around" on
> > powerpc, where the mapping -needs- to be uncached bcs you are running on
> > a non cache coherent embedded CPU and trying to mmap DMA memory, but
> > that's something that needs fixing inside powerpc by properly defining
> > dma_mmap_coherent() & ARCH_HAS_DMA_MMAP_COHERENT (I thought we had added
> > it a while back but it's not upstream, patch must have got lost).
> 
> Mea culpa.  I moved to a different team and have had little time for
> the upstream development since then...

That's ok, I did a new one, which you have noticed already anyways :-)

> > We
> > must also make sure we don't go down that path for vmalloc memory
> > though.
>
> Yes.

I haven't actually checked, but I assume that the test

substream->dma_buffer.dev.type == SNDRV_DMA_TYPE_DEV

In snd_pcm_default_mmap() takes care of that, please correct me if
I'm wrong in which case we'll need something else there.

> Your patch looks good.  Thanks for taking care of this! 

Are you taking care of sending it upstream ?

Cheers,
Ben.


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