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, 21 May 2016 12:20:02 -0400
From:	William Breathitt Gray <vilhelm.gray@...il.com>
To:	Greg KH <gregkh@...uxfoundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] Driver core update for 4.7-rc1

On Fri, May 20, 2016 at 10:04:38PM -0700, Greg KH wrote:
>On Fri, May 20, 2016 at 09:51:18PM -0700, Linus Torvalds wrote:
>> On Fri, May 20, 2016 at 8:23 PM, Greg KH <gregkh@...uxfoundation.org> wrote:
>> >
>> > William Breathitt Gray (13):
>> >       base: isa: Remove X86_32 dependency
>> >       isa: Decouple X86_32 dependency from the ISA Kconfig option
>> 
>> So I'm going to revert these unless I get
>> 
>>  (a) a good reason for them
>> 
>>  (b) patches to get rid of the incessant warnings these cause.
>
>What warnings?  I haven't seen any reports of warnings, what .config
>causes them?
>
>> Most of the ISA drivers are not 64-bit safe. They give compiler
>> warnings, and they will definitely simply not work. So just blindly
>> enabling that shit is not the answer.
>> 
>> We've never needed this before, why do we need it now?
>
>I'll let William answer that, it seems he has some crazy isa hardware
>for x86_64 platforms...
>
>thanks,
>
>greg k-h

I'll submit patches to resolve these warnings and errors.

The primary reason for decoupling the x86_32 dependency from the X86 ISA
Kconfig option is to allow the ISA bus driver to be used to interface
with PC/104 devices.

Although you are correct that the ISA bus for general consumers is
essentially legacy from the pre-64-bit era, the PC/104 bus (a derivative
of the ISA bus) is ubiquitous in the embedded systems industry; new
PC/104 devices are developed and produced every day.

Despite the form factor difference, PC/104 devices appear to software as
ISA devices: you can interact with them like you would any other ISA
device, using I/O port-mapped reads and writes. This makes the existing
ISA bus driver an apt solution to interface with PC/104 devices (to
software, there is no difference between PC/104 and ISA).

The issue arises with the X86_32 dependency on the X86 ISA Kconfig
option: this dependency is not necessary because there is no hard 32-bit
dependency on the ISA bus itself; in fact, the ISA bus driver
(drivers/base/isa.c) is portable across all X86 platforms. Worse, the
X86_32 dependency puts an artifical limitation on PC/104 devices.

Many embedded systems vendors produce PC/104 compatible motherboards
running 64-bit X86 processors; this isn't the exception, it's the norm.
To use the ISA bus driver with the X86_32 dependency means preventing
support for PC/104 devices on virtually any modern PC/104 compatible
embedded system motherboard. There are real PC/104 devices out there,
from real companies and people, intended to run on real motherboards
with 64-bit X86 processors.

I'm in the process of developing drivers for a few new PC/104 devices.
For reference, there are currently four PC/104 drivers already merged:
the Apex Embedded Systems STX104 DAC driver, the ACCES 104-DIO-48E
series GPIO driver, the ACCES 104-IDI-48 series GPIO driver, and the
ACCES 104-IDIO-16 series GPIO driver.

Although not necessarily PC/104 devices, the WinSystems EBC-C384
watchdog timer driver and WinSystems WS16C48 GPIO driver communicate via
an ISA bus interface and are also expected to run on motherboards with
64-bit X86 processors.

One alternative to decoupling the X86_32 dependency from the ISA Kconfig
option would be to copy the drivers/base/isa.c code to a new
drivers/base/pc104.c file, which will serve as the PC/104 bus driver;
new PC/104 drivers intended to run on any X86 platform can use this new
bus driver. However, it doesn't seem right to maintain an identical set
of code simply to sidestep a Kconfig dependency issue.

Removing the X86_32 dependency from the X86 ISA Kconfig option results
in warnings and errors for two reasons:

    1. The relevant code is meant to be 32-bit X86 specific.
       - In this case, an explicit X86_32 should be added to the
	 Kconfig option for the relevant code.

    2. The relevant code is meant to work on both 32-bit and 64-bit X86
       platforms, but a 32-bit specific piece of code was overlooked.
       - In this case, the code should be fixed to be portable across
	 X86 platforms as intended.

Regardless, in both scenarios, adding an explicit X86_32 dependency to
the relevant Kconfig options resolves the warnings and errors by
limiting the compilation to X86_32 as they have been before; thus the
status quo is maintained. However, a major benefit is gained: the ISA
bus driver may now be used to support these new PC/104 devices expected
to run with 64-bit X86 processors.

Regarding the excerpt of warnings already posted: the Kconfig for the
IDE chipsets has an X86 dependency which should explicitly be X86_32,
while the 3C515 and NI65 drivers' Kconfig dependencies should also be
adjusted since neither use the X86 ISA bus driver.

As I said before, it is my intention to submit patches to resolve the
warnings and errors which have appeared; they are currently there simply
because I mistakenly overlooked them when I performed my initial
testing.

I've logged the warnings and errors after compiling from an
allmodconfig, with and without the two commits, and performed a diff
between the two logs to get the new warnings and errors; there appears
to be less than 10 drivers involved, judging from the output, so I'll
investigate the causes and submit patches to resolve the relevant
warnings and errors.

Let me know if there is an alternative solution that would be more
suitable in order to facilitate PC/104 device support on 64-bit X86
platforms.

William Breathitt Gray

Powered by blists - more mailing lists