[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZqBHwnPW_R4lFXVK@casper.infradead.org>
Date: Wed, 24 Jul 2024 01:16:02 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Mary Strodl <mstrodl@...edom.csh.rit.edu>,
Christian Gmeiner <christian.gmeiner@...il.com>,
Christoph Hellwig <hch@...radead.org>,
Mary Strodl <mstrodl@....rit.edu>, linux-kernel@...r.kernel.org,
urezki@...il.com, linux-mm@...ck.org, lee@...nel.org,
andi.shyti@...nel.org, linux-i2c@...r.kernel.org,
s.hauer@...gutronix.de
Subject: Re: [PATCH 1/3] mm: vmalloc: export __vmalloc_node_range
On Tue, Jul 23, 2024 at 05:00:43PM -0700, Andrew Morton wrote:
> On Fri, 19 Jul 2024 13:42:40 +0100 Matthew Wilcox <willy@...radead.org> wrote:
>
> > On Fri, Jul 19, 2024 at 07:58:40AM -0400, Mary Strodl wrote:
> > > Maybe some of the stuff the driver does right now could be moved into
> > > vmalloc? In other words, we could provide a different function that
> > > allocates an executable page, copies memory into it, then marks it
> > > read-only. Would that do better to alleviate concerns?
> >
> > No. We are not running arbitrary x86 code. That is a security
> > nightmare.
>
> Sure, if such a thing were to be done we'd want it localized within the
> driver rather than offered globally.
>
> But if there was some hack within the driver to do this, what problems
> might that cause? What are the scenarios?
That we're running arbitrary x86 code (provided by the manufacturer)
inside the kernel where it can undermine every security guarantee we
provide?
Powered by blists - more mailing lists