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: <af8d2f99-52f1-ae88-126e-cf90bd6cb3b2@infradead.org>
Date:   Thu, 6 Apr 2023 14:31:58 -0700
From:   Randy Dunlap <rdunlap@...radead.org>
To:     "Maciej W. Rozycki" <macro@...am.me.uk>,
        Sam Ravnborg <sam@...nborg.org>
Cc:     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 4/6/23 14:01, Maciej W. Rozycki wrote:
> Hi Sam,
> 
>>>  This looks completely wrong to me, any ordinary PCI parallel port card 
>>> ought just to work as long as you have PCI (S390 is special I'm told).  
>>> What needs to be done is AFAICT just making `parport_pc_find_nonpci_ports' 
>>> in arch/sparc/include/asm/parport.h SPARC64-specific, i.e.:
>>>
>>> static int parport_pc_find_nonpci_ports(int autoirq, int autodma)
>>> {
>>> 	return (IS_ENABLED(CONFIG_SPARC64) &&
>>> 		platform_driver_register(&ecpp_driver));
>>> }
>>>
>>> or suchlike and let the optimiser get rid of all the unwanted unsupported 
>>> stuff.
>>
>> arch/sparc/include/asm/parport.h is sparc64 specific - and it will
>> result in the wrong result if it is pulled in for sparc32 builds.
>> This is what we see today.
>>
>> 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.
> 
>  I don't have a SPARC toolchain handy or I could even try and build it 
> (but I'm sure there are many people around who can do it without bending 
> backwards).

https://mirrors.edge.kernel.org/pub/tools/crosstool/


-- 
~Randy