From: John Garry <john.garry@huawei.com>
To: Jiaxun Yang <jiaxun.yang@flygoat.com>, <catalin.marinas@arm.com>,
<will@kernel.org>, <arnd@arndb.de>, <akpm@linux-foundation.org>,
<xuwei5@hisilicon.com>, <lorenzo.pieralisi@arm.com>,
<helgaas@kernel.org>, <song.bao.hua@hisilicon.com>
Cc: <linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <linux-arch@vger.kernel.org>,
<linux-mips@vger.kernel.org>, <linux-pci@vger.kernel.org>,
<linuxarm@openeuler.org>
Subject: Re: [PATCH RFC 0/4] Fix arm64 crash for accessing unmapped IO port regions (reboot)
Date: Mon, 18 Jan 2021 09:42:25 +0000 [thread overview]
Message-ID: <6c0a2484-2cd6-ea1f-1094-21a7e86d71a2@huawei.com> (raw)
In-Reply-To: <982ed6eb-6975-aea8-1555-a557633966f5@flygoat.com>
On 18/01/2021 01:59, Jiaxun Yang wrote:
> 在 2021/1/16 上午12:58, John Garry 写道:
>> This is a reboot of my original series to address the problem of drivers
>> for legacy ISA devices accessing unmapped IO port regions on arm64
>> systems
>> and causing the system to crash.
>>
>> There was another recent report of such an issue [0], and some old ones
>> [1] and [2] for reference.
>>
>> The background is that many systems do not include PCI host controllers,
>> or they do and controller probe may have failed. For these cases, no IO
>> ports are mapped. However, loading drivers for legacy ISA devices can
>> crash the system as there is nothing to stop them accessing those IO
>> ports (which have not been io remap'ed).
>>
>> My original solution tried to keep the kernel alive in these
>> situations by
>> rejecting logical PIO access to PCI IO regions until PCI IO port regions
>> have been mapped.
>>
>> This series goes one step further, by just reserving the complete legacy
>> IO port range in 0x0--0xffff for arm64. The motivation for doing this is
>> to make the request_region() calls for those drivers fail, like this:
>>
>> root@ubuntu:/home/john# insmod mk712.ko
>> [ 3415.575800] mk712: unable to get IO region
>> insmod: ERROR: could not insert module mk712.ko: No such device
>>
>> Otherwise, in theory, those drivers could initiate rogue accesses to
>> mapped IO port regions for other devices and cause corruptions or
>> side-effects. Indeed, those drivers should not be allowed to access
>> IO ports at all in such a system.
>>
>> As a secondary defence, for broken drivers who do not call
>> request_region(), IO port accesses in range 0--0xffff will be ignored,
>> again preserving the system.
>>
>> I am sending as an RFC as I am not sure of any problem with reserving
>> first 0x10000 of IO space like this. There is reserve= commandline
>> argument, which does allow this already.
>
Hi Jiaxun,
>
> Is it ok with ACPI? I'm not really familiar with ACPI on arm64 but my
> impression
> is ACPI would use legacy I/O ports to communicate with kbd controller,
> EC and
> power management facilities.
I tested for ACPI. As far as I'm concerned, fixed IO ports should not be
used on arm64 systems.
Indeed, ACPI spec says IO port addresses should be CPU addressable, and
it is the job of the kernel to io remap those correctly for systems
which do not support IO ports natively, i.e. those that define PCI_IOBASE.
>
> We'd better have a method to detect if ISA bus is not present on the system
> instead of reserve them unconditionally.
>
For ISA bus or any IO ports region, they would/should be behind PCI host
bridge or modeled as INDIRECT IO host and we should allocate logic PIO
region for them, and there should be no assumption on the IO port
address in drivers, i.e. not fixed.
Thanks,
John
>
>>
>> For reference, here's how /proc/ioports looks on my arm64 system with
>> this change:
>>
>> root@ubuntu:/home/john# more /proc/ioports
>> 00010000-0001ffff : PCI Bus 0002:f8
>> 00010000-00010fff : PCI Bus 0002:f9
>> 00010000-00010007 : 0002:f9:00.0
>> 00010000-00010007 : serial
>> 00010008-0001000f : 0002:f9:00.1
>> 00010008-0001000f : serial
>> 00010010-00010017 : 0002:f9:00.2
>> 00010018-0001001f : 0002:f9:00.2
>> 00020000-0002ffff : PCI Bus 0004:88
>> 00030000-0003ffff : PCI Bus 0005:78
>> 00040000-0004ffff : PCI Bus 0006:c0
>> 00050000-0005ffff : PCI Bus 0007:90
>> 00060000-0006ffff : PCI Bus 000a:10
>> 00070000-0007ffff : PCI Bus 000c:20
>> 00080000-0008ffff : PCI Bus 000d:30
>>
>> [0]
>> https://lore.kernel.org/linux-input/20210112055129.7840-1-song.bao.hua@hisilicon.com/T/#mf86445470160c44ac110e9d200b09245169dc5b6
>>
>> [1] https://lore.kernel.org/linux-pci/56F209A9.4040304@huawei.com
>> [2]
>> https://lore.kernel.org/linux-arm-kernel/e6995b4a-184a-d8d4-f4d4-9ce75d8f47c0@huawei.com/
>>
>>
>> Difference since v4:
>> https://lore.kernel.org/linux-pci/1560262374-67875-1-git-send-email-john.garry@huawei.com/
>>
>> - Reserve legacy ISA region
>>
>> John Garry (4):
>> arm64: io: Introduce IO_SPACE_BASE
>> asm-generic/io.h: Add IO_SPACE_BASE
>> kernel/resource: Make ioport_resource.start configurable
>> logic_pio: Warn on and discard accesses to addresses below
>> IO_SPACE_BASE
>>
>> arch/arm64/include/asm/io.h | 1 +
>> include/asm-generic/io.h | 4 ++++
>> include/linux/logic_pio.h | 5 +++++
>> kernel/resource.c | 2 +-
>> lib/logic_pio.c | 20 ++++++++++++++------
>> 5 files changed, 25 insertions(+), 7 deletions(-)
>>
>
> .
next prev parent reply other threads:[~2021-01-18 9:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-15 16:58 John Garry
2021-01-15 16:58 ` [PATCH RFC 1/4] arm64: io: Introduce IO_SPACE_BASE John Garry
2021-01-15 16:58 ` [PATCH RFC 2/4] asm-generic/io.h: Add IO_SPACE_BASE John Garry
2021-01-15 16:58 ` [PATCH RFC 3/4] kernel/resource: Make ioport_resource.start configurable John Garry
2021-01-15 16:58 ` [PATCH RFC 4/4] logic_pio: Warn on and discard accesses to addresses below IO_SPACE_BASE John Garry
2021-01-18 1:59 ` [PATCH RFC 0/4] Fix arm64 crash for accessing unmapped IO port regions (reboot) Jiaxun Yang
2021-01-18 9:42 ` John Garry [this message]
2021-01-26 15:16 ` Arnd Bergmann
2021-01-26 17:56 ` John Garry
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=6c0a2484-2cd6-ea1f-1094-21a7e86d71a2@huawei.com \
--to=john.garry@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=helgaas@kernel.org \
--cc=jiaxun.yang@flygoat.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linuxarm@openeuler.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=song.bao.hua@hisilicon.com \
--cc=will@kernel.org \
--cc=xuwei5@hisilicon.com \
/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
all inboxes | Powered by JetHome®