libc: report _SC_NPROCESSORS_ONLN more accurately in cpu-limited jails

We don't support CPU hotplug, but we do support cpuset(8) restrictions
on jails (including prison0, which uses cpuset 1). The

libc: report _SC_NPROCESSORS_ONLN more accurately in cpu-limited jails

We don't support CPU hotplug, but we do support cpuset(8) restrictions
on jails (including prison0, which uses cpuset 1). The process cannot
widen its cpuset beyond its root set, so it makes sense to instead
report the number of cpus enabled there rather than the total number
in the system.

This change is effectively a nop for the majority of systems and jails
in the wild, though it does reduce the performance of this query now
that we can't take advantage of AT_NCPUS being provided in the auxinfo.

The implementation here is notably different than Linux, which would not
take cgroups into account. They do, however, take CPU hotplug into
account, so the possibility for it to diverge from (and be lower than)
the # configured count to reflect what the process can actually be
scheduled on doesn't really diverge in semantics.

Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D52295

show more ...

Remove a few more stray __FBSDID uses

Reviewed by: imp, emaste
Differential Revision: https://reviews.freebsd.org/D41954

jail: allow root to implicitly widen its cpuset to attach

The default behavior for attaching processes to jails is that the jail's
cpuset augments the attaching processes, so that it cannot be used

jail: allow root to implicitly widen its cpuset to attach

The default behavior for attaching processes to jails is that the jail's
cpuset augments the attaching processes, so that it cannot be used to
escalate a user's ability to take advantage of more CPUs than the
administrator wanted them to.

This is problematic when root needs to manage jails that have disjoint
sets with whatever process is attaching, as this would otherwise result
in a deadlock. Therefore, if we did not have an appropriate common
subset of cpus/domains for our new policy, we now allow the process to
simply take on the jail set *if* it has the privilege to widen its mask
anyways.

With the new logic, root can still usefully cpuset a process that
attaches to a jail with the desire of maintaining the set it was given
pre-attachment while still retaining the ability to manage child jails
without jumping through hoops.

A test has been added to demonstrate the issue; cpuset of a process
down to just the first CPU and attempting to attach to a jail without
access to any of the same CPUs previously resulted in EDEADLK and now
results in taking on the jail's mask for privileged users.

PR: 253724
Reviewed by: jamie (also discussed with)
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D28952

show more ...

libc: tests: add some tests for cpuset(2)

The cpuset(2) tests should be run as root (require.user properly set) with
>= 3 cpus for maximum coverage. All tests that want to modify the cpuset
don't as

libc: tests: add some tests for cpuset(2)

The cpuset(2) tests should be run as root (require.user properly set) with
>= 3 cpus for maximum coverage. All tests that want to modify the cpuset
don't assume any particular cpu layout (i.e. the first cpu may not be 0, the
last may not be first + count) and the following scenarios are tested:

1.) newset: basic execute cpuset() to grab a new cpuset, make sure the
assigned cpuset then has a different ID.
2.) transient: create a new cpuset then assign the process its original
cpuset, ensuring that the one we created is now gone.
3.) deadlk: test assigning an anonymous mask, then resetting the process
base affinity with 1-cpu overlap w.r.t. the anonymous mask and with
0-cpu overlap w.r.t. the anonymous mask.
4.) jail_attach_newbase: process attaches to a jail with its own
cpuset+mask (e.g. cpuset -c -l 1,2 jail -c path=/ command=/bin/sh)
5.) jail_attach_newbase_plain: process attaches to a jail with its own
cpuset (e.g. cpuset -c jail -c path=/ command=/bin/sh)
6.) jail_attach_prevbase: process attaches to a jail with the containing
jail's root cpuset (e.g. jail -c path=/ command=/bin/sh)
7.) jail_attach_plain: process attaches to a jail with the containing jail's
root cpuset+mask.
8.) badparent: creates a new cpuset and modifies the anonymous thread mask,
then setid's back to the original and checks that cpuset_getid() returns
the expected set.

Differential Revision: https://reviews.freebsd.org/D27307

show more ...

