linux-kernel - Re: arm64 syzbot instances

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] [day] [month] [year] [list]

Message-ID: <CAFEAcA9d5NLUcn_wdj=pUWEW9arRcZnOwUuqtoSep=FSjpB_Tw@mail.gmail.com>
Date:   Mon, 22 Mar 2021 16:49:24 +0000
From:   Peter Maydell <peter.maydell@...aro.org>
To:     John Garry <john.garry@...wei.com>
Cc:     Arnd Bergmann <arnd@...db.de>, Dmitry Vyukov <dvyukov@...gle.com>,
        Mark Rutland <mark.rutland@....com>,
        Marc Zyngier <maz@...nel.org>, Will Deacon <will@...nel.org>,
        Ard Biesheuvel <ardb@...nel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        syzkaller <syzkaller@...glegroups.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Alex Bennée <alex.bennee@...aro.org>
Subject: Re: arm64 syzbot instances

On Mon, 22 Mar 2021 at 16:36, John Garry <john.garry@...wei.com> wrote:
>
> >>
> >> There's apparently a bit in the PCI spec that reads:
> >>          The host bus bridge, in PC compatible systems, must return all
> >>          1's on a read transaction and discard data on a write transaction
> >>          when terminated with Master-Abort.
> >>
> >> which obviously applies only to "PC compatible systems".
> >
> > Right. As far as I can tell, all ARMv8 and most ARMv7 based SoCs
> > do this to be more compatible with PC style operating systems like
> > Linux, but you are right that the specification here does not
> > mandate that, and the older ARMv5 SoCs seem to be compliant
> > as well based on this.

> >> TBH I'm having difficulty seeing why the kernel should be doing
> >> this at all, though. The device tree tells you you have a PCI
> >> controller; PCI supports enumeration of devices; you know exactly
> >> where everything is mapped because the BARs tell you that.
> >> I don't see anything that justifies the kernel in randomly
> >> dereferencing areas of the IO or memory windows where it hasn't
> >> mapped anything.
>
> BIOS has described a CPU-addressable PIO region in the PCI hostbridge,
> and the kernel has mapped it:
>
> [    3.974309][    T1] pci-host-generic 4010000000.pcie:       IO
> 0x003eff0000..0x003effffff -> 0x0000000000
>
> So I don't see why any accesses there should fault.

As requested above, do you have the PCI spec reference for
why the PIO region is supposed to do -1/discard for parts of
the PIO region where the kernel hasn't mapped any devices ?
For classic PCI, at least, the spec does not seem to mandate it.

thanks
-- PMM