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: <13d0c3f1-7e6b-4f25-ae00-9e41a15ec36c@app.fastmail.com>
Date: Tue, 14 Jan 2025 18:04:02 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Maciej W. Rozycki" <macro@...am.me.uk>
Cc: "Geert Uytterhoeven" <geert@...ux-m68k.org>,
 "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,
 "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 17:11, Maciej W. Rozycki wrote:
> On Tue, 14 Jan 2025, Arnd Bergmann wrote:
>> >> 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.
>> >
>> > Shouldn't arch/mips/include/asm/io.h do
>> >
>> >     #define PCI_IOBASE mips_io_port_base
>> >
>> > unconditionally, _before_ including  <asm-generic/io.h>?
>> 
>> Yes, I think this would make the most sense, but the ordering
>> with the PCI initialization needs to be done carefully,
>> to ensure that PCI_IOBASE has its final value before the first
>> call to pci_remap_iospace().
>
>  Is defining PCI_IOBASE going to do the right thing for non-PCI MIPS 
> platforms, or should the definition be #ifdef CONFIG_PCI rather than 
> unconditional?  FWIW I think all PCI MIPS platforms support port I/O.

PCI_IOBASE should be defined whenever CONFIG_HAS_IOPORT is set.
Ideally that should allow using the generic inb/outb and
ioread/iowrite helpers from include/asm-generic/io.h, but
unfortunately those don't support the address swizzling required
on SGI and Octeon platforms.

These platforms look like they currently set a NULL pointer
as the I/O port base:

arch/mips/alchemy/common/setup.c:       set_io_port_base(0);
arch/mips/ath79/setup.c:        set_io_port_base(KSEG1);
arch/mips/bcm63xx/setup.c:      set_io_port_base(0);
arch/mips/bmips/setup.c:        set_io_port_base(0);
arch/mips/lantiq/prom.c:        set_io_port_base((unsigned long) KSEG1);

At least some of these, possibly all, also have a PCI or PCMCIA
host controller driver that sets a different value later
when that bus is probed.

I don't see any I/O space getting set up for ath25, dec, ingenic,
loongson32, pic32, eyeq, nintendo64, and realtek-rtl. It looks to
me like any I/O port access on these turns into a misaligned NULL
pointer dereference, but there is a good chance I'm missing how
it gets set up there.

       Arnd.