linux-kernel - Re: [patch v5 2/8] add prctl task isolation prctl docs and samples

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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 28 Oct 2021 16:53:43 +0200
From:   Frederic Weisbecker <frederic@...nel.org>
To:     Marcelo Tosatti <mtosatti@...hat.com>
Cc:     linux-kernel@...r.kernel.org, Nitesh Lal <nilal@...hat.com>,
        Nicolas Saenz Julienne <nsaenzju@...hat.com>,
        Christoph Lameter <cl@...ux.com>,
        Juri Lelli <juri.lelli@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Alex Belits <abelits@...its.com>, Peter Xu <peterx@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Daniel Bristot de Oliveira <bristot@...hat.com>
Subject: Re: [patch v5 2/8] add prctl task isolation prctl docs and samples

On Wed, Oct 27, 2021 at 02:52:47PM -0300, Marcelo Tosatti wrote:
> On Wed, Oct 27, 2021 at 02:38:06PM +0200, Frederic Weisbecker wrote:
> > > +        The 'pmask' argument specifies the location of an 8 byte mask
> > > +        containing which features should be activated. Features whose
> > > +        bits are cleared will be deactivated. The possible
> > > +        bits for this mask are:
> > > +
> > > +                - ``ISOL_F_QUIESCE``:
> > > +
> > > +                Activate quiescing of background kernel activities.
> > > +                Quiescing happens on return to userspace from this
> > > +                system call, and on return from subsequent
> > > +                system calls (unless quiesce_oneshot_mask is configured,
> > > +                see below).
> > > +
> > > +        If the arg3 argument is non-zero, it specifies a pointer to::
> > > +
> > > +         struct task_isol_activate_control {
> > > +                 __u64 flags;
> > > +                 __u64 quiesce_oneshot_mask;
> > 
> > So you are using an entire argument here to set a single feature (ISOL_F_QUIESCE).
> 
> Yes, but there is room at "struct task_isol_activate_control" for other features 
> to use (and additional space in the remaining prctl arguments, if necessary).

Ok but we have a configuration syscall and an activation syscall. Why bothering
with config parts on activation syscall?


> 
> > It looks like the oneshot VS every syscall behaviour should be defined at
> > configuration time for individual ISOL_F_QUIESCE features.
> 
> It seems one-shot selection is dependent on the 
> application logic:
> 
> 	configure task isolation
> 	enable oneshot quiescing of kernel activities
> 	do {
> 		process data (no system calls)
> 		if (event) {
> 			process event with syscalls
> 			enable oneshot quiescing of kernel activities
> 		}
>        } while (!exit_condition);
> 
> Considering configuration performed outside the application (by chisol),
> is the administrator supposed to know the internals of the application
> at this level ?

If the launcher doesn't know about details, just leave them to the isolated
app. I mean we have a syscall to get the configured features, it's easy to
modify their configuration and set the oneshot mode on the place wanted
by the isolated app.

> 
> What if the application desires to use one-shot in a section
> (of code) and "all syscalls" for another section.

Doesn't sound like a problem.

> 
> > Also do we want that to always apply to all syscalls? Should we expect corner
> > cases with some of them? 
> 
> What type of corner cases do you think of?

I don't trust my imagination enough to display all possible user workloads.

> 
> > What about exceptions and interrupts?
> 
> Should move the isolation_exit_to_user_mode_prepare call from
> __syscall_exit_to_user_mode_work to exit_to_user_mode_prepare.
> Good point.
> 
> About your question. Think so, because otherwise: 
> 
>      enable oneshot quiescing of kernel activities
>      do {
>              process data (no system calls)	    <--- 1. IRQ/exception
>              if (event) {
>                      process event with syscalls
>                      enable oneshot quiescing of kernel activities
>              }
>      } while (exit_condition == false);
> 
> 
> If either an interrupt or exception occurs at point 1 above, userspace
> might not be notified, and the interrupt/exception handler might 
> change state in the kernel which makes the current CPU a target
> for IPIs, for example changing per-CPU vm statistics.

Ok but please leave configuration space to modify that in the future just in case.

Thanks.