linux-kernel - Re: Preemption Signal Management

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: <f9e0126e-2bd4-eda4-0c07-9393d56d1421@kernel.org>
Date:   Tue, 25 May 2021 17:39:49 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     Sargun Dhillon <sargun@...gun.me>,
        Linux Containers <containers@...ts.linux.dev>,
        LKML <linux-kernel@...r.kernel.org>
Cc:     Kees Cook <keescook@...omium.org>,
        Christian Brauner <christian.brauner@...ntu.com>,
        Tycho Andersen <tycho@...ho.pizza>,
        Giuseppe Scrivano <gscrivan@...hat.com>,
        Rodrigo Campos <rodrigo@...volk.io>,
        Mauricio Vásquez Bernal <mauricio@...volk.io>
Subject: Re: Preemption Signal Management

On 5/21/21 9:23 AM, Sargun Dhillon wrote:
> Andy pointed out that we need a mechanism to determine whether or
> notifications are preempted. He suggested we use EPOLLPRI to indicate
> whether or not notifications are preempted. My outstanding question is
> whether or not we need to be able to get insight of what caused the
> preemption, and to which notification.
> 
> In the past, Christian has suggested just background polling
> notification IDs for validity, which is a fine mechanism to determine
> that preemption has occurred. We could raise EPOLLPRI whenever a
> notification has changed into the preempted state, but that would
> require an O(n) operations across all outstanding notifications to
> determine which one was preempted, and in addition, it doesn't give a
> lot of information as to why the preemption occurred (fatal signal,
> preemption?).
> 
> In order to try to break this into small parts, I suggest:
> 1. We make it so EPOLLPRI is raised (always) on preempted notifications
> 2. We allow the user to set a flag to "track" notifications. If they
> specify this flag, they can then run a "stronger" ioctl -- let's say
> SECCOMP_IOCTL_NOTIF_STATUS, which, if the flag was specified upon
> receiving the notification will return the current state of the
> notification and if a signal preempted it, it will always do that.
> 
> ---
> Alternatively (and this is my preference), we add another filter flag,
> like SECCOMP_FILTER_FLAG_NOTIF_PREEMPT, which changes the behaviour
> to:
> 1. Raise EPOLLPRI on preempted notifications
> 2. All preemption notifications must be cleared via
> SECCOMP_IOCTL_NOTIF_RECV_STATUS.

This seems sensible, except I don't think "preempted" is the right word.
 The state machine is pretty simple:

live -> signaled -> killed

(and we can go straight from live to killed, too.)  So EPOLLPRI could be
signaled if any notification changes state, and a new ioctl could read
the list of notifications that have changed state.

--Andy