From owner-freebsd-arch@freebsd.org Tue Jan 5 18:56:17 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 3CFAA4C5DBB for ; Tue, 5 Jan 2021 18:56:17 +0000 (UTC) (envelope-from ryan@ixsystems.com) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 4D9MCg49KMz4sSq for ; Tue, 5 Jan 2021 18:56:15 +0000 (UTC) (envelope-from ryan@ixsystems.com) Received: by mail-ot1-x32e.google.com with SMTP id 11so657841oty.9 for ; Tue, 05 Jan 2021 10:56:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ixsystems.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=nTRUfrxGASXFoxRiA6fVYvGzMQQX5qh4y3zaAPU/1to=; b=Jg3KFtVoTlPVzQ8NlwpTdaB6cnNfBn79Iw6/gSdQhdqVH6vzQzf3wAmICFj9XdFyNT vMCSDCqxIo01UAgSIXmB/uK1ExD/2KxJLt9THzLN5tHSTJ8CJoAViqZwPJc6SssVkDOw 4Wvvw73pxDNi10tA3Mk8GgcrjKfOl0eUZBfK3iJ4d/FGmhZXtgyrUR8R1tbv/Ix6WNEI Cf9V/kyTt2KnslyEdUgoljTUEJ3S81pOBB9cspha0rY4SAW+Zb2UoJkaqpODq9zDC5tM ouU5AmfTBO744MISjFNIs7cMpgtYp6EJ8IM1frwTDF27uN7WPoatNYCpkDmNcuWKgPnR ASVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=nTRUfrxGASXFoxRiA6fVYvGzMQQX5qh4y3zaAPU/1to=; b=iNHuXxKQBjEbt01WXrpjMzKLYnAT+h7l2gi2ff9N5HXPbPZIXoDtDtZWXnGM3G1zO7 tCSR3KVjVSP+CLnReT9UU6EtFR1LEqmEbhKroTTkY47bLk9nXgUouZKqE02I/Ynma3Df XXdtIeUhtkzewFBPAZWfr6oyHkTybyveEhqEXmtAhICCJerEhTS00OqP0k/A1D5Jcf/8 5urqytVkaESZuuNCkeRthwi0wq/hm/YUMNPhv4J3DYHYsuw8BbiGuhMg1u1mhLtC0Wte 7qt2qcI3kN50E9zcXpqdRP5wKO92D8GB795gGLDJXNw55Oq03lovju02cSMTopzEo7an CoVw== X-Gm-Message-State: AOAM532pkF2Q+zw2vTMmMVe9pO/tNAZdVDHAEVTKQf7tkaPCAcGH2jbM SZVvc52ac0yiCqqAygYFBZeUd7LbU9ewprJcKq6+KegKAm8= X-Google-Smtp-Source: ABdhPJx8H7qayUMEkC6cHhlWc3S3H/pFsCCbYsxixQPCJaWLwp8qxudEdaXLdwBhSmkSM2qC4rQT+CR2Kw5+z+1GeRo= X-Received: by 2002:a9d:23ca:: with SMTP id t68mr657236otb.281.1609872974418; Tue, 05 Jan 2021 10:56:14 -0800 (PST) MIME-Version: 1.0 References: <1EB6D7ED-F370-42EA-AC66-93D8BC96F29C@FreeBSD.org> <20201226211810.g4ll4ow23fitmxdo@ivaldir.net> In-Reply-To: From: Ryan Moeller Date: Tue, 5 Jan 2021 13:56:03 -0500 Message-ID: Subject: Re: libifconfig non-private in 13? To: Kristof Provost Cc: Li-Wen Hsu , Baptiste Daroussin , freebsd-arch@freebsd.org, freqlabs@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4D9MCg49KMz4sSq X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ixsystems.com header.s=google header.b=Jg3KFtVo; dmarc=pass (policy=none) header.from=ixsystems.com; spf=pass (mx1.freebsd.org: domain of ryan@ixsystems.com designates 2607:f8b0:4864:20::32e as permitted sender) smtp.mailfrom=ryan@ixsystems.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::32e:from]; R_DKIM_ALLOW(-0.20)[ixsystems.com:s=google]; FREEFALL_USER(0.00)[ryan]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; ARC_NA(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::32e:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[ixsystems.com:+]; DMARC_POLICY_ALLOW(-0.50)[ixsystems.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::32e:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; 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, 05 Jan 2021 18:56:17 -0000 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=E2=80=99s since made some strides and has grown a few users. Ifcon= fig > >>> now depends > >>> on it as well. > >>> > >>> While it=E2=80=99s far from finished it=E2=80=99d 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=E2=80=99m 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 rev= ised, 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 hel= p 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=E2=80=99m sure it=E2=80=99s possible. Ryan actually done some of that w= ork: > 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 bindi= ngs for libifconfig, as well. 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. --=20 Ryan Moeller iXsystems, Inc. OS Developer Email: ryan@iXsystems.com From owner-freebsd-arch@freebsd.org Wed Jan 6 10:26:48 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 9F1D24CB07C for ; Wed, 6 Jan 2021 10:26:48 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (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 4D9lsM4PFlz3JmN for ; Wed, 6 Jan 2021 10:26:46 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 8D4015C0150 for ; Wed, 6 Jan 2021 05:26:46 -0500 (EST) Received: from imap6 ([10.202.2.56]) by compute2.internal (MEProxy); Wed, 06 Jan 2021 05:26:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skunkwerks.at; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=KWqVh zsJ++5FBlaf805ZDs7nmbJhkb3nwW3I2Axzm7o=; b=VRMf/IiZYQfGmy9/OkhkW yiK8yZco5Y8AKAOY+a0l+qAZubHD1374DsFdPR37SR2q831fdtSi2zFiSd7WMN5f fh1L7/l+D1ULhCaeeSVZ4koEVKMScR6eb43CE9i5AOrWY0ZqDPEYm6t0Cz/GZrYU 8MjJc8L7/6xdp1gRMUVo/phMp/Q1S6d+AjTfbkx5+KjVFfLc2MnQFISpBA/efFIq WQYtOO8TeiCtSlKKpNfx95tFzPfmzFZfHexJq2a17iGjfNXL+/H1dRqZ4EzH8A1h oB+CnW+n3Z0bca74+ZbiDHmE58ZGVOfKUgak3qwqtJQVRyHlh7KNy0o0XyNHpRrP A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=KWqVhzsJ++5FBlaf805ZDs7nmbJhkb3nwW3I2Axzm 7o=; b=hFpj3U54k9f3flj1GEjit6dFfSl6IrMh/SKpsPKie/DuSkhEr41h4BNt1 Knguj+O9wmpzx8+hi7g/JdlKmfX1WedCd+A8S6mfvPfpa81yUvNAQ5QrtxGRHRea L+3T/GabO1pV0e+YQfL5LLgWyBbiL063fzVq71eVnf+u3ogB4LtcaomeqUAd7E2i ZN5B4Ept3mpwQzq95ccrDSKN7qSZiSzuvrJ87crS8htkghqH/Tp5DfrtpWGi/U2x d7tcuVQJPTXta5L69OYHyRfUkA6FrfRiTStMcu6rKwzQgRgJ0eJe0GXW9ms+VQ+o 8AJgoG6cjc+L7B4AJQYnQQkPdUlAA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdefledgudejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdffrghvvgcuvehothhtlhgvhhhusggvrhdfuceouggt hhesshhkuhhnkhifvghrkhhsrdgrtheqnecuggftrfgrthhtvghrnhepuedvgffhteejtd euhfevkeevfefgleevffdtffeiveektdfgieetjeffgfehfffhnecuffhomhgrihhnpehf rhgvvggsshgurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepuggthhesshhkuhhnkhifvghrkhhsrdgrth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 39BE21405BE; Wed, 6 Jan 2021 05:26:53 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396 Mime-Version: 1.0 Message-Id: <6073d0d6-8632-446f-8bbd-c8b7df4ce53d@www.fastmail.com> In-Reply-To: References: <1EB6D7ED-F370-42EA-AC66-93D8BC96F29C@FreeBSD.org> <20201226211810.g4ll4ow23fitmxdo@ivaldir.net> Date: Wed, 06 Jan 2021 10:26:25 +0000 From: "Dave Cottlehuber" To: freebsd-arch@freebsd.org Subject: Re: libifconfig non-private in 13? Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4D9lsM4PFlz3JmN X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=skunkwerks.at header.s=fm1 header.b=VRMf/IiZ; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=hFpj3U54; dmarc=none; spf=pass (mx1.freebsd.org: domain of dch@skunkwerks.at designates 66.111.4.27 as permitted sender) smtp.mailfrom=dch@skunkwerks.at X-Spamd-Result: default: False [-1.59 / 15.00]; XM_UA_NO_VERSION(0.01)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.27:from]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.27]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[skunkwerks.at:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.27:from]; SUBJECT_ENDS_QUESTION(1.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.111.4.27:from]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11403, ipnet:66.111.4.0/24, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[skunkwerks.at:s=fm1,messagingengine.com:s=fm1]; FREEFALL_USER(0.00)[dch]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[skunkwerks.at]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[66.111.4.27:from:127.0.2.255]; MID_RHS_WWW(0.50)[]; 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: Wed, 06 Jan 2021 10:26:48 -0000 On Tue, 5 Jan 2021, at 18:56, Ryan Moeller wrote: > > >> On Mon, Dec 21, 2020 at 09:02:00PM +0100, Kristof Provost wrote: > > >>> Hi, > > >>> > > >>> Libifconfig was marked as private (and experimental) back in 201= 6. > > >>> It=E2=80=99s since made some strides and has grown a few users. = Ifconfig > > >>> now depends > > >>> on it as well. ... > > I=E2=80=99m sure it=E2=80=99s possible. Ryan actually done some of t= hat work: > > https://reviews.freebsd.org/D25447 > > > > Maybe we should merge that too. yes & yes - both of these would be great additions & steps in the right = direction. A+ Dave From owner-freebsd-arch@freebsd.org Thu Jan 7 04:23:00 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 3C5D14C2535 for ; Thu, 7 Jan 2021 04:23:00 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail01.asahi-net.or.jp (mail01.asahi-net.or.jp [202.224.55.13]) by mx1.freebsd.org (Postfix) with ESMTP id 4DBCl61nfWz4Vyk for ; Thu, 7 Jan 2021 04:22:57 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from localhost (cpe-184-152-96-96.nj.res.rr.com [184.152.96.96]) (Authenticated sender: NR2Y-OOT) by mail01.asahi-net.or.jp (Postfix) with ESMTPSA id 1AEEE112F8E for ; Thu, 7 Jan 2021 13:22:53 +0900 (JST) Date: Wed, 6 Jan 2021 23:20:38 -0500 From: Yoshihiro Ota To: freebsd-arch@freebsd.org Subject: Re: RFC: removing ndis(4) Message-Id: <20210106232038.9fd928646cb34933578fd29c@j.email.ne.jp> In-Reply-To: <178622db-7dcd-fcae-743c-883711121733@kondratyev.su> References: <20201203001247.GF18452@spindle.one-eyed-alien.net> <178622db-7dcd-fcae-743c-883711121733@kondratyev.su> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; i386-portbld-freebsd12.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DBCl61nfWz4Vyk X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ota@j.email.ne.jp designates 202.224.55.13 as permitted sender) smtp.mailfrom=ota@j.email.ne.jp X-Spamd-Result: default: False [0.37 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:202.224.55.0/24]; TO_DN_NONE(0.00)[]; RCVD_NO_TLS_LAST(0.10)[]; RECEIVED_SPAMHAUS_PBL(0.00)[184.152.96.96:received]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[202.224.55.13:from]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:4685, ipnet:202.224.32.0/19, country:JP]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCVD_IN_DNSWL_LOW(-0.10)[202.224.55.13:from]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.17)[0.173]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[email.ne.jp]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[202.224.55.13:from:127.0.2.255]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_COUNT_TWO(0.00)[2]; 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: Thu, 07 Jan 2021 04:23:00 -0000 On Thu, 3 Dec 2020 06:28:00 +0300 Vladimir Kondratyev wrote: > On 03.12.2020 03:12, Brooks Davis wrote: > > I'd like to propose that we remove the ndis(4) driver prior to FreeBSD > > 13. It was a clever idea in the early 2000's when the market was > > flooded with 10/100 NICs with Windows-only drivers, but that hasn't been > > the case for ages and the driver has had no meaningful maintenance in > > ages[0]. I'd be a bit surprised if it worked at all today (it surely > > won't work with modern Windows drivers). > > > > To try to examine the popularity of ndis, I checked dmesgd.nycbug.org > > and there are 5 total entries with the most recent being 2007. > > > > The PC Card attachments are currently marked for deletion prior to > > FreeBSD 13. > > > > Unless there is surprising outcry I plan to add (and MFC) deprecation > > notices in about a week's time and remove the driver shortly thereafter. > > > > -- Brooks > > > > [0] I noticed today that part of the ndis 802.11 ioctl handler has been > > broken since 2005. > > ndis(4) was functional at least in 2015 and at that time it was the only > way to utilize BCM's wi-fi built in my "Asus EEEPC" ndis is still functional and indeed I have one of Asus that only works NDIS BCM. A problem is an old hardware needs existing code working although new hardware gets new hardware and driver. It was indeed broken long while ago but my fix was merged. If I remember correctly, my fix went to 11.0-RELEASE. It will be nice if we can wait after 13-release branching. Hiro From owner-freebsd-arch@freebsd.org Fri Jan 8 17:26: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 03F414D0041 for ; Fri, 8 Jan 2021 17:26:44 +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 4DC94w1M6Yz4ggH; Fri, 8 Jan 2021 17:26:39 +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 CB87227000B7; Fri, 8 Jan 2021 12:26:38 -0500 (EST) DMARC-Filter: OpenDMARC Filter v1.3.1 duke.cs.duke.edu CB87227000B7 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail0816; t=1610126799; bh=7CvA/t8L/5N6Cmk1gmapepnHMIHaSAUA9Vwp6wFQNwQ=; h=To:From:Subject:Date:From; b=sE7kLDfYJwtyjClQQsHWNesATI+saMr7O026/4Sd7D2JBiR1fI6a1rQ35bbYlppMX s65Em1sgkuGpaFXv2ZGtHlMhzLPVGUKUww6nJQufz+ArsZmfu4H9NpNLcHUwCq8W3S KnVe5i7Pm6rhtJg3OwZurNsFVUXHbPjPc627cuqzK3Ik8Fxo+JiB4vJ1UqZTRdvcIE DOEi/6bICpUoZCyRGvt/oVxkWXiTWb8ffS5uNktpGihQPOV0iPwkE1itx5Te0aRdfp lvSB8NPFkLKQ7qYC/n0L1Hd/LiYVk6p+qw4QVtGO+WJzoP9lySVPEIKRz4bRRoR7UU UWHyDIFDirZmw== To: freebsd-arch@FreeBSD.org From: Andrew Gallatin Subject: Should we enable KERN_TLS on amd64 for FreeBSD 13? Cc: Allan Jude , John Baldwin , Rick Macklem Message-ID: <8eff83e5-49bc-d410-626e-603c03877b80@cs.duke.edu> Date: Fri, 8 Jan 2021 12:26:38 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DC94w1M6Yz4ggH X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.duke.edu header.s=mail0816 header.b=sE7kLDfY; 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 [-2.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]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[152.3.140.1:from]; 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]; MIME_GOOD(-0.10)[text/plain]; SUBJECT_ENDS_QUESTION(1.00)[]; DWL_DNSWL_LOW(-1.00)[duke.edu:dkim]; RCVD_IN_DNSWL_LOW(-0.10)[152.3.140.1:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; SPAMHAUS_ZRD(0.00)[152.3.140.1:from:127.0.2.255]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arch] X-Mailman-Approved-At: Fri, 08 Jan 2021 20:10:32 +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: Fri, 08 Jan 2021 17:26:44 -0000 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. 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 From owner-freebsd-arch@freebsd.org Fri Jan 8 20:23:07 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 0410F4D5105 for ; Fri, 8 Jan 2021 20:23:07 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (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 "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DCF0V5lZQz3Chn; Fri, 8 Jan 2021 20:23:06 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 108KMuca022429 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 8 Jan 2021 12:22:56 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 108KMu3g022428; Fri, 8 Jan 2021 12:22:56 -0800 (PST) (envelope-from sgk) Date: Fri, 8 Jan 2021 12:22:56 -0800 From: Steve Kargl To: Andrew Gallatin Cc: freebsd-arch@freebsd.org, Rick Macklem , Allan Jude Subject: Re: Should we enable KERN_TLS on amd64 for FreeBSD 13? Message-ID: <20210108202256.GA7669@troutmask.apl.washington.edu> References: <8eff83e5-49bc-d410-626e-603c03877b80@cs.duke.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8eff83e5-49bc-d410-626e-603c03877b80@cs.duke.edu> X-Rspamd-Queue-Id: 4DCF0V5lZQz3Chn 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: Fri, 08 Jan 2021 20:23:07 -0000 On Fri, Jan 08, 2021 at 12:26:38PM -0500, 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. > > 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. > Drew, For those that use a custom kernel configuration, would we need to add 'options KERN_TLS' to our config files, or can a module be loaded from the boot loader (ie. via /boot/loader.conf)? I have no preference between 1 or 2, either seems acceptable to me for those running the bleeding edge. -- Steve From owner-freebsd-arch@freebsd.org Fri Jan 8 21:44:58 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 153834D843F for ; Fri, 8 Jan 2021 21:44:58 +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 4DCGpx4lcNz3L3P; Fri, 8 Jan 2021 21:44:57 +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 108Lilco065983 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 8 Jan 2021 13:44:47 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 108LilK8065982; Fri, 8 Jan 2021 13:44:47 -0800 (PST) (envelope-from jmg) Date: Fri, 8 Jan 2021 13:44:47 -0800 From: John-Mark Gurney To: Andrew Gallatin Cc: freebsd-arch@FreeBSD.org, Rick Macklem , Allan Jude Subject: Re: Should we enable KERN_TLS on amd64 for FreeBSD 13? Message-ID: <20210108214446.GJ31099@funkthat.com> Mail-Followup-To: Andrew Gallatin , freebsd-arch@FreeBSD.org, Rick Macklem , Allan Jude References: <8eff83e5-49bc-d410-626e-603c03877b80@cs.duke.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8eff83e5-49bc-d410-626e-603c03877b80@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]); Fri, 08 Jan 2021 13:44:47 -0800 (PST) X-Rspamd-Queue-Id: 4DCGpx4lcNz3L3P 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: Fri, 08 Jan 2021 21:44:58 -0000 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). IMO, this is the best option for at least 13-current (we can revisit this before 13.0-R happens), and preferably for 13.0-R. W/ both a kernel option and a sysctl to disable, we have a way to address issues, and getting code being used and tested is the best way to make it stable, and shaking out any remaining bugs. -- 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 Sat Jan 9 01:03:09 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 466B34DBD41 for ; Sat, 9 Jan 2021 01:03:09 +0000 (UTC) (envelope-from jhb@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 4DCMCd0qKdz3n5c; Sat, 9 Jan 2021 01:03:09 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro.local (unknown [IPv6:2601:648:8681:1cb0:f8a3:17ff:c878:e67f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 8968E5F74; Sat, 9 Jan 2021 01:03:08 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: Should we enable KERN_TLS on amd64 for FreeBSD 13? To: Andrew Gallatin , freebsd-arch@FreeBSD.org, Rick Macklem , Allan Jude References: <8eff83e5-49bc-d410-626e-603c03877b80@cs.duke.edu> <20210108214446.GJ31099@funkthat.com> From: John Baldwin Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <4fe4a57c-8c43-a677-4872-d0671104c414@FreeBSD.org> Date: Fri, 8 Jan 2021 17:03:07 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <20210108214446.GJ31099@funkthat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US 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: Sat, 09 Jan 2021 01:03:09 -0000 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. 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. :) -- John Baldwin From owner-freebsd-arch@freebsd.org Sat Jan 9 02:24:16 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 AACF84DF3C4 for ; Sat, 9 Jan 2021 02:24:16 +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 4DCP1D3N7Dz3tPy; Sat, 9 Jan 2021 02:24:15 +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 1092OAo1073711 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 8 Jan 2021 18:24:10 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 1092O9EA073710; Fri, 8 Jan 2021 18:24:09 -0800 (PST) (envelope-from jmg) Date: Fri, 8 Jan 2021 18:24:09 -0800 From: John-Mark Gurney To: John Baldwin Cc: Andrew Gallatin , freebsd-arch@FreeBSD.org, Rick Macklem , Allan Jude Subject: Re: Should we enable KERN_TLS on amd64 for FreeBSD 13? Message-ID: <20210109022409.GL31099@funkthat.com> Mail-Followup-To: John Baldwin , Andrew Gallatin , 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4fe4a57c-8c43-a677-4872-d0671104c414@FreeBSD.org> 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]); Fri, 08 Jan 2021 18:24:10 -0800 (PST) X-Rspamd-Queue-Id: 4DCP1D3N7Dz3tPy 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: Sat, 09 Jan 2021 02:24:16 -0000 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.. > 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 < 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 6D5714DB72C for ; Sat, 9 Jan 2021 00:46:14 +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 4DCLr62Nfyz3ldd; Sat, 9 Jan 2021 00:46:13 +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 E53862700131; Fri, 8 Jan 2021 19:46:10 -0500 (EST) DMARC-Filter: OpenDMARC Filter v1.3.1 duke.cs.duke.edu E53862700131 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail0816; t=1610153171; bh=7JZbwKHQ7v15omYe37aqXodqzux57v4mOrDyWY/Z/Fk=; h=Subject:To:From:Date:From; b=cZOaPCuk0lWFK9TZTgMInKiudYgXeQTiMwByYVHUbkkRkzDx9bfRVoGaBN32TNF0a roqpy4D0cdRFpe0TxtxPisOTBUZxmY7LAwIDnbefX7n1sGRYyF325+/hV1J1f5FPXL Adw20GQYIWLsRiD7Pmyr40nG8bGQRjviJ4fNchkB9uXZ0eQc2ubyf02xz5kxQKXlOO JlsAKu0rZEh6wCXgl7wGXTnp5RrQ5Fd3Xr3ShchF+X1qapMwszSZZPXo8J0DltnT4G S6h4+RIlqgV4+uBMOsvoV2z72GryYr5xdUdypWQN4IMfz8hr2u2jndogOGunIY07kn R6Dr1QEq8XXxA== Subject: Re: Should we enable KERN_TLS on amd64 for FreeBSD 13? To: Steve Kargl Cc: freebsd-arch@freebsd.org, Rick Macklem , Allan Jude References: <8eff83e5-49bc-d410-626e-603c03877b80@cs.duke.edu> <20210108202256.GA7669@troutmask.apl.washington.edu> From: Andrew Gallatin Message-ID: <10fb8ede-b8cf-645c-ceee-a9cb3f9fe39f@cs.duke.edu> Date: Fri, 8 Jan 2021 19:46:10 -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: <20210108202256.GA7669@troutmask.apl.washington.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DCLr62Nfyz3ldd X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Mailman-Approved-At: Sat, 09 Jan 2021 07:52:37 +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 00:46:14 -0000 On 1/8/21 3:22 PM, Steve Kargl wrote: > On Fri, Jan 08, 2021 at 12:26:38PM -0500, 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. >> >> 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. >> > > Drew, > > For those that use a custom kernel configuration, would we need > to add 'options KERN_TLS' to our config files, or can a module > be loaded from the boot loader (ie. via /boot/loader.conf)? > > I have no preference between 1 or 2, either seems acceptable to > me for those running the bleeding edge. > Its not as simple as just loading a module, you'd need to have options KERN_TLS in your kernel config. There are a few places in the kernel with ifdefs for KERN_TLS (sendfile, and sockets, for example). Thank you for the feedback! Drew From owner-freebsd-arch@freebsd.org Sat Jan 9 00:51:58 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 B7E834DB8AD for ; Sat, 9 Jan 2021 00:51:58 +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 4DCLyj57Sqz3m7G; Sat, 9 Jan 2021 00:51:57 +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 EA6412700131; Fri, 8 Jan 2021 19:51:55 -0500 (EST) DMARC-Filter: OpenDMARC Filter v1.3.1 duke.cs.duke.edu EA6412700131 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail0816; t=1610153517; bh=QaMBv4m1XlUBfbAaIm/mijIPJhQUYAhnpTLXWuJ7tNY=; h=Subject:To:From:Date:From; b=mQxLYUrIKXAwZ3BXGYL/GewJzgFQILOMtqZL3QwkSYDnMEKdtOuzxBwK6ys+iSjMC HXZU2ZrXtHtqKnEwy97U6ys1eBjj6LrIZsjMpr8n0ddmIGtc2aR7Eb7A9pJPtH0QBg gawlEA85CvY6buXwiXs4NYXMvjfEgp1xt5Gvp+Z864+lSfaheUA3RHUJXZzaVPmeQL 0M8JKD7YkUaFC87L524uUWlMnLHJ8hAbKf3NjbMKcMZyc1VwJWLiS1GljGvpYdfWhj fEpX/jKC4ula1c4SfPWFFDOaQvq7AgJR2cGyuHZyli5ZDauxvPWW1ysDE6KsUG1pSQ oSR55Z69+4eKw== Subject: Re: Should we enable KERN_TLS on amd64 for FreeBSD 13? To: freebsd-arch@FreeBSD.org, Rick Macklem , Allan Jude References: <8eff83e5-49bc-d410-626e-603c03877b80@cs.duke.edu> <20210108214446.GJ31099@funkthat.com> From: Andrew Gallatin Message-ID: Date: Fri, 8 Jan 2021 19:51:55 -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: <20210108214446.GJ31099@funkthat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DCLyj57Sqz3m7G X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.duke.edu header.s=mail0816 header.b=mQxLYUrI; 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)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_LOW(-1.00)[duke.edu:dkim]; SPAMHAUS_ZRD(0.00)[152.3.140.1:from:127.0.2.255]; 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: Sat, 09 Jan 2021 07:53:29 +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 00:51:58 -0000 On 1/8/21 4: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). It is enabled in the ports openssl. We (Netflix) have patches to the base openssl, but I believe that it was decided we don't want to diverge, so its not in base. > IMO, this is the best option for at least 13-current (we can revisit > this before 13.0-R happens), and preferably for 13.0-R. W/ both a > kernel option and a sysctl to disable, we have a way to address issues, > and getting code being used and tested is the best way to make it > stable, and shaking out any remaining bugs. > Awesome, thanks for the feedback! Drew From owner-freebsd-arch@freebsd.org Sat Jan 9 11:11:45 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 EA9BB4D1044 for ; Sat, 9 Jan 2021 11:11:45 +0000 (UTC) (envelope-from SRS0=8det=GM=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 4DCcjs0kn2z4qH5; Sat, 9 Jan 2021 11:11:44 +0000 (UTC) (envelope-from SRS0=8det=GM=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 49F0B28422; Sat, 9 Jan 2021 12:11:37 +0100 (CET) Received: from illbsd.quip.test (ip-94-113-69-69.net.upcbroadband.cz [94.113.69.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 7452628416; Sat, 9 Jan 2021 12:11:34 +0100 (CET) Subject: Re: Should we enable KERN_TLS on amd64 for FreeBSD 13? To: John Baldwin , Andrew Gallatin , 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: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: Date: Sat, 9 Jan 2021 12:11:33 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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: 4DCcjs0kn2z4qH5 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of SRS0=8det=GM=quip.cz=000.fbsd@elsa.codelab.cz has no SPF policy when checking 94.124.105.4) smtp.mailfrom=SRS0=8det=GM=quip.cz=000.fbsd@elsa.codelab.cz X-Spamd-Result: default: False [-0.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=8det=GM=quip.cz=000.fbsd@elsa.codelab.cz]; RECEIVED_SPAMHAUS_PBL(0.00)[94.113.69.69:received]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[94.124.105.4:from]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=8det=GM=quip.cz=000.fbsd@elsa.codelab.cz]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.997]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; AUTH_NA(1.00)[]; DMARC_NA(0.00)[quip.cz]; SPAMHAUS_ZRD(0.00)[94.124.105.4:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; 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: Sat, 09 Jan 2021 11:11:46 -0000 On 09/01/2021 03:24, John-Mark Gurney wrote: > John Baldwin wrote this message on Fri, Jan 08, 2021 at 17:03 -0800: [...] > 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.. > >> 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. AFAIK all ports uses base OpenSSL. I have a question for a long time - what is the benefit to have ports build with base OpenSSL instead of ports OpenSSL? For example for FreeBSD 11.4 it causes many ports unbuildable because base OpenSSL is 1.0 but many ports need 1.1.1. I was using PC-BSD on desktop where all ports were built with LibreSSL, then I switched ports in out poudriere builder for servers to use OpenSSL from ports because we needed newer version (newer features). Everything works fine on 25+ machines on FreeBSD 11.4 with OpenSSL 1.1.1 from ports. So why ports are not built with OpenSSL from ports by default? Can it cause some problems in some edge cases? Kind regards Miroslav Lachman From owner-freebsd-arch@freebsd.org Sat Jan 9 12:30:38 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 826714D31AB for ; Sat, 9 Jan 2021 12:30:38 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DCfSt17j9z4tvq; Sat, 9 Jan 2021 12:30:37 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 109CUWDu024556; Sat, 9 Jan 2021 04:30:32 -0800 (PST) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 109CUW1E024555; Sat, 9 Jan 2021 04:30:32 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202101091230.109CUW1E024555@gndrsh.dnsmgr.net> Subject: Re: Should we enable KERN_TLS on amd64 for FreeBSD 13? In-Reply-To: <8eff83e5-49bc-d410-626e-603c03877b80@cs.duke.edu> To: Andrew Gallatin Date: Sat, 9 Jan 2021 04:30:32 -0800 (PST) CC: freebsd-arch@freebsd.org, Rick Macklem , Allan Jude X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4DCfSt17j9z4tvq 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: Sat, 09 Jan 2021 12:30:38 -0000 > > 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. > > 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. 4) If possible could the few places that have #ifdef be dealt with using a switch table or IFUNCs so that the KTLS code could be enable at boot time via a loadable module? > > 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 > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arch@freebsd.org Sat Jan 9 14:08:29 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 3B2DD4D5B18 for ; Sat, 9 Jan 2021 14:08:29 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660058.outbound.protection.outlook.com [40.107.66.58]) (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 4DChdn00Cpz3GdC; Sat, 9 Jan 2021 14:08:28 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kNAlYmYnbQ6wPH1rZ5iqqW0erYiWX9xGzbeIxywuK7YZLi0IueMwqzEVdmWXiM/ldjd++7UWxO2d14cZNBBx62n9LEGy5ZXesmvCRApQ79t4zU+h6KtiOY5aGqp0iGfRAeAv5b2bxYAWWJLTUdF2bqayfnWchqPJUzM8RMVGeUtT6RD8jXPOxHASS6kmnKYEHMw/Lta+KnoPxyj4vk9aFywBXO8wv3HiTzjTyDkzz0GCqo2+JjFTLIO6NYRePxlYCBOtr75ZaJZlaYSayCZOqNF/1FRXRhomVKTiR6LceB6IhrS/vt8U5uxXp+L7llTIaOEDGHtTD/cOZMIkwT3fow== 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=cgxoTaG8nCpfS3PyU1uTqmVTStsQEfeuoORWb3V55Vk=; b=gN2VktZCMPOqywWKrqlcpTPosNaDqBBGOZI6Tz7jV69nsRHZkhSa22/wRWrEJ7QrQcdmP6WeoF3MgvSUsZl7DxUuftPa3JbII1AyFnflq3I3aAo8l8yCSCk+tCMfOVVj8yy/4neSJtMegwxt3KiQrhtUJYtjr2JYTUqHJd1i/ZSx2dpRYF+rRp23xo8YfTO6YdpEtWzKpnqbzYjhF4r62MGurRKA6NbAShOrrbQdfBqhaPVExMiI23Tl9RuddnZUuUnSs+auYdXLb4VHs1lTl7RuUfgb5mDjGz5C83jFbgvrkh/6sARzfYBy4r7UYoGtQYQ/JhZCxtPn6uyDPQOBww== 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=cgxoTaG8nCpfS3PyU1uTqmVTStsQEfeuoORWb3V55Vk=; b=lwAFMqgEK+moCrBjAQp9FmmlpGb6V/Fpn8MhDiwcuMIvXOs5RikMuraqps0f5zlBapQ0OccijzQL2UpmA1LDDV9niiEyPMNnm2JZLtaYnT94gBeKIf2mB+bWv4iV1//WZaTY6GWM7/P2UNWqId/YWu2rUtx9Gj4Mt7odLWr4VZQ4sGV+Klhh/EVzGpNJpxJKvq6v5HqPkQEIC+WnJllvY3RCwJPja32jAz6m+cRo7N6drdLhUrQZc4CGjeJKTpZoGjbL224WIrcbZU9dkHQtITufGVc0XFR5fgR+weRP+7tLSzBeUWgyMWGzVLR8c+0Uz9ShodOSK19QpqkNXIyBAQ== Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQXPR01MB2790.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:4e::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6; Sat, 9 Jan 2021 14:08:27 +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.006; Sat, 9 Jan 2021 14:08:27 +0000 From: Rick Macklem To: John Baldwin , Andrew Gallatin , "freebsd-arch@FreeBSD.org" , 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/3w== Date: Sat, 9 Jan 2021 14:08:27 +0000 Message-ID: References: <8eff83e5-49bc-d410-626e-603c03877b80@cs.duke.edu> <20210108214446.GJ31099@funkthat.com>, <4fe4a57c-8c43-a677-4872-d0671104c414@FreeBSD.org> In-Reply-To: <4fe4a57c-8c43-a677-4872-d0671104c414@FreeBSD.org> 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: 5bf7d76b-6bc7-4bdb-82df-08d8b4a80937 x-ms-traffictypediagnostic: YQXPR01MB2790: 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: VveDE/9eXmvi0OyMm2M2yg0j/zzmdDqUq7ZSX8GD1vb5e9vZB+ItrkSnTsuoHkgmubNB0zYluZ3RRrf0ZDPpj30Lk9vW9qXE0B9KJ4+mnQfbIFRH4vW/R3aVtjeIsQdf7Ugu6weFiTiXO6dXDVN3sQbq6EEMlPBShpOZ+WzlDXB92SX8Jx3HyfYqyIcKeGBjjbzuAcCoHvDbcUxAAJt9mSMUCKiDseYIDGNwiwDJSKHX6IMSmzq1PoNPvPYAE+x93DN5W8mRqbLHJ7e6f1Cj/YOiWBCgTzTqfjtvibbwReBlLZJU68Ejwbsz49e2TaPnwNjh4p+SnzL6kUBGu6Kb3J1Z3L11P8p+x+J90Gb1QjfPxJbE+gptlI6dmd7k6NaZdvvPwrDFqDC56F6AELZOsg== 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:(39860400002)(366004)(376002)(346002)(396003)(136003)(8936002)(786003)(5660300002)(186003)(316002)(33656002)(110136005)(86362001)(7696005)(6506007)(52536014)(83380400001)(76116006)(2906002)(66446008)(91956017)(478600001)(66476007)(66946007)(64756008)(55016002)(8676002)(71200400001)(66556008)(9686003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?87Kac5u26VfqtifvQp+vxc8F+jP5a4Pj9u9Vr4IepV8T5wke+ViDSoPVz8?= =?iso-8859-1?Q?HE7zTzZ2bDjX+3T9h60qr/L3JKujxyycRJYnNx2bSz8TUlWsq09b33sfDJ?= =?iso-8859-1?Q?CE93fO+RbqoYAOAKXaVCtqGB6igR4icgBbvNzgQfS7XRzxMWYwolB+qLnU?= =?iso-8859-1?Q?3x7+gtkVBYOm1zugdeI2DQRZO6rLCkKdykuxm7LKT2SQ+KaDRACBvCxkKp?= =?iso-8859-1?Q?QiKiIyrQW/3YZz77BT/0k6IzG44cQtnsLr7kMY4RckQ0/yVH5LbrJkx9pq?= =?iso-8859-1?Q?JaAvuNJFwjTx3bda/LLPDg8jTR2nEpjPXaq8RuEUyrQZN6j2pAAZkLIOaC?= =?iso-8859-1?Q?j467Fb8M9mpIkzMzdkme3D43yiXMPU8YpGdity6HxKcq3pWi9hGxO4SfPa?= =?iso-8859-1?Q?y0e50PuJPR8NzvdZv+wunkxu16NdlrUNHWHw2fKVGjYAmNgh4z/PgiEsn3?= =?iso-8859-1?Q?iTiB8ZmfL+OAJi13AS1a/fjyz8no0MuAPVv910HOxLRd+DUfb85F26l0h+?= =?iso-8859-1?Q?q9ip11c1/cDCT1hsamhdLMsrAjNcuu0rLIHTwERUgt5aTfO9s52KWRRtxT?= =?iso-8859-1?Q?u6hdlKsCbLgnyUyPCJ/saBL+MFgTY8GYvDNPvUxvY287sVr+sKi5930nfr?= =?iso-8859-1?Q?+dGo+g2DrPI+Dn6fK2UdbyeOcJLDODapbMKrjzMECdPWld1n+Gks6IzhLD?= =?iso-8859-1?Q?n9laVN4WCFplAaDdzt1Y+H2lnUQZdpSQNtem3EJvXgbCSDNvOk/JtDkEj/?= =?iso-8859-1?Q?ytIj8VzI6QqIJEdAYcwYlD49ZZdQo9pyq6ukees/Xkmi7MZ1yEKyum8G71?= =?iso-8859-1?Q?dlHc0oiGlHUr6rD77oQcGRw9czONrX3OSDa3AYBbnuxJpo6a+NqYq2BEAF?= =?iso-8859-1?Q?LzGZ3drRdgVHfpv2P+qQChRlPhW9IwObF3tYQVXHDUuiTohRG6v2Nbi34Y?= =?iso-8859-1?Q?7h/ysR0o1QP7dSYw228W+uzGFWh2I8Nwhyp7PJBAGlU2r514+0E3xcCQx7?= =?iso-8859-1?Q?d9LmVBaWYiXVW6qMqK6UahZKm0N+/0qeWrwrUua4Ekorrt6pB0Y17kdzVr?= =?iso-8859-1?Q?+cyQfN0wjcjJzGeEueBxxTc=3D?= 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: 5bf7d76b-6bc7-4bdb-82df-08d8b4a80937 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2021 14:08:27.4094 (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: 914tlW3iLRDBtyrWfI/6khce3Jq5kP7VfQ7BlSuVmRHX/lWX/6q+nLL7ZDjtVheMFtFhNQ1GaUjmfhZuQjgCoQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB2790 X-Rspamd-Queue-Id: 4DChdn00Cpz3GdC 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: Sat, 09 Jan 2021 14:08:29 -0000 John Baldwin wrote:=0A= >John-Mark Gurney wrote:=0A= >> Andrew Gallatin wrote:=0A= >>>=0A= >>> There are essentially 3 options=0A= >>>=0A= >>> 1) Fully enable KTLS by adding 'options KERN_TLS' to GENERIC, and=0A= >>> flipping kern.ipc.tls.enable=3D1=0A= >>>=0A= >>> The advantage of this is that it "just works" out of the box for users,= =0A= >>> and for reviewers.=0A= >>>=0A= >>> The drawback is that new code is thrust on unsuspecting users,=0A= >>> potentially exposing them to bugs that we have not found in our=0A= >>> somewhat limited web serving workload.=0A= >>=0A= >> This is my vote.=0A= >>=0A= >> I assume that the in tree and ports tree OpenSSL libraries will make=0A= >> use of it when present? Does this mean fetch and the like will also=0A= >> use it when talking w/ https website? (that's a nice benefit).=0A= >=0A= >In tree OpenSSL does not support KTLS. OpenSSL considers KTLS support=0A= >too large of a feature to officially backport to the 1.1.1 branch, so=0A= >if we add it in base, it will mean keeping it as a local diff.=0A= >=0A= >OTOH, I do maintain a backport of KTLS to 1.1.1 and there is a KTLS=0A= >option for the security/openssl port (not on by default, it perhaps=0A= >should be on 13?) which includes KTLS support. security/openssl-devel=0A= >(which tracks OpenSSL 3) also has a KTLS option that probably should=0A= >be enabled by default on 13 as it only consists of enabling the=0A= >option without requiring patches to the port.=0A= As of r557013, the KTLS option is enabled by default in openssl-devel.=0A= =0A= >I can raise the issue again with secteam about importing KTLS into the=0A= >base OpenSSL. I think the main issue is the risk of getting a merge=0A= >conflict when merging in an SA, though from my experience maintaining=0A= >the KTLS patchset against 1.1.1 for the past year or so, I expect that=0A= >risk to be fairly low.=0A= >=0A= >Personally, it would make my life a bit happier as a developer using=0A= >KTLS for it to at least be in GENERIC by default, but that's a pretty=0A= >narrow use case. :)=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= --> It is unfortunate that Openssl3 (openssl-devel) is still in alpha test.= =0A= =0A= If there is a package for an openssl with KTLS support, then having KERN_TL= S=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= rick=0A= =0A= --=0A= John Baldwin=0A= From owner-freebsd-arch@freebsd.org Sat Jan 9 18:29:12 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 200084DF134 for ; Sat, 9 Jan 2021 18:29:12 +0000 (UTC) (envelope-from SRS0=8det=GM=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 4DCpQb644Tz3qf8; Sat, 9 Jan 2021 18:29:11 +0000 (UTC) (envelope-from SRS0=8det=GM=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 1D5CC28416; Sat, 9 Jan 2021 19:29:10 +0100 (CET) Received: from illbsd.quip.test (ip-94-113-69-69.net.upcbroadband.cz [94.113.69.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 9BD8D28411; Sat, 9 Jan 2021 19:29:08 +0100 (CET) Subject: Re: Should we enable KERN_TLS on amd64 for FreeBSD 13? To: Rick Macklem , Andrew Gallatin , "freebsd-arch@FreeBSD.org" , Allan Jude References: <8eff83e5-49bc-d410-626e-603c03877b80@cs.duke.edu> <20210108214446.GJ31099@funkthat.com> <4fe4a57c-8c43-a677-4872-d0671104c414@FreeBSD.org> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <121d9135-e2a1-11ac-2538-f9fbb7505d89@quip.cz> Date: Sat, 9 Jan 2021 19:29:08 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DCpQb644Tz3qf8 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: Sat, 09 Jan 2021 18:29:12 -0000 On 09/01/2021 15:08, Rick Macklem wrote: > John Baldwin wrote: >> John-Mark Gurney wrote: >>> Andrew Gallatin wrote: >>>> >>>> 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. > As of r557013, the KTLS option is enabled by default in openssl-devel. > >> 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. >> >> 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 don't know what the relationship between ports and packages is, > but if there is soon a package for openssl-devel (with KTLS enabled > like it is in ports), then no build from sources would be needed for > openssl. If package is built with dependency on base OpenSSL then it will not use libraries installed by openssl-devel. If packgage is built with dependency on ports OpenSSL (security/openssl) then it pulls openssl package and openssl-devel will be deinstalled as it conflicts with other SSL implementations. They cannot coexist. > --> It is unfortunate that Openssl3 (openssl-devel) is still in alpha test. > > If there is a package for an openssl with KTLS support, then having KERN_TLS > in GENERIC might be nice, since no source builds would be needed. > (I have no preference w.r.t "enabled by default", since the > sysctl can easily be set via sysctl.conf.) > > Although nfs-over-tls is not yet implemented for non-FreeBSD > systems, I would like to see it become easy to enable during the > FreeBSD release cycle and having KERN_TLS in GENERIC would > be a step in that direction. > > Oh, and I'm not saying it is worth changing, but having Openssl > use KTLS and the kernel use KERN_TLS slightly obscures the fact > that they refer to related code.