[RFC,UKL,09/10] exec: Give userspace a method for starting UKL process

Commit Message

Ali Raza Oct. 3, 2022, 10:21 p.m. UTC

From: Eric B Munson <[e-mail]>

From: Eric B Munson <[e-mail]>

The UKL process might depend on setup that is to be done by user space
prior to its initialization.  We need a way to let userspace signal that it
is ready for the UKL process to run. We will have setup a special name for
this process in the kernel config and if this name is passed to exec that
will start the UKL process. This way, if user space setup is required we
can be sure that the process doesn't run until explicitly started.

If a more traditional unikernel execution is desired, set the init= boot
param to the UKL process name.

Cc: Jonathan Corbet <[e-mail]>
Cc: Masahiro Yamada <[e-mail]>
Cc: Michal Marek <[e-mail]>
Cc: Nick Desaulniers <[e-mail]>
Cc: Thomas Gleixner <[e-mail]>
Cc: Ingo Molnar <[e-mail]>
Cc: Borislav Petkov <[e-mail]>
Cc: Dave Hansen <[e-mail]>
Cc: "H. Peter Anvin" <[e-mail]>
Cc: Andy Lutomirski <[e-mail]>
Cc: Eric Biederman <[e-mail]>
Cc: Kees Cook <[e-mail]>
Cc: Peter Zijlstra <[e-mail]>
Cc: Alexander Viro <[e-mail]>
Cc: Arnd Bergmann <[e-mail]>
Cc: Juri Lelli <[e-mail]>
Cc: Vincent Guittot <[e-mail]>
Cc: Dietmar Eggemann <[e-mail]>
Cc: Steven Rostedt <[e-mail]>
Cc: Ben Segall <[e-mail]>
Cc: Mel Gorman <[e-mail]>
Cc: Daniel Bristot de Oliveira <[e-mail]>
Cc: Valentin Schneider <[e-mail]>
Cc: Paolo Bonzini <[e-mail]>
Cc: Josh Poimboeuf <[e-mail]>

Suggested-by: Thomas Unger <[e-mail]>
Signed-off-by: Eric B Munson <[e-mail]>
Signed-off-by: Ali Raza <[e-mail]>
---
 fs/exec.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

Comments

Andy Lutomirski Oct. 4, 2022, 5:35 p.m. UTC | #1

On Mon, Oct 3, 2022, at 3:21 PM, Ali Raza wrote:
> From: Eric B Munson <[e-mail]>
>
> From: Eric B Munson <[e-mail]>
>
> The UKL process might depend on setup that is to be done by user space
> prior to its initialization.  We need a way to let userspace signal that it
> is ready for the UKL process to run. We will have setup a special name for
> this process in the kernel config and if this name is passed to exec that
> will start the UKL process. This way, if user space setup is required we
> can be sure that the process doesn't run until explicitly started.

This is just bizarre IMO.  Why is there one single UKL process?

How about having a way to start a UKL process and then, if desired, start *another* UKL process?  (And obviously there would be a security mode in which only a UKL process that is actually part of the kernel image can run or that only a UKL process with a hash that's part of the kernel image can run.)

--Andy

Ali Raza Oct. 6, 2022, 9:25 p.m. UTC | #2

On 10/4/22 13:35, Andy Lutomirski wrote:
> On Mon, Oct 3, 2022, at 3:21 PM, Ali Raza wrote:
>> From: Eric B Munson <[e-mail]>
>>
>> From: Eric B Munson <[e-mail]>
>>
>> The UKL process might depend on setup that is to be done by user space
>> prior to its initialization.  We need a way to let userspace signal that it
>> is ready for the UKL process to run. We will have setup a special name for
>> this process in the kernel config and if this name is passed to exec that
>> will start the UKL process. This way, if user space setup is required we
>> can be sure that the process doesn't run until explicitly started.
> 
> This is just bizarre IMO.  Why is there one single UKL process?
> 
> How about having a way to start a UKL process and then, if desired, start *another* UKL process?  (And obviously there would be a security mode in which only a UKL process that is actually part of the kernel image can run or that only a UKL process with a hash that's part of the kernel image can run.)
> 
> --Andy

Again, the commit message could have been worded better.

There can be two cases here, one where a UKL process forks or a new UKL
process is run once the first finishes. In this case, there a single UKL
application being run multiple times. The second case is where two
different UKL applications (both linked with the kernel) are run in
different processes, concurrently or one after the other. Lets look at
both of these cases.

For case 1, there is no restriction on how many UKL processes can run.
UKL allows forking, so there can be multiple processes but they will
have to share the text and data which is loaded along with the kernel
text and data. In the future, one can borrow ideas from how glibc
handles TLS i.e., where each UKL process would copy data into its user
half of memory. But we have not designed or implemented that yet. We
have tested applications that fork/clone. We have not tested running the
same UKL process again after an earlier UKL process exits, but there is
nothing stopping that from working.

For case 2, we have not yet implemented that. But for discussion's sake,
we can have two or more mutually trusting applications, all linked with
the kernel. And if you do /UKL1 or /UKL2 (or some proper names), you
should be able to run them concurrently. Again, although much of the
plumbing for this is there, we haven't implemented it fully yet.

Thank you again for the detailed feedback.

--Ali

Patch

diff --git a/fs/exec.c b/fs/exec.c
index 4ae06fcf7436..e30c6beb209b 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1888,6 +1888,22 @@  static int bprm_execve(struct linux_binprm *bprm,
 	return retval;
 }
 
+#ifdef CONFIG_UNIKERNEL_LINUX
+static void check_ukl_exec(const char *name)
+{
+	if (!strcmp(name, CONFIG_UKL_NAME)) {
+		pr_debug("In PID %d and current->ukl_thread is %d\nGoing to create UKL here.\n",
+				current->pid, is_ukl_thread());
+		enter_ukl_kernel();
+	}
+}
+#else
+static void check_ukl_exec(const char *name)
+{
+	(void)name;
+}
+#endif
+
 static int do_execveat_common(int fd, struct filename *filename,
 			      struct user_arg_ptr argv,
 			      struct user_arg_ptr envp,
@@ -1899,6 +1915,8 @@  static int do_execveat_common(int fd, struct filename *filename,
 	if (IS_ERR(filename))
 		return PTR_ERR(filename);
 
+	check_ukl_exec(filename->name);
+
 	/*
 	 * We move the actual failure in case of RLIMIT_NPROC excess from
 	 * set*uid() to execve() because too many poorly written programs
@@ -1985,6 +2003,8 @@  int kernel_execve(const char *kernel_filename,
 	if (WARN_ON_ONCE(current->flags & PF_KTHREAD))
 		return -EINVAL;
 
+	check_ukl_exec(kernel_filename);
+
 	filename = getname_kernel(kernel_filename);
 	if (IS_ERR(filename))
 		return PTR_ERR(filename);