linux-kernel - Re: [PATCH v2] nubus: Don't list card resources by default

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:   Sun, 26 Mar 2023 14:22:14 +1100 (AEDT)
From:   Finn Thain <fthain@...ux-m68k.org>
To:     Brad Boyer <flar@...andria.com>
cc:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        linux-m68k@...ts.linux-m68k.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] nubus: Don't list card resources by default

On Sat, 25 Mar 2023, Brad Boyer wrote:

> On Sat, Mar 25, 2023 at 10:35:52AM +1100, Finn Thain wrote:
> 
> > 
> > I think those cards are in the same category as video cards in the 
> > sense that userspace drivers would need /dev/mem.
> 
> Probably. I was just thinking that having some of the information 
> already parsed out might be useful. It's hard to say without having 
> anything written to use it.
> 

If someone wanted to write something that uses the procfs information they 
could still do so, but they would have to enable a kernel parameter first.

> ...
> However, the system ROM doesn't use exactly the same structure as a 
> NuBus expansion ROM. That might complicate such work. It might be easier 
> to use the firmware infrastructure to load them from files and extract 
> the drivers from the latest system software that still supported 
> anything with an IOP. The updated IOP drivers are each separate 
> resources in the system file that could be extracted with native 
> developer utilities in MacOS. Then we presumably have the latest. I've 
> never found any hint that the IOP hardware was any different between 
> models that have them.
> 

My thinking was that a firmware cutter (whether it was for ROM resources 
or slot resources) would remain separate from the kernel, as that seems to 
be the usual pattern. The existing mechanisms for distributing to 
/lib/firmware and loading from /lib/firmware could be leveraged.

> > I can't figure out why procfs access to the slot resources from pseudo 
> > slot 0 would be desirable (?)
> 
> I'm not sure. Someone clearly thought it was useful in the past.

That's not clear to me.

Someone clearly thought that the procfs files may be useful for some 
unknown purpose in userspace. And someone clearly thought that the slot 0 
resources may be useful for configuring drivers in kernelspace.
Neither of those panned out.

The only possible use I can think of for slot 0 resources in userspace 
(e.g. a "TechTool" for Linux) would be better served by mmap'ing the ROM 
using /dev/mem.

> I don't think I have any models with anything interesting there. I 
> suspect the main thing would be an equivalent to the ROM on a video card 
> for the built-in display adapter on those systems.
> 

Only to the extent that such hardware cannot be probed or simply inferred 
from bootinfo records already provided (like gestalt id). But the slot 0 
vs. bootinfo question seems unrelated to the procfs question, right?