linux-kernel - Re: [REGRESSION] mipsel: no RTC CMOS on the Malta platform in QEMU

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <436dc4cb-6d99-415e-b20c-52f3221f85fc@app.fastmail.com>
Date: Tue, 14 Jan 2025 08:01:22 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Jiaxun Yang" <jiaxun.yang@...goat.com>,
 Mateusz Jończyk <mat.jonczyk@...pl>,
 "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
 Linux-Arch <linux-arch@...r.kernel.org>, linux-kernel@...r.kernel.org
Cc: "Baoquan He" <bhe@...hat.com>,
 "Thomas Bogendoerfer" <tsbogend@...ha.franken.de>,
 "Alexandre Belloni" <alexandre.belloni@...tlin.com>,
 regressions@...ts.linux.dev
Subject: Re: [REGRESSION] mipsel: no RTC CMOS on the Malta platform in QEMU

On Tue, Jan 14, 2025, at 00:29, Jiaxun Yang wrote:
> 在2025年1月13日一月 下午10:16，Mateusz Jończyk写道：
>> The mediator seems to be that this bad commit causes 
>> arch/mips/include/asm/io.h
>> to #include <asm-generic/io.h> at the end. As a side effect, this causes
>> the PCI_IOBASE macro to be defined:
>>
>> #ifndef PCI_IOBASE
>> #define PCI_IOBASE ((void __iomem *)0)
>> #endif
>>
>> That PCI_IOBASE value above is AFAIK incorrect for MIPS (it should be
>> defined to mips_io_port_base as far as I can tell), but this does not 
>> matter much here.
>
> You are right, this is what should be done.
>
> A quick fix would be #undef PCI_IOBASE in arch/mips/include/asm/io.h
> just after including #include <asm-generic/io.h>, with ralink and loongson64
> as exception.
>
> In the long term, we should scrutinize platform usage of mips_io_base
> following ralink's approach.

I think we are close to the point of being able to remove the broken
default PCI_IOBASE: the NULL pointer here is almost always wrong, and
mainly existed to shut up build failures on architectures that have
no port I/O at all. I know that sparc32 and m68k have cases that
actually rely on the broken PCI_IOBASE, so those need a local workaround,
not sure if some mips platform also falls into this category, as
I have not looked here in detail.

Hopefully we can get to a point where any reference to port I/O
(inb/outb, PCI_IOPORT, mips_io_port_base, ...) is guarded by
an #ifdef CONFIG_HAS_IOPORT check, and this is set exactly on
those platforms that set mips_io_port_base to a valid address.

      Arnd