On 07/19/22 21:21, Richard W.M. Jones wrote:
> On Fri, Jul 15, 2022 at 05:42:35PM -0400, Ben Cotton wrote:
>> https://fedoraproject.org/wiki/Changes/SELinux_Parallel_Autorelabel
>>
>> This document represents a proposed Change. As part of the Changes
>> process, proposals are publicly announced in order to receive
>> community feedback. This proposal will only be implemented if approved
>> by the Fedora Engineering Steering Committee.
>>
>>
>> == Summary ==
>> After a system's SELinux mode is switched from disabled to enabled, or
>> after an administrator runs `fixfiles onboot`, SELinux autorelabel
>> will be run in parallel by default.
>>
>> == Owner ==
>> * Name: [[User:plautrba| Petr Lautrbach]]
>> * Email: plaut...@redhat.com
>>
>>
>> == Detailed Description ==
>> SELinux tools `restorecon` and `fixfiles` recently gained the ability
>> to relabel files in parallel using the `-T nthreads` option. This
>> option is currently not used in the automatic relabel after reboot.
>> When users want/need the parallel relabeling they have to specify the
>> option explicitly (e.g. `fixfiles -T 0 onboot`). With this change `-T
>> 0` (0 == use all available CPU cores) will be the default for
>> `fixfiles onboot` and users will have to use `fixfiles -T 1 onboot` to
>> force it to use only one thread.
>>
>> The rationale is that when autorelabel runs, there are no other
>> resource-intensive processes running on the system, so it's fine (and
>> actually better) to use all available parallelism to speed up the task
>> and get to a fully booted system faster.
>>
>>
>> == Benefit to Fedora ==
>> Faster reboot after switching back to an SELinux enabled system or
>> when triggering autorelabel explicitly.
> [...]
>> == Upgrade/compatibility impact ==
>>
>>
>> == How To Test ==
>> # boot with SELinux disabled - add `selinux=0` to the kernel command line
>> # reboot
>> # store the time it took
>> # run `fixfiles -T 1 onboot`
>> # reboot
>> # the latter reboot should take longer time
> [...]
>
> I wonder if we can use this in virt tools & virt-v2v:
>
> https://github.com/libguestfs/libguestfs/blob/master/daemon/selinux-relabel.c
>
> We actually use setfiles instead of fixfiles. setfiles appears to
> have no -T option unfortunately. Is there a reason why setfiles
> doesn't have / need this option?
Upstream setfiles(8) does support the parallelized operation.
When I was working on the patches for RHBZ#1794518 (-> selinux commit
range d108226d3fc6..2b6f7e969cf6), the selinux library exposed two APIs:
- selinux_restorecon(3)
- selinux_restorecon_parallel(3)
Internally, both call selinux_restorecon_common(), just with a different
thread count (open-coded "1", versus forwarding "nthreads", respectively).
The setfiles(8) utility had already called the newer API since commit
93902fc8340f ("setfiles/restorecon: support parallel relabeling",
2021-11-23). This commit was going to be released in selinux-3.4; Fedora
35 currently ships libselinux-3.3-1.fc35.x86_64. The latest build in
Koji for Fedora 36 is only libselinux-3.3-4.fc36, too.
I think we could modify libguestfs to test "setfiles" for the "-T"
option -- with setfiles_has_option() --, and if it's present, pass "-T
0". However, for that to be actually useful, we'd need to start up the
appliance with multiple VCPUs -- using guestfs_set_smp().
... Apparently, virt-customize already exposes an "--smp" option for
that, so we might get away with modifying libguestfs only.
Thanks
Laszlo
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
