From: John Garry <john.garry@huawei.com> To: Bjorn Helgaas <helgaas@kernel.org> Cc: Guenter Roeck <linux@roeck-us.net>, <wangkefeng.wang@huawei.com>, <lorenzo.pieralisi@arm.com>, <arnd@arndb.de>, <rafael@kernel.org>, <linux-pci@vger.kernel.org>, <will.deacon@arm.com>, <linux-kernel@vger.kernel.org>, <linuxarm@huawei.com>, <andy.shevchenko@gmail.com>, <catalin.marinas@arm.com>, <bp@suse.de>, <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v3 3/4] lib: logic_pio: Reject accesses to unregistered CPU MMIO regions Date: Mon, 8 Apr 2019 09:01:14 +0100 [thread overview] Message-ID: <d80304b9-13f0-246c-49a7-b95f735d8f67@huawei.com> (raw) In-Reply-To: <20190405180615.GB109021@google.com> On 05/04/2019 19:06, Bjorn Helgaas wrote: > On Fri, Apr 05, 2019 at 09:10:27AM +0100, John Garry wrote: >> On 04/04/2019 19:58, Bjorn Helgaas wrote: >>> On Thu, Apr 04, 2019 at 10:43:36AM -0700, Guenter Roeck wrote: >>>> On Thu, Apr 04, 2019 at 05:52:35PM +0100, John Garry wrote: >>>>>>> Note that the f71805f driver does not call >>>>>>> request_{muxed_}region(), as it should. >>>>> >>>>>> ... which is the real problem, one that is not solved by this >>>>>> patch. This may result in parallel and descructive accesses if >>>>>> there is another device on the LPC bus, and another driver >>>>>> accessing that device. Personally I'd rather have >>>>>> request_muxed_region() added to the f71805f driver. >>>>> >>>>> Right, we should and will still fix f71805f. If you recall, I did >>>>> have the f71805f fix in the v1 series, but you committed that it >>>>> was orthogonal, so I decided to take it out of this work for now. >>>>> >>>>> And even if we fix up f71805f and other known drivers which don't >>>>> call request_muxed_region(), we still need to police against these >>>>> rogue accesses, which is what this patch attempts to do. >>>>> >>>> Do we ? I am personally not convinced that LPC accesses _have_ to >>>> occur through PCI on any given system. >>> >>> On current systems, I suspect ISA/LPC devices are typically connected >>> via a PCI-to-ISA/LPC bridge. But AFAIK there's no actual requirement >>> for that bridge, and there certainly *were* systems with ISA devices >>> but no PCI at all. >>> >>> IMO, if you want to build ISA drivers on your arch, you need to make >>> sure the inb() probing done by those drivers works like it does on >>> x86. If there's no device there, the inb() should return 0xff with no >>> fuss and no crash. >> >> Right, and this is what I am attempting to do here. >> >> So today a call to request_muxed_region() can still succeed even if no IO >> space mapped. >> >> As such, even well-behaved drivers like f71882fg can still crash the system, >> as noted in RFC patch 1/4 ("resource: Request IO port regions from children >> of ioport_resource"). > Correction: "As such, *on arm* even well-behaved drivers like f71882fg can still crash the system, ... So, yes, x86 - which has native IO ports - would not have this issue. > Maybe I'm missing something, but on x86, drivers like f71882fg do not > crash the system because inb() *never* causes a crash. > > If you want to build that driver for ARM, I think you need to make > sure that inb() on ARM also *never* causes a crash. I don't think > changing f71882fg and all the similar drivers is the right answer. > Right, so this is the intention of this patch. However it would be still good to find a way to fail a request to claim an IO port region if none is accessible or mapped. Thanks, John > Bjorn > > . >
WARNING: multiple messages have this Message-ID (diff)
From: John Garry <john.garry@huawei.com> To: Bjorn Helgaas <helgaas@kernel.org> Cc: wangkefeng.wang@huawei.com, lorenzo.pieralisi@arm.com, arnd@arndb.de, rafael@kernel.org, linux-pci@vger.kernel.org, will.deacon@arm.com, linux-kernel@vger.kernel.org, linuxarm@huawei.com, andy.shevchenko@gmail.com, linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, bp@suse.de, Guenter Roeck <linux@roeck-us.net> Subject: Re: [PATCH v3 3/4] lib: logic_pio: Reject accesses to unregistered CPU MMIO regions Date: Mon, 8 Apr 2019 09:01:14 +0100 [thread overview] Message-ID: <d80304b9-13f0-246c-49a7-b95f735d8f67@huawei.com> (raw) In-Reply-To: <20190405180615.GB109021@google.com> On 05/04/2019 19:06, Bjorn Helgaas wrote: > On Fri, Apr 05, 2019 at 09:10:27AM +0100, John Garry wrote: >> On 04/04/2019 19:58, Bjorn Helgaas wrote: >>> On Thu, Apr 04, 2019 at 10:43:36AM -0700, Guenter Roeck wrote: >>>> On Thu, Apr 04, 2019 at 05:52:35PM +0100, John Garry wrote: >>>>>>> Note that the f71805f driver does not call >>>>>>> request_{muxed_}region(), as it should. >>>>> >>>>>> ... which is the real problem, one that is not solved by this >>>>>> patch. This may result in parallel and descructive accesses if >>>>>> there is another device on the LPC bus, and another driver >>>>>> accessing that device. Personally I'd rather have >>>>>> request_muxed_region() added to the f71805f driver. >>>>> >>>>> Right, we should and will still fix f71805f. If you recall, I did >>>>> have the f71805f fix in the v1 series, but you committed that it >>>>> was orthogonal, so I decided to take it out of this work for now. >>>>> >>>>> And even if we fix up f71805f and other known drivers which don't >>>>> call request_muxed_region(), we still need to police against these >>>>> rogue accesses, which is what this patch attempts to do. >>>>> >>>> Do we ? I am personally not convinced that LPC accesses _have_ to >>>> occur through PCI on any given system. >>> >>> On current systems, I suspect ISA/LPC devices are typically connected >>> via a PCI-to-ISA/LPC bridge. But AFAIK there's no actual requirement >>> for that bridge, and there certainly *were* systems with ISA devices >>> but no PCI at all. >>> >>> IMO, if you want to build ISA drivers on your arch, you need to make >>> sure the inb() probing done by those drivers works like it does on >>> x86. If there's no device there, the inb() should return 0xff with no >>> fuss and no crash. >> >> Right, and this is what I am attempting to do here. >> >> So today a call to request_muxed_region() can still succeed even if no IO >> space mapped. >> >> As such, even well-behaved drivers like f71882fg can still crash the system, >> as noted in RFC patch 1/4 ("resource: Request IO port regions from children >> of ioport_resource"). > Correction: "As such, *on arm* even well-behaved drivers like f71882fg can still crash the system, ... So, yes, x86 - which has native IO ports - would not have this issue. > Maybe I'm missing something, but on x86, drivers like f71882fg do not > crash the system because inb() *never* causes a crash. > > If you want to build that driver for ARM, I think you need to make > sure that inb() on ARM also *never* causes a crash. I don't think > changing f71882fg and all the similar drivers is the right answer. > Right, so this is the intention of this patch. However it would be still good to find a way to fail a request to claim an IO port region if none is accessible or mapped. Thanks, John > Bjorn > > . > _______________________________________________ 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:[~2019-04-08 8:01 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-04-04 15:59 [PATCH v3 0/4] Fix system crash for accessing unmapped IO port regions John Garry 2019-04-04 15:59 ` John Garry 2019-04-04 15:59 ` [RFC PATCH v3 1/4] resource: Request IO port regions from children of ioport_resource John Garry 2019-04-04 15:59 ` John Garry 2019-04-04 16:00 ` [PATCH v3 2/4] lib: logic_pio: Use logical PIO low-level accessors for !CONFIG_INDIRECT_PIO John Garry 2019-04-04 16:00 ` John Garry 2019-04-04 16:00 ` [PATCH v3 3/4] lib: logic_pio: Reject accesses to unregistered CPU MMIO regions John Garry 2019-04-04 16:00 ` John Garry 2019-04-04 16:41 ` Guenter Roeck 2019-04-04 16:41 ` Guenter Roeck 2019-04-04 16:52 ` John Garry 2019-04-04 16:52 ` John Garry 2019-04-04 17:43 ` Guenter Roeck 2019-04-04 17:43 ` Guenter Roeck 2019-04-04 18:58 ` Bjorn Helgaas 2019-04-04 18:58 ` Bjorn Helgaas 2019-04-05 8:10 ` John Garry 2019-04-05 8:10 ` John Garry 2019-04-05 18:06 ` Bjorn Helgaas 2019-04-05 18:06 ` Bjorn Helgaas 2019-04-05 18:29 ` Guenter Roeck 2019-04-05 18:29 ` Guenter Roeck 2019-04-08 8:19 ` John Garry 2019-04-08 8:19 ` John Garry 2019-04-08 13:47 ` Guenter Roeck 2019-04-08 13:47 ` Guenter Roeck 2019-04-08 16:35 ` John Garry 2019-04-08 16:35 ` John Garry 2019-04-08 16:50 ` Will Deacon 2019-04-08 16:50 ` Will Deacon 2019-04-09 10:38 ` John Garry 2019-04-09 10:38 ` John Garry 2019-04-08 8:01 ` John Garry [this message] 2019-04-08 8:01 ` John Garry 2019-04-04 16:00 ` [PATCH v3 4/4] lib: logic_pio: Fix up some prints John Garry 2019-04-04 16:00 ` 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=d80304b9-13f0-246c-49a7-b95f735d8f67@huawei.com \ --to=john.garry@huawei.com \ --cc=andy.shevchenko@gmail.com \ --cc=arnd@arndb.de \ --cc=bp@suse.de \ --cc=catalin.marinas@arm.com \ --cc=helgaas@kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pci@vger.kernel.org \ --cc=linux@roeck-us.net \ --cc=linuxarm@huawei.com \ --cc=lorenzo.pieralisi@arm.com \ --cc=rafael@kernel.org \ --cc=wangkefeng.wang@huawei.com \ --cc=will.deacon@arm.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.