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