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: <20240718143103.82e33c556b2d1b6145ae43e0@linux-foundation.org>
Date: Thu, 18 Jul 2024 14:31:03 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Mary Strodl <mstrodl@...edom.csh.rit.edu>
Cc: 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, christian.gmeiner@...il.com
Subject: Re: [PATCH 1/3] mm: vmalloc: export __vmalloc_node_range

On Thu, 18 Jul 2024 09:20:15 -0400 Mary Strodl <mstrodl@...edom.csh.rit.edu> wrote:

> On Thu, Jul 18, 2024 at 01:53:23PM +0100, Matthew Wilcox wrote:
> > That does work, but I would assume that since this BIOS exists to
> > communicate with the hardware that it'd need various special privileges
> > and that running in ring 3 would not work.
> 
> Exactly.
>  
> > Ultimately, better off running the whole thing inside a VM and passing
> > the device through to the guest.  Or ignoring the BIOS entirely and
> > implementing direct access to the hardware.  But neither of these
> > approaches is "a way to do what I'm trying to do", they're entirely
> > different approaches to making this hardware work.
> 
> If I ran the whole thing inside a VM, I would still need support in the
> kernel, right?
> 
> As far as I know, there is no documentation on Congatec's side about the
> underlying interface. Obviously I could disassemble the blob in the BIOS
> and figure it out, but I suspect that will have much less hardware
> compatibility and be subject to random breakage if they make a BIOS
> update or something. Plus, I would probably run afoul of copyright if I
> wrote a driver after doing that.
> 
> I'm not really thrilled that this is their design either, but I'm not
> sure that there is a better answer...
> 

The hardware is weird, but we should try to support it in some fashion.
But without making dangerous functionality more widely available.  So
we're looking for some solution which can be fully contained within
that hardware's driver.

Dumb idea, there will be other ideas: is it practical to take that code
blob out of the BIOS, put it into a kernel module (as a .byte table in
a .s file and suitable C interfacing), compile that up and insmod that
module?