Conversation
…lock symlinks and not magic links The from-nothing build (run 35496552035, 9329c91) stopped in stage 04 at util-linux: libmount/src/hook_idmap.c:335, 'RESOLVE_NO_SYMLINKS' undeclared. Everything before it had passed on the new toolchain, the compiler check included. It is upstream's, and visible only where the C library's <fcntl.h> does not bring <linux/openat2.h> in, which is glibc before 2.43. hook_idmap.c uses the constant and includes nothing that defines it. Looking for where the other files get it found the worse half: include/fileutils.h defines a fallback of 0x02, and in the kernel's ABI 0x02 is RESOLVE_NO_MAGICLINKS; RESOLVE_NO_SYMLINKS is 0x04. context.c preprocesses to `mnt_context_is_restricted(cxt) ? 0x02 : 0` on such a libc, so the restricted-mount hardening 2.42 added blocks the wrong thing. Kryptik's mount is not setuid, so that mode is not reachable here; it is fixed anyway, because a carried patch should not leave a known-wrong constant beside the line it touches. build/patches/util-linux-2.42.3 holds one patch: fileutils.h includes the kernel header where configure found it and its fallback is 0x04, and hook_idmap.c includes fileutils.h as context.c and hook_mount.c do. The row becomes s_util_linux, which applies the set through apply_repo_patches with the same configure flags as before. Reproduced and checked on a glibc 2.39 host: the released tarball fails at the identical line; the patch applies to it with no fuzz through the project's own function, which refuses a tampered copy; the whole package then builds; and context.c preprocesses to 0x04 where it had 0x02.
…lds against glibc 2.40, and asks the kernel to block symlinks and not magic links
…n stage 05 asks Stage 05 kept a private list of options that must survive config resolution and took only =y. The built-in rule made the virtio GPU driver a module, the fragment says =m, the fragment check passed (374 lines, none dropped), and the private list then failed the kernel as MISSING CONFIG_DRM_VIRTIO_GPU, two and a half hours into each of three builds, because no build had reached stage 05 since the rule was merged. CI's config check could not have caught it: it shared the fragment check with the stage and not this list. The list and its rule are in build/lib/kconfig-check.sh now, and tools/resolve-kernel-config.sh asks them too, so CI answers in half a minute. Built in or a module is the fragment's to say, and the fragment check holds it to that; this list exists so that deleting a guarantee from a fragment is noticed, and a bool cannot come out =m, so nothing is loosened. Checked on the resolved config: it passes; with DM_VERITY deleted or SECCOMP_FILTER switched off it is refused. Both checks read the .config once into a map. They asked the file with sed | head for each of 374 fragment lines, some 750 processes and as many passes over the whole file; the fragment check takes a quarter of a second.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes the stage 05 failure that ended three Distro runs on 2026-09-20 (35530539514, 35530672889, 35530674126), each after stage 04 had passed:
MISSING CONFIG_DRM_VIRTIO_GPU.Contains #40 (the branch starts at its merge), so merging this fixes both of main's build failures.
Stage 05 kept a private list of options that must survive config resolution and accepted only
=y. The built-in rule (ADR-013) made the virtio GPU driver a module; the fragment says=m; the fragment check passed (374 lines, none dropped); the private list failed the kernel. No build had reached stage 05 since that rule was merged, and CI's config check shares the fragment check with the stage but not this list, so it could not have caught it.build/lib/kconfig-check.sh;tools/resolve-kernel-config.shasks them too, so CI answers in half a minute what took a build two and a half hours.=yor=mpasses. Which one is the fragment's to say, and the fragment check holds it to that. A bool cannot come out=m, so no guarantee is loosened. The list's job is to notice a guarantee being deleted from a fragment..configonce into a map instead ofsed | headper fragment line (about 750 processes); the fragment check takes a quarter of a second.Checked on the config resolved from the pinned source: every critical option passes, the virtio GPU as a module; the fragment result is unchanged (374 lines; the three compiler-plugin options this host cannot honour, as before); with
DM_VERITYdeleted, orSECCOMP_FILTERswitched off, the check refuses. Shellcheck clean. Distro run 35533755616 is building this tree.