linux-kernel - Re: [RFC PATCH v2 1/3] resource: Request IO port regions from children of ioport_resource

Open Source and information security mailing list archives

Date:   Fri, 29 Mar 2019 10:42:17 +0000
From:   John Garry <john.garry@...wei.com>
To:     Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Bjorn Helgaas <helgaas@...nel.org>
CC:     <wangkefeng.wang@...wei.com>, <arnd@...db.de>, <rafael@...nel.org>,
        <linux-pci@...r.kernel.org>, Will Deacon <will.deacon@....com>,
        <linux-kernel@...r.kernel.org>, <linuxarm@...wei.com>,
        <andy.shevchenko@...il.com>,
        <linux-arm-kernel@...ts.infradead.org>,
        "Catalin Marinas" <catalin.marinas@....com>, <bp@...e.de>,
        <linux@...ck-us.net>
Subject: Re: [RFC PATCH v2 1/3] resource: Request IO port regions from
 children of ioport_resource

On 28/03/2019 17:46, Lorenzo Pieralisi wrote:
> On Tue, Mar 26, 2019 at 05:48:10PM -0500, Bjorn Helgaas wrote:
>
> [...]
>

Hi Lorenzo,

>> I'm not convinced about this last sentence.
>>
>> It's true that on most modern systems, including that Intel PCH, the
>> Super I/O controller is attached via an LPC bridge on a PCI bus.
>>
>> But I don't think it's an actual requirement that PCI be involved.
>> There certainly once were systems, e.g., PC/104, that had ISA devices
>> but no PCI.  Maybe Super I/O attached via ISA is obsolete enough that
>> we don't care any more, but I really don't know.
>>
>>>> On x86, I think inb/inw/inl from a port where nothing responds
>>>> probably just returns ~0, and outb/outw/outl just get dropped.
>>>> Shouldn't arm64 do the same, without crashing?
>>>
>>> That would be ideal and we're doing something similar in patch 2/3.
>>>
>>> So on ARM64 we have to IO remap the PCI IO resource. If this mapping is not
>>> done (due to no PCI host), then any inb/inw/inl calls will crash the system.
>>
>> My take is that ARM64 is responsible for implementing inb/inw/inl in
>> such a way that they don't crash.  I don't think it's practical to
>> update all the old ISA drivers or even the core code to work around
>> that.
>
> The problem is that those drivers are accessing a resource that does not
> exist in practice, it is taken for granted on x86 systems (and on IA64)
> because that was an actual bus (actual or emulated) and was made part of
> the architecture. The ISA space is not necessarily tied to PCI,
> at least not always.
>
> Side note: these drivers can't be compiled on PPC, it would be
> good to understand why, I have a hunch it can be related.

I mentioned this earlier:

I saw that in commits like 746cdfbf01c0 ("hwmon: Avoid building drivers 
forpowerpc that read/write ISA addresses"), PPC would not build these
drivers, as, like arm, it has no native ISA.

However I still don't think just avoiding compiling these drivers for 
certain archs solves the problem.

[...]

>>>>> [1] https://www.spinics.net/lists/linux-pci/msg49821.html
>>>>
>>>> Please use a https://lore.kernel.org/ URL instead of spinics.net.
>>>
>>> ok, I hope that I can find this old thread.
>>
>> The beauty of lore.kernel.org is that the URL contains the Message-ID, so
>> it's easy build the URL and it would contain useful information even if
>> lore.kernel.org disappeared:
>>
>> https://lore.kernel.org/linux-pci/56F209A9.4040304@huawei.com
>
> Yes, the bottom line is what Arnd outlined in the thread above.
>
> ISA IO port space is not necessarily PCI but it does not exist
> architecturally on ARM systems.
>
> Taking the example of IA64, the ISA space is memory mapped (like any
> other arch except for x86) but IIUC the virtual mapping for the ISA
> port space _always_ exists on IA64 so this issue won't happen.
>
> Arnd pointed out a solution in the thread above but I need to check
> if that's feasible.

I doubt that it can work now.

Since we when introduced the concept of logical PIO space, this IO space 
became sparely populated by 2 regions - MMIO and indirect IO - so we 
cannot grow it as we map in regions. I also don't think it works for 
when we IO unmap regions.

Thanks,
John

>
> Lorenzo
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> .
>

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives