linux-kernel - Re: [RFC UKL 09/10] exec: Give userspace a method for starting UKL process

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 6 Oct 2022 17:25:44 -0400
From:   Ali Raza <aliraza@...edu>
To:     Andy Lutomirski <luto@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Cc:     Jonathan Corbet <corbet@....net>, masahiroy@...nel.org,
        michal.lkml@...kovi.net,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Kees Cook <keescook@...omium.org>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Arnd Bergmann <arnd@...db.de>, juri.lelli@...hat.com,
        vincent.guittot@...aro.org, dietmar.eggemann@....com,
        Steven Rostedt <rostedt@...dmis.org>,
        Ben Segall <bsegall@...gle.com>, mgorman@...e.de,
        bristot@...hat.com, vschneid@...hat.com,
        Paolo Bonzini <pbonzini@...hat.com>, jpoimboe@...nel.org,
        linux-doc@...r.kernel.org, linux-kbuild@...r.kernel.org,
        linux-mm@...ck.org, linux-fsdevel@...r.kernel.org,
        linux-arch@...r.kernel.org,
        the arch/x86 maintainers <x86@...nel.org>, rjones@...hat.com,
        munsoner@...edu, tommyu@...edu, drepper@...hat.com,
        lwoodman@...hat.com, mboydmcse@...il.com, okrieg@...edu,
        rmancuso@...edu
Subject: Re: [RFC UKL 09/10] exec: Give userspace a method for starting UKL
 process

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