close_range is not available on older systems, preventing the building of a UML kernel

close_range is not available on older systems, preventing the building of a UML kernel

[Glenn Washburn]

Hi all,

I'm wanting to build a UML kernel on Debian bullseye, which is at
kernel version 5.10, which does not support close_range(). It appears
as though close_range() support is required on the host since commit
32e8eaf263d ("um: use execveat to create userspace MMs"). Was there a
conscious decision to break support for kernels less than 5.11, when
close_range() was added. What is the policy on support of the host
kernel? Since 5.4 is still supported as a longterm release. I think it
would be nice to at least support 5.4. Is there any interest in
removing this restriction?

Also, this system is at glibc 2.31, which does not have execveat()
support, which is required by that same commit above. Since execveat()
has been supported since 3.19, this kernel should support it. Perhaps
the issue can be resolved by defining a syscall wrapper in the UM
headers if support is not found in glibc.

Glenn

Re: close_range is not available on older systems, preventing the building of a UML kernel

[Benjamin Berg]

Hi,

On Wed, 2025-01-08 at 02:24 -0600, Glenn Washburn wrote:
> I'm wanting to build a UML kernel on Debian bullseye, which is at
> kernel version 5.10, which does not support close_range(). It appears
> as though close_range() support is required on the host since commit
> 32e8eaf263d ("um: use execveat to create userspace MMs"). Was there a
> conscious decision to break support for kernels less than 5.11, when
> close_range() was added. What is the policy on support of the host
> kernel? Since 5.4 is still supported as a longterm release. I think it
> would be nice to at least support 5.4. Is there any interest in
> removing this restriction?
> 
> Also, this system is at glibc 2.31, which does not have execveat()
> support, which is required by that same commit above. Since execveat()
> has been supported since 3.19, this kernel should support it. Perhaps
> the issue can be resolved by defining a syscall wrapper in the UM
> headers if support is not found in glibc.

Yeah, we need the CLOSE_RANGE_CLOEXEC flag, which was added in 5.11.

On the one hand, there is no real alternative. This is a relatively hot
path (fork/exec), so I wouldn't want to replace the call with a loop.

On the other, this is "only" an extra safety measure. It is acceptable
for this to fail (the result is not even checked currently). As such,
the biggest issue seems to be that your libc does not yet have the
symbol.

Said differently, we could just replace the call with:

#ifndef CLOSE_RANGE_CLOEXEC
#define CLOSE_RANGE_CLOEXEC    (1U << 2)
#endif

  syscall(__NR_close_range, 0, ~0U, CLOSE_RANGE_CLOEXEC);


I am not sure whether we would want to do this in the upstream code.

Benjamin

Re: close_range is not available on older systems, preventing the building of a UML kernel

[Geert Uytterhoeven]

Hi Benjamin,

On Wed, Jan 8, 2025 at 11:58 AM Benjamin Berg <benjamin@sipsolutions.net> wrote:
> On Wed, 2025-01-08 at 02:24 -0600, Glenn Washburn wrote:
> > I'm wanting to build a UML kernel on Debian bullseye, which is at
> > kernel version 5.10, which does not support close_range(). It appears
> > as though close_range() support is required on the host since commit
> > 32e8eaf263d ("um: use execveat to create userspace MMs"). Was there a
> > conscious decision to break support for kernels less than 5.11, when
> > close_range() was added. What is the policy on support of the host
> > kernel? Since 5.4 is still supported as a longterm release. I think it
> > would be nice to at least support 5.4. Is there any interest in
> > removing this restriction?
> >
> > Also, this system is at glibc 2.31, which does not have execveat()
> > support, which is required by that same commit above. Since execveat()
> > has been supported since 3.19, this kernel should support it. Perhaps
> > the issue can be resolved by defining a syscall wrapper in the UM
> > headers if support is not found in glibc.
>
> Yeah, we need the CLOSE_RANGE_CLOEXEC flag, which was added in 5.11.
>
> On the one hand, there is no real alternative. This is a relatively hot
> path (fork/exec), so I wouldn't want to replace the call with a loop.
>
> On the other, this is "only" an extra safety measure. It is acceptable
> for this to fail (the result is not even checked currently). As such,
> the biggest issue seems to be that your libc does not yet have the
> symbol.
>
> Said differently, we could just replace the call with:
>
> #ifndef CLOSE_RANGE_CLOEXEC
> #define CLOSE_RANGE_CLOEXEC    (1U << 2)
> #endif

Would including include/uapi/linux/close_range.h help?

>   syscall(__NR_close_range, 0, ~0U, CLOSE_RANGE_CLOEXEC);
>
> I am not sure whether we would want to do this in the upstream code.

tools/testing/selftests/bpf/prog_tests/d_path.c does that, too.
But that's not real upstream kernel code...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: close_range is not available on older systems, preventing the building of a UML kernel

[Benjamin Berg]

Hi,

On Wed, 2025-01-08 at 12:13 +0100, Geert Uytterhoeven wrote:
> Hi Benjamin,
> 
> On Wed, Jan 8, 2025 at 11:58 AM Benjamin Berg <benjamin@sipsolutions.net> wrote:
> > On Wed, 2025-01-08 at 02:24 -0600, Glenn Washburn wrote:
> > > I'm wanting to build a UML kernel on Debian bullseye, which is at
> > > kernel version 5.10, which does not support close_range(). It appears
> > > as though close_range() support is required on the host since commit
> > > 32e8eaf263d ("um: use execveat to create userspace MMs"). Was there a
> > > conscious decision to break support for kernels less than 5.11, when
> > > close_range() was added. What is the policy on support of the host
> > > kernel? Since 5.4 is still supported as a longterm release. I think it
> > > would be nice to at least support 5.4. Is there any interest in
> > > removing this restriction?
> > > 
> > > Also, this system is at glibc 2.31, which does not have execveat()
> > > support, which is required by that same commit above. Since execveat()
> > > has been supported since 3.19, this kernel should support it. Perhaps
> > > the issue can be resolved by defining a syscall wrapper in the UM
> > > headers if support is not found in glibc.
> > 
> > Yeah, we need the CLOSE_RANGE_CLOEXEC flag, which was added in 5.11.
> > 
> > On the one hand, there is no real alternative. This is a relatively hot
> > path (fork/exec), so I wouldn't want to replace the call with a loop.
> > 
> > On the other, this is "only" an extra safety measure. It is acceptable
> > for this to fail (the result is not even checked currently). As such,
> > the biggest issue seems to be that your libc does not yet have the
> > symbol.
> > 
> > Said differently, we could just replace the call with:
> > 
> > #ifndef CLOSE_RANGE_CLOEXEC
> > #define CLOSE_RANGE_CLOEXEC    (1U << 2)
> > #endif
> 
> Would including include/uapi/linux/close_range.h help?

Well, I expect there is the chance that the system version of the
header is included indirectly and that would lead to redefines.

> >   syscall(__NR_close_range, 0, ~0U, CLOSE_RANGE_CLOEXEC);
> > 
> > I am not sure whether we would want to do this in the upstream code.
> 
> tools/testing/selftests/bpf/prog_tests/d_path.c does that, too.
> But that's not real upstream kernel code...

I'll submit a patch. I am a bit ambivalent about supporting kernels as
old as 5.4. But, it is simple here, so might as well do it.

Benjamin