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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20211027175247.GA296917@fuller.cnet>
Date:   Wed, 27 Oct 2021 14:52:47 -0300
From:   Marcelo Tosatti <mtosatti@...hat.com>
To:     Frederic Weisbecker <frederic@...nel.org>
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:38:06PM +0200, Frederic Weisbecker wrote:
> > +- activation state:
> > +
> > +        The activation state (whether activate/inactive) of the task
> 
> active/inactive ?

Fixed.

> > +        This feature allows quiescing select kernel activities on
> 
> selected?

Fixed.

> > +                - Bit ISOL_INHERIT_CONF: Inherit task isolation configuration.
> > +                  This is the stated written via prctl(PR_ISOL_CFG_SET, ...).
> 
> state

Fixed.

> > +        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).

> 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 ?

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

> 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? 

> 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.

> My wild guess is that we need to leave room for future flexibility. Either open
> some configuration space on ISOL_F_QUIESCE for that or create a seperate
> ISOL_F_QUIESCE_ONESHOT.

See above about oneshot being application dependent.

> 
> Other than that, the general interface looks good! Now time for me to
> look at the implementation...

OK, thanks.