On Mon, Feb 24, 2025 at 12:28:22AM +0100, Joerg Sonnenberger wrote:
>
>
> On 2/23/25 8:34 PM, Thomas Klausner wrote:
> > On Mon, Feb 24, 2025 at 06:32:09AM +1100, Matthew Green wrote:
> > > > Log Message:
> > > > Add LIBRARY section and explicitly mention that these interfaces
> > > > require super-user privileges.
> > >
> > > this can be relaxed with the
> > > security.models.extensions.user_set_cpu_affinity sysctl.
> >
> > I found this and wondered what the attack model is that makes it default to
> > off...
>
> Any kind of cache side channel attacks are much easier if you can explicitly
> control where things are executed.
Thanks for the explanation.
I just checked the man page again and noticed that you had been
talking about pset while I had thought we talked about the cpuset_*
interfaces.
I think the sysctl only affects the cpuset_* and not pset. At least
the attached test program, basically copied from the man page, fails
for me:
# sysctl security.models.extensions.user_set_cpu_affinity
security.models.extensions.user_set_cpu_affinity = 1
# gcc -Wall -o psettest psettest.c -lrt
# ./psettest
psettest: pset_create: Operation not permitted
Thomas
#include <stdlib.h>
#include <stddef.h>
#include <stdio.h>
#include <sys/pset.h>
#include <err.h>
int main() {
psetid_t psid;
cpuid_t ci = 0;
if (pset_create(&psid) < 0)
err(EXIT_FAILURE, "pset_create");
/* Assign CPU 0 to the processor-set */
if (pset_assign(psid, ci, NULL) < 0)
err(EXIT_FAILURE, "pset_assign");
/* Bind the current process to the processor-set */
if (pset_bind(psid, P_PID, P_MYID, NULL) < 0)
err(EXIT_FAILURE, "pset_bind");
/*
* At this point, CPU 0 runs only the current process.
*/
printf("success\n");
if (pset_destroy(psid) < 0)
err(EXIT_FAILURE, "pset_destroy");
}
