Bug 1370281 - 00000000-00000000 adresses in /proc/iomem
00000000-00000000 adresses in /proc/iomem
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
23
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-08-25 15:34 EDT by Andrej Manduch
Modified: 2016-08-25 15:58 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-08-25 15:42:17 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Andrej Manduch 2016-08-25 15:34:18 EDT
Description of problem:

Then I cat /proc/iomem under non-root user I get very weird results. /proc/iomem looks kinda like it supposed to look like except every address range are 00000000-00000000. Under root it behaves as expected.

[test@lenovo-rd230-02 ~]$ head /proc/iomem 
00000000-00000000 : reserved
00000000-00000000 : System RAM
00000000-00000000 : reserved
00000000-00000000 : PCI Bus 0000:00
00000000-00000000 : Video ROM
00000000-00000000 : Adapter ROM
00000000-00000000 : Adapter ROM
00000000-00000000 : Adapter ROM
00000000-00000000 : PCI Bus 0000:00
00000000-00000000 : reserved


Under root:
[root@lenovo-rd230-02 ~]# head /proc/iomem
00000000-00000fff : reserved
00001000-0009a3ff : System RAM
0009a400-0009ffff : reserved
000a0000-000bffff : PCI Bus 0000:00
000c0000-000c7fff : Video ROM
000c8000-000c8fff : Adapter ROM
000c9000-000c9fff : Adapter ROM
000ca000-000cafff : Adapter ROM
000d0000-000dffff : PCI Bus 0000:00
000e0000-000fffff : reserved



Version-Release number of selected component (if applicable):
[test@lenovo-rd230-02 ~]$ uname -r
4.6.7-200.fc23.x86_64

How reproducible:
Every time.

Steps to Reproduce:
1. su - test
2. cat /proc/iomem

Expected results:

It should print real addresses or return ioerror when reading /proc/iomem. But I don't think returning wrong addresses are sane behaviour.

Additional info:
on RHEL6 and RHEL7 cat /proc/iomem under unprivileged user returns same as under root.
Comment 1 Josh Boyer 2016-08-25 15:42:17 EDT
This was intentionally changed with

commit 51d7b120418e99d6b3bf8df9eb3cc31e8171dee4
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Apr 14 12:05:37 2016 -0700

    /proc/iomem: only expose physical resource addresses to privileged users
    
    In commit c4004b02f8e5b ("x86: remove the kernel code/data/bss resources
    from /proc/iomem") I was hoping to remove the phyiscal kernel address
    data from /proc/iomem entirely, but that had to be reverted because some
    system programs actually use it.
    
    This limits all the detailed resource information to properly
    credentialed users instead.
    
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

which was in the 4.6 kernel release.
Comment 2 Andrej Manduch 2016-08-25 15:51:43 EDT
Thanks Josh,

I wasn't aware about this. However it still feels as wrong behaviour to me. I guess it would be more sane if it would behave more like let say /proc/$some_id/environ . I mean If privileged user tried to read that it would return real values and if unprivileged user wants to read that it would end up with Permission Denied or ioerror.

But I guess correct place to brag about this is kernel mailing list.

btw: thanks again Josh for super fast responce.
Comment 3 Josh Boyer 2016-08-25 15:58:39 EDT
(In reply to Andrej Manduch from comment #2)
> Thanks Josh,
> 
> I wasn't aware about this. However it still feels as wrong behaviour to me.
> I guess it would be more sane if it would behave more like let say
> /proc/$some_id/environ . I mean If privileged user tried to read that it
> would return real values and if unprivileged user wants to read that it
> would end up with Permission Denied or ioerror.
> 
> But I guess correct place to brag about this is kernel mailing list.

Right.

> btw: thanks again Josh for super fast responce.

No problem.

Note You need to log in before you can comment on or make changes to this bug.