The kernel's sched_setattr interface allows for more control over a processes
scheduling attributes as the previously used sched_setscheduler interface.
Using sched_setattr is also the prerequisite for support of utilization
clamping (UCLAMP [1], see #26705) and allows to set sched_runtime. The latter,
sched_runtime, will probably become a relevant scheduling parameter of the
EEVDF scheduler [2, 3], and therefore will not only apply to processes
scheduled via SCHED_DEADLINE, but also for processes scheduled via
SCHED_OTHER/SCHED_BATCH (i.e., most processes).
1: https://docs.kernel.org/next/scheduler/sched-util-clamp.html
2: https://lwn.net/Articles/969062/
3: https://lwn.net/ml/linux-kernel/20240405110010.934104715@infradead.org/
We have very similar code for setting generic efi vars in sd-stub and
sd-boot. Let's share it.
This changes behaviour in a minor way: if you chainload multiple
versions of an sd-boot you'll see the efi vars of the first one now in
the OS, not of the last one.
But this should not matter, invocation like that should generally not
happen.
Let's do the section measurement first, before we use any data of it.
Let's bring up the boot splash next, so that it covers anything else we
might do.
Instead of keeping three parallel arrays of dt base, dt size and dt
filename, just introduce a proper structure and use an array of that,
greatly simplifying DT handling.
Let's make sure we validate that the DOS/PE header offsets are actually
reasonable, and do not cause overflows when added to the base addresses.
(This shouldn're really be a problem URL, since the DOS header offset is
16bit only, but let's be extra careful with this)
Let's put a limit on how much memory we'll allocate for the section. And
let's add a safety overflow check.
(This is more a theoretic than a real problem, since on all PE archs
NumberOfSections is 16bit only.)
The construct is a POSIX invention, but it's just so useful, let's also
define it in EFI mode, so that we can use similar constructs in EFI mode
and userspace.
We already had 'auth_admin_keep' for org.freedesktop.login1.reboot and similar
actions. If a user is allowed to perform an action, I think they should be
allowed to _block_ the same action. Guarding this by auth_admin follows the
general principle of not allowing fully unprivileged users to have too much say
over the machine.
