From nobody Tue Dec 17 21:49:02 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 4YCVnZ4xmrz5hm9j for ; Tue, 17 Dec 2024 21:49:06 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YCVnZ4M71z4jx6; Tue, 17 Dec 2024 21:49:06 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qv1-xf2b.google.com with SMTP id 6a1803df08f44-6d918f066c1so30429606d6.2; Tue, 17 Dec 2024 13:49:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734472145; x=1735076945; darn=freebsd.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :from:to:cc:subject:date:message-id:reply-to; bh=fV1xHY8gWlkbTbf6GrieQ8VrZgpaHwk2C2r7ycE8Z+k=; b=Y2RhahsibNhaVWH356lpjv33LsewNGUkpvLtYu2/PDSq/0f2WzG8feIzM7NL7aOzGh uA8sucqhjwjVFzSu7DtzyAZlnRUs7OcZAy8yEGwMeIo3VeAY7cpWe2pawe1TghieLTht mT9K54gxNXCEe13DygnAKH7BPegIdXIvOQ1Vjx9GDpUE7+gVNdHbVQcG14RBJ28uP9Z6 x7N6POe33z5j2R6uChjM4Arr4K7AhaI2AKm48KE+GM2xDiCqqmHRnD1wxyzDw/hNw4Q+ 5Vdpn3Rfo0NCGk2OTy3+Q65zPJ9RsrcTm/TBq7teA2lb4t3d0uFCkfgwQQ04XXNnf92s 6gNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734472145; x=1735076945; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=fV1xHY8gWlkbTbf6GrieQ8VrZgpaHwk2C2r7ycE8Z+k=; b=oSMdCqpnxBSXulPczAaO3CkSpNN3ocz+EXwlsJ1SURIhdTgsk6um9gnL0oF+5yhlM2 w2rvSpNYj9A7PuuvitdhHsroZ99V8zcxswieNaAT/r5bR9UZREXRYVtEw6b6XJkBYj53 xAINX3V224PdaC4eFQVA1An0XHwqZKvlsw5Lp0a4DHGynD1TBiW3jJlvFPZUtvTZccMV c56EtV+QB1eMv/pyx+q2RJRAyxLnPZZM2/GO93TXJIQdsBuJVKTyvdjltUtEjqAfa6IA ng4a1I+YmXa94erUp8lwpTe47GBWc8e249ti/m3gEWF3X+/pSpAOhekBJNT9XfgHmwb2 eQuw== X-Gm-Message-State: AOJu0YyN4IFWJjvAcLjfD2lWwlMOPqEZbXzBME1gG0vydqUjz9JizdR7 ujBQ2XGBA5nS2pIPdQ1Ib5hti3d6tT0XOQZ9C2SfEE7F52FBZqvpKsf/NA== X-Gm-Gg: ASbGnctnjQP1g9RJveL6bC/yOqaUhAw+d+0KFij3iFiTenrOtNaIt5xoJxi6zBaEiGh z7zdlIUcdEgOY/g8Vdsxf28tFZ3sIsLYK8PemCzJo2DJq6ML/T5VBfnRU1uOU1/3P3u2W7698ug JyiE4+uIkOioHU8XmpZlJR60hEt5lb7QSrtUWTowJ2pgE1r4X+lbHtLSuO699nCYEONflyLjvwT fgQhAyO6N6ZjcMaXntQpNlVH8qu3YhVivPKCxafKenVnsBop34xOExbtuGcO7j8fJpGcMc= X-Google-Smtp-Source: AGHT+IHiERK9QBPM4QD8OiMYsMseCsECgQp3Pqi6S+zbeHGT4Utw2kdm0PD9Fn4p4ohy6rht/Y2+6Q== X-Received: by 2002:a05:6214:2a82:b0:6d8:ae2c:503a with SMTP id 6a1803df08f44-6dd092788d3mr9608086d6.48.1734472145090; Tue, 17 Dec 2024 13:49:05 -0800 (PST) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-467b2ca0731sm43862081cf.27.2024.12.17.13.49.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Dec 2024 13:49:04 -0800 (PST) Date: Tue, 17 Dec 2024 16:49:02 -0500 From: Mark Johnston To: Kristof Provost Cc: freebsd-jail@freebsd.org Subject: Re: setting VNET tunables in a new jail Message-ID: 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-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4YCVnZ4M71z4jx6 X-Spamd-Bar: ---- On Tue, Dec 17, 2024 at 10:41:15PM +0100, Kristof Provost wrote: > 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 there’s also net.inet.ip.fw.default_to_accept and net.pf.default_to_drop. I'm also adding some more tunables and would like to add test cases for non-default values of those tunables. It's straightforward enough for me to ensure that they're set properly in my test environment, but upstream CIs probably wouldn't go that far. And, if one wants to test both the default and non-default cases today, a reboot is needed. > > 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’m not aware of any where it’d be unsafe. Most of them are tuneables because they’d be annoying to make run-time configurable. (e.g. net.pf.states_hashsize would involve allocating a new hash table and re-hashing existing states into it. It’s possible, but to do it without freezing traffic for an extended period would be difficult.) I do see one wrinkle: when an interface is moved into a jail with net.fibs > 1 and assigned to a FIB that's invalid in the host, we need to somehow reset the interface FIB when the interface is moved back. I suspect it's fine to just reset the interface FIB to 0 when moving back, and we should probably be doing that anyway. Maybe we are already, but I don't see it. > Stuff like that will just work when set for a new vnet. I like this idea. > > Best regards, > Kristof