Message-ID: <771d89a8-b7e0-6095-b101-e7ae91bcdc85@huawei.com>
Date:   Mon, 22 Mar 2021 16:34:33 +0000
From:   John Garry <john.garry@...wei.com>
To:     Arnd Bergmann <arnd@...db.de>,
        Peter Maydell <peter.maydell@...aro.org>
CC:     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

>>
>> 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.
> 
>>> Linux has a driver for DPC, which apparently configures it to
>>> cause an interrupt to log the event, but it does not hook up the
>>> CPU exception handler to this. I don't see an implementation of DPC
>>> in qemu, which I take as an indication that it should use the
>>> default behavior and cause neither an interrupt nor a CPU exception.
>>
>> Hmm, maybe. We should probably also implement -1/discard just because
>> we're not intending to have 'surprising' behaviour.
>>
>> 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.

>> You shouldn't be probing for legacy ISA-port
>> devices unless you're on a system which might actually have them
>> (eg an x86 PC).
> 
> It only happened in this case because there is also a bug in
> the 8250 serial port driver that is configured to assume four ports
> exist at port zero. On real arm64 hardware, this is apparently
> harmless because the driver has coped with this for 30 years ;-)
> 
> There are a few other drivers that assume hardware is accessible
> at the legacy addresses, and applications can also still open /dev/ioport
> (if that is enabled at compile time) for the same purpose. Examples
> could be PC-style mouse/keyboard (emulated by a server BMC),
> PATA/SATA controllers in pre-AHCI mode, VGA console, and a
> couple of industrial I/O drivers that have ISA devices behind a
> PCI bridge.
> 
> Most other actual ISA add-on card drivers can only be enabled
> on kernels that support machines with real slots, so you could
> get them on an i386 kernel running a virtualized x86_64 machine,
> but not on ARMv6 or later kernels, and you can't run pre-ARMv7
> kernels on ARMv8 hardware.
>   There are also lots of the hwmon drivers which use super IO, and probe 
a fixed PIO addresses for HW detection. These may be enabled on any 
architecture (apart from PPC, who explicitly disabled them to avoid 
issues like this).

Thanks,
John

Powered by blists - more mailing lists