netdev - [RFC] connector: add group_exit_code and signal_flags fields to exit_proc

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

Date:   Thu, 1 Mar 2018 20:58:16 +0200
From:   Stefan Strogin <sstrogin@...co.com>
To:     zbr@...emap.net, matthltc@...ibm.com
Cc:     netdev@...r.kernel.org, xe-linux-external@...co.com,
        Stefan Strogin <sstrogin@...co.com>,
        Victor Kamensky <kamensky@...co.com>,
        Taras Kondratiuk <takondra@...co.com>,
        Ruslan Bilovol <rbilovol@...co.com>
Subject: [RFC] connector: add group_exit_code and signal_flags fields to
 exit_proc_event

Hello everyone,

I'm working on a user-space application that should handle events when some
processes (children of a certain process, "App1") are being killed with
SIGKILL. Also these notifications must be filtered somehow, e.g. we don't
need to handle cases when exit() generates SIGKILL to child threads
(group exit), for example an OOM-caused SIGKILL and a group exit-generated one
are totally different and we must somehow distinguish them.
Unfortunately we also cannot use SIGCHLD and waitid() in App1, there
should be another application that monitors children of App1.

My idea is to use PROC_EVENT_EXIT. But unfortunately it seems there is not
enough information in exit_proc_event structure to see if that was group
exit-generated SIGKILL or not. Tell me please if I'm wrong.

So I was thinking to add these two fields to union event_data:
task->signal->group_exit_code
task->signal->flags
This won't increase size of struct proc_event (because of comm_proc_event)
and shouldn't break backward compatibility for the user-space. But it will
add some useful information about what caused the process death.
What do you think, is it an acceptable approach?

Thanks

Signed-off-by: Stefan Strogin <sstrogin@...co.com>
---
 drivers/connector/cn_proc.c  | 2 ++
 include/uapi/linux/cn_proc.h | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/drivers/connector/cn_proc.c b/drivers/connector/cn_proc.c
index a782ce87715c..1006cb506a52 100644
--- a/drivers/connector/cn_proc.c
+++ b/drivers/connector/cn_proc.c
@@ -288,6 +288,8 @@ void proc_exit_connector(struct task_struct *task)
 	ev->event_data.exit.process_tgid = task->tgid;
 	ev->event_data.exit.exit_code = task->exit_code;
 	ev->event_data.exit.exit_signal = task->exit_signal;
+	ev->event_data.exit.group_exit_code = task->signal->group_exit_code;
+	ev->event_data.exit.signal_flags = task->signal->flags;

 	memcpy(&msg->id, &cn_proc_event_id, sizeof(msg->id));
 	msg->ack = 0; /* not used */
diff --git a/include/uapi/linux/cn_proc.h b/include/uapi/linux/cn_proc.h
index 68ff25414700..edf50f398116 100644
--- a/include/uapi/linux/cn_proc.h
+++ b/include/uapi/linux/cn_proc.h
@@ -122,6 +122,8 @@ struct proc_event {
 			__kernel_pid_t process_pid;
 			__kernel_pid_t process_tgid;
 			__u32 exit_code, exit_signal;
+			int group_exit_code;
+			unsigned int signal_flags;
 		} exit;

 	} event_data;
-- 
2.16.1