From nobody Tue Dec 13 19:43:22 2022 X-Original-To: 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 4NWpnm3j54z4kc0G for ; Tue, 13 Dec 2022 19:43:24 +0000 (UTC) (envelope-from jamie@freebsd.org) Received: from gritton.org (gritton.org [162.220.209.3]) (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 "gritton.org", Issuer "gritton.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NWpnm2jhQz3CT0; Tue, 13 Dec 2022 19:43:24 +0000 (UTC) (envelope-from jamie@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: from gritton.org ([127.0.0.3]) (authenticated bits=0) by gritton.org (8.16.1/8.16.1) with ESMTPA id 2BDJhM9R026133; Tue, 13 Dec 2022 11:43:22 -0800 (PST) (envelope-from jamie@freebsd.org) 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 Date: Tue, 13 Dec 2022 11:43:22 -0800 From: James Gritton To: jail@freebsd.org Cc: "glebius@FreeBSD.org" , Andrew Gallatin , "Bjoern A. Zeeb" Subject: Re: prison_flag() check in hot path of in_pcblookup() In-Reply-To: <89pn26q0-pps9-q8n7-1334-q15o5896p6p@serrofq.bet> References: <89pn26q0-pps9-q8n7-1334-q15o5896p6p@serrofq.bet> User-Agent: Roundcube Webmail/1.4.11 Message-ID: <2a96726f498df08c57bf54eff2afc960@freebsd.org> X-Sender: jamie@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4NWpnm2jhQz3CT0 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:30247, ipnet:162.220.208.0/22, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 2022-12-13 11:03, Bjoern A. Zeeb wrote: >>> In either case, a perfect 4-tuple match should be enough to uniquely >>> identify the connection. >>> >>> Even if this somehow is not the case and we have multiple connections >>> somehow sharing the same 4-tuple, how does checking the prison flag >>> help us? > > That logic predates me and came from [1]. The > jail_jailed_sockets_first > sysctl got removed in the review process with rwatson. I am still > trying > to see where the SO_REUSEPORT comment (back then) came from. I know I > only had the first lines initially, so must have been sometime during > review with rwatson as well. Sadly p4 emails where truncated to 1000 > lines so I cannot simply grep for the change (if it is in my mail > archives) or had a useful commit message (but at least would give a > date to check further private email). > > My current guess is that if we have the 4-tuple in both the base > and a jail (hence the SO_REUSEPORT comment) we want the jail not > getting > a socket of the base system returned as that would mean one could > "break > out of prison". But if the inp belongs to a jail we know we can simply > return. So if you find the one of the base system first you'll have to > go and look through the others. > > XXX-jamie: is that all still true in hierarchical jails? I believe so... Multiple jails in a hierarchy can share the same single IP address, but then you also could always have multiple non-hierarchical jails sharing the same single IP address. So in the single-address case, hierarchy doesn't matter. prison_ip_conflict_check() notably doesn't distinguish parent jails from the broader class of "other jails," which means that only the first-level jails in a hierarchy can have multiple IP addresses. So the multi-address case doesn't apply to hierarchical jails. - Jamie