From nobody Tue Dec 17 21:41:15 2024 X-Original-To: freebsd-jail@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YCVcc2Vlbz5hlmN for ; Tue, 17 Dec 2024 21:41:20 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YCVcZ6Y0zz4jZC; Tue, 17 Dec 2024 21:41:18 +0000 (UTC) (envelope-from kp@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1734471678; 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=RmUOVuzJeGKpbWdOrrmiswNvXkQFwUCB5gEzsgbx6AA=; b=Vt/YjD3zeFUYbc2insTQr6+wZurVX+X8KRlotlQEs3N15fQBjb38sm93wVk92eVJh+PTXU EK21/IAeAhZXZIQY7XK5indJFKGfxG4LJqTiMC1WdRIOYmu+KgzvVvdDSkXal1/kj60vEb NIRNCqxepA7GbDGBQonSfd4EojzwPgFL11jqb3QccSl+O7B4vrT1p4Q6O8W/evVCtv7TkY TD8Ek/QnxKG1HjnowTY9zqKREZpI6+Ntdp4OtuHceA4csMU0R8mFD1oxNt97yedRarIwj9 W1FFFb5DnTfPD01jBFz2+0VE9lnfQy+Mkf2nD8V7d5c9RQgljjKvoSAz0Eykvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1734471678; 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=RmUOVuzJeGKpbWdOrrmiswNvXkQFwUCB5gEzsgbx6AA=; b=K+Hs/UyuS083E7Bx9yta2e2DWp1Bymfum6aNzXAHb5crrbp2eNc/aMQ0hzuon3XPGWQjPh 0UcDaEa+iAaNO5QgnykKMXM4CjJvt38QPhYfVjfckjkWUjlZakbVehXwLbPbSlRq0V5Yvp CsyqCisiKQgUe5/g9wmV7K8JsN6XLj/0Mto/w35vN9L93RKwDIbSqMf2K2yo5Wy4yvIDNm c9+xNscSHrixV99b5rono3wMkRwvGIwKmB/MfxjFD2Gm0389L7G4MGnjc6e+KtAovakjEa lvkE3AzVgrC0t5bx7FYxGfGawgJAV1+SP2FpxxgxFmtsfcVjhjQrtE8MnnQX8g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1734471678; a=rsa-sha256; cv=none; b=Q1pXmvV8bV6tthYwW1odl9aO/s/UuRpCZcSuvxvt/RO7sXyk+3xvc3teLZ4tM6JUxP/ZGR 5df6tmeZP6WoMXpMZ6/fUnvTOHZf8BnzmNFRcCLZ9mms6gWE1lRMUrIKSXqgII3/8LU9LE ZtJm3Qm70PfhXrprbW63vceazYB+hXOyuk0QTo+s7hAVj7ZpMwyl3EqkDurd1OT95AFnLi ywW1bod5nJKNz+ifNCqZqBJwwJ9bYCJSzqHorzWFelWH4+zrtO1NKtQCul/Qqz4d7KxMYM JeVqKAd+mw3lhCdxzrRWueG0z/+qgaXupUPnGuhwgBialYZRhkRe9ItY3ODQgA== Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx1.codepro.be", Issuer "R10" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 4YCVcZ5Q0hzcFH; Tue, 17 Dec 2024 21:41:18 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id 63AFF1FCAC; Tue, 17 Dec 2024 22:41:16 +0100 (CET) From: Kristof Provost To: Mark Johnston Cc: freebsd-jail@freebsd.org Subject: Re: setting VNET tunables in a new jail Date: Tue, 17 Dec 2024 22:41:15 +0100 X-Mailer: MailMate (1.14r5937) Message-ID: In-Reply-To: References: List-Id: Discussion about FreeBSD jail(8) List-Archive: https://lists.freebsd.org/archives/freebsd-jail List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-jail@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 17 Dec 2024, at 22:19, Mark Johnston wrote: > We have a number of sysctls which are defined as tunables, whose values= > cannot be changed after boot. Some of these sysctls, such as net.fibs,= > are per-VNET so could in principle be changed at jail creation time. > I'd find it useful to be able to pass a set of tunables to jail_set(2),= > so that corresponding VNET jail has tunables set to the specified > values. For instance, it'd be useful in test suites where I want to > exercise the network stack with different VNET sysctl settings, without= > having to configure the test runner at boot time. > There are a number of such cases. net.fibs is the obvious example, but th= ere=E2=80=99s also net.inet.ip.fw.default_to_accept and net.pf.default_to= _drop. > I think the implementation would involve passing an environment to > vnet_alloc(), which would copy the parent VNET context and then iterate= > over all VNET tunables in the system, invoking > sysctl_load_tunable_by_oid_locked() in such a way that the custom > environment is used to update the tunable's value. > > Is there already some way to do what I want? If not, is there some > reason we shouldn't implement this feature? Are there examples of VNET= > tunables for which it'd be unsafe to have values differing from the > parent VNET? One can print a list of such variables with "sysctl > -aVNT"; the list is pretty short and I don't see many obvious problems > with allowing them to be modified. I=E2=80=99m not aware of any where it=E2=80=99d be unsafe. Most of them a= re tuneables because they=E2=80=99d be annoying to make run-time configur= able. (e.g. net.pf.states_hashsize would involve allocating a new hash ta= ble and re-hashing existing states into it. It=E2=80=99s possible, but to= do it without freezing traffic for an extended period would be difficult= =2E) Stuff like that will just work when set for a new vnet. I like this idea.= Best regards, Kristof