From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=glQ6bWdG; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTP id F2C915A004C for ; Wed, 06 Nov 2024 20:12:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1730920349; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XaL/P5RbLcHzqcc87tdtJn05S1fNfmJU9n/PoZzwDO4=; b=glQ6bWdGZGg+SoSwi1h5PnbZa9otlUpPTaiPzuCVgdY3pkEGS2KJp/Pjuj28+ggHjT81iJ dIfxGoLklv5qMWnBugxzwXALMJp1Or3I88OQoQ6vR6ZplCIpHe1ZjyGhB34MoV64QCSJAF RKNrOKlgEeFGOaO45U6IZ+c4BqO9G1g= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-632-VNEgSEDvMZSYb1hZ8vJDBw-1; Wed, 06 Nov 2024 14:12:28 -0500 X-MC-Unique: VNEgSEDvMZSYb1hZ8vJDBw-1 X-Mimecast-MFC-AGG-ID: VNEgSEDvMZSYb1hZ8vJDBw Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-4327bd6bd60so878395e9.1 for ; Wed, 06 Nov 2024 11:12:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730920346; x=1731525146; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=XaL/P5RbLcHzqcc87tdtJn05S1fNfmJU9n/PoZzwDO4=; b=tlL8cRKmFv1tjjWvcqIsPajn0p3i1DC7YQRxlbfRTkKwhpeaRBu2jdic9MwjG3cIhk 8zlA3YxR9fHP5VSEyauLq8AbPSz7CTg6H3YUXrCS9qWiYYKyZxOAOeav7yDTdVffbZbO TZPjw+jnIsdEEZHrBmdiKn1ipJP8WtieoEBSxgfJzeXpZiKhrHJBS2tmCRD4s9k94T07 En/ee6LgFMk8kN+yjmvvN9Pgl9uSJ/uP7TB4xCKWiVSlbMSY0QkGigPPOi0a9IphygnQ 1K/JMTY2Y4pw+3y6WtjLOZNem/IDQSnSlMZyBGof3T4/dxij0H/JxTw9TmXSlg5ERT8I +Zsg== X-Gm-Message-State: AOJu0Ywunx03JcxWBmr8FcDtAeL0IYSakZo7erPIOVrhbOLS1gT5quWA MqVCQIts31lVF8sRKGDcG5Iuo1c7sN0fCtpoE69QSgCIYHy+SbSscNs8y1ddUcmhFHZlY/TLfOq vI3dT6gCuKLsxfEpIRDwuPArq4+Eqntfm6tGQBW4K8jcVWrRCyTUz+yJG5Q== X-Received: by 2002:a05:6000:1f11:b0:37d:52d0:a59d with SMTP id ffacd0b85a97d-380610f2bd6mr27372071f8f.10.1730920346434; Wed, 06 Nov 2024 11:12:26 -0800 (PST) X-Google-Smtp-Source: AGHT+IFxZm/Pq6EJH7OPtGYedlwvJeUjS0PhQN9PeX/XIe/8QOi9Sve4FSRwpf4EmuB96jPRf767gw== X-Received: by 2002:a05:6000:1f11:b0:37d:52d0:a59d with SMTP id ffacd0b85a97d-380610f2bd6mr27372056f8f.10.1730920346036; Wed, 06 Nov 2024 11:12:26 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-432aa6eb194sm33074345e9.39.2024.11.06.11.12.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Nov 2024 11:12:25 -0800 (PST) Date: Wed, 6 Nov 2024 20:12:23 +0100 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 4/8] linux_dep: Fix CLOSE_RANGE_UNSHARE availability handling Message-ID: <20241106201223.7e45f87d@elisabeth> In-Reply-To: <20241106065421.2568179-5-david@gibson.dropbear.id.au> References: <20241106065421.2568179-1-david@gibson.dropbear.id.au> <20241106065421.2568179-5-david@gibson.dropbear.id.au> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: Aw-Za1qf-EirOZ2_yCV3KgNMiAOYNdxgnBPjNT3nDZQ_1730920347 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: CHUDVICG3OWBGTJHFJITG4NW4LMT54QQ X-Message-ID-Hash: CHUDVICG3OWBGTJHFJITG4NW4LMT54QQ X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Wed, 6 Nov 2024 17:54:17 +1100 David Gibson 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 > --- > 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 > > -#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