From owner-freebsd-arch@freebsd.org Mon Mar 29 14:55:33 2021 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C9B3A5799CC; Mon, 29 Mar 2021 14:55:33 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F8Fxd5SKjz3l8N; Mon, 29 Mar 2021 14:55:33 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.codepro.be", Issuer "R3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 948DE29D4B; Mon, 29 Mar 2021 14:55:33 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id C447D1243C; Mon, 29 Mar 2021 16:55:30 +0200 (CEST) From: "Kristof Provost" To: "Cy Schubert" Cc: "FreeBSD pf" , freebsd-arch@freebsd.org Subject: Re: [RFC] pf ioctl changes Date: Mon, 29 Mar 2021 16:55:29 +0200 X-Mailer: MailMate (1.13.2r5673) Message-ID: <18DC1EA9-ABFC-4A06-8710-A3068370EC52@FreeBSD.org> In-Reply-To: <202103291403.12TE3Y2H094131@slippy.cwsent.com> References: <24E09373-EBCD-4ED1-8B59-A44E687F287E@FreeBSD.org> <202103291403.12TE3Y2H094131@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2021 14:55:33 -0000 On 29 Mar 2021, at 16:03, Cy Schubert wrote: > In message <24E09373-EBCD-4ED1-8B59-A44E687F287E@FreeBSD.org>, > "Kristof > Provost > " writes: >> Hi, >> >> There are several patches in the pipeline that require changes in >> pf’s >> interface between kernel and userspace. >> In the past these have been handled in multiple ways. Either by >> simply >> making the change, breaking binary compatibility, or by introducing a >> v2 >> ioctl (e.g. DIOCADDALTQV1). >> >> While one is better than the other neither is wholly satisfying. New >> versions of calls constitute a maintenance burden after all. >> >> I’d like to change the ioctl interface to use nvlists, which >> would >> make such extensions much easier, because fields can be optional. >> That is, if userspace doesn’t supply the >> ‘shinynewfeature’ field >> the kernel can assume the default value and things just work. >> Similarly, >> if the kernel supplies a ’shinynewfeature’ which userspace >> doesn’t >> know about it’s simply ignored. >> >> The rough plan is to introduce nvlist versions of the get/add rules >> calls for now. Others will follow as the need presents itself. >> As these are new ioctls it is safe to MFC them to stable/12 and >> stable/13. >> The old interface will remain supported in those branches, but >> I’d >> like to remove it from main (and thus FreeBSD 14). >> >> As part of this effort I may end up splitting off the ioctl interface >> code from pfctl into libpfctl, which should make reuse of that code >> easier. >> >> I hope to post preliminary patches in the coming week. >> >> Thoughts? Objections? > > Kernel and userland should be, I'd say must be, kept in sync. We have > many > examples of userland and kernel not being in sync over the years. For > ipfilter, I've made incompatible changes to data structures requiring > userand and kernel be in sync. These are few and far between. > > I've gotten away with this because there is no third party software > that > relies on the ipfilter kernel interfaces. I could be wrong but I doubt > there may be third party software requiring pf ABI compatibility. But > if > there is then verstioned library interfaces are required. > > Given that the advice is to keep kernel and userland in sync there > probably > is no requirement for an UPDATING entry but that would be your call. > There are out-of-tree users of the pf ioctl interface. security/expiretable[1] for example. security/snort2pfcd appears to as well. sysutils/pfstat and sysutils/pftop use the ioctl interface as well, although not the three specific calls of immediate interest. I’m trying to work out how many examples there are, because one way or the other they’re going to have to cope with changes. So, I’d prefer to not just change the definitions of structs, even if we’ve done that in the past. struct pf_rule contains a few peculiarities from historical mistakes that I hope to correct now. Best regards, Kristof [1] Perhaps not the greatest example, because its use of struct pf_state was incorrect, so it couldn’t actually have worked correctly before it stopped building. See PR #253547 for details.