libc: report _SC_NPROCESSORS_ONLN more accurately in cpu-limited jails

We don't support CPU hotplug, but we do support cpuset(8) restrictions
on jails (including prison0, which uses cpuset 1). The

libc: report _SC_NPROCESSORS_ONLN more accurately in cpu-limited jails

We don't support CPU hotplug, but we do support cpuset(8) restrictions
on jails (including prison0, which uses cpuset 1). The process cannot
widen its cpuset beyond its root set, so it makes sense to instead
report the number of cpus enabled there rather than the total number
in the system.

This change is effectively a nop for the majority of systems and jails
in the wild, though it does reduce the performance of this query now
that we can't take advantage of AT_NCPUS being provided in the auxinfo.

The implementation here is notably different than Linux, which would not
take cgroups into account. They do, however, take CPU hotplug into
account, so the possibility for it to diverge from (and be lower than)
the # configured count to reflect what the process can actually be
scheduled on doesn't really diverge in semantics.

Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D52295

show more ...

Remove a few more stray __FBSDID uses

Reviewed by: imp, emaste
Differential Revision: https://reviews.freebsd.org/D41954

jail: allow root to implicitly widen its cpuset to attach

The default behavior for attaching processes to jails is that the jail's
cpuset augments the attaching processes, so that it cannot be used

jail: allow root to implicitly widen its cpuset to attach

The default behavior for attaching processes to jails is that the jail's
cpuset augments the attaching processes, so that it cannot be used to
escalate a user's ability to take advantage of more CPUs than the
administrator wanted them to.

This is problematic when root needs to manage jails that have disjoint
sets with whatever process is attaching, as this would otherwise result
in a deadlock. Therefore, if we did not have an appropriate common
subset of cpus/domains for our new policy, we now allow the process to
simply take on the jail set *if* it has the privilege to widen its mask
anyways.

With the new logic, root can still usefully cpuset a process that
attaches to a jail with the desire of maintaining the set it was given
pre-attachment while still retaining the ability to manage child jails
without jumping through hoops.

A test has been added to demonstrate the issue; cpuset of a process
down to just the first CPU and attempting to attach to a jail without
access to any of the same CPUs previously resulted in EDEADLK and now
results in taking on the jail's mask for privileged users.

PR: 253724
Reviewed by: jamie (also discussed with)
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D28952

show more ...

libc: tests: add some tests for cpuset(2)

The cpuset(2) tests should be run as root (require.user properly set) with
>= 3 cpus for maximum coverage. All tests that want to modify the cpuset
don't as

libc: tests: add some tests for cpuset(2)

The cpuset(2) tests should be run as root (require.user properly set) with
>= 3 cpus for maximum coverage. All tests that want to modify the cpuset
don't assume any particular cpu layout (i.e. the first cpu may not be 0, the
last may not be first + count) and the following scenarios are tested:

1.) newset: basic execute cpuset() to grab a new cpuset, make sure the
assigned cpuset then has a different ID.
2.) transient: create a new cpuset then assign the process its original
cpuset, ensuring that the one we created is now gone.
3.) deadlk: test assigning an anonymous mask, then resetting the process
base affinity with 1-cpu overlap w.r.t. the anonymous mask and with
0-cpu overlap w.r.t. the anonymous mask.
4.) jail_attach_newbase: process attaches to a jail with its own
cpuset+mask (e.g. cpuset -c -l 1,2 jail -c path=/ command=/bin/sh)
5.) jail_attach_newbase_plain: process attaches to a jail with its own
cpuset (e.g. cpuset -c jail -c path=/ command=/bin/sh)
6.) jail_attach_prevbase: process attaches to a jail with the containing
jail's root cpuset (e.g. jail -c path=/ command=/bin/sh)
7.) jail_attach_plain: process attaches to a jail with the containing jail's
root cpuset+mask.
8.) badparent: creates a new cpuset and modifies the anonymous thread mask,
then setid's back to the original and checks that cpuset_getid() returns
the expected set.

Differential Revision: https://reviews.freebsd.org/D27307

show more ...

