From: John Cotton Ericson <mail@JohnEricson.me>
To: Christian Brauner <christian.brauner@ubuntu.com>,
Al Viro <viro@zeniv.linux.org.uk>
Cc: LKML <linux-kernel@vger.kernel.org>,
David Laight <David.Laight@aculab.com>,
Andy Lutomirski <luto@kernel.org>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
Kernel Hardening <kernel-hardening@lists.openwall.com>,
Jann Horn <jann@thejh.net>,
Christian Brauner <christian.brauner@canonical.com>
Subject: Re: Leveraging pidfs for process creation without fork
Date: Tue, 3 Aug 2021 02:00:57 -0400 [thread overview]
Message-ID: <01e72780-e328-23b5-c114-9c35125da7c6@JohnEricson.me> (raw)
In-Reply-To: <20210802121935.dkiw627twcrxbh54@wittgenstein>
On Mon, Aug 2, 2021, at 8:19 AM, Christian Brauner wrote:
> On Sat, Jul 31, 2021 at 10:42:16PM +0000, Al Viro wrote:
> >
> > It's more on the exit/exec/coredump side, actually. For
> > exit we want to be sure that no new live threads will appear in a
> > group once the last live thread has entered do_exit(). For
> > exec (de_thread(), for starters) you want to have all threads
> > except for the one that does execve() to be killed and your
> > thread to take over as group leader. Look for the machinery there
> > and in do_exit()/release_task() involved into that. For coredump
> > you want all threads except for dumper to be brought into do_exit()
> > and stopped there, for dumping one to be able to access their state.
> >
> > Then there's fun with ->sighand treatment - the whole thing
> > critically relies upon ->sighand being shared for the entire thread
> > group; look at the ->sighand->siglock uses.
> >
> > The whole area is full of rather subtle places. Again, the
> > real headache comes from the exit and execve. Embryonic threads are
> > passive; it's the ones already running that can (and do) cause PITA.
I took a look at de_thread and begin_new_exec. It does seems whatever
trouble there is stems from a bit of mixing concerns as I thought.
Most of begin_new_exec seems about wiping clean the current process's
state, including the de_thread, unsharing various things. But then
operations like that first bprm_creds_from_file call (of perhaps more
recent vintage [1]) is about initializing new state from binprm argument.
It is interesting to me to note that some of the "unsharing" happens at
clone time (the namespaces), and some happens (also) at exec time (file
table, signal handlers). This to me is more good concrete evidence fork
+ exec is awkward and strews concerns.
There perhaps will be some subtleties about in which order state can be
set up on the embryonic process, but I don't think any de_thread will be
needed because there will never be threads from a "previous" state lying
around. Indeed there is no "previous" anything, just the current
everything-inert embryonic process.
I would propose trying to rip up begin_new_exec so the unsharing,
de_thread-ing etc. is just done in the traditional exec path, and just
the bprm bits with a non-current fresh embryonic task_sched are done in
the new one.
[1]: 56305aa9b6fab91a5555a45796b79c1b0a6353d1
> Iiuc, you're talking about adding a thread into a thread-group tg1 from
> a thread in another thread-group tg2. I don't think that's a very
> pressing use-case and I agree that that sounds rather nasty right now.
> Unless I'm missing something, a simple api to create something like a
> processes configuration context doesn't require this.
Agreed.
I did mention embryonic processes with multiple threads, but was just a
shower thought and not something I really care about. Also, since that
would entail adding a thread to an inert thread group the creator has
full powers over (it's "on the operating table") I don't think it would
be so bad.
(To keep this new servery metaphor going, exec would be self-surgery,
and adding a thread to *live* thread group would be surgery without
anesthesia.)
> a processes configuration context
This phrase stuck to me, Christian. Not to rush you on your concrete
proposal, but sounds like you are envisioning building up a separate
struct with instructions on how to produce a process, rather than
mutating unscheduled but otherwise genuine `task_struct`s?
> > What do you want that for, BTW?
Those security + ergonomic things I mentioned in my original email are
the main goal.
I have a personal *long*-term goal to see something like CloudABI
resurrected. I think it got most of the interfaces right, but not
process management, and now that there are pidfds, we have a chance to
better.
I'm in no rush, so happy to just see very linux-specific interfaces
evolve in a good direction for now. Writing a personality or some other
shim is not the interesting part, to say the least, so I'm happy to wait
ages before doing that while the internals marinate.
John
next prev parent reply other threads:[~2021-08-03 6:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-01 17:47 forkat(int pidfd), execveat(int pidfd), other awful things? Jason A. Donenfeld
2021-02-01 17:51 ` Jason A. Donenfeld
2021-02-01 18:20 ` Christian Brauner
2021-02-01 18:29 ` Andy Lutomirski
2021-02-02 9:23 ` David Laight
2021-07-28 16:37 ` Leveraging pidfs for process creation without fork John Cotton Ericson
2021-07-29 14:24 ` Christian Brauner
2021-07-29 14:54 ` John Ericson
2021-07-30 1:41 ` Al Viro
2021-07-31 22:11 ` John Ericson
2021-07-31 22:42 ` Al Viro
2021-08-02 12:19 ` Christian Brauner
2021-08-03 6:00 ` John Cotton Ericson [this message]
2021-02-01 18:32 ` forkat(int pidfd), execveat(int pidfd), other awful things? Casey Schaufler
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=01e72780-e328-23b5-c114-9c35125da7c6@JohnEricson.me \
--to=mail@johnericson.me \
--cc=David.Laight@aculab.com \
--cc=Jason@zx2c4.com \
--cc=christian.brauner@canonical.com \
--cc=christian.brauner@ubuntu.com \
--cc=jann@thejh.net \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).