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 <munsoner@xxxxxx> >> >> From: Eric B Munson <munsoner@xxxxxx> >> >> 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
