linux-kernel - Re: Questions about logic

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]

Date:   Thu, 20 Feb 2020 19:55:04 +0800
From:   Jiaxun Yang <jiaxun.yang@...goat.com>
To:     "John Garry" <john.garry@...wei.com>
Cc:     "Wei Xu" <xuwei5@...ilicon.com>, "bhelgaas" <bhelgaas@...gle.com>,
        "andyshevchenko" <andy.shevchenko@...il.com>,
        "Arnd Bergmann" <arnd@...db.de>,
        "linux-kernel" <linux-kernel@...r.kernel.org>,
        "Linux Mips" <linux-mips@...r.kernel.org>
Subject: Re: Questions about logic_pio

 ---- 在 星期四, 2020-02-20 18:52:38 John Garry <john.garry@...wei.com> 撰写 ----
Also Cc MIPS list to check other's opinions.

Hi John.

Thanks for your kind explanation, however, I think this way is
violating how I/O ports supposed to work, at least in MIPS world.

 > >>
 > >> After dig into logic pio logic, I found that logic pio is trying to "allocate" an io_start
 > >> for MMIO ranges, the allocation starts from 0x0. And later the io_start is used to calculate
 > >> cpu_address.  In my opinion, for direct MMIO access, logic_pio address should always
 > >> equal to hw address,
 > 
 > I'm not sure what you mean by simply the hw address.
 > 

I meant  hw_start should always equal to io_start.

MIPS have their own wrapped inl/outl functions, doing the samething with
PCI_IOBASE enabled one. I was just trying to use PCI_IOBASE instead.

Originally, the I/O ports layout seems like this:

00000020-00000021 : pic1
00000060-0000006f : i8042
00000070-00000077 : rtc0
000000a0-000000a1 : pic2
00000170-00000177 : pata_atiixp
000001f0-000001f7 : pata_atiixp
00000376-00000376 : pata_atiixp
000003f6-000003f6 : pata_atiixp
00000800-000008ff : acpi
00001000-00001008 : piix4_smbus
00004000-0003ffff : pci io space
  00004000-00004fff : PCI Bus 0000:01
    00004000-000040ff : 0000:01:05.0
  00005000-00005fff : PCI Bus 0000:03
    00005000-0000501f : 0000:03:00.0

But with PCI_IOBASE defined, I got this:

host bridge /bus@...00000/pci@...00000 ranges:
      MEM 0x0040000000..0x007fffffff -> 0x0040000000
       IO 0x0000004000..0x0000007fff -> 0x0000004000
resource collision: [io  0x0000-0x3fff] conflicts with pic1 [io  0x0020-0x0021]

Because io_start was allocated to 0x0 by Logic PIO.

There are a lot of devices that have fixed ioports thanks to x86's legacy.
For example, in my hardware, ioports for RTC, PIC, I8042 are unmoveable,
and they can't be managed by logic pio subsystem.
Also, the PCI Hostbridge got implied by DeviceTree that it's I/O range
started from 0x4000 in bus side, but then, Logic PIO remapped to PCI_IOBASE + 0x0.
The real address should be PCI_IOBASE + 0x4000,
hardware never got correctly informed about that. And there is still no way to
transform to correct address as it's inside the MMIO_LIMIT.

So the question comes to why we're allocating io_start for MMIO PCI_IOBASE
rather than just check the range provided doesn't overlap each other or exceed
the MMIO_LIMIT.

Thanks.

--
Jiaxun Yang