Re: arm64 syzbot instances

[John Garry]

> > 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