From: John Garry <john.garry@huawei.com>
To: Arnd Bergmann <arnd@arndb.de>, Peter Maydell <peter.maydell@linaro.org>
Cc: "Dmitry Vyukov" <dvyukov@google.com>,
"Mark Rutland" <mark.rutland@arm.com>,
"Marc Zyngier" <maz@kernel.org>, "Will Deacon" <will@kernel.org>,
"Ard Biesheuvel" <ardb@kernel.org>,
"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
syzkaller <syzkaller@googlegroups.com>,
LKML <linux-kernel@vger.kernel.org>,
"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: arm64 syzbot instances
Date: Mon, 22 Mar 2021 16:34:33 +0000 [thread overview]
Message-ID: <771d89a8-b7e0-6095-b101-e7ae91bcdc85@huawei.com> (raw)
In-Reply-To: <CAK8P3a2aQ0C7M2p3DBwjvK5mGyg2_8PQK2=FnkPFp3bVmt_xMw@mail.gmail.com>
>>
>> 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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-03-22 16:39 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-11 11:38 arm64 syzbot instances Dmitry Vyukov
2021-03-11 12:33 ` Mark Rutland
2021-03-11 16:56 ` Dmitry Vyukov
2021-03-17 18:45 ` Mark Rutland
2021-03-18 8:32 ` Dmitry Vyukov
2021-03-11 17:11 ` Dmitry Vyukov
2021-03-11 13:30 ` Arnd Bergmann
2021-03-11 17:25 ` Dmitry Vyukov
2021-03-12 6:42 ` Dmitry Vyukov
2021-03-11 17:57 ` Dmitry Vyukov
2021-03-12 8:39 ` Arnd Bergmann
2021-03-12 8:46 ` Dmitry Vyukov
2021-03-12 9:16 ` Arnd Bergmann
2021-03-12 9:21 ` Dmitry Vyukov
2021-03-12 10:10 ` Arnd Bergmann
2021-03-12 10:38 ` Dmitry Vyukov
2021-03-12 10:52 ` Arnd Bergmann
2021-03-15 9:43 ` John Garry
2021-03-15 10:01 ` Dmitry Vyukov
2021-03-15 10:29 ` John Garry
2021-03-15 10:34 ` Dmitry Vyukov
2021-03-15 11:11 ` Arnd Bergmann
2021-03-20 20:43 ` Peter Maydell
2021-03-21 11:52 ` Arnd Bergmann
2021-03-21 11:55 ` Arnd Bergmann
2021-03-21 18:59 ` Arnd Bergmann
2021-03-22 13:51 ` Peter Maydell
2021-03-22 15:42 ` Arnd Bergmann
2021-03-22 16:34 ` John Garry [this message]
2021-03-22 16:49 ` Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=771d89a8-b7e0-6095-b101-e7ae91bcdc85@huawei.com \
--to=john.garry@huawei.com \
--cc=alex.bennee@linaro.org \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=dvyukov@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=peter.maydell@linaro.org \
--cc=syzkaller@googlegroups.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).