libc: report _SC_NPROCESSORS_ONLN more accurately in cpu-limited jails

We don't support CPU hotplug, but we do support cpuset(8) restrictions
on jails (including prison0, which uses cpuset 1). The

libc: report _SC_NPROCESSORS_ONLN more accurately in cpu-limited jails

We don't support CPU hotplug, but we do support cpuset(8) restrictions
on jails (including prison0, which uses cpuset 1). The process cannot
widen its cpuset beyond its root set, so it makes sense to instead
report the number of cpus enabled there rather than the total number
in the system.

This change is effectively a nop for the majority of systems and jails
in the wild, though it does reduce the performance of this query now
that we can't take advantage of AT_NCPUS being provided in the auxinfo.

The implementation here is notably different than Linux, which would not
take cgroups into account. They do, however, take CPU hotplug into
account, so the possibility for it to diverge from (and be lower than)
the # configured count to reflect what the process can actually be
scheduled on doesn't really diverge in semantics.

Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D52295

show more ...

Remove a few more stray __FBSDID uses

Reviewed by: imp, emaste
Differential Revision: https://reviews.freebsd.org/D41954

jail: allow root to implicitly widen its cpuset to attach

The default behavior for attaching processes to jails is that the jail's
cpuset augments the attaching processes, so that it cannot be used

jail: allow root to implicitly widen its cpuset to attach

The default behavior for attaching processes to jails is that the jail's
cpuset augments the attaching processes, so that it cannot be used to
escalate a user's ability to take advantage of more CPUs than the
administrator wanted them to.

This is problematic when root needs to manage jails that have disjoint
sets with whatever process is attaching, as this would otherwise result
in a deadlock. Therefore, if we did not have an appropriate common
subset of cpus/domains for our new policy, we now allow the process to
simply take on the jail set *if* it has the privilege to widen its mask
anyways.

With the new logic, root can still usefully cpuset a process that
attaches to a jail with the desire of maintaining the set it was given
pre-attachment while still retaining the ability to manage child jails
without jumping through hoops.

A test has been added to demonstrate the issue; cpuset of a process
down to just the first CPU and attempting to attach to a jail without
access to any of the same CPUs previously resulted in EDEADLK and now
results in taking on the jail's mask for privileged users.

PR: 253724
Reviewed by: jamie (also discussed with)
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D28952

show more ...

libc: tests: add some tests for cpuset(2)

The cpuset(2) tests should be run as root (require.user properly set) with
>= 3 cpus for maximum coverage. All tests that want to modify the cpuset
don't as

libc: tests: add some tests for cpuset(2)

The cpuset(2) tests should be run as root (require.user properly set) with
>= 3 cpus for maximum coverage. All tests that want to modify the cpuset
don't assume any particular cpu layout (i.e. the first cpu may not be 0, the
last may not be first + count) and the following scenarios are tested:

1.) newset: basic execute cpuset() to grab a new cpuset, make sure the
assigned cpuset then has a different ID.
2.) transient: create a new cpuset then assign the process its original
cpuset, ensuring that the one we created is now gone.
3.) deadlk: test assigning an anonymous mask, then resetting the process
base affinity with 1-cpu overlap w.r.t. the anonymous mask and with
0-cpu overlap w.r.t. the anonymous mask.
4.) jail_attach_newbase: process attaches to a jail with its own
cpuset+mask (e.g. cpuset -c -l 1,2 jail -c path=/ command=/bin/sh)
5.) jail_attach_newbase_plain: process attaches to a jail with its own
cpuset (e.g. cpuset -c jail -c path=/ command=/bin/sh)
6.) jail_attach_prevbase: process attaches to a jail with the containing
jail's root cpuset (e.g. jail -c path=/ command=/bin/sh)
7.) jail_attach_plain: process attaches to a jail with the containing jail's
root cpuset+mask.
8.) badparent: creates a new cpuset and modifies the anonymous thread mask,
then setid's back to the original and checks that cpuset_getid() returns
the expected set.

Differential Revision: https://reviews.freebsd.org/D27307

show more ...