Bug 1370281

Summary:	00000000-00000000 adresses in /proc/iomem
Product:	[Fedora] Fedora	Reporter:	Andrej Manduch <amanduch>
Component:	kernel	Assignee:	Kernel Maintainer List <kernel-maint>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	23	CC:	gansalmon, ichavero, itamar, jonathan, kernel-maint, madhu.chinakonda, mchehab
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-08-25 19:42:17 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Andrej Manduch 2016-08-25 19:34:18 UTC

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 19:42:17 UTC

This was intentionally changed with

commit 51d7b120418e99d6b3bf8df9eb3cc31e8171dee4
Author: Linus Torvalds <torvalds>
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>

which was in the 4.6 kernel release.

Comment 2 Andrej Manduch 2016-08-25 19:51:43 UTC

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 19:58:39 UTC

(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.