linux-kernel - Hidden IO-Ports: workarounded but WHY?

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 11 Jun 2007 01:44:29 +0200
From:	Federico Di Dio <eflags@...lyno.ath.cx>
To:	linux-kernel@...r.kernel.org
Subject: Hidden IO-Ports: workarounded but WHY?

Hi everybody,
I have an IT8705F SuperIO on my motherboard and everything is working
but the voltage/temperature sensors (running kernel 2.6.21.3).
I read the specs and figured out how to get direct access to the chip:
you can setup it through IO port 0x2e (or 0x4e), and decide where the
sensors will be in the IO space (default: 0x290).
Everything about it is fine, but reading from (or writing to) ports
0x290-0x297 is useless (all I get is 0xff).

With a few lines of code I canged base port to 0xc00 and now it works,
it87.ko loads and works flawlessly; this puzzled me, so I tried a 2.4
kernel and discovered it just works, no need to change the base port.
I also look directly at the ports with DOS DEBUG and got the same
results.

A few facts:
1) The IT8705F is fine (BIOS, Win98, linux 2.4 are just happy
   about it);
2) it works with kernel 2.4.33.3, it doesn't with 2.6.17.13;
3) disabling ACPI, hotplug and everything I tried is irrelevant;
4) the bug is NOT related to the it87 driver: reading the ports
   right after a reboot (with no modules loaded) just returns 0xff,
   while I'm sure I should get reasonable values (I read the whole
   spec, so I'm not messing around with the wrong ports or anything like
   that); the it87 driver, however, finds the chip, but when it
   understands it's unable to do anything useful, it quits (ENODEV);
   after altering the io port to something different, it runs just fine;
5) the io ports are not used by other devices. From /proc/ioports:
   0201-0201 : ns558-pnp
   0330-0331 : MPU401 UART
   [...]
   03f8-03ff : serial
   0cf8-0cff : PCI conf1
   so 0x290-0x297 should be as good as 0xc00-0xc07;
6) I have no idea of what, in the kernel, can cause such a behaviour ;)

  I'm no kernel expert, but this sounds quite like an interesting
problem to me!
  I can produce a detailed report, if you need more informations, but
I'm not subscribed to the lkml, so please CC: me any answer.

Ciao,
Federico Di Dio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/