All of lore.kernel.org
 help / color / mirror / Atom feed
From: Enke Chen <enkechen@cisco.com>
To: Jann Horn <jannh@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H . Peter Anvin" <hpa@zytor.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnd Bergmann <arnd@arndb.de>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Khalid Aziz <khalid.aziz@oracle.com>,
	Kate Stewart <kstewart@linuxfoundation.org>,
	deller@gmx.de, Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Andrew Morton <akpm@linux-foundation.org>,
	christian@brauner.io, Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Dave.Martin@arm.com, mchehab+samsung@kernel.org,
	Michal Hocko <mhocko@kernel.org>, Rik van Riel <riel@surriel.com>,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
	guro@fb.com, Marcos Souza <marcos.souza.org@gmail.com>,
	Oleg Nesterov <oleg@redhat.com>,
	linux@dominikbrodowski.net, Cyrill Gorcunov <gorcunov@openvz.org>,
	yang.shi@linux.alibaba.com, Kees Cook <keescook@chromium.org>,
	kernel list <linux-kernel@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	Victor Kamensky <kamensky@cisco.com>,
	xe-linux-external@cisco.com, sstrogin@cisco.com,
	Enke Chen <enkechen@cisco.com>
Subject: Re: [PATCH] kernel/signal: Signal-based pre-coredump notification
Date: Mon, 22 Oct 2018 13:48:51 -0700	[thread overview]
Message-ID: <14503a22-403e-3e39-cfd5-0b7a2f299986@cisco.com> (raw)
In-Reply-To: <CAG48ez27=w0oWFTYUeFc72-0DL0tf=NOzGCeZgtxFOePPPE5cA@mail.gmail.com>

Jann,

Thanks for the feedback. I will post a revised patch shortly.

On the related topic of "pdeath_signal", there are several inconsistencies
by preserving the flag across execve(2). The flag is cleared under several
conditions in different places. I will start a separate thread to see if
it can still be cleaned up.

     PR_SET_PDEATHSIG (since Linux 2.1.57)
              Set the parent death signal of the calling process to arg2
              (either a signal value in the range 1..maxsig, or 0 to clear).
              This is the signal that the calling process will get when its
              parent dies.  This value is cleared for the child of a fork(2)
              and (since Linux 2.4.36 / 2.6.23) when executing a set-user-ID
              or set-group-ID binary, or a binary that has associated
              capabilities (see capabilities(7)).  This value is preserved
              across execve(2).

-- Enke

On 10/22/18 8:40 AM, Jann Horn wrote:
> On Sat, Oct 20, 2018 at 1:01 AM Enke Chen <enkechen@cisco.com> wrote:
>> Regarding the security considerations, it seems simpler and more secure to
>> just clear the "pre-coredump signal" cross execve(2), and let the new program
>> decide for itself.  What do you think?
> 
> I don't have a problem with these semantics.
> 
> I could imagine someone being unhappy about the theoretical race
> window if they want to perform an in-place reexecution of a running
> service, but I don't know whether anyone actually cares about that.
> 
>> Changes to prctl(2):
>>
>> DESCRIPTION
>>
>>        PR_SET_PREDUMP_SIG (since Linux 4.20.x)
>>               This allows the calling process to receive a signal (arg2,
>>               if nonzero) from a child process prior to the coredump of
>>               the child process. arg2 must be SIGUSR1, or SIGUSR2, or
>>               SIGCHLD, or 0 (for clear).
>>
>>               When SIGCHLD is specified, the signal code is set to
>>               CLD_PREDUMP in such an SIGCHLD signal.
>>
>>               The value of the pre-coredump signal is cleared across
>>               execve(2), or for the child of a fork(2).
>>
>>        PR_GET_PREDUMP_SIG (since Linux 4.20.x)
>>               Return the current value of the pre-coredump signal for the
>>               calling process, in the location pointed to by (int *) arg2.

