linux-kernel - RE: [GIT PULL 1/2] asm-generic: rework PCI I/O space access

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:   Sun, 19 Dec 2021 14:23:29 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'John Garry' <john.garry@...wei.com>,
        Niklas Schnelle <schnelle@...ux.ibm.com>,
        Arnd Bergmann <arnd@...nel.org>
CC:     Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        linux-pci <linux-pci@...r.kernel.org>,
        "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: RE: [GIT PULL 1/2] asm-generic: rework PCI I/O space access

From: John Garry
> Sent: 17 December 2021 14:28
> 
> On 17/12/2021 13:52, Niklas Schnelle wrote:
> 
> Thanks for looking at this again.
> 
> >>> I have tested this on s390 with HAS_IOPORT=n and allyesconfig as well
> >>> as running it with defconfig. I've also been using it on my Ryzen 3990X
> >>> workstation with LEGACY_PCI=n for a few days. I do get about 60 MiB
> >>> fewer modules compared with a similar config of v5.15.8. Hard to say
> >>> which other systems might miss things of course.
> >>>
> >>> I have not yet worked on the discussed IOPORT_NATIVE flag. Mostly I'm
> >>> wondering two things. For one it feels like that could be a separate
> >>> change on top since HAS_IOPORT + LEGACY_PCI is already quite big.
> >>> Secondly I'm wondering about good ways of identifying such drivers and
> >>> how much this overlaps with the ISA config flag.
> 
> I was interesting in the IOPORT_NATIVE flag (or whatever we call it) as
> it solves the problem of drivers which "unconditionally do inb()/outb()
> without checking the validity of the address using firmware or other
> methods first" being built for (and loaded on and crashing) unsuitable
> systems. Such a problem is in [0]
> 
> So if we want to support that later, then it seems that someone would
> need to go back and re-edit many same driver Kconfigs – like hwon, for
> example. I think it's better to avoid that and do it now.

Could you do something where valid arguments to inb() have to come
from some kernel mapping/validation function and are never in the
range [0x0, 0x10000).
Then drivers that are cheating the system will fail.

Or, maybe, only allow [0x0, 0x10000) on systems that have a suitable bus.
With the mapping functions returning a different value (eg the KVA into
the PCI master window) that can be separately verified.
That would let drivers do (say) inb(0x120) on systems that have (something
like) and ISA bus, but not on PCI-only systems which support PCI IO
accesses through a physical address window.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)