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:   Mon, 20 Dec 2021 10:27:39 +0100
From:   Niklas Schnelle <schnelle@...ux.ibm.com>
To:     John Garry <john.garry@...wei.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

On Fri, 2021-12-17 at 16:30 +0000, John Garry wrote:
> On 17/12/2021 15:55, Arnd Bergmann wrote:
> > > > If you have a better way of finding the affected drivers,
> > >   > that would be great.
> > > 
> > > Assuming arm64 should select HAS_IOPORT, I am talking about f71805f as
> > > an example. According to that patch, this driver additionally depends on
> > > HAS_IOPORT; however I would rather arm64, like powerpc, should not allow
> > > that driver to be built at all.
> > Agreed, I missed these when I looked through the HAS_IOPORT users,
> > that's why I suggested to split up that part of the patch per subsystem
> > so they can be inspected more carefully.
> 
> ok
> 
>  >
>  > My feeling is that in this case we want some other dependency, e.g. a
>  > new CONFIG_LPC. It should actually be possible to use this driver on
>  > any machine with an LPC bus, which would by definition be the primary
>  > I/O space, so it should be possible to load it on Arm64.
> 
> You did suggest HARDCODED_IOPORT earlier in this thread, and the 
> definition/premise there seemed sensible to me.
> 
> Anyway it seems practical to make all these changes in a single series, 
> so need a way forward as Niklas has no such changes for this additional 
> kconfig option.
> 
> As a start, may I suggest we at least have Niklas' patch committed to a 
> dev branch based on -next or latest mainline release for further analysis?
> 
> Thanks,
> John
> 
> 

My plan would be to split the patch up into more manageable pieces as
suggested by Arnd plus of course fixes like the missing ARM select. As
Arnd suggested I'll split the HAS_IOPORT additions into the initial
introduction plus arch selects and then the HAS_IOPORT dependencies per
subsytem. I think these per subsystem dependency patches then would be
a great place to find drivers which should have a different dependency
be it on LPC or a newly introduced HARDCODED_IOPORT. The thing is we
can find and check HAS_IOPORT dependencies easily but it's hard to find
HARDCODED_IOPORT so I think the lattter should be a refinement of the
former. It can of course still go in as a single series. I'll
definitely make the next iteration available as a git branch.

Thanks,
Niklas