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:   Sat, 25 Mar 2023 13:44:43 +0100
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Finn Thain <fthain@...ux-m68k.org>
Cc:     Brad Boyer <flar@...andria.com>, linux-m68k@...ts.linux-m68k.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] nubus: Don't list card resources by default

Hi Finn,

On Sat, Mar 25, 2023 at 12:33 AM Finn Thain <fthain@...ux-m68k.org> wrote:
> On Fri, 24 Mar 2023, Brad Boyer wrote:
> > On Fri, Mar 24, 2023 at 10:13:51AM +1100, Finn Thain wrote:
> > > On Thu, 23 Mar 2023, Geert Uytterhoeven wrote:
> > > > On Thu, Mar 23, 2023 at 7:02???AM Finn Thain <fthain@...ux-m68k.org> wrote:
> > > > > --- a/drivers/nubus/nubus.c
> > > > > +++ b/drivers/nubus/nubus.c
> > > > > @@ -34,6 +34,9 @@
> > > > >
> > > > >  LIST_HEAD(nubus_func_rsrcs);
> > > > >
> > > > > +bool procfs_rsrcs;
> > > > > +module_param(procfs_rsrcs, bool, 0444);
> > > >
> > > > With the expanded functionality, is "rsrcs" still a good name?
> > > > Perhaps this should be an integer, so you can define different
> > > > levels? E.g.
> > > >   - 0 = just devices
> > > >   - 1 = above + boards + public resources
> > > >   - 2 = above + private resources
> > >
> > > That really depends on how the proc entries get used. I think it's
> > > probably going to be developers who would use them so I consider all
> > > of this to be outside of the UAPI and subject to change. But it would
> > > be nice to hear from other developers on that point.
> >
> > I don't know of anything that currently uses them, but there's a number
> > of potential uses depending on how far we want to take things. A real
> > video driver for X.org for some of the more advanced cards could take
> > advantage of some of the secondary information made available. I've got
> > a number of NuBus video cards with some acceleration capabilities that
> > were pretty advanced for the time.
>
> Good point. I had not considered Xorg drivers. But I'm not sure why
> userspace drivers would access /proc when they already need /dev/mem or
> some more modern graphics API to be implemented by an in-kernel driver.
>
> > There's even a driver in the ROM on video cards that could be used, but
> > that also requires more emulation of the MacOS environment. KVM could
> > potentially need more information if we got it running on m68k, although
> > I doubt any real Mac has enough RAM to make that useful.
>
> You only need a few MB to run MacOS (or an early Linux distro). So I
> rather think that KVM could be workable with 64 or 128 MB of RAM.
>
> The /proc/bus/nubus/boards file is not affected by this patch, so userland
> tools could still identify the available boards if need be.

Perhaps it would be worthwhile to move the resources out of /proc,
but into a separate virtual file system?
That way people who need access to the additional info can load the
separate virtual file system kernel module, and mount the file system?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds