linux-kernel - Re: [PATCH 1/3] mm: vmalloc: export __vmalloc_node

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: <ZppU8FhsFd9cB-Fi@freedom.csh.rit.edu>
Date: Fri, 19 Jul 2024 07:58:40 -0400
From: Mary Strodl <mstrodl@...edom.csh.rit.edu>
To: Christian Gmeiner <christian.gmeiner@...il.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	Matthew Wilcox <willy@...radead.org>,
	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 Fri, Jul 19, 2024 at 08:41:04AM +0200, Christian Gmeiner wrote:
> This wonderful interface is used in recent products from them too.
> Adding support for it
> in an upstream-able way could be still a benefit, as these products
> are used in different
> industrial environments running on Linux.

Just seconding this. The hardware we have here (conga-TCA7) was
released in 2021. As far as I know, congatec have been using this
interface for a while and provided a pretty bad out-of-tree driver
for it that needed a proprietary library in userspace to talk to
devices instead of actually registering with the kernel facilities
for i2c, watchdog, backlight, etc.

I think it's valuable functionality to support, but it'll need to
happen safely.

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?

Not sure what the restrictions on x86 are, but we could also start
with a writable page, then mark it executable when we un-mark it
writable.

I think this is good discussion, thanks for sharing your thoughts
everybody.