From: Eric B Munson <[email protected]>
From: Eric B Munson <[email protected]>
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 <[email protected]>
Cc: Masahiro Yamada <[email protected]>
Cc: Michal Marek <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Dave Hansen <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Eric Biederman <[email protected]>
Cc: Kees Cook <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Alexander Viro <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Juri Lelli <[email protected]>
Cc: Vincent Guittot <[email protected]>
Cc: Dietmar Eggemann <[email protected]>
Cc: Steven Rostedt <[email protected]>
Cc: Ben Segall <[email protected]>
Cc: Mel Gorman <[email protected]>
Cc: Daniel Bristot de Oliveira <[email protected]>
Cc: Valentin Schneider <[email protected]>
Cc: Paolo Bonzini <[email protected]>
Cc: Josh Poimboeuf <[email protected]>
Suggested-by: Thomas Unger <[email protected]>
Signed-off-by: Eric B Munson <[email protected]>
Signed-off-by: Ali Raza <[email protected]>
---
fs/exec.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
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);
--
2.21.3
On Mon, Oct 3, 2022, at 3:21 PM, Ali Raza wrote:
> From: Eric B Munson <[email protected]>
>
> From: Eric B Munson <[email protected]>
>
> 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
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 <[email protected]>
>>
>> From: Eric B Munson <[email protected]>
>>
>> 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