[SOLVED] landlock syscalls missing?

ZlatkO · 05-03-2024, 03:54 AM

Hi,

When trying to compile tracker-miners-3.7.x without "-D landlock=disabled", meson complains that ...

Code:

meson.build:195:4: ERROR: Problem encountered: Landlock was auto-enabled in build options, but is disabled in the kernel

..., which is not quite true (this is a custom built 6.6.30 LTS kernel):

Code:

[zlatko@disclosure:~]$ grep -i landlock /boot/config
CONFIG_SECURITY_LANDLOCK=y
CONFIG_LSM="landlock,lockdown,yama,loadpin,safesetid,integrity"

However, it appears that all of the landlock related syscalls are indeed missing from glibc's /usr/include/bits/syscall.h:

Code:

[root@disclosure:~]# grep -r SYS_landlock /usr/include/
[root@disclosure:~]#

For reference, here's the output of the same command on a FC39 system:

Code:

[root@wasser:~]# grep -r SYS_landlock /usr/include/
/usr/include/bits/syscall.h:# define SYS_landlock_add_rule __NR_landlock_add_rule
/usr/include/bits/syscall.h:# define SYS_landlock_create_ruleset __NR_landlock_create_ruleset
/usr/include/bits/syscall.h:# define SYS_landlock_restrict_self __NR_landlock_restrict_self

Now, given that ...

1. landlock has been available since kernel 5.13, and Slackware-15.0 initially shipped with 5.15;
2. there appear to be landlock related patches back to at least glibc-2.28, and Slackware-15.0 ships with 2.33;
3. there don't seem to be any bits & bobs explicitly disabling landlock in glibc's SlackBuild script;

... I wonder where the landlock related syscalls have gone? The only reason I could imagine is that they only get included/shipped/exported to "bits/syscall.h" if glibc is built/compiled/packaged on a kernel that actually has CONFIG_SECURITY_LANDLOCK=y enabled, could that be the case? And yes, I know I could do that, but I'd rather not have to rebuild glibc on my system just to find out ...

Thanks for listening,
Thomas

ZlatkO · 05-03-2024, 04:06 AM

Quote:

Originally Posted by ZlatkO

The only reason I could imagine is that they only get included/shipped/exported to "bits/syscall.h" if glibc is built/compiled/packaged on a kernel that actually has CONFIG_SECURITY_LANDLOCK=y enabled, could that be the case?

As usual, answering (one of) my own question(s) only minutes after posting: nope, that doesn't appear to be the case. I just had a look at Slackware-current, and in slackware64-current/source/k/kernel-configs, none of the four config-*s have CONFIG_SECURITY_LANDLOCK=y enabled, and yet in glibc-2.39's "bits/syscall.h" there is:

Code:

#ifdef __NR_landlock_add_rule
# define SYS_landlock_add_rule __NR_landlock_add_rule
#endif

#ifdef __NR_landlock_create_ruleset
# define SYS_landlock_create_ruleset __NR_landlock_create_ruleset
#endif

#ifdef __NR_landlock_restrict_self
# define SYS_landlock_restrict_self __NR_landlock_restrict_self
#endif

Hmmmm ...

Petri Kaukasoina · 05-03-2024, 04:46 AM

In -current:

Code:

$ head -2 /usr/include/bits/syscall.h
/* Generated at libc build time from syscall list.  */
/* The system call list corresponds to kernel 6.7.  */

In 15.0:

Code:

$ head -2 /usr/include/bits/syscall.h
/* Generated at libc build time from syscall list.  */
/* The system call list corresponds to kernel 5.10.  */

ZlatkO · 05-03-2024, 08:05 AM

Aaaaaah! Thanks, I obviously missed that bit. Oops.

But in that case, and with this newly gained knowledge, allow me to slightly rephrase my question: if 15.0 shipped with 5.15, why was/is it using 5.10's syscall list? I briefly thought that it might in fact not be generated, but included "hard-coded" in the upstream glibc sources, but that doesn't seem to be the case, either. From glibc-2.33.tar.xz's glibc-2.33/sysdeps/unix/sysv/linux/include/bits/syscall.h:

Code:

/* The real bits/syscall.h is generated during the build, in
   $(objdir)/misc/bits.  */
#include <misc/bits/syscall.h>

I always somehow implicitly assumed that every release sort of bootstrapped itself, ie. that the "15.0-release" packages would be built on an identical, clean "15.0-build" system, but that doesn't seem to be the case, not even for post-release patches (15.0 originally shipped with glibc-2.33-x86_64-5, and glibc-2.33-x86_64-6_slack15.0 was released on 2024-04-18, but still includes 5.10's syscall list).

Any insights from Slackware's "inner circle" on why things are handled that way, ie. packages get built on a newer-than-previous-release-but-older-than-current-release system? Isn't that actually a recipe for inconsistencies like this? Especially for glibc, I was under the impression that it should always be built with at least the same kernel version or newer, relative to the intended target system. From glibc-2.33/INSTALL:

Quote:

Specific advice for GNU/Linux systems
=====================================

If you are installing the GNU C Library on GNU/Linux systems, you need
to have the header files from a 3.2 or newer kernel around for reference.
[...] These headers must be installed using 'make headers_install';
the headers present in the kernel source directory are not suitable for
direct use by the GNU C Library. You do not need to use that kernel,
just have its headers installed where the GNU C Library can access them,
referred to here as INSTALL-DIRECTORY. The easiest way to do this is to
unpack it in a directory such as '/usr/src/linux-VERSION'. In that
directory, run 'make headers_install
INSTALL_HDR_PATH=INSTALL-DIRECTORY'. Finally, configure the GNU C
Library with the option '--with-headers=INSTALL-DIRECTORY/include'. Use
the most recent kernel you can get your hands on. [...]

With the current setup (ie. building packages for 15.0 on a system running a 5.10 kernel, or at least only having 5.10 kernel headers installed, see above) it seems like all new kernel features between the build kernel(-headers) version and the release kernel version might potentially be wasted, at least if they introduce new syscalls, no? Or am I missing something obvious here?

I fully accept that I'm "on my own" if I like to always run the latest LTS kernel on my system, as I happen to do, but at the same time I would also expect that if my distro ships with a 5.15 kernel out of the box, then I should also be able to use all available features of that specific kernel version. Or am I asking to much here? That's an honest question, and not meant as a snarky remark, BTW.

Thanks for listening,
Thomas

chemfire · 05-03-2024, 09:28 AM

I think you are asking to much. The point of stable release is that it is stable. Which does not mean its going to have the latest release of every package prior to its own release date, and it does not mean that every package will be built with the lasted wizbang features that might be possible to enable post update of other packages.

Without combing back thru the change log my guess is the kernel got updated again after the C library was built. Its important the C library be well tested and very stable so it did not make sense to rebuild it again prior to release. While Slackware could do more of code-freeze, final build, test, release model it would only serve to lengthen the time required to go from beta/rc to release. The result is we'd have more dated packages on release day.

Look at it this way all the major components are 'new enough' at the source level to get you the feature you want in 15.0. So you can probably rebuild the stuff and it will be minimally invasive and work. If Pat used the other model 15.0 would probably have had an older kernel and C library so that it could get enough testing prior to release. There is no perfect solution here. Slackware is and has always been a 'binary' distribution. While I think it is the case currently, I don't think there is really even a formal promise everything in the source directory will even build on the release platform.

ZlatkO · 05-03-2024, 10:31 AM

Quote:

Originally Posted by chemfire

I think you are asking to much. The point of stable release is that it is stable. Which does not mean its going to have the latest release of every package prior to its own release date, and it does not mean that every package will be built with the lasted wizbang features that might be possible to enable post update of other packages. [...]