WARNING: multiple messages have this Message-ID (diff)
From: Enke Chen <enkechen@cisco.com>
To: Jann Horn <jannh@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H . Peter Anvin" <hpa@zytor.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnd Bergmann <arnd@arndb.de>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Khalid Aziz <khalid.aziz@oracle.com>,
	Kate Stewart <kstewart@linuxfoundation.org>,
	deller@gmx.de, Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Andrew Morton <akpm@linux-foundation.org>,
	christian@brauner.io, Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Dave.Martin@arm.com, mchehab+samsung@kernel.org,
	Michal Hocko <mhocko@kernel.org>, Rik van Riel <riel@surriel.com>,
	"Kirill A . Shutemov" <kirill.sh>
Subject: Re: [PATCH] kernel/signal: Signal-based pre-coredump notification
Date: Mon, 22 Oct 2018 13:48:51 -0700	[thread overview]
Message-ID: <14503a22-403e-3e39-cfd5-0b7a2f299986@cisco.com> (raw)
In-Reply-To: <CAG48ez27=w0oWFTYUeFc72-0DL0tf=NOzGCeZgtxFOePPPE5cA@mail.gmail.com>

Jann,

Thanks for the feedback. I will post a revised patch shortly.

On the related topic of "pdeath_signal", there are several inconsistencies
by preserving the flag across execve(2). The flag is cleared under several
conditions in different places. I will start a separate thread to see if
it can still be cleaned up.

     PR_SET_PDEATHSIG (since Linux 2.1.57)
              Set the parent death signal of the calling process to arg2
              (either a signal value in the range 1..maxsig, or 0 to clear).
              This is the signal that the calling process will get when its
              parent dies.  This value is cleared for the child of a fork(2)
              and (since Linux 2.4.36 / 2.6.23) when executing a set-user-ID
              or set-group-ID binary, or a binary that has associated
              capabilities (see capabilities(7)).  This value is preserved
              across execve(2).

-- Enke

On 10/22/18 8:40 AM, Jann Horn wrote:
> On Sat, Oct 20, 2018 at 1:01 AM Enke Chen <enkechen@cisco.com> wrote:
>> Regarding the security considerations, it seems simpler and more secure to
>> just clear the "pre-coredump signal" cross execve(2), and let the new program
>> decide for itself.  What do you think?
> 
> I don't have a problem with these semantics.
> 
> I could imagine someone being unhappy about the theoretical race
> window if they want to perform an in-place reexecution of a running
> service, but I don't know whether anyone actually cares about that.
> 
>> Changes to prctl(2):
>>
>> DESCRIPTION
>>
>>        PR_SET_PREDUMP_SIG (since Linux 4.20.x)
>>               This allows the calling process to receive a signal (arg2,
>>               if nonzero) from a child process prior to the coredump of
>>               the child process. arg2 must be SIGUSR1, or SIGUSR2, or
>>               SIGCHLD, or 0 (for clear).
>>
>>               When SIGCHLD is specified, the signal code is set to
>>               CLD_PREDUMP in such an SIGCHLD signal.
>>
>>               The value of the pre-coredump signal is cleared across
>>               execve(2), or for the child of a fork(2).
>>
>>        PR_GET_PREDUMP_SIG (since Linux 4.20.x)
>>               Return the current value of the pre-coredump signal for the
>>               calling process, in the location pointed to by (int *) arg2.

  reply	other threads:[~2018-10-22 20:48 UTC|newest]

