From owner-freebsd-arch@freebsd.org Sat Jan 9 22:37:25 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 908644E50D0 for ; Sat, 9 Jan 2021 22:37:25 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DCvx064bqz4b8D; Sat, 9 Jan 2021 22:37:24 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from [192.168.1.2] (pool-74-110-137-7.rcmdva.fios.verizon.net [74.110.137.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: gallatin) by duke.cs.duke.edu (Postfix) with ESMTPSA id E92B927000BE; Sat, 9 Jan 2021 17:37:23 -0500 (EST) DMARC-Filter: OpenDMARC Filter v1.3.1 duke.cs.duke.edu E92B927000BE DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail0816; t=1610231844; bh=Vm3ajYWPDycBO0K0zKoi7pd5uQEgEgILkeZzFa3BpXQ=; h=Subject:To:From:Date:From; b=K0/qvazpW3QyBlHAeL2LcjvVtxngePuEkVmKIeh7HxnrmZrj8a1BTJNJvONhd94N+ K/XDR8FI8DBsQZ1l7DVJqlfgkOBu7BsmtZC4ZBvhUh57PmxK/5RYq1j1xRFaoxZsVR qeCT1kkyr+HAe62Vtqz6VZEZiOS6Dkgio6vror3/x7R/uqcBMtsnCaco0dv4RV33Si gJEuoAos5vrznES0yOzZrd4LVy1Fq6X8Mr4/CdpV0pHGNIGR+ansbCph3qZ2ajjJuu XzyA6g/fM857xHwQ1+ew9VYCA8avaCb8bhfRdPuSEJ1pVO9XcE09DZSOYX04A0+2hb W8sxQBH5xNwaA== Subject: Re: Should we enable KERN_TLS on amd64 for FreeBSD 13? To: John Baldwin , freebsd-arch@FreeBSD.org, Rick Macklem , Allan Jude References: <8eff83e5-49bc-d410-626e-603c03877b80@cs.duke.edu> <20210108214446.GJ31099@funkthat.com> <4fe4a57c-8c43-a677-4872-d0671104c414@FreeBSD.org> <20210109022409.GL31099@funkthat.com> From: Andrew Gallatin Message-ID: <993ebe97-d4b4-fe59-5b4f-9d607bb5e698@cs.duke.edu> Date: Sat, 9 Jan 2021 17:37:23 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20210109022409.GL31099@funkthat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DCvx064bqz4b8D X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.duke.edu header.s=mail0816 header.b=K0/qvazp; dmarc=pass (policy=none) header.from=cs.duke.edu; spf=pass (mx1.freebsd.org: domain of gallatin@cs.duke.edu designates 152.3.140.1 as permitted sender) smtp.mailfrom=gallatin@cs.duke.edu X-Spamd-Result: default: False [-4.10 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:152.3.140.0/23]; DKIM_TRACE(0.00)[cs.duke.edu:+]; DMARC_POLICY_ALLOW(-0.50)[cs.duke.edu,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RECEIVED_SPAMHAUS_PBL(0.00)[74.110.137.7:received]; SUBJECT_ENDS_QUESTION(1.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[152.3.140.1:from]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:13371, ipnet:152.3.128.0/17, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[cs.duke.edu:s=mail0816]; FREEFALL_USER(0.00)[gallatin]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; SPAMHAUS_ZRD(0.00)[152.3.140.1:from:127.0.2.255]; DWL_DNSWL_LOW(-1.00)[duke.edu:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[152.3.140.1:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arch] X-Mailman-Approved-At: Sun, 10 Jan 2021 09:01:02 +0000 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: Sat, 09 Jan 2021 22:37:25 -0000 On 1/8/21 9:24 PM, John-Mark Gurney wrote: > John Baldwin wrote this message on Fri, Jan 08, 2021 at 17:03 -0800: >> On 1/8/21 1:44 PM, John-Mark Gurney wrote: >>> Andrew Gallatin wrote this message on Fri, Jan 08, 2021 at 12:26 -0500: >>>> Kernel TLS (KTLS) support was added roughly a year ago, and provides >>>> an efficient software or hardware accelerated path to have the kernel >>>> (or the NIC) handle TLS crypto. This is quite useful for web and >>>> NFS servers, and provides a huge (2x -> 5x) efficiency gain by >>>> avoiding data copies into userspace for crypto, and potentially >>>> offloading the crypto to hardware. >>>> >>>> >>>> KTLS is well tested on amd64, having been used in production at Netflix >>>> for nearly 4 years. The vast majority of Netflix video has been served >>>> via KTLS for the last few years. Its what has allowed us to serve >>>> 100Gb/s on Xeon 2697A cpus for years, and what allows us to serve >>>> nearly 400Gb/s on AMD servers with NICs which support crypto offload. >>>> >>>> I have received a few requests to enable it by default in GENERIC, and >>>> I'd like to get some opinions. >>>> >>>> There are essentially 3 options >>>> >>>> 1) Fully enable KTLS by adding 'options KERN_TLS' to GENERIC, and >>>> flipping kern.ipc.tls.enable=1 >>>> >>>> The advantage of this is that it "just works" out of the box for users, >>>> and for reviewers. >>>> >>>> The drawback is that new code is thrust on unsuspecting users, >>>> potentially exposing them to bugs that we have not found in our >>>> somewhat limited web serving workload. >>> >>> This is my vote. >>> >>> I assume that the in tree and ports tree OpenSSL libraries will make >>> use of it when present? Does this mean fetch and the like will also >>> use it when talking w/ https website? (that's a nice benefit). >> >> In tree OpenSSL does not support KTLS. OpenSSL considers KTLS support >> too large of a feature to officially backport to the 1.1.1 branch, so >> if we add it in base, it will mean keeping it as a local diff. >> >> OTOH, I do maintain a backport of KTLS to 1.1.1 and there is a KTLS >> option for the security/openssl port (not on by default, it perhaps >> should be on 13?) which includes KTLS support. security/openssl-devel >> (which tracks OpenSSL 3) also has a KTLS option that probably should >> be enabled by default on 13 as it only consists of enabling the >> option without requiring patches to the port. >> >> I can raise the issue again with secteam about importing KTLS into the >> base OpenSSL. I think the main issue is the risk of getting a merge >> conflict when merging in an SA, though from my experience maintaining >> the KTLS patchset against 1.1.1 for the past year or so, I expect that >> risk to be fairly low. > > Considering that 1.1.1 support will end long before the support time of > 13-current ends, that's only two+ years of work to merge supported > patches, then we're on our own anyways.. We (Netflix) have maintained patches to base openssl for several years, and I can recall only one tricky merge. But I think this ship has sailed. I'm not about to ask to make somebody else's life more difficult. >> Personally, it would make my life a bit happier as a developer using >> KTLS for it to at least be in GENERIC by default, but that's a pretty >> narrow use case. :) > > I forget about the OpenSSL status in ports, do all ports that use > OpenSSL use ports OpenSSL? I guess not, because git-lite didn't > install OpenSSL, but supports https... > > If none(almost none) of the FreeBSD software (or ports) uses it by > default, then my vote changes to 3, which is to not enable it. If you > have to do all this work to get software to use KTLS, checking out the > ports tree and compiling custom ports, etc, then you're already far > enough along the path that recompiling the kernel isn't that big of a > stretch, and it saves the kernel code space, and the security risk > of another API... > > Compiling a kernel w/ it really isn't THAT hard... > > cat > sys/amd64/conf/KTLS < include GENERIC > > options KERN_TLS > EOF > make buildkernel KERNCONF=KTLS -j 4 > make installkernel KERNCONF=KTLS -j 4 > From owner-freebsd-arch@freebsd.org Sun Jan 10 14:40:47 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 D16184CE97F for ; Sun, 10 Jan 2021 14:40:47 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670088.outbound.protection.outlook.com [40.107.67.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DDKJZ5Jlxz4kGk; Sun, 10 Jan 2021 14:40:46 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IG/a+LShu8xVMA4no+TngsRxQ+exjJ3SgQEKUSUrvlenrijSM6zcl0qLOEko190lScuz77cDrGRF34L1C/vVQtSUu+1r9j16u4mRhOIaroZ9ggPWEDvA3slt92o4FGtzpBNHA26dHNnVCUqYp7TWaBWOYw+K//2lM1671L2OXm/8f0FAD641Z6pAuwY1+zZop2NPtKZwGP5yBhknXeHePRIPCJoCwvGYUW3UP8h+EOs73aV27uFfR3fI9+dOwlLoPq847DeSwwBhefDvo887V/YFB/XeNBHT7fNmFCIqeD6vhGZ4BaaOPV4HmuMyGlZh63v0XFeNsBahly5OQ/jxLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NxJRWlgF/wHhK7IDwGZLKZFfxMYpJd9fD7Nd9vSB4Ew=; b=BL79nFVsxITuvW9pmspJbgCHVXaOff02C4bqBdnnqyRB4jJXVtFi5QXw3hoX+xw0DeRPdyzH04GZv5SRV67S4vzdp9Ku1zsS55X5EURPt2DimLWBnTcahJL+pVYJaNlx6VFTKJ5o/Zv92M3ou1N99AdzCjXzU/DU3Rz8Rcjfh/R3zRJaP2zu4lkTjqTo7dgtr+dsp/uSNjrGfjMJMTRHlQlGZNt13SeK4jNK/uI3co5H+ErpvVKajJs6RiCP9iO6QUrk/Yd2qimD1tQL7xw99s59Z9yk7FOy3y9zvLrx/Q2X2OqOeiNFe8gjv7+cP5J8CaT16/bY9TDb3bSvBYrjPA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NxJRWlgF/wHhK7IDwGZLKZFfxMYpJd9fD7Nd9vSB4Ew=; b=f/J4AodY68RUJXYY0t9fKAODfnwcEKd4osjQiSZe74HKvgPqfSJqTumvg+Hik05y6x1TC7bl5mVs5RVtAPCsHSkNCnE+X8CgAAhKXEM48juzzoj/vOfop3aGMjzuUpINm93NwbjIYJWy1WDbQV/f2cFyVudTGzom3gOSlrj9VKpLzMtBOdGofEu+A359E8TBn5v9NAkdV/jjUQP7mnXc4yraebwMqYmZwIm5hAT+rlbVeZ3xNGAT+19UvH62qbCERU0SkVxnXhUqDtJXjHOWNaJPvHkfylBXmhC3xmckiae0s85lX+mgnOrN9S8OyNXn1T4yRKZucX9ouB82usQVtQ== Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQXPR01MB2711.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:45::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.11; Sun, 10 Jan 2021 14:40:44 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::3d86:c7f9:bc4c:40c0]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::3d86:c7f9:bc4c:40c0%6]) with mapi id 15.20.3742.012; Sun, 10 Jan 2021 14:40:44 +0000 From: Rick Macklem To: "freebsd-arch@FreeBSD.org" , John Baldwin , Allan Jude Subject: Re: Should we enable KERN_TLS on amd64 for FreeBSD 13? Thread-Topic: Should we enable KERN_TLS on amd64 for FreeBSD 13? Thread-Index: AQHW5eNvRyaqghxs0EmWNOwUeGmWsqoeQzCAgAA3aoCAANV/34AATsIAgAB/hOWAANKV2g== Date: Sun, 10 Jan 2021 14:40:44 +0000 Message-ID: References: <8eff83e5-49bc-d410-626e-603c03877b80@cs.duke.edu> <20210108214446.GJ31099@funkthat.com> <4fe4a57c-8c43-a677-4872-d0671104c414@FreeBSD.org> , <121d9135-e2a1-11ac-2538-f9fbb7505d89@quip.cz>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2755da84-93bc-4ee6-ac7a-08d8b575b64a x-ms-traffictypediagnostic: YQXPR01MB2711: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zqUkcCOnDXWpjGY8jQV0nK+OVH3hoIA2/NOL+hQ4kmBOt5y9grQ1RDKXoH8ePIMQxYacwI2n7+5fZeo3ZLSrxbvZnWBZbRwm/5DBFIFWe46F5X29xW8OPZ1s+10B1/MvG9AnQQMeN4+Wmlx/aGBvXUeJwNAqcz2neF2gFCNTpPRw+6bNJlxq1jJr9qG3fwBVovw8HOntLLVnEhWNLR+wI8xDEoCrdP0WXehPspyk8QohqoKx7oWBYgxagNq1+Mw2zqtBptwifE63P8xh+8b2v/7AZhh9Hos/CHLIDvjOTb+kFbidW4ZKQz0m0akwyr/bqjrJ4k+tJwk86n+nO9nZOxHU5hrVjlw+yoIuZBfARrPKan7PzxZe+YiqwSX3X4cgXE9v3mRGUSJehRvmZVNbTZL6wLRHz+D1qPtaemr2caZLwfreIwAuSR06zPpX8gGC1SV8w+8Wv1s9Zh19YkyZcA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(136003)(366004)(346002)(376002)(39850400004)(396003)(83380400001)(8936002)(786003)(316002)(55016002)(66476007)(66556008)(9686003)(52536014)(6506007)(66446008)(8676002)(478600001)(7696005)(966005)(66946007)(5660300002)(86362001)(71200400001)(450100002)(33656002)(2906002)(76116006)(91956017)(110136005)(2940100002)(186003)(64756008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: hpO3cRBGEH5rhHZjwTZg7kGAVPhMxML02SXrbfR1suElfG8j9+MUmXJ7zS6qwatv+m9hmwIEQHZz3a+2BNKDv7wkS96r1i7JoLS5W8BMgpAJ3QBvrwLqn7rzN0YhgSy/DL+oAR5tdhwynPKe/IkPBbkBWLBTmhP9+UPw8Pww+/q6fQiGpAXQDL/tjCDM1GCzRtnd/8CNRhVq7crJiljOpsr8K8kWnL9ftalrOda9Vyjv6vlSlLyl0nU0wN0ZDmR8ZinHK4x3WTlUqvaTLmyhFjGTVJLunGLknJbfCcUVnPfCIosJBK7bgXIet1wfABnSskyl1dD9DRKjJ1RpauNqX7Asa+JjxWlFRTfdO91xTRrxDelHhOS1UG/grHkForJx0dIP8kRRlGXpIZkx/pRTBFz6Dn0G6zaRjn18mdFH5ujom1dqvqSKmSvqTy5gcUbimat6vRRKwa1ERzaY9wOt8NTBNYMTimOr1tZJ6BaVIdgDHryKx7LQfvyvkBLj0C+cv2TYp8KOrcbTvK5aOdHa2DALpZ9vozYcdsJR8lGofmSaHLiAHyTjRWdM628Z0LhOYVJNOrlG4c23xQXlcuu9KDLtJxxhNfOqYhT/HkbzvnTcuCVNDNZBgcAslh9KPOfc+QY+mc6BQeJ4XcEI7rF07jqKT79te/ArBlI2OnWsBTw+9ImQlPyZZsTDkOSws6ZU7TEjqU3+7vLXwr0VoBx7AiZm1DuGfivgHebaWquY/XchCwcDPaPNJ0V7DPOmFNPOfB/GUwPkELVO5mayzvGZzRfGswad4lXDvtY/KkGy+fQ= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 2755da84-93bc-4ee6-ac7a-08d8b575b64a X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2021 14:40:44.6313 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: a4rhenOiQGPRK1P2KA9WYmRyYLdk/auZQTkZLyes0Olqy8d5rKtiEb/o+7E9aVtvTjFFpt5YtdBRe1oPHai3cA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB2711 X-Rspamd-Queue-Id: 4DDKJZ5Jlxz4kGk X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=f/J4AodY; arc=pass (microsoft.com:s=arcselector9901:i=1); dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.67.88 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-5.10 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[uoguelph.ca:+]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_LOW(-0.10)[40.107.67.88:from]; SUBJECT_ENDS_QUESTION(1.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[40.107.67.88:from]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[40.107.67.88:from:127.0.2.255]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; FROM_EQ_ENVFROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.67.88:from]; MAILMAN_DEST(0.00)[freebsd-arch] 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: Sun, 10 Jan 2021 14:40:47 -0000 Miroslav Lachman wrote:=0A= >Rick Macklem wrote:=0A= [stuff snipped]=0A= >>=0A= >> I don't know what the relationship between ports and packages is,=0A= >> but if there is soon a package for openssl-devel (with KTLS enabled=0A= >> like it is in ports), then no build from sources would be needed for=0A= >> openssl.=0A= >=0A= >If package is built with dependency on base OpenSSL then it will not use= =0A= >libraries installed by openssl-devel.=0A= >If packgage is built with dependency on ports OpenSSL (security/openssl)= =0A= >then it pulls openssl package and openssl-devel will be deinstalled as=0A= >it conflicts with other SSL implementations. They cannot coexist.=0A= Sorry, what I meant by relationship is if/when a port becomes a package.=0A= =0A= I am not at home, so I can't try:=0A= # pkg install openssl-devel=0A= to see if it works.=0A= =0A= My point was "if it works or will work soon, then having KERN_TLS in=0A= GENERIC would be nice, since then nothing needs to be built from source.=0A= =0A= rick=0A= =0A= =0A= > --> It is unfortunate that Openssl3 (openssl-devel) is still in alpha tes= t.=0A= >=0A= > If there is a package for an openssl with KTLS support, then having KERN_= TLS=0A= > in GENERIC might be nice, since no source builds would be needed.=0A= > (I have no preference w.r.t "enabled by default", since the=0A= > sysctl can easily be set via sysctl.conf.)=0A= >=0A= > Although nfs-over-tls is not yet implemented for non-FreeBSD=0A= > systems, I would like to see it become easy to enable during the=0A= > FreeBSD release cycle and having KERN_TLS in GENERIC would=0A= > be a step in that direction.=0A= >=0A= > Oh, and I'm not saying it is worth changing, but having Openssl=0A= > use KTLS and the kernel use KERN_TLS slightly obscures the fact=0A= > that they refer to related code.=0A= =0A= _______________________________________________=0A= freebsd-arch@freebsd.org mailing list=0A= https://lists.freebsd.org/mailman/listinfo/freebsd-arch=0A= To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"=0A= =0A= From owner-freebsd-arch@freebsd.org Sun Jan 10 16:43:36 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 8AB904D2403 for ; Sun, 10 Jan 2021 16:43:36 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from tor1-11.mx.scaleengine.net (tor1-11.mx.scaleengine.net [IPv6:2001:470:1:474::25]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DDN2J3Xtfz4sdq; Sun, 10 Jan 2021 16:43:36 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by tor1-11.mx.scaleengine.net (Postfix) with ESMTPSA id 8E332BDEA; Sun, 10 Jan 2021 16:43:35 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 tor1-11.mx.scaleengine.net 8E332BDEA Subject: Re: Should we enable KERN_TLS on amd64 for FreeBSD 13? To: Andrew Gallatin , freebsd-arch@FreeBSD.org Cc: John Baldwin , Rick Macklem References: <8eff83e5-49bc-d410-626e-603c03877b80@cs.duke.edu> From: Allan Jude Message-ID: Date: Sun, 10 Jan 2021 11:43:34 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <8eff83e5-49bc-d410-626e-603c03877b80@cs.duke.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4DDN2J3Xtfz4sdq X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] 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: Sun, 10 Jan 2021 16:43:36 -0000 On 2021-01-08 12:26, Andrew Gallatin wrote: > > Kernel TLS (KTLS) support was added roughly a year ago, and provides > an efficient software or hardware accelerated path to have the kernel > (or the NIC) handle TLS crypto.  This is quite useful for web and > NFS servers, and provides a huge (2x -> 5x) efficiency gain by > avoiding data copies into userspace for crypto, and potentially > offloading the crypto to hardware. > > > KTLS is well tested on amd64, having been used in production at Netflix > for nearly 4 years.   The vast majority of Netflix video has been served > via KTLS for the last few years.  Its what has allowed us to serve > 100Gb/s on Xeon 2697A cpus for years, and what allows us to serve > nearly 400Gb/s on AMD servers with NICs which support crypto offload. > > I have received a few requests to enable it by default in GENERIC, and > I'd like to get some opinions. > > There are essentially 3 options > > 1) Fully enable KTLS by adding 'options KERN_TLS' to GENERIC, and > flipping kern.ipc.tls.enable=1 > > The advantage of this is that it "just works" out of the box for users, > and for reviewers. > > The drawback is that new code is thrust on unsuspecting users, > potentially exposing them to bugs that we have not found in our > somewhat limited web serving workload. > I am in favour of just enabling it. As mentioned elsewhere in the thread, if it does cause a problem, we can switch the sysctl to default to off. I think we want to get this in ASAP, and then we can decide on the default value for the sysctl after we get broader user testing closer to 13.0-RELEASE > 2) Enable KTLS in GENERIC, but leave it turned off by default. > > This option allows users to enable ktls without a rebuild of GENERIC, > but does not enable it by default. So they can enable it if they > know about it, but are protected from bugs. > > The disadvantages of this are that it increases the kernel size > by ~20K, starts up one thread per core on every amd64 machine, > and it adds more required tuning to get good performance from FreeBSD. > > > 3) Continue along with KTLS disabled in GENERIC > > This is the lowest risk, but adds a higher bar for users wanting > to use ktls. > > > > Note that the discussion is focused on amd64 only, as KTLS will > only work on 64-bit platforms which use a direct map.  It has > not been tested at all on ppc64, and currently causes a > panic-at-boot on arm64 due to what are suspected to be problems > in the arm64 PCB setup. See: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247945 > > Drew > -- Allan Jude From owner-freebsd-arch@freebsd.org Mon Jan 11 05:42:04 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 A7FB84CD4D9 for ; Mon, 11 Jan 2021 05:42:04 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DDjJW3GQGz4kRd; Mon, 11 Jan 2021 05:42:02 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 10B5fxnv077870 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 10 Jan 2021 21:41:59 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 10B5fwDQ077869; Sun, 10 Jan 2021 21:41:58 -0800 (PST) (envelope-from jmg) Date: Sun, 10 Jan 2021 21:41:58 -0800 From: John-Mark Gurney To: Andrew Gallatin Cc: John Baldwin , freebsd-arch@FreeBSD.org, Rick Macklem , Allan Jude Subject: Re: Should we enable KERN_TLS on amd64 for FreeBSD 13? Message-ID: <20210111054158.GM31099@funkthat.com> Mail-Followup-To: Andrew Gallatin , John Baldwin , freebsd-arch@FreeBSD.org, Rick Macklem , Allan Jude References: <8eff83e5-49bc-d410-626e-603c03877b80@cs.duke.edu> <20210108214446.GJ31099@funkthat.com> <4fe4a57c-8c43-a677-4872-d0671104c414@FreeBSD.org> <20210109022409.GL31099@funkthat.com> <993ebe97-d4b4-fe59-5b4f-9d607bb5e698@cs.duke.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <993ebe97-d4b4-fe59-5b4f-9d607bb5e698@cs.duke.edu> X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Sun, 10 Jan 2021 21:41:59 -0800 (PST) X-Rspamd-Queue-Id: 4DDjJW3GQGz4kRd X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [0.14 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[jmg]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; RBL_DBL_DONT_QUERY_IPS(0.00)[208.87.223.18:from]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; SPAMHAUS_ZRD(0.00)[208.87.223.18:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_LONG(-0.11)[-0.115]; NEURAL_HAM_SHORT(-0.94)[-0.940]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; MAILMAN_DEST(0.00)[freebsd-arch] 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, 11 Jan 2021 05:42:04 -0000 Andrew Gallatin wrote this message on Sat, Jan 09, 2021 at 17:37 -0500: > On 1/8/21 9:24 PM, John-Mark Gurney wrote: > > John Baldwin wrote this message on Fri, Jan 08, 2021 at 17:03 -0800: > >> On 1/8/21 1:44 PM, John-Mark Gurney wrote: > >>> Andrew Gallatin wrote this message on Fri, Jan 08, 2021 at 12:26 -0500: > >>>> Kernel TLS (KTLS) support was added roughly a year ago, and provides > >>>> an efficient software or hardware accelerated path to have the kernel > >>>> (or the NIC) handle TLS crypto. This is quite useful for web and > >>>> NFS servers, and provides a huge (2x -> 5x) efficiency gain by > >>>> avoiding data copies into userspace for crypto, and potentially > >>>> offloading the crypto to hardware. > >>>> > >>>> > >>>> KTLS is well tested on amd64, having been used in production at Netflix > >>>> for nearly 4 years. The vast majority of Netflix video has been served > >>>> via KTLS for the last few years. Its what has allowed us to serve > >>>> 100Gb/s on Xeon 2697A cpus for years, and what allows us to serve > >>>> nearly 400Gb/s on AMD servers with NICs which support crypto offload. > >>>> > >>>> I have received a few requests to enable it by default in GENERIC, and > >>>> I'd like to get some opinions. > >>>> > >>>> There are essentially 3 options > >>>> > >>>> 1) Fully enable KTLS by adding 'options KERN_TLS' to GENERIC, and > >>>> flipping kern.ipc.tls.enable=1 > >>>> > >>>> The advantage of this is that it "just works" out of the box for users, > >>>> and for reviewers. > >>>> > >>>> The drawback is that new code is thrust on unsuspecting users, > >>>> potentially exposing them to bugs that we have not found in our > >>>> somewhat limited web serving workload. > >>> > >>> This is my vote. > >>> > >>> I assume that the in tree and ports tree OpenSSL libraries will make > >>> use of it when present? Does this mean fetch and the like will also > >>> use it when talking w/ https website? (that's a nice benefit). > >> > >> In tree OpenSSL does not support KTLS. OpenSSL considers KTLS support > >> too large of a feature to officially backport to the 1.1.1 branch, so > >> if we add it in base, it will mean keeping it as a local diff. > >> > >> OTOH, I do maintain a backport of KTLS to 1.1.1 and there is a KTLS > >> option for the security/openssl port (not on by default, it perhaps > >> should be on 13?) which includes KTLS support. security/openssl-devel > >> (which tracks OpenSSL 3) also has a KTLS option that probably should > >> be enabled by default on 13 as it only consists of enabling the > >> option without requiring patches to the port. > >> > >> I can raise the issue again with secteam about importing KTLS into the > >> base OpenSSL. I think the main issue is the risk of getting a merge > >> conflict when merging in an SA, though from my experience maintaining > >> the KTLS patchset against 1.1.1 for the past year or so, I expect that > >> risk to be fairly low. > > > > Considering that 1.1.1 support will end long before the support time of > > 13-current ends, that's only two+ years of work to merge supported > > patches, then we're on our own anyways.. > > > We (Netflix) have maintained patches to base openssl for several > years, and I can recall only one tricky merge. But I think this > ship has sailed. I'm not about to ask to make somebody else's > life more difficult. I mean, if you (Netflix) is already maintaing, and making the changes, then it isn't making anyone's life more difficult if any future changes that need to be done are contributed back to the project. Or are you more saying that Netflix does not want to commit to doing the necessary changes in a timely fashion when a SA comes out? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@freebsd.org Mon Jan 11 07:10:01 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 843B44CEB4F for ; Mon, 11 Jan 2021 07:10:01 +0000 (UTC) (envelope-from gonzo@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4DDlG133Tnz4nt8 for ; Mon, 11 Jan 2021 07:10:01 +0000 (UTC) (envelope-from gonzo@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 66F5B4CECEC; Mon, 11 Jan 2021 07:10:01 +0000 (UTC) Delivered-To: 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 66BD74CEB4D for ; Mon, 11 Jan 2021 07:10:01 +0000 (UTC) (envelope-from gonzo@freebsd.org) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DDlG10tWhz4p2M for ; Mon, 11 Jan 2021 07:10:00 +0000 (UTC) (envelope-from gonzo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bluezbox.com; s=mail; h=Content-Type:MIME-Version:Message-ID:Subject:To: From:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=hDpssxoPnPHkt8EK8ve9CjtYz4/5u0IywI72pCvx3Yg=; b=AMKrJsQ95ThWDHBPnUn/J8daL8 YqzmxbrvzI3/LUiOqAVinES7Qj1lk6J3IKP0B4lRG+nRqbS9JK0zD5q4GhF+L9xKHnbpF4BOYiass jEJ91ad8bJvTpqqKSHApbpbeg7/qmrPadhZXM2DpmXsGJiCzmGUThO3s5mYoyTn/LLf4=; Received: from localhost ([127.0.0.1] helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94 (FreeBSD)) (envelope-from ) id 1kyrKs-000HKQ-Gu for arch@freebsd.org; Sun, 10 Jan 2021 23:09:55 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id 10B79sxW066613 for arch@freebsd.org; Sun, 10 Jan 2021 23:09:54 -0800 (PST) (envelope-from gonzo@freebsd.org) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@freebsd.org using -f Date: Sun, 10 Jan 2021 23:09:54 -0800 From: Oleksandr Tymoshenko To: arch@freebsd.org Subject: RFC: SoC audio framework Message-ID: <20210111070954.GA66409@bluezbox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD/11.2-RELEASE-p10 (amd64) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Hi, For some time I've been working on an audio support for ARM-based SoCs. I submitted the framework part for review and also on included two drivers to illustrate the framework usage. It's pretty low-in [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Rspamd-Queue-Id: 4DDlG10tWhz4p2M X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:14061, ipnet:45.55.0.0/19, country:US] 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, 11 Jan 2021 07:10:01 -0000 Hi, For some time I've been working on an audio support for ARM-based SoCs. I submitted the framework part for review and also on included two drivers to illustrate the framework usage. It's pretty low-intrusive and self-contained so I don't expect to break things in a major way but would appreciate if somebody went through it with a fresh pair of eyes. Review URL: https://reviews.freebsd.org/D27830 Full branch with more drivers: https://github.com/gonzoua/freebsd-src/tree/projects/socaudio Thank you -- gonzo From owner-freebsd-arch@freebsd.org Tue Jan 12 06:51:34 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 7FE684CB559 for ; Tue, 12 Jan 2021 06:51:34 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DFLpF56YGz4VqL; Tue, 12 Jan 2021 06:51:33 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 10C6pVfi031887 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 11 Jan 2021 22:51:31 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 10C6pVcq031886; Mon, 11 Jan 2021 22:51:31 -0800 (PST) (envelope-from jmg) Date: Mon, 11 Jan 2021 22:51:31 -0800 From: John-Mark Gurney To: Ryan Moeller Cc: Kristof Provost , Li-Wen Hsu , Baptiste Daroussin , freebsd-arch@freebsd.org, freqlabs@freebsd.org Subject: Re: libifconfig non-private in 13? Message-ID: <20210112065131.GO31099@funkthat.com> Mail-Followup-To: Ryan Moeller , Kristof Provost , Li-Wen Hsu , Baptiste Daroussin , freebsd-arch@freebsd.org, freqlabs@freebsd.org References: <1EB6D7ED-F370-42EA-AC66-93D8BC96F29C@FreeBSD.org> <20201226211810.g4ll4ow23fitmxdo@ivaldir.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Mon, 11 Jan 2021 22:51:31 -0800 (PST) X-Rspamd-Queue-Id: 4DFLpF56YGz4VqL X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [-0.80 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[jmg]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; RBL_DBL_DONT_QUERY_IPS(0.00)[208.87.223.18:from]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[6]; SPAMHAUS_ZRD(0.00)[208.87.223.18:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; MAILMAN_DEST(0.00)[freebsd-arch] 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: Tue, 12 Jan 2021 06:51:34 -0000 Ryan Moeller wrote this message on Tue, Jan 05, 2021 at 13:56 -0500: > On Sun, Dec 27, 2020 at 9:15 AM Kristof Provost wrote: > > > > On 26 Dec 2020, at 22:33, Li-Wen Hsu wrote: > > > On Sun, Dec 27, 2020 at 5:18 AM Baptiste Daroussin > > > wrote: > > >> > > >> On Mon, Dec 21, 2020 at 09:02:00PM +0100, Kristof Provost wrote: > > >>> Hi, > > >>> > > >>> Libifconfig was marked as private (and experimental) back in 2016. > > >>> It???s since made some strides and has grown a few users. Ifconfig > > >>> now depends > > >>> on it as well. > > >>> > > >>> While it???s far from finished it???d be more useful for some users > > >>> if it were > > >>> public. That would at least imply some level of API/ABI stability, > > >>> which is > > >>> why I???m bringing it up here before pulling the trigger. > > >>> > > >>> Does anyone see any reasons to not do this? > > >>> > > I agree with the feeling that the current API may eventually need to be revised, > but as far as I'm aware nobody has plans or work in progress on that front. > I don't object to making the library public, and perhaps that will even help > gather interested parties to help continue fleshing out the missing pieces. > > > >> > > >> I would go the otherway around, any reason to make it public yet? if > > >> yes they go > > >> ahead, if no keep it private ;) > > > > > > I would say it is nice to have some scripting language bindings to it, > > > although I'm not sure if this is possible and a feasible usage. > > > > > I???m sure it???s possible. Ryan actually done some of that work: > > https://reviews.freebsd.org/D25447 > > > > Maybe we should merge that too. > > The API does make bindings a little funky, but it works. > > I recall speaking to at least one person who was interested in Python bindings > for libifconfig, as well. I currently would like to use libifconfig, but I'm worried that it's undocumented. There are no man pages to help guide a user. IMO, it shouldn't be made public till there is decent documentation for it. The lua bindings has docs, but I haven't looked at them in detailed to see if they could be adapted to the C api at all.. I'd be more than willing to [help] maintain a ctypes based ifconfig binding for Python. These are often pretty quick to get together.. > My only plans for the time being are to continue moving functionality > from ifconfig > into libifconfig little by little, but it's an "if and when I feel > like it" low priority kind of thing. > As I do this I will continue to keep the flua library updated as well. > > If memory serves, I have everything currently in libifconfig > implemented in the flua library > and roughly documented in the ifconfig(3lua) manual page, but that > isn't a whole lot. > A ton of useful/important ifconfig features are not yet implemented in > libifconfig. > Still, it's better than nothing even in the current state. Most of the > basic useful getters > are there, at least. Not much is there in the way of setters. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@freebsd.org Tue Jan 12 17:36:20 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 302A94E02DB for ; Tue, 12 Jan 2021 17:36:20 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DFd6B2s9kz3tD6; Tue, 12 Jan 2021 17:36:18 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x833.google.com with SMTP id a6so2092818qtw.6; Tue, 12 Jan 2021 09:36:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=h8DKh26AlGc/6TXVOYNvyugbi0mVoU/G/4DP/0oSo+Y=; b=KO2IlbrG+jG9fbXl5Chc9q+I+2LOQ0KC/UhrFj4S9Ie2aAiDT8orYU+vJGUbUDPbfJ mMKWd1oQSReNB6qcPCeh0n8nFba3YtdOOrLxKJ4dhziSL2tgCevpNcjwQ1ktWpKAIL5v R7z1OI5t/7sgLovTlRbyevszvAGQ5oog9JFb/XewlWrGHNWJYkOSGdY9LKEEBS1BBOEQ hy5oKQcXbJgHTALJB775N2ek4gaSCWlYCmpw2/HZV6vp89lXWErG+0xloCZZkqQxKLzM y/LfrOBj66iJ1SWGpBnyblElg411BfxFhIoajUzqA0KmElMH9PPI5pURzf+yNdLNMyOx KDUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=h8DKh26AlGc/6TXVOYNvyugbi0mVoU/G/4DP/0oSo+Y=; b=WNYRyiRM+lR/VX/TxwW4DA/Q5tXlpo8T3qyKr5OCVWyW2CJASOilFlMZcMnKUulclg rg5nKHEwKLmp4qFBwUS1Vo4hfZUVsHrXuKvSmyC8GNO57HuSnriiIC1j+yQ9GUNq+bNf F/aRuGNLg5+yC5vB2PQY7z37qXCUc2cftWoVNwHZbU7el35jf4zdqmGb60SIospI72XY kh9MHasrCKMKeyeTuaWPa/dXXKMUnRnlWueXVsh0cWCwEg1PrdFEW8TjfRj4AOHQhyfr biw2KXV8yscexg8GatwipiJmQZctJdItNCJs6OdyVkqWXUpItpK3UyaNwtSwyuSizPys Sj5A== X-Gm-Message-State: AOAM532SkmoUa5uGomGWt8RUfeDzb/Rno/7Pu2U0ATrKApH1mWbLaaoZ rJYiGAtDD5fjhdDDVbFN0/RWj1KfwNf+Yg== X-Google-Smtp-Source: ABdhPJyY0PQyZdGRLuCSgvW4V4V/9O77XLT63pn0apb1vx7k+8LsSlCto+VAFPcVJI081w40Qnp5nw== X-Received: by 2002:ac8:7b56:: with SMTP id m22mr51313qtu.380.1610472973805; Tue, 12 Jan 2021 09:36:13 -0800 (PST) Received: from raichu ([142.126.164.150]) by smtp.gmail.com with ESMTPSA id y26sm1510472qth.53.2021.01.12.09.36.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Jan 2021 09:36:13 -0800 (PST) Sender: Mark Johnston Date: Tue, 12 Jan 2021 12:36:10 -0500 From: Mark Johnston To: Kristof Provost Cc: freebsd-arch@freebsd.org Subject: Re: libifconfig non-private in 13? Message-ID: References: <1EB6D7ED-F370-42EA-AC66-93D8BC96F29C@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1EB6D7ED-F370-42EA-AC66-93D8BC96F29C@FreeBSD.org> X-Rspamd-Queue-Id: 4DFd6B2s9kz3tD6 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=KO2IlbrG; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::833 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-1.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::833:from]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::833:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::833:from]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arch] 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: Tue, 12 Jan 2021 17:36:20 -0000 On Mon, Dec 21, 2020 at 09:02:00PM +0100, Kristof Provost wrote: > Hi, > > Libifconfig was marked as private (and experimental) back in 2016. > It’s since made some strides and has grown a few users. Ifconfig now > depends on it as well. > > While it’s far from finished it’d be more useful for some users if > it were public. That would at least imply some level of API/ABI > stability, which is why I’m bringing it up here before pulling the > trigger. > > Does anyone see any reasons to not do this? I note that libifconfig doesn't version its symbols. In other words, compatibility-breaking changes generally require a shlib version bump, which will be painful for out-of-tree consumers (and if we don't expect to have such consumers there's no reason to make it a public library). Symbol versioning isn't perfect but makes some kinds of breaking changes easier to handle, and might be worthwhile here since I'd expect libifconfig to keep evolving for a while. Should we add a symbol map ahead of making libifconfig public? From owner-freebsd-arch@freebsd.org Tue Jan 12 18:48:50 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 9BAC54E2E80 for ; Tue, 12 Jan 2021 18:48:50 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DFfjt417jz4WBk; Tue, 12 Jan 2021 18:48:50 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from [10.187.247.77] (mobile-166-171-187-161.mycingular.net [166.171.187.161]) (authenticated bits=0) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTPSA id 10CImhmq063617 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 12 Jan 2021 13:48:43 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Tue, 12 Jan 2021 13:48:43 -0500 (EST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Daniel Eischen Mime-Version: 1.0 (1.0) Subject: Re: libifconfig non-private in 13? Date: Tue, 12 Jan 2021 13:48:42 -0500 Message-Id: <9CA63E1A-C206-4FF3-9B29-DB630D06D4A7@freebsd.org> References: Cc: Kristof Provost , freebsd-arch@freebsd.org In-Reply-To: To: Mark Johnston X-Mailer: iPhone Mail (18C66) X-Rspamd-Queue-Id: 4DFfjt417jz4WBk X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] 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: Tue, 12 Jan 2021 18:48:50 -0000 > On Jan 12, 2021, at 12:37 PM, Mark Johnston wrote: >=20 > =EF=BB=BFOn Mon, Dec 21, 2020 at 09:02:00PM +0100, Kristof Provost wrote: >> Hi, >>=20 >> Libifconfig was marked as private (and experimental) back in 2016. >> It=E2=80=99s since made some strides and has grown a few users. Ifconfig n= ow=20 >> depends on it as well. >>=20 >> While it=E2=80=99s far from finished it=E2=80=99d be more useful for some= users if=20 >> it were public. That would at least imply some level of API/ABI=20 >> stability, which is why I=E2=80=99m bringing it up here before pulling th= e=20 >> trigger. >>=20 >> Does anyone see any reasons to not do this? >=20 > I note that libifconfig doesn't version its symbols. In other words, > compatibility-breaking changes generally require a shlib version bump, > which will be painful for out-of-tree consumers (and if we don't expect > to have such consumers there's no reason to make it a public library). > Symbol versioning isn't perfect but makes some kinds of breaking changes > easier to handle, and might be worthwhile here since I'd expect > libifconfig to keep evolving for a while. Should we add a symbol map > ahead of making libifconfig public? Perhaps there are exceptions, but I would suggest that any new base library b= eing made public provide versioned symbols. -- DE= From owner-freebsd-arch@freebsd.org Tue Jan 12 18:50:47 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 A1C5B4E2B71 for ; Tue, 12 Jan 2021 18:50:47 +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 "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DFfm74JLsz4WQj; Tue, 12 Jan 2021 18:50:47 +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 6CD02FA1C; Tue, 12 Jan 2021 18:50:47 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id 2B248C7B3; Tue, 12 Jan 2021 19:50:46 +0100 (CET) From: "Kristof Provost" To: "Mark Johnston" Cc: freebsd-arch@freebsd.org Subject: Re: libifconfig non-private in 13? Date: Tue, 12 Jan 2021 19:50:45 +0100 X-Mailer: MailMate (1.13.2r5673) Message-ID: <51DB9AE6-66F8-43A8-8B47-07E3441CBC29@FreeBSD.org> In-Reply-To: References: <1EB6D7ED-F370-42EA-AC66-93D8BC96F29C@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown 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: Tue, 12 Jan 2021 18:50:47 -0000 On 12 Jan 2021, at 18:36, Mark Johnston wrote: > On Mon, Dec 21, 2020 at 09:02:00PM +0100, Kristof Provost wrote: >> Hi, >> >> Libifconfig was marked as private (and experimental) back in 2016. >> It’s since made some strides and has grown a few users. Ifconfig >> now >> depends on it as well. >> >> While it’s far from finished it’d be more useful for some users >> if >> it were public. That would at least imply some level of API/ABI >> stability, which is why I’m bringing it up here before pulling the >> trigger. >> >> Does anyone see any reasons to not do this? > > I note that libifconfig doesn't version its symbols. In other words, > compatibility-breaking changes generally require a shlib version bump, > which will be painful for out-of-tree consumers (and if we don't > expect > to have such consumers there's no reason to make it a public library). > Symbol versioning isn't perfect but makes some kinds of breaking > changes > easier to handle, and might be worthwhile here since I'd expect > libifconfig to keep evolving for a while. Should we add a symbol map > ahead of making libifconfig public? Yes, we should to that, as well as write up a man page for the current API. I did make a start on the man page a while back, but spare time has been hard to come by. Best regards, Kristof From owner-freebsd-arch@freebsd.org Tue Jan 12 19:18:44 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 4E3444E37AD for ; Tue, 12 Jan 2021 19:18:44 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DFgNN1b12z4Y8Y; Tue, 12 Jan 2021 19:18:44 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk1-x731.google.com with SMTP id 186so2938990qkj.3; Tue, 12 Jan 2021 11:18:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=tHFXbiHNk0mFX2+EYXEF2Cc3IHjfuOqQYS1pPK8Z1Zo=; b=S++TCFzA66AZfQPC+Nd9eptIXztJ+boGNmeUPXEw1UnqV3ElAXjLDOSK9tu7FafTNA f1vEURk00mLhlhvspM+xkzg627LylrhMp1B7SJwkEl4sWdaOv9n23xf06UWTL3LZWVIU 37ktsf5RkAf4/OJgNycZVnjkk2/W7RPMk5Vq4RZkIxHlaYnK/+sNM7T/4twEei1NAMZL EVKcKFWmLGJZ7WkPFoCmvQacmKenYw3W45KXJoJ0mNWqv1Tb131y/P8XdBOevUbX30zf sqc+gwlI7wkS9SXzUxg0oZu69Iw8xuCC2b5HMve7cxyPYke+JcAjYqxZSfixf86Qi3Uv lXMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=tHFXbiHNk0mFX2+EYXEF2Cc3IHjfuOqQYS1pPK8Z1Zo=; b=WHGlA38LFbGJUzaqTo3RPtwieChReLYFdlBHAa2WiljCNAoAYjWGmoeTm6a07IQnEG h9Isx5nTjHjrhIrFSp6YhX2xkpy7x/NTleD2Ex2cuI0WSNB6RJMQJxjbQg+Yn43+fp7u uXKTc9ZaGrI428p36v0VJ5sTupNp05t3VZyXs8Vw0WvM2pOScUA9OtVp/1vgKK0XXTjv e8ol5cVGwg7PB3prEIyZDvarXOZFHYaHcmsLq5YRYIj5o2iqnMlV/abAquIn3FIkGn+R oVP8om79AKek88pLlIQi1y4sRD98eB5F/7i00xVFGWIZxnR1ChcH10CtYdcard3ZgBnc JQlQ== X-Gm-Message-State: AOAM53040nEKDxvIOWwJcarb6BStiKLR8Wnjkz/67VsjDGkBNP1ky4St rAXK9ne0FZJVqry3hdELNV4+MDPZKRh4og== X-Google-Smtp-Source: ABdhPJyYhLfKTF2gCfjB1hBLj4pyfu49iCSr9xWCQMFnx8nPxqaHOMz5C/60slMC8gP+9gV2t4k4Qw== X-Received: by 2002:a05:620a:140c:: with SMTP id d12mr919880qkj.340.1610479122757; Tue, 12 Jan 2021 11:18:42 -0800 (PST) Received: from raichu ([142.126.164.150]) by smtp.gmail.com with ESMTPSA id q70sm1853782qka.107.2021.01.12.11.18.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Jan 2021 11:18:41 -0800 (PST) Sender: Mark Johnston Date: Tue, 12 Jan 2021 14:18:39 -0500 From: Mark Johnston To: Kristof Provost Cc: freebsd-arch@freebsd.org Subject: Re: libifconfig non-private in 13? Message-ID: References: <1EB6D7ED-F370-42EA-AC66-93D8BC96F29C@FreeBSD.org> <51DB9AE6-66F8-43A8-8B47-07E3441CBC29@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <51DB9AE6-66F8-43A8-8B47-07E3441CBC29@FreeBSD.org> X-Rspamd-Queue-Id: 4DFgNN1b12z4Y8Y X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] 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: Tue, 12 Jan 2021 19:18:44 -0000 On Tue, Jan 12, 2021 at 07:50:45PM +0100, Kristof Provost wrote: > On 12 Jan 2021, at 18:36, Mark Johnston wrote: > > On Mon, Dec 21, 2020 at 09:02:00PM +0100, Kristof Provost wrote: > >> Hi, > >> > >> Libifconfig was marked as private (and experimental) back in 2016. > >> It’s since made some strides and has grown a few users. Ifconfig > >> now > >> depends on it as well. > >> > >> While it’s far from finished it’d be more useful for some users > >> if > >> it were public. That would at least imply some level of API/ABI > >> stability, which is why I’m bringing it up here before pulling the > >> trigger. > >> > >> Does anyone see any reasons to not do this? > > > > I note that libifconfig doesn't version its symbols. In other words, > > compatibility-breaking changes generally require a shlib version bump, > > which will be painful for out-of-tree consumers (and if we don't > > expect > > to have such consumers there's no reason to make it a public library). > > Symbol versioning isn't perfect but makes some kinds of breaking > > changes > > easier to handle, and might be worthwhile here since I'd expect > > libifconfig to keep evolving for a while. Should we add a symbol map > > ahead of making libifconfig public? > > Yes, we should to that, as well as write up a man page for the current > API. > I did make a start on the man page a while back, but spare time has been > hard to come by. I posted a review to add a symbol map at least: https://reviews.freebsd.org/D28119 From owner-freebsd-arch@freebsd.org Fri Jan 15 04:52:57 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 2DEEF4D8865; Fri, 15 Jan 2021 04:52:57 +0000 (UTC) (envelope-from jamie@freebsd.org) Received: from gritton.org (gritton.org [199.192.165.131]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DH8205mk1z3vyP; Fri, 15 Jan 2021 04:52:56 +0000 (UTC) (envelope-from jamie@freebsd.org) Received: from gritton.org ([127.0.0.131]) (authenticated bits=0) by gritton.org (8.15.2/8.15.2) with ESMTPA id 10F4qskr047231; Thu, 14 Jan 2021 20:52:55 -0800 (PST) (envelope-from jamie@freebsd.org) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 14 Jan 2021 20:52:54 -0800 From: James Gritton To: freebsd-jail@freebsd.org, freebsd-arch@freebsd.org Subject: Stopping dead jails from rising again User-Agent: Roundcube Webmail/1.4.1 Message-ID: <12f6f121a4ac3a50be556a98d8c6595d@freebsd.org> X-Sender: jamie@freebsd.org X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (gritton.org [127.0.0.131]); Thu, 14 Jan 2021 20:52:55 -0800 (PST) X-Rspamd-Queue-Id: 4DH8205mk1z3vyP X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:30247, ipnet:199.192.164.0/22, country:US]; local_wl_from(0.00)[freebsd.org] 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: Fri, 15 Jan 2021 04:52:57 -0000 I've got some changes to the jail system, to undo a mistake I made years ago: allowing a dead jail to be brought back to life via jail_set(...JAIL_DYING). The main point of this is to re-create jails with hard-coded JIDs (which themselves were a mistake) without waiting for the old jails to let go of all their resources. Currently, adding such a jail brings the old one back (uf there is an old one), meaning that you're not sure if the "new" jail will start with default values, or with whatever its previous incarnation had. Among other things, there have been rumblings of associated security problems with that (though any specifics have been cleaned up). Since I still need to handle the hard-coded JIDs, the new strategy is to silently renumber the old dying jail, so the new jail can have the ID it expect while still being brand-new. This is imperfect, but I think it's a good deal better than the current alternative. If anyone cares to look into this this for some constructive criticism (or I suppose for any criticism): https://reviews.freebsd.org/D27876 https://reviews.freebsd.org/D28150 - Jamie