Yes, I agree with you on the core concept of stability vs. features. BUT: what was the point of releasing 15.0 with the 5.15 kernel then? It was relatively new at that point (5.15.19), so why not keep 5.10 (which is also an LTS kernel) instead, especially if glibc is compiled against it anyway? If, OTOH, the point of going with 5.15 was "features", then what good are the features if you can't actually use them? And it couldn't have been security & bug fixes, because those get backported to earlier LTS kernels as well anyway (that's the whole point of LTS kernels). If the point of keeping glibc at 5.10 was "stability", then wouldn't things be even more stable if the running system kernel actually matched the glibc kernel version?

Something about this mismatch doesn't feel quite right, IMHO, and I'd really be interested in the rationale behind it. Plus it just irks my inner Mr. Monk that there's a discrepancy between "kernel-shipped" and "kernel-glibc-is-compiled-against".

Don't get me wrong, I've been using Slackware since 1997, so I'm well aware of what I can expect from it vs. what I can NOT expect.

It's not a big deal, I just keep compiling stuff with the necessary features disabled, I'm just curious about the logic behind it.

Petri Kaukasoina · 05-03-2024, 10:33 AM

/usr/include/sys/syscall.h tells us:

Code:

/* This file should list the numbers of the system calls the system knows.
   But instead of duplicating this we use the information available
   from the kernel sources.  */
#include <asm/unistd.h>

/* The Linux kernel header file defines macros __NR_*, but some
   programs expect the traditional form SYS_*.  <bits/syscall.h>
   defines SYS_* macros for __NR_* macros of known names.  */
#include <bits/syscall.h>

<asm/unistd.h> reads <asm/unistd_64.h> which does have __NR_landlock_* defined (by kernel-headers-5.15.*). So, it seems to me that the syscalls are there but not with the traditional SYS_ form. What happens if you simply patch your program source with this:

Code:

grep -rl SYS_landlock_ *|while read f;do sed -i 's/SYS_landlock_/__NR_landlock_/g' $f;done

reddog83 · 05-03-2024, 11:16 AM

Just a question are you looking to build Gnome on Slackware 15.0?
Tracker 3.7 is compiled usually with Gnome 46 which we do have built on Slackware Current only due to needing the graphics stack upgraded as well as someother programs.

Quote:

Originally Posted by ZlatkO

Hi,

When trying to compile tracker-miners-3.7.x without "-D landlock=disabled", meson complains that ...

Code:

meson.build:195:4: ERROR: Problem encountered: Landlock was auto-enabled in build options, but is disabled in the kernel

..., which is not quite true (this is a custom built 6.6.30 LTS kernel):

Code:

[zlatko@disclosure:~]$ grep -i landlock /boot/config
CONFIG_SECURITY_LANDLOCK=y
CONFIG_LSM="landlock,lockdown,yama,loadpin,safesetid,integrity"

However, it appears that all of the landlock related syscalls are indeed missing from glibc's /usr/include/bits/syscall.h:

Code:

[root@disclosure:~]# grep -r SYS_landlock /usr/include/
[root@disclosure:~]#

For reference, here's the output of the same command on a FC39 system:

Code:

[root@wasser:~]# grep -r SYS_landlock /usr/include/
/usr/include/bits/syscall.h:# define SYS_landlock_add_rule __NR_landlock_add_rule
/usr/include/bits/syscall.h:# define SYS_landlock_create_ruleset __NR_landlock_create_ruleset
/usr/include/bits/syscall.h:# define SYS_landlock_restrict_self __NR_landlock_restrict_self

Now, given that ...

1. landlock has been available since kernel 5.13, and Slackware-15.0 initially shipped with 5.15;
2. there appear to be landlock related patches back to at least glibc-2.28, and Slackware-15.0 ships with 2.33;
3. there don't seem to be any bits & bobs explicitly disabling landlock in glibc's SlackBuild script;

... I wonder where the landlock related syscalls have gone? The only reason I could imagine is that they only get included/shipped/exported to "bits/syscall.h" if glibc is built/compiled/packaged on a kernel that actually has CONFIG_SECURITY_LANDLOCK=y enabled, could that be the case? And yes, I know I could do that, but I'd rather not have to rebuild glibc on my system just to find out ...

Thanks for listening,
Thomas

Petri Kaukasoina · 05-03-2024, 11:39 AM

Quote:

Originally Posted by Petri Kaukasoina

In -current:
/* The system call list corresponds to kernel 6.7. */
In 15.0:
/* The system call list corresponds to kernel 5.10. */

I think the names of the SYS_* definitions come from a hard coded list in the glibc sources. In glibc-2.33/sysdeps/unix/sysv/linux/syscall-names.list (Slackware 15.0):

Code:

...
# The list of system calls is current as of Linux 5.10.
kernel 5.10
...

And in glibc-2.39/sysdeps/unix/sysv/linux/syscall-names.list (-current):

Code:

...
# The list of system calls is current as of Linux 6.7.
kernel 6.7
...
landlock_add_rule
landlock_create_ruleset
landlock_restrict_self
...

ZlatkO · 05-03-2024, 12:31 PM

Quote:

Originally Posted by reddog83

Just a question are you looking to build Gnome on Slackware 15.0? [...]

I'm not looking to build it, I'm actually (constantly) upgrading my existing GNOME 46.1 install.

reddog83 · 05-03-2024, 12:34 PM

Quote:

Originally Posted by ZlatkO

I'm not looking to build it, I'm actually (constantly) upgrading my existing GNOME 46.1 install.

So are you on 15 or current??

ZlatkO · 05-03-2024, 12:43 PM

Quote:

Originally Posted by Petri Kaukasoina

I think the names of the SYS_* definitions come from a hard coded list in the glibc sources. [...]

Thanks for that hint, Petri, it didn't occur to me to search for similar but slightly different named syscalls.

And you're right, there's actually quite a bunch of them:

Code:

[zlatko@disclosure:~]$ grep -ril landlock /usr/include/
/usr/include/asm-x86/unistd_64.h
/usr/include/asm-x86/unistd_x32.h
/usr/include/asm-x86/unistd_32.h
/usr/include/asm-generic/unistd.h
/usr/include/linux/landlock.h
/usr/include/seccomp-syscalls.h

I'll see if I can slap around^W^W patch

tracker-miners-3.7 a bit to accept them under a different name.

ZlatkO · 05-03-2024, 12:47 PM

Quote:

Originally Posted by reddog83

So are you on 15 or current??

I'm on 15.0, as shown on the screenshot.

What I meant by "constantly updating" is that I compile & install GNOME, freedesktop.org & assorted packages as they are being released, but I'm using 15.0 as a base for that.

reddog83 · 05-03-2024, 12:49 PM

Ahhh thats kool

reddog83 · 05-03-2024, 01:02 PM

If you want you can join our Discord channel we build Gnome on Current.

https://discord.gg/4HdDXfhj