linux-kernel - [PATCH] events: add a flag to perf_event_open() to set O

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

Message-Id: <1383168950-8933-1-git-send-email-ydroneaud@opteya.com>
Date:	Wed, 30 Oct 2013 22:35:50 +0100
From:	Yann Droneaud <ydroneaud@...eya.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Yann Droneaud <ydroneaud@...eya.com>,
	Paul Mackerras <paulus@...ba.org>,
	Ingo Molnar <mingo@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	linux-kernel@...r.kernel.org, viro@...iv.linux.org.uk
Subject: [PATCH] events: add a flag to perf_event_open() to set O_CLOEXEC

This patch adds PERF_FLAG_FD_CLOEXEC flag for
perf_event_open() syscall.

perf_event_open() creates a new file descriptor,
but unlike open() syscall, it lack a flag to atomicaly
set close-on-exec (O_CLOEXEC).

Not using O_CLOEXEC by default and not letting userspace
provide the "open" flags should be avoided: in most case
O_CLOEXEC must be used to not leak file descriptor across
exec().

Using O_CLOEXEC when creating a file descriptor allows
userspace to set latter, using fcntl(), without any risk
of race, if the file descriptor is going to be inherited
or not across exec().

Link: http://lkml.kernel.org/r/94b641a81a06ba4943cf77e80bc271c8@meuh.org
Link: http://lkml.kernel.org/r/cover.1383121137.git.ydroneaud@opteya.com
Signed-off-by: Yann Droneaud <ydroneaud@...eya.com>
---

Hi Peter,

This patch should replaces
"[PATCH v4 6/7] events: use get_unused_fd_flags(0) instead of get_unused_fd()"

Please have a look.

Regards.

 include/uapi/linux/perf_event.h |  1 +
 kernel/events/core.c            | 11 ++++++++---
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index 009a655..c217765 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -699,6 +699,7 @@ enum perf_callchain_context {
 #define PERF_FLAG_FD_NO_GROUP		(1U << 0)
 #define PERF_FLAG_FD_OUTPUT		(1U << 1)
 #define PERF_FLAG_PID_CGROUP		(1U << 2) /* pid=cgroup id, per-cpu mode only */
+#define PERF_FLAG_FD_CLOEXEC		(1U << 3) /* O_CLOEXEC */
 
 union perf_mem_data_src {
 	__u64 val;
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 953c143..44de88c 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -119,7 +119,8 @@ static int cpu_function_call(int cpu, int (*func) (void *info), void *info)
 
 #define PERF_FLAG_ALL (PERF_FLAG_FD_NO_GROUP |\
 		       PERF_FLAG_FD_OUTPUT  |\
-		       PERF_FLAG_PID_CGROUP)
+		       PERF_FLAG_PID_CGROUP |\
+		       PERF_FLAG_FD_CLOEXEC)
 
 /*
  * branch priv levels that need permission checks
@@ -6933,6 +6934,7 @@ SYSCALL_DEFINE5(perf_event_open,
 	int event_fd;
 	int move_group = 0;
 	int err;
+	int fd_flags;
 
 	/* for future expandability... */
 	if (flags & ~PERF_FLAG_ALL)
@@ -6961,7 +6963,9 @@ SYSCALL_DEFINE5(perf_event_open,
 	if ((flags & PERF_FLAG_PID_CGROUP) && (pid == -1 || cpu == -1))
 		return -EINVAL;
 
-	event_fd = get_unused_fd();
+	fd_flags = (flags & PERF_FLAG_FD_CLOEXEC) ? O_CLOEXEC : 0;
+
+	event_fd = get_unused_fd_flags(fd_flags);
 	if (event_fd < 0)
 		return event_fd;
 
@@ -7083,7 +7087,8 @@ SYSCALL_DEFINE5(perf_event_open,
 			goto err_context;
 	}
 
-	event_file = anon_inode_getfile("[perf_event]", &perf_fops, event, O_RDWR);
+	event_file = anon_inode_getfile("[perf_event]", &perf_fops, event,
+					O_RDWR | fd_flags);
 	if (IS_ERR(event_file)) {
 		err = PTR_ERR(event_file);
 		goto err_context;
-- 
1.8.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/