public inbox for passt-dev@passt.top
 help / color / mirror / code / Atom feed
From: Stefano Brivio <sbrivio@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: passt-dev@passt.top
Subject: Re: [PATCH 4/8] linux_dep: Fix CLOSE_RANGE_UNSHARE availability handling
Date: Wed, 6 Nov 2024 20:12:23 +0100	[thread overview]
Message-ID: <20241106201223.7e45f87d@elisabeth> (raw)
In-Reply-To: <20241106065421.2568179-5-david@gibson.dropbear.id.au>

On Wed,  6 Nov 2024 17:54:17 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:

> If CLOSE_RANGE_UNSHARE isn't defined, we define a fallback version of
> close_range() which is a (successful) no-op.  This is broken in several
> ways:
>  * It doesn't actually fix compile if using old kernel headers, because
>    the caller of close_range() still directly uses CLOSE_RANGE_UNSHARE
>    unprotected by ifdefs

For users using distribution packages, that is, pretty much everybody
not developing passt, this is generally not a concern, because build
environments typically ship kernel headers matching the C library and
the distribution version at hand.

>  * Even if it did fix the compile, it means inconsistent behaviour between
>    a compile time failure to find the value (we silently don't close files)
>    and a runtime failure (we die with an error from close_range())

Given that this is mostly relevant for stuff built against musl (and
running on a musl-based distribution), that's not really a problem in
practice. See 6e9ecf57410b ("util: Provide own version of close_range(),
and no-op fallback").

But sure, I'm fine with these changes in general, as they're strictly
speaking more correct than the current behaviour, minus the next point.

>  * Silently not closing the files we intend to close for security reasons
>    is probably not a good idea in any case

It's arguably even worse to force users to run containers or guests as
root. That's the reason for the no-op implementation.

I don't think that introducing a dependency on a >= 5.9 kernel is a
good idea.

If this bothers you or cppcheck, I'd rather call close_range()
(possibly the weakly aliased implementation), and log a warning on
ENOSYS instead of failing.

> As bonus this fixes a cppcheck error I see with some different options I'm
> looking to apply in future.
> 
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
>  linux_dep.h | 12 ++++--------
>  1 file changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/linux_dep.h b/linux_dep.h
> index 3a41e42..240f50a 100644
> --- a/linux_dep.h
> +++ b/linux_dep.h
> @@ -127,22 +127,18 @@ struct tcp_info_linux {
>  
>  #include <linux/close_range.h>
>  
> -#ifdef CLOSE_RANGE_UNSHARE	/* Linux kernel >= 5.9 */
>  /* glibc < 2.34 and musl as of 1.2.5 need these */
>  #ifndef SYS_close_range
>  #define SYS_close_range		436
>  #endif
> +#ifndef CLOSE_RANGE_UNSHARE	/* Linux kernel < 5.9 */
> +#define CLOSE_RANGE_UNSHARE	(1U << 1)
> +#endif
> +
>  __attribute__ ((weak))
>  /* cppcheck-suppress funcArgNamesDifferent */
>  int close_range(unsigned int first, unsigned int last, int flags) {
>  	return syscall(SYS_close_range, first, last, flags);
>  }
> -#else
> -/* No reasonable fallback option */
> -/* cppcheck-suppress funcArgNamesDifferent */
> -int close_range(unsigned int first, unsigned int last, int flags) {
> -	return 0;
> -}
> -#endif
>  
>  #endif /* LINUX_DEP_H */

-- 
Stefano


  reply	other threads:[~2024-11-06 19:12 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-06  6:54 [PATCH 0/8] Avoid running cppcheck on system headers David Gibson
2024-11-06  6:54 ` [PATCH 1/8] linux_dep: Generalise tcp_info.h to handling Linux extension compatibility David Gibson
2024-11-06  6:54 ` [PATCH 2/8] log: Only check for FALLOC_FL_COLLAPSE_RANGE availability at runtime David Gibson
2024-11-06 19:10   ` Stefano Brivio
2024-11-06 20:54     ` David Gibson
2024-11-06  6:54 ` [PATCH 3/8] linux_dep: Move close_range() conditional handling to linux_dep.h David Gibson
2024-11-06 19:10   ` Stefano Brivio
2024-11-06 20:56     ` David Gibson
2024-11-06  6:54 ` [PATCH 4/8] linux_dep: Fix CLOSE_RANGE_UNSHARE availability handling David Gibson
2024-11-06 19:12   ` Stefano Brivio [this message]
2024-11-06 21:01     ` David Gibson
2024-11-07  7:03       ` Stefano Brivio
2024-11-06  6:54 ` [PATCH 5/8] ndp: Use const pointer for ndp_ns packet David Gibson
2024-11-06  6:54 ` [PATCH 6/8] udp: Don't dereference uflow before NULL check in udp_reply_sock_handler() David Gibson
2024-11-06  6:54 ` [PATCH 7/8] util: Work around cppcheck bug 6936 David Gibson
2024-11-06  6:54 ` [PATCH 8/8] cppcheck: Don't check the system headers David Gibson
2024-11-07 14:55 ` [PATCH 0/8] Avoid running cppcheck on " Stefano Brivio
2024-11-07 23:58   ` David Gibson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20241106201223.7e45f87d@elisabeth \
    --to=sbrivio@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=passt-dev@passt.top \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://passt.top/passt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).