Thread overview: 148+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-13  0:33 [PATCH] kernel/signal: Signal-based pre-coredump notification Enke Chen
2018-10-13  0:33 ` Enke Chen
2018-10-13  6:40 ` Greg Kroah-Hartman
2018-10-13  6:40   ` Greg Kroah-Hartman
2018-10-15 18:16   ` Enke Chen
2018-10-15 18:16     ` Enke Chen
2018-10-15 18:43     ` Greg Kroah-Hartman
2018-10-15 18:43       ` Greg Kroah-Hartman
2018-10-15 18:49       ` Enke Chen
2018-10-15 18:49         ` Enke Chen
2018-10-15 18:58         ` Greg Kroah-Hartman
2018-10-15 18:58           ` Greg Kroah-Hartman
2018-10-13 10:44 ` Christian Brauner
2018-10-13 10:44   ` Christian Brauner
2018-10-15 18:39   ` Enke Chen
2018-10-15 18:39     ` Enke Chen
2018-10-15 18:39     ` Enke Chen
2018-10-13 18:27 ` Jann Horn
2018-10-13 18:27   ` Jann Horn
2018-10-15 18:36   ` Enke Chen
2018-10-15 18:36     ` Enke Chen
2018-10-15 18:54     ` Jann Horn
2018-10-15 18:54       ` Jann Horn
2018-10-15 19:23       ` Enke Chen
2018-10-15 19:23         ` Enke Chen
2018-10-19 23:01       ` Enke Chen
2018-10-19 23:01         ` Enke Chen
2018-10-22 15:40         ` Jann Horn
2018-10-22 15:40           ` Jann Horn
2018-10-22 20:48           ` Enke Chen [this message]
2018-10-22 20:48             ` Enke Chen
2018-10-15 12:05 ` Oleg Nesterov
2018-10-15 12:05   ` Oleg Nesterov
2018-10-15 18:54   ` Enke Chen
2018-10-15 18:54     ` Enke Chen
2018-10-15 19:17   ` Enke Chen
2018-10-15 19:17     ` Enke Chen
2018-10-15 19:26     ` Enke Chen
2018-10-15 19:26       ` Enke Chen
2018-10-16 14:14     ` Oleg Nesterov
2018-10-16 14:14       ` Oleg Nesterov
2018-10-16 15:09       ` Eric W. Biederman
2018-10-16 15:09         ` Eric W. Biederman
2018-10-16 15:09         ` Eric W. Biederman
2018-10-17  0:39       ` Enke Chen
2018-10-17  0:39         ` Enke Chen
2018-10-15 21:21 ` Alan Cox
2018-10-15 21:21   ` Alan Cox
2018-10-15 21:31   ` Enke Chen
2018-10-15 21:31     ` Enke Chen
2018-10-15 23:28 ` Eric W. Biederman
2018-10-15 23:28   ` Eric W. Biederman
2018-10-15 23:28   ` Eric W. Biederman
2018-10-16  0:33   ` valdis.kletnieks
2018-10-16  0:33     ` valdis.kletnieks
2018-10-16  0:33     ` valdis.kletnieks
2018-10-16  0:54   ` Enke Chen
2018-10-16  0:54     ` Enke Chen
2018-10-16 15:26     ` Eric W. Biederman
2018-10-16 15:26       ` Eric W. Biederman
2018-10-16 15:26       ` Eric W. Biederman
2018-10-22 21:09 ` [PATCH v2] " Enke Chen
2018-10-22 21:09   ` Enke Chen
2018-10-23  9:23   ` Oleg Nesterov
2018-10-23  9:23     ` Oleg Nesterov
2018-10-23 19:43     ` Enke Chen
2018-10-23 19:43       ` Enke Chen
2018-10-23 21:40       ` Enke Chen
2018-10-23 21:40         ` Enke Chen
2018-10-24 13:52       ` Oleg Nesterov
2018-10-24 13:52         ` Oleg Nesterov
2018-10-24 21:56         ` Enke Chen
2018-10-24 21:56           ` Enke Chen
2018-10-24  5:39   ` [PATCH v3] " Enke Chen
2018-10-24  5:39     ` Enke Chen
2018-10-24 14:02     ` Oleg Nesterov
2018-10-24 14:02       ` Oleg Nesterov
2018-10-24 22:02       ` Enke Chen
2018-10-24 22:02         ` Enke Chen
2018-10-25 22:56     ` [PATCH v4] " Enke Chen
2018-10-25 22:56       ` Enke Chen
2018-10-26  8:28       ` Oleg Nesterov
2018-10-26  8:28         ` Oleg Nesterov
2018-10-26 22:23         ` Enke Chen
2018-10-26 22:23           ` Enke Chen
2018-10-29 11:18           ` Oleg Nesterov
2018-10-29 11:18             ` Oleg Nesterov
2018-10-29 21:08             ` Enke Chen
2018-10-29 21:08               ` Enke Chen
2018-10-29 22:31             ` [PATCH v5] " Enke Chen
2018-10-29 22:31               ` Enke Chen
2018-10-30 16:46               ` Oleg Nesterov
2018-10-30 16:46                 ` Oleg Nesterov
2018-10-31  0:25                 ` Enke Chen
2018-10-31  0:25                   ` Enke Chen
2018-11-22  0:37                 ` Andrew Morton
2018-11-22  0:37                   ` Andrew Morton
2018-11-22  1:09                   ` Enke Chen
2018-11-22  1:09                     ` Enke Chen
2018-11-22  1:18                     ` Enke Chen
2018-11-22  1:18                       ` Enke Chen
2018-11-22  1:33                     ` Andrew Morton
2018-11-22  1:33                       ` Andrew Morton
2018-11-22  4:57                       ` Enke Chen
2018-11-22  4:57                         ` Enke Chen
2018-11-12 23:22               ` Enke Chen
2018-11-12 23:22                 ` Enke Chen
2018-11-27 22:54               ` [PATCH v5 1/2] " Enke Chen
2018-11-27 22:54                 ` Enke Chen
2018-11-28 15:19                 ` Dave Martin
2018-11-28 15:19                   ` Dave Martin
2018-11-29  0:15                   ` Enke Chen
2018-11-29  0:15                     ` Enke Chen
2018-11-29 11:55                     ` Dave Martin
2018-11-29 11:55                       ` Dave Martin
2018-11-30  0:27                       ` Enke Chen
2018-11-30  0:27                         ` Enke Chen
2018-11-30 12:03                       ` Oleg Nesterov
2018-11-30 12:03                         ` Oleg Nesterov
2018-12-05  6:47                       ` Jann Horn
2018-12-05  6:47                         ` Jann Horn
2018-12-04 22:37                     ` Andrew Morton
2018-12-04 22:37                       ` Andrew Morton
2018-12-06 17:29                       ` Oleg Nesterov
2018-12-06 17:29                         ` Oleg Nesterov
2018-10-25 22:56     ` [PATCH] selftests/prctl: selftest for pre-coredump signal notification Enke Chen
2018-10-25 22:56       ` Enke Chen
2018-11-27 22:54       ` [PATCH v5 2/2] " Enke Chen
2018-11-27 22:54         ` Enke Chen
2018-10-24 13:29   ` [PATCH v2] kernel/signal: Signal-based pre-coredump notification Eric W. Biederman
2018-10-24 13:29     ` Eric W. Biederman
2018-10-24 13:29     ` Eric W. Biederman
2018-10-24 23:50     ` Enke Chen
2018-10-24 23:50       ` Enke Chen
2018-10-25 12:23       ` Eric W. Biederman
2018-10-25 12:23         ` Eric W. Biederman
2018-10-25 12:23         ` Eric W. Biederman
2018-10-25 20:45         ` Enke Chen
2018-10-25 20:45           ` Enke Chen
2018-10-25 21:24         ` Enke Chen
2018-10-25 21:24           ` Enke Chen
2018-10-25 21:56         ` Enke Chen
2018-10-25 21:56           ` Enke Chen
2018-10-25 13:45     ` Jann Horn
2018-10-25 13:45       ` Jann Horn
2018-10-25 20:21       ` Eric W. Biederman
2018-10-25 20:21         ` Eric W. Biederman
2018-10-25 20:21         ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=14503a22-403e-3e39-cfd5-0b7a2f299986@cisco.com \
    --to=enkechen@cisco.com \
    --cc=Dave.Martin@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=christian@brauner.io \
    --cc=deller@gmx.de \
    --cc=ebiederm@xmission.com \
    --cc=gorcunov@openvz.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=guro@fb.com \
    --cc=hpa@zytor.com \
    --cc=jannh@google.com \
    --cc=kamensky@cisco.com \
    --cc=keescook@chromium.org \
    --cc=khalid.aziz@oracle.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kstewart@linuxfoundation.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@dominikbrodowski.net \
    --cc=marcos.souza.org@gmail.com \
    --cc=mchehab+samsung@kernel.org \
    --cc=mhocko@kernel.org \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=riel@surriel.com \
    --cc=sstrogin@cisco.com \
    --cc=tglx@linutronix.de \
    --cc=viro@zeniv.linux.org.uk \
    --cc=will.deacon@arm.com \
    --cc=x86@kernel.org \
    --cc=xe-linux-external@cisco.com \
    --cc=yang.shi@linux.alibaba.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.