[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161214165856.GD17255@8bytes.org>
Date: Wed, 14 Dec 2016 17:58:56 +0100
From: Joerg Roedel <joro@...tes.org>
To: Andy Lutomirski <luto@...capital.net>
Cc: David Laight <David.Laight@...lab.com>,
David Woodhouse <dwmw2@...radead.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Ingo Molnar <mingo@...nel.org>,
Andy Lutomirski <luto@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
"dhowells@...hat.com" <dhowells@...hat.com>,
"keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
Eric Biggers <ebiggers3@...il.com>,
"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
Herbert Xu <herbert@...dor.apana.org.au>,
Stephan Mueller <smueller@...onox.de>
Subject: Re: [PATCH] keys/encrypted: Fix two crypto-on-the-stack bugs
On Tue, Dec 13, 2016 at 08:40:00AM -0800, Andy Lutomirski wrote:
> But I think this is rather silly. Joerg, Linus, etc: would it be okay
> to change lib/dma-debug.c to allow DMA *from* rodata?
Yeah, this would be fine for DMA_TO_DEVICE mappings. At least I can't
think of a reason right now to not allow it, in the end its also
read-only memory for the CPU, so it can be readable by devices too.
There is no danger of race conditions like on stacks or data leaks, as
there is only compile-time data in rodata.
Joerg
Powered by blists - more mailing lists