linux-kernel - Re: [PATCH] parport_pc: don't allow driver for SPARC32

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: <alpine.DEB.2.21.2306190000530.14084@angie.orcam.me.uk>
Date:   Mon, 19 Jun 2023 00:42:08 +0100 (BST)
From:   "Maciej W. Rozycki" <macro@...am.me.uk>
To:     Randy Dunlap <rdunlap@...radead.org>
cc:     Sam Ravnborg <sam@...nborg.org>,
        Niklas Schnelle <schnelle@...ux.ibm.com>,
        linux-kernel@...r.kernel.org,
        Sudip Mukherjee <sudipm.mukherjee@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        sparclinux@...r.kernel.org, linux-parport@...ts.infradead.org
Subject: Re: [PATCH] parport_pc: don't allow driver for SPARC32

On Fri, 7 Apr 2023, Randy Dunlap wrote:

> >  There are PC-style PCI (and PCIe) parallel ports in the form of option 
> > cards being sold; I have one in my RISC-V machine (and I had to go through 
> > the hassle of figuring out why the heck I am not able to select the driver 
> > in configuration; a situation analogous to what Randy's change wants to 
> > arrange).  You can plug one into any machine that has PCI slots and my 
> > understanding from Linux Kconfig files is there are such 32-bit SPARC 
> > machines in existence or the dependency on PCI wouldn't offer the driver.  
> > Otherwise just don't enable CONFIG_PCI for 32-bit SPARC.
> > 
> 
> If there are 32-bit Sparc machines with PCI slots, we must not have any
> users with parallel ports or we should have heard about it IMO.

 I wouldn't be surprised, parallel ports are not that common nowadays, let 
alone used.  Myself I haven't used a parallel printer for ages now, though 
I still own a couple of odd other parallel devices, such as a ROM emulator 
or the firmware download port of an old MIPS development board (actually a 
regular Super I/O parallel port of said device hijacked by an onboard FPGA 
for this second purpose if enabled with an onboard rocker switch).  That's 
not the usual stuff people tend to use I suppose.

> >> An alternative fix, and better I think, would be to audit all archs
> >> and let the relevant ones select ARCH_MIGHT_HAVE_PC_PARPORT, so we
> >> avoided the ugly "|| (PCI && !S390 && !SPARC32)" case for PARPORT_PC.

 I should have noted this before: ARCH_MIGHT_HAVE_PC_PARPORT is for true 
ISA or Super I/O parallel ports only.  We handle true PCI implementations 
in a generic platform-agnostic way, as long as the platform implements PCI 
I/O commands in the host bridge.  The latter requirement only excludes a 
bunch of platforms, most notably S390 and recent 64-bit POWER systems.

 With Niklas's HAS_IOPORT patches the S390 special case will soon be gone.

> >  It's only S390 that is special in that it has a limited set of specially 
> > crafted PCI options it can ever support (or so I am told; something about 
> > the firmware or suchlike).
> 
> >From my reading, if a Sparc32 machine has a PCI port, it might be able to
> have a parallel port. However, even with Maciej's suggested code change
> instead of my patch, the ebus code is not being compiled for Sparc32 -- only
> for Sparc64, so more changes are needed beyond Maciej's suggestion.
> 
> But the documentation that I found refers to Ebus on Sparc4 machines.

 Well, even though I came across a bunch of SPARC machines in the past I'm 
not familiar enough with the platform to have an idea what SPARC4 refers 
to.  You can enable CONFIG_PCI for a SPARC32 kernel however, which I infer 
from there are 32-bit SPARC machines in existence with PCI connectivity.  
That I find enough for a potential PC-style parallel port configuration 
with such a system, for as many ports as the availability of slots allows.

> >  Any other platform that has PCI slots will handle PC-style PCI parallel 
> > port option cards just fine, as long as it supports PCI I/O read/write 
> > commands (some systems such as POWER9 machines don't; Niklas Schnelle has 
> > been recently working on a generic way to exclude drivers for devices that 
> > require PCI port I/O from being offered with systems that have no support 
> > for PCI port I/O).
> > 
> >  Let me know if you find anything here unclear or have any other questions 
> > or comments.
> 
> /me wishes that we had a Sparc maintainer.

 What happened to DaveM?

 In any case after a couple of iterations I have made a succesful build of 
a 32-bit SPARC toolchain now, which I was able to verify a fix with I have 
outlined earlier in this thread.  Posted as archived at: 
<https://lore.kernel.org/r/alpine.DEB.2.21.2306182347101.14084@angie.orcam.me.uk/>.

  Maciej