linux-kernel - Re: What would cause /proc/ioports do be zeroed out?

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] [day] [month] [year] [list]

Message-ID: <87h8zuccw9.fsf@fencepost.gnu.org>
Date:   Tue, 06 Jun 2017 00:01:26 +0200
From:   David Kastrup <dak@....org>
To:     linux-kernel@...r.kernel.org
Cc:     Randy Dunlap <rdunlap@...radead.org>
Subject: Re: What would cause /proc/ioports do be zeroed out?

David Kastrup <dak@....org> writes:

> Randy Dunlap <rdunlap@...radead.org> writes:
>
>> On 06/05/17 02:08, David Kastrup wrote:
>>> 
>>> The current symptom is that I cannot load some ACPI modules (compiled
>>> via DKMS for x86_64 architecture) without io_force option, with the
>>> kernel stating:
>>> 
>>> [  248.145348] thinkpad_ec: cannot claim IO ports 0x1600-0x161f... 
>>> [  248.145350] consider using force_io=1.
>>> 
>>> Now here is the really fishy thing:
>>> 
>>> cat /proc/ioports
>>> 0000-0000 : PCI Bus 0000:00
>>>   0000-0000 : dma1
>>
>> Does /proc/iomem show the same thing (i.e., zeros)?
>
> Yes.
>
>> How about if you do the test while logged in as root?
>
> Darn it.  Everything looks normal then in either case.  So the /proc
> thing likely is a red herring:

> I have another computer with a Mate 17.04 distribution that is
> complete 64bit including userland.  It also masks the ioports like
> this as non-root user and does not have the thinkpad_ec loading
> problem.

Bah.  Once I can see the assigned ports, the ports complained about are
for the acceleration sensors.  And once I install hdapsd (the daemon
acting on acceleration sensors) on that second computer, the same error
occurs.  So it has nothing at all to do with package management or 64/32
bits.

And uninstalling hdapsd on my primary computer also solves the problem
(as does setting the force_io option in
/etc/modprobe.d/thinkpad_ec.conf).

So lots of red herrings here.  I just don't know why I started seeing
this problem recently.  But I am not likely to find out.

So I removed the hdapsd package.  Not sure whether the thinkpad_ec
module from tp-smapi-dkms replaces it: at least it accesses the same
ports.

So it's really some problem specific to modules and functionality tied
into my hardware rather than some general kernel functionality.

Sorry for the noise.

-- 
David Kastrup