Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753312AbbEKUtm (ORCPT ); Mon, 11 May 2015 16:49:42 -0400 Received: from mail-wg0-f51.google.com ([74.125.82.51]:34930 "EHLO mail-wg0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752556AbbEKUtj (ORCPT ); Mon, 11 May 2015 16:49:39 -0400 MIME-Version: 1.0 In-Reply-To: References: From: Alex Henrie Date: Mon, 11 May 2015 14:49:17 -0600 Message-ID: Subject: Fwd: ioperm is preserved across fork and execve, but iopl is not To: Kees Cook , "H. Peter Anvin" , Doug Johnson , Thomas Gleixner , Ingo Molnar , Tyler Hicks , Al Viro , linux-kernel@vger.kernel.org Content-Type: multipart/mixed; boundary=f46d043be0aa29ba120515d48451 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3228 Lines: 68 --f46d043be0aa29ba120515d48451 Content-Type: text/plain; charset=UTF-8 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 --f46d043be0aa29ba120515d48451 Content-Type: text/x-csrc; charset=US-ASCII; name="iopl3.c" Content-Disposition: attachment; filename="iopl3.c" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i9kbz3mj0 I2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDx1bmlzdGQuaD4KCmludCBtYWluKGludCBhcmdj LCBjaGFyKiBhcmd2W10pCnsKICAgIGlmIChpb3BsKDMpID09IC0xKQogICAgewogICAgICAgIHBl cnJvcigiaW9wbCIpOwogICAgICAgIHJldHVybiAxOwogICAgfQoKICAgIGlmIChleGVjdnAoYXJn dlsxXSwgJmFyZ3ZbMV0pID09IC0xKQogICAgewogICAgICAgIHBlcnJvcigiZXhlY3ZwIik7CiAg ICAgICAgcmV0dXJuIDE7CiAgICB9CgogICAgcmV0dXJuIDA7Cn0K --f46d043be0aa29ba120515d48451 Content-Type: text/x-csrc; charset=US-ASCII; name="beep.c" Content-Disposition: attachment; filename="beep.c" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i9kbz7sf1 Ly9QbGF5cyBhIHRvbmUgb24gdGhlIHN5c3RlbSBzcGVha2VyIGZvciAxIHNlY29uZAoKI2luY2x1 ZGUgPHN0ZGlvLmg+CgppbnQgbWFpbigpCnsKICAgIF9fYXNtX18oIm1vdmIgJDB4QjYsICVhbFxu IgogICAgICAgICAgICAib3V0YiAlYWwsICQweDQzXG4iCiAgICAgICAgICAgICJpbmIgJDB4NjEs ICVhbFxuIgogICAgICAgICAgICAib3JiICQweDAzLCAlYWxcbiIKICAgICAgICAgICAgIm91dGIg JWFsLCAkMHg2MVxuIgogICAgICAgICAgICAibW92YiAkMHg2NCwgJWFsXG4iCiAgICAgICAgICAg ICJvdXRiICVhbCwgJDB4NDJcbiIKICAgICAgICAgICAgIm1vdmIgJDB4MDEsICVhbFxuIgogICAg ICAgICAgICAib3V0YiAlYWwsICQweDQyXG4iKTsKICAgIHNsZWVwKDEpOwogICAgX19hc21fXygi aW5iICQweDYxLCAlYWxcbiIKICAgICAgICAgICAgImFuZGIgJDB4RkMsICVhbFxuIgogICAgICAg ICAgICAib3V0YiAlYWwsICQweDYxXG4iKTsKICAgIHJldHVybiAwOwp9Cg== --f46d043be0aa29ba120515d48451 Content-Type: application/x-sh; name="test.sh" Content-Disposition: attachment; filename="test.sh" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i9kbzad52 IyEvYmluL3NoCmdjYyBpb3BsMy5jIC1vIGlvcGwzCmdjYyBiZWVwLmMgLW8gYmVlcApzdWRvIHNl dGNhcCBjYXBfc3lzX3Jhd2lvK2VpcCAuL2lvcGwzCi4vaW9wbDMgLi9iZWVwCg== --f46d043be0aa29ba120515d48451-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/