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>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMMLpeRZ-ApD82V6+psii+Yd1JprNwKNi_EDtkDHseKDKzX-mQ@mail.gmail.com>
Date:	Mon, 11 May 2015 14:49:17 -0600
From:	Alex Henrie <alexhenrie24@...il.com>
To:	Kees Cook <keescook@...omium.org>,
	"H. Peter Anvin" <hpa@...or.com>, Doug Johnson <dougvj@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Tyler Hicks <tyhicks@...onical.com>,
	Al Viro <viro@...iv.linux.org.uk>, linux-kernel@...r.kernel.org
Subject: Fwd: ioperm is preserved across fork and execve, but iopl is not

Dear kernel developers,

The ioperm and iopl calls are both used to grant a process permission
to access I/O devices directly. iopl(3) is equivalent to ioperm(0,
0xFFFF, 1). However, permissions granted through ioperm are preserved
across fork and execve, and permissions granted through iopl are not.
This makes no sense: The two calls do the same thing, so there is no
security benefit to dropping one on fork or execve but not the other.

As recently as October 2012, 32-bit Linux kernels preserved both iopl
and ioperm across fork and execve, but the behavior of iopl changed
with this commit:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/x86/kernel/process_32.c?id=6783eaa2e1253fbcbe2c2f6bb4c843abf1343caf

And the man page for iopl continues to state "permissions are
inherited by fork and execve": http://linux.die.net/man/2/iopl

A test program demonstrating the problem is attached, and I will send
a proposed patch shortly. CAP_SYS_RAWIO is still required to use
ioperm or iopl.

Please CC me on any reply, as I am not subscribed to the LKML.

-Alex

View attachment "iopl3.c" of type "text/x-csrc" (267 bytes)

View attachment "beep.c" of type "text/x-csrc" (499 bytes)

Download attachment "test.sh" of type "application/x-sh" (103 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