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.2304072142290.62619@angie.orcam.me.uk>
Date:   Fri, 7 Apr 2023 22:01:38 +0100 (BST)
From:   "Maciej W. Rozycki" <macro@...am.me.uk>
To:     Sam Ravnborg <sam@...nborg.org>
cc:     Niklas Schnelle <schnelle@...ux.ibm.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        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, Sam Ravnborg wrote:

> > > Randy's suggestion is fine, as we avoid building parport support
> > > for sparc32. If someone shows up and need parport support
> > > for sparc32 then we could look into how to enable it.
> > > Until then, we are better helped avoiding building the driver.
> > 
> >  I disagree.  Why artificially prevent perfectly good hardware from 
> > working with a perfectly good driver especially as the fix is just a 
> > trivial exercise?  And I offered a solution.
> 
> There is no sparc32 with a PC style parallel port, so the parport_pc
> have no value for a sparc32 machine.

 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.

 Apologies if I wasn't clear enough with my reasoning, although I think 
the lone presence of the PCI dependency in Kconfig ought have to make it 
clear.

> The sparc32 machines have the parport_sunbpp driver for their parallel
> port.

 That's an onboard device or an SBus option card though, right?

> 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.

 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).

 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.

  Maciej