From: Avi Kivity <avi@redhat.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: "Ingo Molnar" <mingo@elte.hu>,
"Pekka Enberg" <penberg@cs.helsinki.fi>,
"Tom Zanussi" <tzanussi@gmail.com>,
"Frédéric Weisbecker" <fweisbec@gmail.com>,
"Steven Rostedt" <rostedt@goodmis.org>,
"Arnaldo Carvalho de Melo" <acme@redhat.com>,
"Peter Zijlstra" <peterz@infradead.org>,
linux-perf-users@vger.kernel.org,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: disabling group leader perf_event
Date: Mon, 06 Sep 2010 20:50:55 +0300 [thread overview]
Message-ID: <4C8529FF.6090500@redhat.com> (raw)
In-Reply-To: <20100906164824.339cd82e@lxorguk.ukuu.org.uk>
On 09/06/2010 06:48 PM, Alan Cox wrote:
>> No, I want the ability to terminate the code at any time and clean up
>> any resources used. We have exactly the same requirements for ordinary
>> userspace.
> So you intend to prevent its use at any point where we have a kernel only
> resource held in any way manner or form ? Remember we don't hold locks or
> many kinds of kernel resource across syscalls.
I don't think we can allow the downloaded code to hold any kernel
locks. If the locks are necessary for correct operation, then the
untrusted code can "forget" to take them. If they aren't necessary,
don't expose them in the first place. All APIs exposed to the code have
to be thread safe. We can allow locks that only protect user data
structures (and so we can just wipe them out if we need to kill the
code, just like with futexes[1]).
Other resources are easy, we do this everywhere, including for userspace.
> Likewise I'm interested
> how you will keep it compatible with real time ?
It's just like other executing any user code. Whatever thread executes
that code is impacted by its real time characteristics. If a
non-realtime thread executes it, who cares. If a real time thread
executes it, then it's up to the user to guarantee real time behaviour.
The kernel need only ensure that user code given by a low-priority task
is not executed in a high priority task.
>> So you do want to jit?
> Depends what you mean by jit. JIT normally implies compiling/recompiling
> as you go. Do we want to compile it once at load time - probably,
> assuming the tool is present.
That's jit enough for me. These would usually be small code snippets,
not megabytes of junk, though that would no doubt follow if we do a good
job.
We could probably s/netfilter/call to user code/ and remove tons of
potentially vulnerable kernel code, and gain lots of flexibility into
the bargain. I'd like to use this for kvm as well.
[1] Ignoring robust futexes, IIUC
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
next prev parent reply other threads:[~2010-09-06 17:51 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-06 9:12 disabling group leader perf_event Avi Kivity
2010-09-06 11:24 ` Peter Zijlstra
2010-09-06 11:34 ` Avi Kivity
2010-09-06 11:54 ` Peter Zijlstra
2010-09-06 11:58 ` Avi Kivity
2010-09-06 12:29 ` Peter Zijlstra
2010-09-06 12:40 ` Ingo Molnar
2010-09-06 13:16 ` Steven Rostedt
2010-09-06 16:42 ` Tom Zanussi
2010-09-07 12:53 ` Steven Rostedt
2010-09-07 14:16 ` Tom Zanussi
2010-09-06 12:49 ` Avi Kivity
2010-09-06 12:43 ` Ingo Molnar
2010-09-06 12:45 ` Avi Kivity
2010-09-06 12:59 ` Ingo Molnar
2010-09-06 13:41 ` Pekka Enberg
2010-09-06 13:54 ` Ingo Molnar
2010-09-06 14:57 ` Avi Kivity
2010-09-06 15:30 ` Alan Cox
2010-09-06 15:20 ` Avi Kivity
2010-09-06 15:48 ` Alan Cox
2010-09-06 17:50 ` Avi Kivity [this message]
2010-09-06 15:47 ` Ingo Molnar
2010-09-06 17:55 ` Avi Kivity
2010-09-07 3:44 ` Ingo Molnar
2010-09-07 8:33 ` Stefan Hajnoczi
2010-09-07 9:13 ` Avi Kivity
2010-09-07 22:43 ` Ingo Molnar
2010-09-07 15:55 ` Alan Cox
2010-09-08 1:44 ` Paul Mackerras
2010-09-08 6:16 ` Pekka Enberg
2010-09-08 6:44 ` Ingo Molnar
2010-09-08 7:30 ` Peter Zijlstra
2010-09-08 19:30 ` Frank Ch. Eigler
2010-09-09 7:38 ` Ingo Molnar
2010-09-08 6:19 ` Avi Kivity
2010-09-06 20:31 ` Pekka Enberg
2010-09-06 20:37 ` Pekka Enberg
2010-09-07 4:03 ` Ingo Molnar
2010-09-07 9:30 ` Pekka Enberg
2010-09-07 22:27 ` Ingo Molnar
2010-09-07 10:57 ` KOSAKI Motohiro
2010-09-07 12:14 ` Pekka Enberg
2010-09-07 13:35 ` Steven Rostedt
2010-09-07 13:47 ` Avi Kivity
2010-09-07 16:02 ` Steven Rostedt
2010-09-12 6:46 ` Pavel Machek
2010-09-12 17:54 ` Avi Kivity
2010-09-12 18:48 ` Ingo Molnar
2010-09-12 19:14 ` Pavel Machek
2010-09-12 20:32 ` Ingo Molnar
2010-09-12 21:06 ` Pavel Machek
2010-09-12 22:19 ` Ingo Molnar
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=4C8529FF.6090500@redhat.com \
--to=avi@redhat.com \
--cc=acme@redhat.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=penberg@cs.helsinki.fi \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tzanussi@gmail.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.