From nobody Mon Aug 2 08:38:06 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 98EF912B98D2 for ; Mon, 2 Aug 2021 08:38:17 +0000 (UTC) (envelope-from alfadev@protonmail.com) Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) (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 "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GdWc80ccpz3JPd for ; Mon, 2 Aug 2021 08:38:16 +0000 (UTC) (envelope-from alfadev@protonmail.com) Date: Mon, 02 Aug 2021 08:38:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1627893487; bh=L5SleSfgyfmSt4sb9l2xxwLG+8/wwgISEHqHdtltQbw=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=d7cGl2MNOdhx24ZsV6tISiprQy3gi7UztIiSyylt7P1Ij2XUGJ9lrPcGusrtq91wy Wi/1HF2HxsLuqARaGytUyB71c3PyejRZXQ0JXn2AR4iaQdS2KRcYcn9mm3ZOp5cYIi lGpfV24+em3AB5vS7P9jOTyW4zfYVAXKm4ZLZBr0= To: Martin Beran Cc: "freebsd-ipfw@FreeBSD.org" , "freebsd-hackers@FreeBSD.org" Reply-To: alfadev Subject: Re: How to Force Packet Traversal Order (IPFW2 => PF) Message-ID: In-Reply-To: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Rspamd-Queue-Id: 4GdWc80ccpz3JPd X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protonmail.com header.s=protonmail header.b=d7cGl2MN; dmarc=pass (policy=quarantine) header.from=protonmail.com; spf=pass (mx1.freebsd.org: domain of alfadev@protonmail.com designates 185.70.40.135 as permitted sender) smtp.mailfrom=alfadev@protonmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; HAS_REPLYTO(0.00)[alfadev@protonmail.com]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[protonmail.com]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; DKIM_TRACE(0.00)[protonmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[protonmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[185.70.40.135:from]; MAILMAN_DEST(0.00)[freebsd-hackers] Reply-To: alfadev@protonmail.com From: alfadev via freebsd-ipfw X-Original-From: alfadev X-ThisMailContainsUnwantedMimeParts: N Thank you all , I made further research and found same issue (Multi WAN + Captive Portal no= t working when pf+ipfw enabled same time) on OPNSENSE first mention is here: https://github.com/opnsense/core/issues/1166 here is the OPNSENSE solution: https://git.furworks.de/opensourcemirror/opnsense-src/commit/83fd8a61b942d8= 4f553e53127c4be02b318f7cf4 https://reviews.freebsd.org/D8109 https://reviews.freebsd.org/D8109 i will try solutions above links and hope this helps me and others.. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Sunday, August 1st, 2021 at 1:19 AM, Martin Beran wrote= : > p=C3=A1 30. 7. 2021 v 13:41 odes=C3=ADlatel alfadev via freebsd-ipfw < > > freebsd-ipfw@freebsd.org> napsal: > > > Hi, > > > > I have to use both IPFW and PF sametime in my freebsd 12.2 gateway > > > > According to my observations firewalls are following this order all of = my > > > > scenarios PF =3D> IPFW2. I see this exactly When i use PF's route-to op= tion . > > > > When i create Load-Balancing rule using PF's route-to, packets not ente= ring > > > > into IPFW. So when i made PBR, IPFW rules like mac based piping, bandwi= dth, > > > > captive portal etc. does not works. > > > > So that > > > > i am trying to do this order: > > > > input =3D> ipfw =3D> pf > > > > but i think i cannot change this order without touching kernel level . > > > > when i made some research i found this > > > > https://www.opennet.ru/tips/info/1431.shtml > > I think that you do not need to touch kernel source, nor build a custom > > kernel. The order of calling packet filtering modules depends on the orde= r > > of registering the modules to packet processing hooks. Instead of loading > > the modules by their respective startup scripts, you can load them in the > > required order by including them in /etc/rc.conf in variable kld_list. I = do > > not remember if the order of calling is the same or the opposite of the > > order of module loading. > > Martin Beran From nobody Mon Aug 2 13:11:32 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B61E012DCFA9 for ; Mon, 2 Aug 2021 13:11:41 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (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 4Gddgb3RTNz3tgJ for ; Mon, 2 Aug 2021 13:11:39 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qv1-xf2d.google.com with SMTP id js7so6252484qvb.4 for ; Mon, 02 Aug 2021 06:11:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=fb5ighB+7gbPjDOsd5/opKfAfsp/MvPqJvno7Kz6tyU=; b=KOKENdrzFzRpHIHqgErvcNgIZeFdTcO3/Gi/d38N/9M2oEyjoPXK/lg+G8Z4Sikudg ekFuzmT8ZO1sxoH0nflr0OmpW/Ul3N15YTXdRnDLVG4Os4UuN+GcfuLqe3cDaYhAxUsG vKj/f50Lggrbmv4Oqe9x38GmaopD4791qpxzxl6bIPcKmNm5g1sbV69HTMGcEeKtLi6J 4J8x/BNDxpaL5Cywmr0baQfOTbtATdtwK+LXxjCFRuHcJ4fHX6ieSipR+xDouZUrvydy WH9BVb5Acwd07+4iUSSFoyX148Jj5S6XvwOMAO9Rv+f6isaYAXeY64H0ty+wYOOkUe/S CYsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=fb5ighB+7gbPjDOsd5/opKfAfsp/MvPqJvno7Kz6tyU=; b=m5eeNpkM+0Z8nYaVyDLHu0g2bGCJufVZxLwqJpoqE3kn3Yu53jpiPfADpa3SV/k2oh ZOvP/YAFPx1/lf4EonGk6A219mXYEF5RBlslM9Hk1cksS8jpKNqUCmh6qCDhyaFF59dL fmYHw50cO+24idvv8adL5/KVZadOg0x291IDUbngaIdPEoNXdUkRI9v9IqmdMguW8U4I T5/hihAUZkgblWYJh4aNPfO5eDdD1UukD5lEde0ve7AV8qNYnxILVDUxnHpjzZBurkzZ eGAzaE14BtBPatHQT6VtlM0fav22zq0QFxrLYIcGBsX/69O7dhoxKj4JeCdViloeAPeX K6eg== X-Gm-Message-State: AOAM531pYbhIrCWhVwaMuIfFleIAAUdM40O3sdbjtZaLbdy835ZQiYS1 hrzf97kVNiVI/CZWFrA8BnlJRQ== X-Google-Smtp-Source: ABdhPJxZVq1iDtoUC5RgDrkYJx0F8TpbaU8GWXVU+60KgsrbWvMKHTDkPwp0KR2bj9rRAcfDp/OtGw== X-Received: by 2002:a0c:ed21:: with SMTP id u1mr16266106qvq.6.1627909893682; Mon, 02 Aug 2021 06:11:33 -0700 (PDT) Received: from mutt-hbsd (pool-100-16-224-136.bltmmd.fios.verizon.net. [100.16.224.136]) by smtp.gmail.com with ESMTPSA id 18sm6047769qkv.118.2021.08.02.06.11.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Aug 2021 06:11:33 -0700 (PDT) Date: Mon, 2 Aug 2021 09:11:32 -0400 From: Shawn Webb To: Ed Maste Cc: "freebsd-toolchain@FreeBSD.org" , FreeBSD Hackers , Dimitry Andric , Alexander Richardson Subject: Re: Migrating to LLVM binutils tools (ar, nm, addr2line, etc.) Message-ID: <20210802131132.c7egr6cphq322qcj@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 14.0-CURRENT-HBSD FreeBSD 14.0-CURRENT-HBSD X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="k2ouhyaedg3r5tdd" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4Gddgb3RTNz3tgJ X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=KOKENdrz; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::f2d as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org X-Spamd-Result: default: False [-5.10 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[hardenedbsd.org]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f2d:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] X-ThisMailContainsUnwantedMimeParts: N --k2ouhyaedg3r5tdd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 05, 2021 at 11:09:18AM -0400, Ed Maste wrote: > FreeBSD migrated from GNU binutils to versions from ELF Tool Chain, > starting in 2014. At that time there were no usable LLVM versions of > those tools, but they have been developing rapidly since then. Now I > think it may be prudent to migrate to the LLVM tools where they exist, > for both functionality and maintainability reasons. >=20 > I'd like to allow use of link-time optimization (LTO) in the FreeBSD > base system. LTO runs optimization passes over the entire executable > (or library) at link time and thus allows for more effective > optimization than when performed on individual compilation units. >=20 > When using LTO object files (.o) including those contained in static > library archives (.a) contain LLVM IR bitcode rather than target > object code. This means that utilities that operate on object files > need to support LLVM IR; we currently use a number of bespoke tools > and ones obtained from ELF Tool Chain that do not have this support. >=20 > Alex Richardson also pointed out that asan (address sanitizer) > produces a useful backtrace only if addr2line is llvm-symbolizer. >=20 > Like ELF Tool Chain the LLVM tools aim for command line and output > format compatibility with GNU binutils, although there are a few minor > differences. Where these cause a material issue (breaking a port or > eliminating required functionality) we can submit LLVM bugs and work > on patches. >=20 > In the past we provided build knobs to control individual utilities > (e.g. WITH_LLD_IS_LD); I'd like to avoid perpetuating that here. It > seems individual knobs (WITH_LLVM_AR_IS_AR, WITH_LLVM_NM_IS_NM, > WITH_LLVM_SYMBOLIZER_IS_ADDR2LINE etc.) will introduce extra > complexity without adding much value. >=20 > Alex is working on a patch now and will follow up shortly, but I > wanted to email the list as a heads-up, and see if there are any > comments or concerns. >=20 > Potential next steps are: > - Introduce new build knob > - Iterate on exp-runs and call for testing > - Switch to LLVM tools by default > - Major release (14.0) > - Retire knob, leaving only the LLVM implementation. Hey Ed, As background for anyone curious, HardenedBSD switched to using llvm-ar, llvm-nm, and llvm-objdump by default years ago as part of the work to start integrating Cross-DSO CFI. We've noticed one small, but important, issue with llvm-ar (which is also the same underlying program as llvm-ranlib) in some behavior that doesn't match ELF Toolchain's ar/ranlib (which I'll call elftc-ar). For most cases, when elftc-ar fails, it does not set the exitcode to non-zero. This tricks the ports tree to continue to build a port where elftc-ar actually errored. llvm-ar does the right thing in exiting with a non-zero exit code on error. However, due to this discrepency in behavior, certain ports that cause an error condition when calling ar/ranlib continue to build when elftc-ar is used, but fail to build when llvm-ar is used. I'm thinking that I'll report this same issue to the ELF Toolchain folks since elftc-ar really should exit with a non-zero exitcode on failure. I've just now hacked llvm-ar to behave the same as elftc-ar[0] and will do a poudriere bulk run soon. I'll report back my status with the ELF Toolchain notification and the poudriere run as soon as I have more info. [0]: https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/commit/5bdcc54a23f058= 83f55e895da49726955fa8b07b Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --k2ouhyaedg3r5tdd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmEH7wIACgkQ/y5nonf4 4fqODQ/8Dp5G6Yjk861k59c2MSLnj2As3Mu7XgTe3/HPznAUg8GRgtTzwZHi52R3 lTPtHHiCtKytGr4UQKfSpdJ2NXvTJ3IWY/Ul77BlMGb3+gGVli2suf6xgkI82ZWC jsTfMyD6FlRAHc17AbuWHaCYiuarJI+CLPnA6Bcarvz+fAE1TVsqgWDcV5WtBjSD XGTZWSvDHGZmvH7evsoXkBXq1mT8C6L7LbcHecNdEYONkTnMDHL0KDGoyZovX9Zv gigqPuPHJXd6h/0xNkQ6XSmv0g0V2o0sSC8gVYN/hbDJ+oTja04r7b+3pc8R/Lw/ oVZ56SuO52Q45hsUnhxNtXfbMcDfG39ExVRfy2NRHUGu5Vh8fy3vCXv7y0rdQnX+ jX8d5k+s9s48qjzKKjWkKgdoyyBuOLq5RELp98fZs3FJem6wfMD96avdwxcgD75v uMyGaAxoU4380n0Mdlq3VwJxrP9uPVhb0kVHCGs088i1d6lOP4cXjaEZxHxdW+wz awm6PRHYcofx4JkGru52WcavIxHOWLnCwU0rHSikLlNMwU+4gv3HvD9dCh6+E0+C DHyoOS7UxaFnNYEujCZz9PjRL8CpCfZV5vzfxcr2m1V1wxYHCRZnOcN9vV3BJ4gM rAG/RG66Vln6PUv1kywqby9Iv6FdR7plc3O9hRAr6rGFKp3RLyc= =jthh -----END PGP SIGNATURE----- --k2ouhyaedg3r5tdd-- From nobody Mon Aug 2 15:25:21 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3890013462AC for ; Mon, 2 Aug 2021 15:25:36 +0000 (UTC) (envelope-from christos@freebsd.org) Received: from christos (mail.margiolis.net [95.179.159.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Gdhf74SMYz4bMF; Mon, 2 Aug 2021 15:25:35 +0000 (UTC) (envelope-from christos@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=default; bh=kHn7ZpGuHlqG 9O2Xcgxm6IYuIOv1kd1jv5vZ3bLxk0k=; h=subject:cc:to:from:date; d=margiolis.net; b=dD5ya92i1PuT9dRKcJaNNsgJzSj1b5etBsApDg9x+iuLhgKXLPt lE3emELdEMkKOUhqvV1acwQnXjCrZlMJfzL3EnXVLq/spkRdq31BeZBVInCROZY+ckOH5c O2o6HsbOe1oLhrQiWDrsg2vzMEQ8gvwvndhFJpJPxEoxKv5l/0= Received: from pleb (athedsl-202981.home.otenet.gr [85.74.112.131]) by christos (OpenSMTPD) with ESMTPSA id ec1f24b2 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Mon, 2 Aug 2021 15:25:26 +0000 (UTC) Date: Mon, 2 Aug 2021 18:25:21 +0300 From: Christos Margiolis To: freebsd-hackers@freebsd.org Cc: hselasky@freebsd.org Subject: [GSoC'21 Weekly Update #8] Sound mixer improvements Message-ID: <20210802152521.r6nuyop7jtdswwa3@pleb> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4Gdhf74SMYz4bMF 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:20473, ipnet:95.179.144.0/20, country:US] X-ThisMailContainsUnwantedMimeParts: N Hello, Last week I did the following: sound(4): - Implemented a new read-only sysctl to report the playback/recording mode of the sound device (dev.pcm.X.mode). The sysctl values are: 1=mixer, 2=play, 4=rec. These values can also be OR'ed together if more than one mode is supported. mixer(3): - Added functions to make user-defined controls. mixer(8): - Made /dev/sndstat "useless" since with the new sysctl we can get all the information it provides. Documentation: - Worked on the man pages for mixer(3) and mixer(8). Also on the 21st of July, my mute ioctl patch for sound(4) got merged into upstream: https://cgit.freebsd.org/src/commit/?id=0f8dafb45859569aa36b63ca2bb4a1c35c970d1e The code is available on: - GitHub: https://github.com/christosmarg/mixer - Sourcehut: https://git.sr.ht/~crm/mixer - My Git server: https://git.margiolis.net/mixer/files.html The project's Wiki article can be found at: - https://wiki.freebsd.org/SummerOfCode2021Projects/SoundMixerImprovements From nobody Mon Aug 2 23:47:34 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E07D012DB8EE for ; Mon, 2 Aug 2021 23:47:41 +0000 (UTC) (envelope-from verification@freebsd.org) Received: from serv-17259.my-tss.com (serv-17259.my-tss.com [66.115.166.235]) (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 4GdvnT3xpYz3mjh for ; Mon, 2 Aug 2021 23:47:41 +0000 (UTC) (envelope-from verification@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=acecase.com ; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From: 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=IG7ZuOZF9z98Cqme4b8sSXc+CItfsVkk/MCUQ+acS78=; b=ifzOoff8AZHHXxbFj7VyhgZRN6 xePpyDG9AHq1dlZgXhzECOjYutnvvPP5OZMyo5flozhMGUKmiiZEqXFQH25kUlgd9mgb0yb6XYNx8 9xYtqbGEuenpav/0kCOKrArEer0Km1ZMMtbbe9ecQ1C/M9lq6Y/VQDnw0090D/vYak/kCKRIrk3dY qjULemIkWkG8akPy3P5ZDEP4jV4snFZsRFTV7wdcsV4Oq+oO9s8G2NQzFlzt/FrZGkxVFP6UvcCKT Qj8y0sE2vxPRU4A2IgRcQKPuEaOKasJej610CdL1JhRoM03xzwkCG5XBdvr7xq27iy6VqW6S3lOCS p5ReDZ6w==; Received: from [37.0.8.140] (port=58532) by SERV-17259.my-tss.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mAheh-0007rw-Vh for hackers@freebsd.org; Mon, 02 Aug 2021 19:47:35 -0400 From: verification@freebsd.org To: hackers@freebsd.org Subject: Your freebsd.org Account Email Verification Date: 2 Aug 2021 16:47:34 -0700 Message-ID: <20210802164734.A0883FD1C2C0BA34@freebsd.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_93593374.523B8E58" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - SERV-17259.my-tss.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freebsd.org X-Get-Message-Sender-Via: SERV-17259.my-tss.com: authenticated_id: sales@acecase.com X-Authenticated-Sender: SERV-17259.my-tss.com: sales@acecase.com X-Source: X-Source-Args: X-Source-Dir: X-Rspamd-Queue-Id: 4GdvnT3xpYz3mjh 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:46562, ipnet:66.115.128.0/18, country:US] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: Y ------=_NextPart_000_0012_93593374.523B8E58 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Dear hackers ------=_NextPart_000_0012_93593374.523B8E58-- From nobody Tue Aug 3 04:01:47 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DE84B12A58C8 for ; Tue, 3 Aug 2021 04:01:59 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 4Gf1Qt686Jz4csX for ; Tue, 3 Aug 2021 04:01:58 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: by mail-ua1-x92e.google.com with SMTP id 67so1924258uaq.4 for ; Mon, 02 Aug 2021 21:01:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=dpJUw5/uDnpBI1Mf8idzwQmH5sr4+PW5C4GSuyPRjzY=; b=dU2H30GoA4yB3kSbI22kEJYF5vb0dUnkd5e04OojcmNBHH99Jv/cvCDad0iSpzvuWU 6WN8QuwCYluYzZRj7FQcQ4996KqXGsb6yRpodBWs+kEMTL9EuI3Xzz9L/g+Qkn+VMxuQ k1FgD0EEMTA3AkIJfUKmjIutRKcX1f0+Y5Dji0liv5oP5le9jokm2oyKQd/umivyCQps zr/PmGdMZPAyP3UpaApe8F3bqbCqOi90H+BDUFfoRRG2AjI73mtTc6ptGgLM/QmUYEra zQVmMwopqO5KUUOJUx6O9VswSa3GRxvUIGBATwypIGjtOPBSSiX6pcol6LqJSVxL9lDV 9x7A== 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; bh=dpJUw5/uDnpBI1Mf8idzwQmH5sr4+PW5C4GSuyPRjzY=; b=nBLv74kkKqrvLkM4aRmXfxiawR/0KRnewhQ1OoliLkmdk6BZl/jbGFjS1F1HSDjK5v lANkXElyHg2D04cwYCShy6oj8kh2CbEvvJNL9MLSeXIZg0n2xLHsCZDYAH1xcuUyba0V Y+kOY+AD+CKcZzNdxqHX52QXsMvq6C7wRfm/wB8fuNw6shxIdVeOgM9LC8XwVWAgVSvZ zl1K33zeful0J/HDxcpxYpj6Hhn2SJifs0W353f3jnaCI7fI3uzohYmGQguLdGhAMgS5 qEmHrmgUmzvY1NfVKag3RM1zg58d7jwqz0Cqqovk4HK7wjuRUrWimQVB8WTAv4eev1ey KRvA== X-Gm-Message-State: AOAM5312FI3xC/lpmseE4goeX3R09S+vyaIRvM1BChwoB6YtUdsyIcO5 JkvnlvyaOoK7YfiSz8epd9Js6IiU3nJJeRD3n1lJroX/2Mg= X-Google-Smtp-Source: ABdhPJwcIzYCBRwTYYVqxMubyBAc5mJM5txGK2L5WbsaU7Yky4nTiEeTJwMr6vWCgansZRzEzpPLe7AU94o1Jt0N8S8= X-Received: by 2002:ab0:6913:: with SMTP id b19mr1010331uas.48.1627963318257; Mon, 02 Aug 2021 21:01:58 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Date: Tue, 3 Aug 2021 07:01:47 +0300 Message-ID: Subject: Fwd: Wired Memory Increasing about 500MBytes per day To: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="0000000000004ac99205c89fbf6f" X-Rspamd-Queue-Id: 4Gf1Qt686Jz4csX X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=dU2H30Go; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ozkankirik@gmail.com designates 2607:f8b0:4864:20::92e as permitted sender) smtp.mailfrom=ozkankirik@gmail.com X-Spamd-Result: default: False [-1.92 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:~,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_SHORT(0.98)[0.983]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::92e:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: Y --0000000000004ac99205c89fbf6f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm sorry for cross posting, but I couldn't received any replies. ---------- Forwarded message --------- From: =C3=96zkan KIRIK Date: Mon, Aug 2, 2021 at 8:00 AM Subject: Wired Memory Increasing about 500MBytes per day To: FreeBSD Net , freebsd-stable < freebsd-stable@freebsd.org> Hello, I'm using FreeBSD stable/12 0f97f2a1857a96563792f0d873b11a16ff9f818c (Jul 25) built. pf, ipfw and ipsec options are built with kernel. The server is used as firewall that squid and snort3 (daq - netmap) is running. I saw that, wired memory is increasing every day. It's about 500MBytes per day. I'm checking vmstat and top (sorted by res), I couldn't find what is consuming the wired memory. How can I find that which process or which part of kernel is consuming the wired memory ? # first a few lines of top last pid: 61147; load averages: 3.83, 3.92, 4.02 up 3+14:09:57 07:53:44 4294 threads: 42 running, 4153 sleeping, 99 waiting CPU: 3.1% user, 0.0% nice, 10.4% system, 0.0% interrupt, 86.5% idle Mem: 3074M Active, 11G Inact, 11G Wired, 1572M Buf, 101G Free ARC: 3764M Total, 1385M MFU, 2144M MRU, 2666K Anon, 19M Header, 213M Other 3243M Compressed, 3510M Uncompressed, 1.08:1 Ratio # vmstat -m Type InUse MemUse HighUse Requests Size(s) CAM dev queue 5 1K - 5 64 scsi_da 0 0K - 388 32,256 UART 3 3K - 3 16,1024 USB 43 87K - 78 16,32,128,256,512,1024,2048,4096,16384,32768 USBdev 31 4K - 53 32,64,128,256,512,4096 SCSI ENC 26 133K - 67266 16,64,512,1024,2048,32768,6553= 6 nvlist 282 26K - 52522369 16,32,64,128,256,2048,4096,819= 2 vtbuf 24 1968K - 46 4096 vt 11 6K - 11 512 acpiintr 1 1K - 1 64 DEVFS3 194 49K - 269 256 DEVFS1 146 73K - 217 512 DEVFS_RULE 56 27K - 56 64,512 DEVFS 15 1K - 20 16,32,128 DEVFSP 529 34K - 748886191 64 nullfs_hash 1 16384K - 1 nullfs_node 27 2K - 34 64 nullfs_mount 10 1K - 11 32 pfs_nodes 20 10K - 20 512 tmpfs mount 3 1K - 3 128 tmpfs name 4791 116K - 18569 16,32,64,128 GEOM 357 54K - 3904 16,32,64,128,256,512,1024,2048,4096,8192,16384 raid_data 0 0K - 612 32,128,256 isadev 7 1K - 7 128 acpica 16568 1655K - 738465 16,32,64,128,256,512,1024,2048,4096 acpitask 1 64K - 1 65536 acpisem 24 3K - 24 128 cdev 4 1K - 4 256 filedesc 367 2390K - 4457314 16,32,64,128,256,512,4096,8192,16384,32768,65536 sigio 17 2K - 415 64 filecaps 6 1K - 90314 16,32,64 kdtrace 4829 1110K - 15580812 64,256 kenv 148 14K - 148 16,32,64,128,8192 kqueue 1176 726K - 25696080 64,128,256,512,2048,4096,8192,16384,32768 proc-args 634 46K - 6581654 16,32,64,128,256 hhook 34 7K - 51 32,256 ithread 449 73K - 455 32,128,256 prison 11 5K - 12 16,32,4096 KTRACE 100 13K - 100 128 evdev 3 3K - 7 1024 linker 481 505K - 633 16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536 lockf 39 5K - 7173761 64,128 loginclass 3 1K - 8 64 devbuf 19975 49482K - 38585 16,32,64,128,256,512,1024,2048,4096,8192,16384,65536 temp 4192 173K - 75602914 16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536 module 537 68K - 538 128 mtx_pool 2 72K - 2 8192,65536 osd 14 1K - 129800 16,32,64,128,256 pmchooks 1 1K - 1 128 pmc 2 1K - 2 64 session 93 12K - 437777 128 proc 2 256K - 2 subproc 1468 2561K - 6842581 512,4096 cred 1869 468K - 2482324 256 plimit 83 21K - 827841 256 uidinfo 14 34K - 17233 128,32768 ix 42 117K - 42 512,1024,2048,4096 sysctl 1 1K - 2408297 32,64 sysctloid 15990 820K - 16624 16,32,64,128,256 sysctltmp 0 0K - 5790925 16,64,256,1024 acpidev 179 12K - 179 64 CAM SIM 6 2K - 6 256 tidhash 1 256K - 1 callout 33 9352K - 33 umtx 10204 1276K - 10204 128 p1003.1b 1 1K - 1 16 bus 2040 231K - 341181 16,32,64,128,256,512,1024,4096 bus-sc 202 1751K - 72634 16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536 devstat 20 41K - 20 32,4096 eventhandler 169 14K - 170 64,128 firmware 26 2K - 26 16,32,128 gtaskqueue 198 44K - 198 16,32,256,8192 kobj 332 1328K - 1289 4096 Per-cpu 1 1K - 1 32 CAM XPT 42 4K - 1443 16,32,64,128,256,512,1024,2048,65536 rman 408 48K - 816 16,32,128 sbuf 1 1K - 839349 16,32,64,128,256,512,2048,4096,8192,16384,32768,65536 toponodes 84 11K - 84 128 CAM DEV 9 18K - 520 2048 taskqueue 648 74K - 942 16,32,64,128,256,512 terminal 11 3K - 11 256 Unitno 65 4K - 3793393 32,64 vmem 4 2368K - 12 4096,8192,16384,32768,65536 ioctlops 0 0K - 2234885 256,512,1024,2048,4096 select 2671 334K - 2671 128 iov 0 0K - 248581529 16,64,128,256,512,1024,4096 msg 4 204K - 4 4096,8192,65536 sem 4 106K - 4 2048,4096 shm 14 58K - 282515 2048,32768 tty 14 14K - 24 1024 pts 1 1K - 11 256 mbuf_tag 0 0K - 339649313 32,64 shmfd 34 23K - 21424 64,256,1024,8192 soname 78 7K - 49413750 16,32,64,128 pcb 990 4460K - 669045 16,32,64,128,1024,2048,8192 kbdmux 6 22K - 8 16,512,1024,2048,16384 acl 0 0K - 124531 4096 vfscache 4 32961K - 4 256,65536 cl_savebuf 0 0K - 247 64 vfs_hash 1 16384K - 1 vnodes 1 1K - 1 256 mount 261 13K - 61165 16,32,64,128,256,1024 statfs 0 0K - 3613124 4096 LED 4 1K - 4 16,128 vnodemarker 0 0K - 214729 512 fadvise 0 0K - 137 32 chacha20random 1 8K - 1 8192 BPF 2535 25717K - 2247023944 16,64,128,256,512,2048,4096 ifdescr 1 1K - 1 16 ifnet 513 1027K - 1482 64,128,256,512,1024,2048,4096 ifaddr 5117 1388K - 15096 16,32,64,128,256,512,2048,4096 ether_multi 13633 1089K - 40471 16,32,64,128 clone 38 5K - 55 128 epair 2 1K - 4 128 ipsec 6 2K - 9 256 lltable 37732 18363K - 246041 256,512 tun 7 1K - 11 32,256 vlan 2864 359K - 38902 64,128,256 iflib 314 3652K - 338 32,64,256,512,1024,4096,8192,16384,32768 routetbl 12731 3113K - 247870 32,64,128,256,512,8192 vnet 2 1K - 3 64 vnet_data 2 384K - 3 vnet_data_free 1 1K - 1 32 igmp 511 64K - 1479 128 in_multi 487 122K - 1446 256 ip_moptions 0 0K - 6 64 encap_export_host 18 1K - 18 32,64 mroutetbl 8 53K - 12 256,2048,8192,16384 sctp_a_it 0 0K - 6133 16 sctp_vrf 2 1K - 3 64 sctp_ifa 1572 197K - 6888 128 sctp_ifn 487 61K - 6888 128 sctp_iter 0 0K - 6133 256 tfo_ccache 2 256K - 3 hostcache 2 64K - 3 32768 LRO 48 960K - 48 8192,32768 tcpfunc 1 1K - 1 64 syncache 2 1088K - 3 in6_multi 4880 686K - 14475 32,256 ip6_moptions 0 0K - 1 32 mld 497 63K - 1461 128 ip6ndp 983 153K - 4354 64,256 inpcbpolicy 6117 192K - 952852053 32 secasvar 8 4K - 1390 256,1024 sahead 8 4K - 1052 256,1024 ipsecpolicy 56 16K - 1530 256,1024 ipsecrequest 44 6K - 1516 128 ipsec-misc 51 2K - 8317 16,32 ipsec-saq 4 4K - 152 256,1024 ipsec-reg 2 1K - 2 32 dummynet 10 2069K - 13 512,1024 dummynet 8 3K - 10 256,512 IpFw/IpAcct 94 2428K - 1721 16,32,64,128,256,512,1024,2048,4096,8192 ipfw_tbl 3 1K - 267 128 pfsync 4 65K - 6 512,32768 pf_temp 0 0K - 10651 32,64 pf_hash 14 23056K - 21 2048 pf_ifnet 543 140K - 30387 128,256,2048 pf_rule 6475 9594K - 70452 128,2048 pf_osfp 2382 245K - 7146 64,128 pf_table 1647 3294K - 56328 2048 linux 5 1K - 6 16,64 linuxcurrent 2 1K - 2 64,256 crypto 58 43K - 3734 128,512,1024,4096 xform 0 0K - 145609856 64 pagedep 1 2048K - 4 256 inodedep 1 16384K - 6 512 bmsafemap 1 8K - 5 256,8192 newblk 1 32768K - 4 256 freeblks 0 0K - 1 128 freefile 0 0K - 1 64 diradd 0 0K - 8 128 mkdir 0 0K - 4 128 dirrem 0 0K - 5 128 newdirblk 0 0K - 2 64 freework 1 1K - 2 16,128 sbdep 0 0K - 3 64 savedino 0 0K - 4 256 softdep 1 1K - 1 512 ufs_dirhash 600 113K - 1164 16,32,64,128,256,512 ufs_mount 9 50K - 68 512,4096,8192 UMAHash 61 9148K - 155 512,1024,2048,4096,8192,16384,32768,65536 md_disk 17 5K - 17 32,4096 md_sectors 16 64K - 16 4096 rpc 1 4K - 1 4096 fpukern_ctx 32 32K - 32 1024 memdesc 1 4K - 1 4096 pci_link 16 2K - 16 64,128 CAM CCB 0 0K - 47838681 2048 mrsasbuf 949 2860K - 951 32,128,256,2048,8192 CAM path 13 1K - 7263 32 CAM periph 10 3K - 541 16,32,64,128,256 netmap 262944 1126176K - 262944 acpi_perf 32 16K - 32 512 sr_iov 6 3K - 6 512 apmdev 1 1K - 1 128 madt_table 0 0K - 2 256,4096 CAM I/O Scheduler 2 1K - 2 128 entropy 1 1K - 5527116 32,4096 intr 4 484K - 4 65536 io_apic 3 6K - 3 2048 local_apic 1 32K - 1 32768 CAM queue 14 52K - 1551 16,32,64,128,256,512,1024,2048,4096,16384 MCA 65 21K - 65 128,256,512 cpus 2 1K - 2 128 msi 87 11K - 87 128 nexusdev 6 1K - 6 16 scsi_cd 0 0K - 8 16 kstat_data 12 1K - 12 64 solaris 366461 463423K - 2105003083 16,32,64,128,256,512,1024,2048,4096,8192,16384,32768 sfs_nodes 6 3K - 6 512 aesni_data 2 3K - 2 256,2048 ioat 16 7168K - 16 disc 1 1K - 2 16 gre 5 1K - 5 64,128 netgraph_msg 0 0K - 5 64,128,256 netgraph_hook 0 0K - 2 128 netgraph_node 7 2K - 11 128,256 netgraph_path 0 0K - 4 16 netgraph_sock 6 1K - 9 32,128 netgraph_mppc 0 0K - 2 1024,65536 eli data 35 4K - 865337 64,256,1024,2048,4096,8192,16384,32768,65536 Regards, --0000000000004ac99205c89fbf6f-- From nobody Wed Aug 4 01:09:40 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id EDCF7137FE18; Wed, 4 Aug 2021 01:10:02 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f51.google.com (mail-io1-f51.google.com [209.85.166.51]) (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 4GfYZ16vTNz4dtV; Wed, 4 Aug 2021 01:10:01 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f51.google.com with SMTP id n19so650737ioz.0; Tue, 03 Aug 2021 18:10:01 -0700 (PDT) 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; bh=5c+6kiUNqTRnH23tp5Mo50VO5czSh+sc1BmU+Ch1pJ0=; b=UADcrovnGyR/jT9gVltLmx0MK1b61ebFTTOqUKa9bo5p5ka+fgNHrndkdqc6pmKKp7 AK2dj28C3eaOOz80xjuw9FHyCar5fK5ywVK8rTZTG+q6x7oLRqASPq2dHrjfzrjf/L6L 7d2l6g2Pk3OC8i/IryDjhCCWapC+UkRcq+FJG1ORtgDC1CXL77edU2c59Y+ymfiCVodh FdS4yOKk67C0j4imZ6dgdbscoDx4uV+71EA/TajyTalNLS1BCtmjlQYRzlaHK6/eFxG/ YJMg3oOqniM6anvXlvx7Jt2B4VRJ+wslE4k1IqNz9Pc1ieFSrCt1CkOAclX21QjmgdUS Ln6w== X-Gm-Message-State: AOAM533e1gENnDU2ZIM8lCzqA0QeAhq3l8+u/Z2YS4eSCZQQ0qXRjunU DkVsV0FWy63BkcagRsoAJaTw16PDQlYfGVet2BADa5ATvuI= X-Google-Smtp-Source: ABdhPJxnGJP5X0x/eSdf6gqxP3FpGVBEeshMEihaBatYYBTTyU+txrEG1iV/TyMvVILRCPYjmBu/5thaf0RGi6tJPgw= X-Received: by 2002:a05:6638:34aa:: with SMTP id t42mr21373111jal.128.1628039394732; Tue, 03 Aug 2021 18:09:54 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <20210802131132.c7egr6cphq322qcj@mutt-hbsd> In-Reply-To: <20210802131132.c7egr6cphq322qcj@mutt-hbsd> From: Ed Maste Date: Tue, 3 Aug 2021 21:09:40 -0400 Message-ID: Subject: Re: Migrating to LLVM binutils tools (ar, nm, addr2line, etc.) To: Shawn Webb Cc: "freebsd-toolchain@FreeBSD.org" , FreeBSD Hackers , Dimitry Andric , Alexander Richardson Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4GfYZ16vTNz4dtV X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.51 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-2.88 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.990]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.51:from]; NEURAL_HAM_MEDIUM(-0.89)[-0.889]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.51:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Mon, 2 Aug 2021 at 09:11, Shawn Webb wrote: > > For most cases, when elftc-ar fails, it does not set the exitcode to > non-zero. This tricks the ports tree to continue to build a port where > elftc-ar actually errored. Thanks for the notice - I didn't see this email until now, but saw the related discussion on HardenedBSD's IRC channel this morning. Note that FreeBSD ar is different from ELF Tool Chain's ar; the latter is a fork of FreeBSDs, and there are some distinct bug fixes or improvements in each version that are not present in the other. Here FreeBSD's ar is buggy, and llvm-ar, GNU ar, and ELF Tool Chain's ar all return a non-zero exit code. Code review with fix for FreeBSD's ar: https://reviews.freebsd.org/D31402 Exp-run request: https://bugs.freebsd.org/257599 From nobody Wed Aug 4 12:13:46 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7CBB515E9F8B for ; Wed, 4 Aug 2021 12:13:48 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 4GfrHw2Rvyz3n74 for ; Wed, 4 Aug 2021 12:13:48 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk1-x72a.google.com with SMTP id t3so1170678qkg.11 for ; Wed, 04 Aug 2021 05:13:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=l1aC55U1/17jZz0HqoYk0H7GYLhtJmEwTz4dEG1//CU=; b=DLl1LJ6vXIMhEo3ImQydzAKsPqJpLuwJEoSKMW1idx2FqpOVERoWEg9iOQjYTo/6zd r6YGmNc3Wqb+wRwOXhQzUUs1l7SmOu/tTsyoKvN0ydLXVzaVnhgJmDFIDtpCAAPfYbBU jsszGcZkuntV/Zo3dvB8UZC1D1w5DvQjMOhiPtWBGnIB7M6ndvhum1nY85vyJ1JHhB07 qiCeH3UT/Bx7QksyH8RjzYfHXyZa8sk1VFwblzR6eGhCMGvuYB8jKgNGNMin2n4fX/JQ sXREaEBQiUzuniNtd0MLe6qaUSXp8cqcH/gm+rdo55uUHDj8RQWZJ2QTfnMQQCmajn8V In4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=l1aC55U1/17jZz0HqoYk0H7GYLhtJmEwTz4dEG1//CU=; b=BlACjy0zeTH9X8r8xilUFuOOlEJ6O1feAKW4WYJ3HXhO8s/mZxFznhX7A8f5B97lJg iO3nHN0hllkwvspIxX8gpAzlWiWt72FZw5Fuv3xEcoYJKBMEXn/fEwGCFXRLJf4nkycF Bk2LpKFqn7b1PMHUV6GAiX4BdxJ199+s7CQfPvIyrFjen2OUZCY8lYu8oQb0NkgLVfQU 9/OXRzrooQD15WZwFH12YV9tdGAX7mvacI78q1bPqou/amTRusBnIpyDDP7oJyAm8lWi B/DqNE8xNByDY5QlbgfZFP8w5CSdgsRI1TVnPY6gf8KFUQcJQn8zQJBnyp8EN8fYkYl+ cwMA== X-Gm-Message-State: AOAM533GLW9Pa+B36BCipd24c2dJJPvhN0j0njqDIWbsCO/womhr+U/o miyBgP8RpunUa/Yo+hYTJ2XMJw== X-Google-Smtp-Source: ABdhPJzJlvULgOVkvfcu08h8fJuuXZFGP7uWmu5ZZRIf41qMlZwO8WbunrpVjbUwUaCp1SaRRQmc6Q== X-Received: by 2002:a05:620a:f03:: with SMTP id v3mr26069474qkl.96.1628079227965; Wed, 04 Aug 2021 05:13:47 -0700 (PDT) Received: from mutt-hbsd (pool-100-16-224-136.bltmmd.fios.verizon.net. [100.16.224.136]) by smtp.gmail.com with ESMTPSA id o2sm1187199qkm.109.2021.08.04.05.13.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Aug 2021 05:13:47 -0700 (PDT) Date: Wed, 4 Aug 2021 08:13:46 -0400 From: Shawn Webb To: Ed Maste Cc: "freebsd-toolchain@FreeBSD.org" , FreeBSD Hackers , Dimitry Andric , Alexander Richardson Subject: Re: Migrating to LLVM binutils tools (ar, nm, addr2line, etc.) Message-ID: <20210804121346.b6xelxg3mwellffe@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 14.0-CURRENT-HBSD FreeBSD 14.0-CURRENT-HBSD X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: <20210802131132.c7egr6cphq322qcj@mutt-hbsd> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oagg7em5zd5opkop" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4GfrHw2Rvyz3n74 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --oagg7em5zd5opkop Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 03, 2021 at 09:09:40PM -0400, Ed Maste wrote: > On Mon, 2 Aug 2021 at 09:11, Shawn Webb wrot= e: > > > > For most cases, when elftc-ar fails, it does not set the exitcode to > > non-zero. This tricks the ports tree to continue to build a port where > > elftc-ar actually errored. >=20 > Thanks for the notice - I didn't see this email until now, but saw the > related discussion on HardenedBSD's IRC channel this morning. >=20 > Note that FreeBSD ar is different from ELF Tool Chain's ar; the latter > is a fork of FreeBSDs, and there are some distinct bug fixes or > improvements in each version that are not present in the other. Here > FreeBSD's ar is buggy, and llvm-ar, GNU ar, and ELF Tool Chain's ar > all return a non-zero exit code. >=20 > Code review with fix for FreeBSD's ar: https://reviews.freebsd.org/D31402 > Exp-run request: https://bugs.freebsd.org/257599 I was mistaken about which ar was errant. I apologize. Thank you very much for the clarification. Thanks again, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --oagg7em5zd5opkop Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmEKhHgACgkQ/y5nonf4 4frxmg//Xj5XUk+59S/6aDCupkXPt6flYjOywX19yu1Zc96mvoRO+NIRu44PSaDG ewjxuz/Nqpm7PxOmlEWyzBXc3kIO+zSH3cdpCw61yiiksF4iHp3mb/Bqlw125IJY eI7jvm4v2BMBfh33y+FbuKsnV/1q33VGQpIFhLndPB1PKvl0r/a2CxaRVOLPxsbj U3GNt/jvC2djWxPzqb/k3gCiSyXnUykuI86GUgT0O44OuTkJZPlUr0GjfNIqHFdk wEW3zhIKaoaKxNx5AShPy1chc2S+jDepg3GEwfQHUmAAtaddxqZ3W3wbkoJ1CxwI pXQDZFTQHCBVElSFyKEyDr5FICz+icWHWotzKYbitpaRm5o7E/N8ePRMfnczAXJo 5ysnnHUJ+k+s8+1FG67BuLKfD2G8yX5XEEbI5l0bAhZe0Ubea+Vrhpnth5L2FAJx uhxK/Ex3riBOPnDJA2Iy5zLJWdemgm1y08XZgRwDdsgTOSRdTxMkYnJwwkwNJtu2 CVMT5pqi7k42/r52tJS9v2Jpjv7jArlG+4Yb32DilPX7WJVEp/57m3hDNWChujOy OBhO9ya7HXPYn+rn4IY3RDzZfTazJOb6Sp6B95MdPs34bo3TDOO+f6mZwha8fqQ2 u8RF1iTJ+7Ti8N5xAicjppgpTO2kOQhGS2Y/JxYhWeAA5Gt8g3I= =L+L+ -----END PGP SIGNATURE----- --oagg7em5zd5opkop-- From nobody Wed Aug 4 12:33:48 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 10D6815EBBDA for ; Wed, 4 Aug 2021 12:33:54 +0000 (UTC) (envelope-from SRS0+Fut7=M3=moira.hest-guild.se=andkem@lysator.liu.se) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (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 4Gfrl55JT2z3pqs for ; Wed, 4 Aug 2021 12:33:53 +0000 (UTC) (envelope-from SRS0+Fut7=M3=moira.hest-guild.se=andkem@lysator.liu.se) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id A2AE14000B for ; Wed, 4 Aug 2021 14:33:52 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 8AD624000F; Wed, 4 Aug 2021 14:33:52 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL,UNPARSEABLE_RELAY autolearn=disabled version=3.4.2 X-Spam-Score: 0.0 Received: from moira.hest-guild.se (unknown [IPv6:2001:9b1:28ff:5100::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 31FF04000B for ; Wed, 4 Aug 2021 14:33:49 +0200 (CEST) Received: from andkem (uid 1000) (envelope-from andkem@moira.hest-guild.se) id 1817869a by moira.hest-guild.se (DragonFly Mail Agent v0.13); Wed, 04 Aug 2021 14:33:48 +0200 Date: Wed, 4 Aug 2021 14:33:48 +0200 From: Andreas Kempe To: freebsd-bluetooth@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: RFC: PoC: Bluetooth secure simple pairing support Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="+pkO+WIezJok9CBI" Content-Disposition: inline X-Virus-Scanned: ClamAV using ClamSMTP X-Rspamd-Queue-Id: 4Gfrl55JT2z3pqs X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=liu.se; spf=pass (mx1.freebsd.org: domain of SRS0@lysator.liu.se designates 2001:6b0:17:f0a0::3 as permitted sender) smtp.mailfrom=SRS0@lysator.liu.se X-Spamd-Result: default: False [-5.60 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.lysator.liu.se:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain,text/x-diff]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; HAS_ATTACHMENT(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[liu.se,none]; RCVD_TLS_LAST(0.00)[]; FORGED_SENDER(0.30)[kempe@lysator.liu.se,SRS0@lysator.liu.se]; SIGNED_PGP(-2.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~]; ASN(0.00)[asn:1653, ipnet:2001:6b0::/32, country:EU]; TAGGED_FROM(0.00)[Fut7=M3=moira.hest-guild.se=andkem]; FROM_NEQ_ENVFROM(0.00)[kempe@lysator.liu.se,SRS0@lysator.liu.se] X-ThisMailContainsUnwantedMimeParts: N --+pkO+WIezJok9CBI Content-Type: multipart/mixed; boundary="m88YXiM89buYlW4g" Content-Disposition: inline --m88YXiM89buYlW4g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello everyone, A few months back I sent a mail titled "Wireless Logitecgh M557 mouse issues" to the bluetooth list and since then I finally found some time to do more digging into the issue. Comparing the FreeBSD behaviour to that of Linux via packet dumps, I found that the reason my buetooth mouse is not able to reconnect to my FreeBSD machine is that no pairing is performed. Currently, the initial connection to the mouse is made and the mouse is used in an unpaired state. When the mouse tries to reconnect, the computer has no authentication key and the connection fails. Attached to this mail, you can find a proof of concept patch for allowing pairing between my mouse and the FreeBSD host. Using the attached patch, I'm able to connect my mouse and it reconnects when switched off and on again. The patch applies on top of Git revision 142f0d36d90979a983e1bb0b69d1d859338b4d90. Using the PoC ------------- In its current form, hcsecd has a very rudimentary implementation of pairing support. No real state machine is used and error handling is pretty much non-existent. The implementation assumes all operations went well (which they have always done with my mouse so far). Using the patch and performing the pairing: 1. Ensure that /var/db/{hcsecd.keys,bthidd.hids} do not contain entries fro the mouse. 2. Prep the hcsecd configuration file with the mouse. device { bdaddr 00:1f:20:f5:cd:5f; name "Bluetooth Mouse M557"; key nokey; pin nopin; } 3. Prep the bthidd configuration file. device { bdaddr 00:1f:20:f5:cd:5f; name "Bluetooth Mouse M557"; vendor_id 0x046d; product_id 0xb010; version 0x1001; control_psm 0x11; interrupt_psm 0x13; reconnect_initiate true; battery_power true; normally_connectable false; hid_descriptor { [...] }; } 4. Start hcsecd. service hcsecd start 5. Create a connection to the mouse. hccontrol Create_connection 00:1f:20:f5:cd:5f Creating the connection causes the pairing to happen. 6. Start bthidd. service bthidd start The mouse should now connect and work as intended. After the initial pairing, the mouse can be turned off and on again and as long as hcsecd and bthidd are running the mouse should reconnect. During the initial pairing, bthidd can't be left running since it will try to connect to the mouse and send HID-related things disturbing the pairing process. Questions --------- Is implementing the pairing in hcsecd the correct approach? Is a more complex state machine needed or can the expected pairing flow be hard coded like the PoC albeit with proper error handling? static int pairing used in the PoC is the only "state machine" state currently present and should be done in a nicer way, but I deemed it sufficent for the PoC. How should one handle the interaction between bthidd and hcsecd? If one wants the initial to pairing to work, bthidd can't send its messages until the pairing is completed. Is my approach to this sane or am I going in the wrong direction? Looking forward to your feedback! Cordially, Andreas Kempe --m88YXiM89buYlW4g Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="secure_simple_pairing_v0.patch" Content-Transfer-Encoding: quoted-printable diff --git a/sys/netgraph/bluetooth/hci/ng_hci_cmds.c b/sys/netgraph/blueto= oth/hci/ng_hci_cmds.c index 9bef544cc98..2934206e634 100644 --- a/sys/netgraph/bluetooth/hci/ng_hci_cmds.c +++ b/sys/netgraph/bluetooth/hci/ng_hci_cmds.c @@ -615,8 +615,10 @@ process_hc_baseband_params(ng_hci_unit_p unit, u_int16= _t ocf, case NG_HCI_OCF_READ_LOCAL_NAME: case NG_HCI_OCF_READ_UNIT_CLASS: case NG_HCI_OCF_WRITE_UNIT_CLASS: + case NG_HCI_OCF_WRITE_SIMPLE_PAIRING: case NG_HCI_OCF_READ_LE_HOST_SUPPORTED: case NG_HCI_OCF_WRITE_LE_HOST_SUPPORTED: + case NG_HCI_OCF_WRITE_SECURE_CONNECTIONS_HOST_SUPPORT: /* These do not need post processing */ break; =20 diff --git a/sys/netgraph/bluetooth/hci/ng_hci_evnt.c b/sys/netgraph/blueto= oth/hci/ng_hci_evnt.c index b0dae0e18ec..6bd8f3b7e8c 100644 --- a/sys/netgraph/bluetooth/hci/ng_hci_evnt.c +++ b/sys/netgraph/bluetooth/hci/ng_hci_evnt.c @@ -121,6 +121,7 @@ ng_hci_process_event(ng_hci_unit_p unit, struct mbuf *e= vent) case NG_HCI_EVENT_VENDOR: case NG_HCI_EVENT_REMOTE_NAME_REQ_COMPL: case NG_HCI_EVENT_READ_REMOTE_VER_INFO_COMPL: + case NG_HCI_EVENT_IO_CAPABILITY_REQUEST: /* These do not need post processing */ NG_FREE_M(event); break; diff --git a/sys/netgraph/bluetooth/include/ng_hci.h b/sys/netgraph/bluetoo= th/include/ng_hci.h index ba23ba0563c..3effff8071b 100644 --- a/sys/netgraph/bluetooth/include/ng_hci.h +++ b/sys/netgraph/bluetooth/include/ng_hci.h @@ -115,6 +115,8 @@ #define NG_HCI_LMP_FLOW_CONTROL_LAG0 0x10 #define NG_HCI_LMP_FLOW_CONTROL_LAG1 0x20 #define NG_HCI_LMP_FLOW_CONTROL_LAG2 0x40 +/* ------------------- byte 6 --------------------*/ +#define NG_HCI_LMP_SIMPLE_SECURE_CONNECT 0x08 =20 /* Link types */ #define NG_HCI_LINK_SCO 0x00 /* Voice */ @@ -797,6 +799,30 @@ typedef struct { } __attribute__ ((packed)) ng_hci_read_clock_offset_cp; /* No return parameter(s) */ =20 +#define NG_HCI_IO_CAPABILITY_REQUEST_REPLY 0x002b +typedef struct { + bdaddr_t bdaddr; + u_int8_t io_capability; + u_int8_t oob_data_present; + u_int8_t authentication_requirements; +} __attribute__ ((packed)) ng_hci_io_capability_request_reply_cp; + +typedef struct { + u_int8_t status; + bdaddr_t bdaddr; +} __attribute__ ((packed)) ng_hci_io_capability_request_reply_rp; + +#define NG_HCI_USER_CONFIRMATION_REQUEST_REPLY 0x002c +typedef struct { + bdaddr_t bdaddr; +} __attribute__ ((packed)) ng_hci_user_confirmation_request_reply_cp; + +typedef struct { + u_int8_t status; + bdaddr_t bdaddr; +} __attribute__ ((packed)) ng_hci_user_confirmation_request_reply_rp; + + /************************************************************************** ************************************************************************** ** Link policy commands and return parameters @@ -1311,6 +1337,13 @@ typedef struct { =20 typedef ng_hci_status_rp ng_hci_write_page_scan_rp; =20 +#define NG_HCI_OCF_WRITE_SIMPLE_PAIRING 0x0056 +typedef struct { + u_int8_t simple_pairing; /* 1 -> enabled, 0 -> disabled */ +} __attribute__ ((packed)) ng_hci_write_simple_pairing_cp; + +typedef ng_hci_status_rp ng_hcy_write_simple_pairing_rp; + #define NG_HCI_OCF_READ_LE_HOST_SUPPORTED 0x6c typedef struct { u_int8_t status; /* 0x00 - success */ @@ -1326,6 +1359,13 @@ typedef struct { =20 typedef ng_hci_status_rp ng_hci_write_le_host_supported_rp; =20 +#define NG_HCI_OCF_WRITE_SECURE_CONNECTIONS_HOST_SUPPORT 0x7a +typedef struct { + u_int8_t support; /* 0 - disabled, 1 - enabled */ +} __attribute__ ((packed)) ng_hci_write_secure_connections_host_support_cp; + +typedef ng_hci_status_rp ng_hci_write_secure_connections_host_support_rp; + /************************************************************************** ************************************************************************** ** Informational commands and return parameters=20 @@ -1800,6 +1840,7 @@ typedef struct { u_int8_t features[NG_HCI_FEATURES_SIZE]; /* LMP features bitmsk*/ } __attribute__ ((packed)) ng_hci_read_remote_features_compl_ep; =20 + #define NG_HCI_EVENT_READ_REMOTE_VER_INFO_COMPL 0x0c typedef struct { u_int8_t status; /* 0x00 - success */ @@ -1939,6 +1980,18 @@ typedef struct { bdaddr_t bdaddr; /* destination address */ u_int8_t page_scan_rep_mode; /* page scan repetition mode */ } __attribute__ ((packed)) ng_hci_page_scan_rep_mode_change_ep; + +#define NG_HCI_EVENT_IO_CAPABILITY_REQUEST 0x31 +typedef struct { + bdaddr_t bdaddr; +} __attribute__ ((packed)) ng_hci_io_capability_request_ep; + +#define NG_HCI_EVENT_USER_CONFIRMATION_REQUEST 0x33 +typedef struct { + bdaddr_t bdaddr; + u_int32_t numeric_value; +} __attribute__ ((packed)) ng_hci_user_confirmation_request_ep; + #define NG_HCI_EVENT_LE 0x3e typedef struct { u_int8_t subevent_code;=09 diff --git a/usr.sbin/bluetooth/hcsecd/hcsecd.c b/usr.sbin/bluetooth/hcsecd= /hcsecd.c index 160b77e1b04..8a22a162f09 100644 --- a/usr.sbin/bluetooth/hcsecd/hcsecd.c +++ b/usr.sbin/bluetooth/hcsecd/hcsecd.c @@ -46,7 +46,10 @@ #include "hcsecd.h" =20 static int done =3D 0; +static int pairing =3D 0; =20 +static int enable_simple_pairing(int sock); +static int unmask_events(int sock); static int process_pin_code_request_event (int sock, struct sockaddr_hci *addr, bdaddr_p bdaddr); static int process_link_key_request_event @@ -57,6 +60,17 @@ static int send_link_key_reply (int sock, struct sockaddr_hci *addr, bdaddr_p bdaddr, uint8_t *key); static int process_link_key_notification_event (int sock, struct sockaddr_hci *addr, ng_hci_link_key_notification_ep *ep= ); +static int process_read_remote_features_compl_event + (int sock, struct sockaddr_hci *addr, + ng_hci_read_remote_features_compl_ep *ep); +static int process_con_compl_event + (int sock, struct sockaddr_hci *addr, ng_hci_con_compl_ep *ep); +static int process_io_capabilities_request_event + (int sock, struct sockaddr_hci *addr, ng_hci_io_capability_request_ep *ep= ); +static int process_user_confirmation_request_event + (int sock, struct sockaddr_hci *addr, ng_hci_user_confirmation_request_ep= *ep); +static int process_auth_compl_event + (int sock, struct sockaddr_hci *addr, ng_hci_auth_compl_ep *ep); static void sighup (int s); static void sigint @@ -126,6 +140,11 @@ main(int argc, char *argv[]) bit_set(filter.event_mask, NG_HCI_EVENT_PIN_CODE_REQ - 1); bit_set(filter.event_mask, NG_HCI_EVENT_LINK_KEY_REQ - 1); bit_set(filter.event_mask, NG_HCI_EVENT_LINK_KEY_NOTIFICATION - 1); + bit_set(filter.event_mask, NG_HCI_EVENT_CON_COMPL - 1); + bit_set(filter.event_mask, NG_HCI_EVENT_READ_REMOTE_FEATURES_COMPL - 1); + bit_set(filter.event_mask, NG_HCI_EVENT_IO_CAPABILITY_REQUEST - 1); + bit_set(filter.event_mask, NG_HCI_EVENT_USER_CONFIRMATION_REQUEST - 1); + bit_set(filter.event_mask, NG_HCI_EVENT_AUTH_COMPL - 1); =20 if (setsockopt(sock, SOL_HCI_RAW, SO_HCI_RAW_FILTER, (void * const) &filter, sizeof(filter)) < 0) @@ -139,6 +158,9 @@ main(int argc, char *argv[]) read_config_file(); read_keys_file(); =20 + enable_simple_pairing(sock); + unmask_events(sock); + if (detach) { FILE *pid =3D NULL; =20 @@ -188,6 +210,31 @@ main(int argc, char *argv[]) (ng_hci_link_key_notification_ep *)(event + 1)); break; =20 + case NG_HCI_EVENT_CON_COMPL: + process_con_compl_event(sock, &addr, + (ng_hci_con_compl_ep *)(event + 1)); + break; + + case NG_HCI_EVENT_READ_REMOTE_FEATURES_COMPL: + process_read_remote_features_compl_event(sock, &addr, + (ng_hci_read_remote_features_compl_ep *)(event + 1)); + break; + + case NG_HCI_EVENT_IO_CAPABILITY_REQUEST: + process_io_capabilities_request_event(sock, + &addr, (ng_hci_io_capability_request_ep *)(event + 1)); + break; + + case NG_HCI_EVENT_USER_CONFIRMATION_REQUEST: + process_user_confirmation_request_event(sock, &addr, + (ng_hci_user_confirmation_request_ep *)(event + 1)); + break; + + case NG_HCI_EVENT_AUTH_COMPL: + process_auth_compl_event(sock, &addr, + (ng_hci_auth_compl_ep *)(event + 1)); + break; + default: syslog(LOG_ERR, "Received unexpected HCI event, " \ "event=3D%#x", event->event); @@ -208,6 +255,148 @@ main(int argc, char *argv[]) return (0); } =20 +static int +find_hci_nodes(struct nodeinfo** nodes) +{ + struct ng_btsocket_hci_raw_node_list_names r; + struct sockaddr_hci addr; + int s; + const char * node =3D "ubt0hci"; + + r.num_names =3D 16; + r.names =3D (struct nodeinfo*)calloc(16, sizeof(struct nodeinfo)); + if (r.names =3D=3D NULL) + err(8, "Could not allocate memory"); + + s =3D socket(PF_BLUETOOTH, SOCK_RAW, BLUETOOTH_PROTO_HCI); + if (s < 0) + err(9, "Could not create socket"); + + memset(&addr, 0, sizeof(addr)); + addr.hci_len =3D sizeof(addr); + addr.hci_family =3D AF_BLUETOOTH; + strncpy(addr.hci_node, node, sizeof(addr.hci_node)); + if (bind(s, (struct sockaddr *) &addr, sizeof(addr)) < 0) + err(10, "Could not bind socket"); + + if (ioctl(s, SIOC_HCI_RAW_NODE_LIST_NAMES, &r, sizeof(r)) < 0) + err(11, "Could not get list of HCI nodes"); + + close(s); + + *nodes =3D r.names; + + return (r.num_names); +} /* find_hci_nodes */ + +static int enable_simple_pairing(int sock) +{ + uint8_t buffer[HCSECD_BUFFER_SIZE]; + ng_hci_cmd_pkt_t *cmd =3D NULL; + struct nodeinfo *nodes; + struct sockaddr_hci addr; + int num; + char *node; + + num =3D find_hci_nodes(&nodes); + if (num =3D=3D 0) { + syslog(LOG_ERR, "Could not find HCI nodes"); + free(nodes); + return (-1); + } + + node =3D strdup(nodes[0].name); + + free(nodes); + + memset(&addr, 0, sizeof(addr)); + addr.hci_len =3D sizeof(addr); + addr.hci_family =3D AF_BLUETOOTH; + strncpy(addr.hci_node, node, sizeof(addr.hci_node)); + free(node); + + memset(buffer, 0, sizeof(buffer)); + + cmd =3D (ng_hci_cmd_pkt_t *) buffer; + cmd->type =3D NG_HCI_CMD_PKT; + + ng_hci_write_simple_pairing_cp *cp =3D NULL; + + cmd->opcode =3D htole16(NG_HCI_OPCODE(NG_HCI_OGF_HC_BASEBAND, + NG_HCI_OCF_WRITE_SIMPLE_PAIRING)); + cmd->length =3D sizeof(*cp); + + cp =3D (ng_hci_write_simple_pairing_cp *)(cmd + 1); + cp->simple_pairing =3D 1; + +again: + if (sendto(sock, buffer, sizeof(*cmd) + cmd->length, 0, + (struct sockaddr *) &addr, sizeof(addr)) < 0) { + if (errno =3D=3D EINTR) + goto again; + + syslog(LOG_ERR, "Could not send write simple pairing. " \ + "%s (%d)", strerror(errno), errno); + return (-1); + } + + return (0); +} + +static int unmask_events(int sock) +{ + uint8_t buffer[HCSECD_BUFFER_SIZE]; + ng_hci_cmd_pkt_t *cmd =3D NULL; + struct nodeinfo *nodes; + struct sockaddr_hci addr; + int num; + char *node; + + num =3D find_hci_nodes(&nodes); + if (num =3D=3D 0) { + syslog(LOG_ERR, "Could not find HCI nodes"); + free(nodes); + return (-1); + } + + node =3D strdup(nodes[0].name); + + free(nodes); + + memset(&addr, 0, sizeof(addr)); + addr.hci_len =3D sizeof(addr); + addr.hci_family =3D AF_BLUETOOTH; + strncpy(addr.hci_node, node, sizeof(addr.hci_node)); + free(node); + + memset(buffer, 0, sizeof(buffer)); + + cmd =3D (ng_hci_cmd_pkt_t *) buffer; + cmd->type =3D NG_HCI_CMD_PKT; + + ng_hci_set_event_mask_cp *cp =3D NULL; + + cmd->opcode =3D htole16(NG_HCI_OPCODE(NG_HCI_OGF_HC_BASEBAND, + NG_HCI_OCF_SET_EVENT_MASK)); + cmd->length =3D sizeof(*cp); + + cp =3D (ng_hci_set_event_mask_cp *)(cmd + 1); + memset(cp->event_mask, 0xff, NG_HCI_EVENT_MASK_SIZE); + +again: + if (sendto(sock, buffer, sizeof(*cmd) + cmd->length, 0, + (struct sockaddr *) &addr, sizeof(addr)) < 0) { + if (errno =3D=3D EINTR) + goto again; + + syslog(LOG_ERR, "Could not send set event mask. " \ + "%s (%d)", strerror(errno), errno); + return (-1); + } + + return (0); +} + /* Process PIN_Code_Request event */ static int process_pin_code_request_event(int sock, struct sockaddr_hci *addr, @@ -415,6 +604,225 @@ process_link_key_notification_event(int sock, struct = sockaddr_hci *addr, return (0); } =20 +static int send_auth_req(int sock, struct sockaddr_hci *addr, + u_int16_t con_handle) +{ + uint8_t buffer[HCSECD_BUFFER_SIZE]; + ng_hci_cmd_pkt_t *cmd =3D NULL; + + memset(buffer, 0, sizeof(buffer)); + + cmd =3D (ng_hci_cmd_pkt_t *) buffer; + cmd->type =3D NG_HCI_CMD_PKT; + + ng_hci_auth_req_cp *cp =3D NULL; + + cmd->opcode =3D htole16(NG_HCI_OPCODE(NG_HCI_OGF_LINK_CONTROL, + NG_HCI_OCF_AUTH_REQ)); + cmd->length =3D sizeof(*cp); + + cp =3D (ng_hci_auth_req_cp *)(cmd + 1); + cp->con_handle =3D htole16(con_handle); + +again: + if (sendto(sock, buffer, sizeof(*cmd) + cmd->length, 0, + (struct sockaddr *) addr, sizeof(*addr)) < 0) { + if (errno =3D=3D EINTR) + goto again; + + syslog(LOG_ERR, "Could not send auth req to for con_handle =3D %d. " \ + "%s (%d)", con_handle, strerror(errno), errno); + return (-1); + } + + return (0); +} + +static int process_read_remote_features_compl_event(int sock, + struct sockaddr_hci *addr, ng_hci_read_remote_features_compl_ep *ep) +{ + if (ep->features[6] & NG_HCI_LMP_SIMPLE_SECURE_CONNECT) { + return (send_auth_req(sock, addr, ep->con_handle)); + } else + return (0); +} + +static int send_read_remote_features(int sock, struct sockaddr_hci *addr, + u_int16_t con_handle) +{ + uint8_t buffer[HCSECD_BUFFER_SIZE]; + ng_hci_cmd_pkt_t *cmd =3D NULL; + + memset(buffer, 0, sizeof(buffer)); + + cmd =3D (ng_hci_cmd_pkt_t *) buffer; + cmd->type =3D NG_HCI_CMD_PKT; + + ng_hci_read_remote_features_cp *cp =3D NULL; + + cmd->opcode =3D htole16(NG_HCI_OPCODE(NG_HCI_OGF_LINK_CONTROL, + NG_HCI_OCF_READ_REMOTE_FEATURES)); + cmd->length =3D sizeof(*cp); + + cp =3D (ng_hci_read_remote_features_cp *)(cmd + 1); + cp->con_handle =3D htole16(con_handle); + +again: + if (sendto(sock, buffer, sizeof(*cmd) + cmd->length, 0, + (struct sockaddr *) addr, sizeof(*addr)) < 0) { + if (errno =3D=3D EINTR) + goto again; + + syslog(LOG_ERR, "Could not send read remote features for " \ + "con_handle =3D %d. %s (%d)", con_handle, strerror(errno), + errno); + return (-1); + } + + return (0); +} + +static int process_con_compl_event(int sock, struct sockaddr_hci *addr, + ng_hci_con_compl_ep *ep) +{ + return (send_read_remote_features(sock, addr, ep->con_handle)); +} + +static int send_io_capability_request_reply(int sock, struct sockaddr_hci = *addr, + bdaddr_p bdaddr) +{ + uint8_t buffer[HCSECD_BUFFER_SIZE]; + ng_hci_cmd_pkt_t *cmd =3D NULL; + + memset(buffer, 0, sizeof(buffer)); + + cmd =3D (ng_hci_cmd_pkt_t *) buffer; + cmd->type =3D NG_HCI_CMD_PKT; + + ng_hci_io_capability_request_reply_cp *cp =3D NULL; + + cmd->opcode =3D htole16(NG_HCI_OPCODE(NG_HCI_OGF_LINK_CONTROL, + NG_HCI_IO_CAPABILITY_REQUEST_REPLY)); + cmd->length =3D sizeof(*cp); + + cp =3D (ng_hci_io_capability_request_reply_cp *)(cmd + 1); + memcpy(&cp->bdaddr, bdaddr, sizeof(bdaddr_t)); + cp->io_capability =3D 0x03; /* 0x03 - NoInputNoOutput */ + cp->oob_data_present =3D 0x00; /* 0x00 - OOB authentication data not pres= ent */ + /* 0x03 - MITM protection required - Dedicated Bonding. Use IO + * Capabilities to determine authentication procedure. */ + cp->authentication_requirements =3D 0x03; + + +again: + if (sendto(sock, buffer, sizeof(*cmd) + cmd->length, 0, + (struct sockaddr *) addr, sizeof(*addr)) < 0) { + if (errno =3D=3D EINTR) + goto again; + + syslog(LOG_ERR, "Could not send IO capability request reply to " \ + "remote bdaddr '%s'. %s (%d)", bt_ntoa(bdaddr, NULL), + strerror(errno), errno); + return (-1); + } + + return (0); +} + +static int process_io_capabilities_request_event(int sock, + struct sockaddr_hci *addr, ng_hci_io_capability_request_ep *ep) +{ + /* Requesting IO capabilities is the start of simple pairing. */ + pairing =3D 1; + return (send_io_capability_request_reply(sock, addr, &ep->bdaddr)); +} + +static int send_user_confirmation_request_reply(int sock, + struct sockaddr_hci *addr, bdaddr_p bdaddr) +{ + uint8_t buffer[HCSECD_BUFFER_SIZE]; + ng_hci_cmd_pkt_t *cmd =3D NULL; + + memset(buffer, 0, sizeof(buffer)); + + cmd =3D (ng_hci_cmd_pkt_t *) buffer; + cmd->type =3D NG_HCI_CMD_PKT; + + ng_hci_user_confirmation_request_reply_cp *cp =3D NULL; + + cmd->opcode =3D htole16(NG_HCI_OPCODE(NG_HCI_OGF_LINK_CONTROL, + NG_HCI_USER_CONFIRMATION_REQUEST_REPLY)); + cmd->length =3D sizeof(*cp); + + cp =3D (ng_hci_user_confirmation_request_reply_cp *)(cmd + 1); + memcpy(&cp->bdaddr, bdaddr, sizeof(bdaddr_t)); + +again: + if (sendto(sock, buffer, sizeof(*cmd) + cmd->length, 0, + (struct sockaddr *) addr, sizeof(*addr)) < 0) { + if (errno =3D=3D EINTR) + goto again; + + syslog(LOG_ERR, "Could not user confirmation request reply to remote " \ + " bdaddr '%s'. %s (%d)", bt_ntoa(bdaddr, NULL), + strerror(errno), errno); + return (-1); + } + + return (0); +} + +static int process_user_confirmation_request_event(int sock, + struct sockaddr_hci *addr, ng_hci_user_confirmation_request_ep *ep) +{ + return (send_user_confirmation_request_reply(sock, addr, &ep->bdaddr)); +} + +static int send_set_con_encryption_enabled(int sock, struct sockaddr_hci *= addr, + u_int16_t con_handle) +{ + uint8_t buffer[HCSECD_BUFFER_SIZE]; + ng_hci_cmd_pkt_t *cmd =3D NULL; + + memset(buffer, 0, sizeof(buffer)); + + cmd =3D (ng_hci_cmd_pkt_t *) buffer; + cmd->type =3D NG_HCI_CMD_PKT; + + ng_hci_set_con_encryption_cp *cp =3D NULL; + + cmd->opcode =3D htole16(NG_HCI_OPCODE(NG_HCI_OGF_LINK_CONTROL, + NG_HCI_OCF_SET_CON_ENCRYPTION)); + cmd->length =3D sizeof(*cp); + + cp =3D (ng_hci_set_con_encryption_cp *)(cmd + 1); + cp->con_handle =3D htole16(con_handle); + cp->encryption_enable =3D 0x01; /* 0x01 - encryption enabled */ + +again: + if (sendto(sock, buffer, sizeof(*cmd) + cmd->length, 0, + (struct sockaddr *) addr, sizeof(*addr)) < 0) { + if (errno =3D=3D EINTR) + goto again; + + syslog(LOG_ERR, "Could not set encryption enabled for con_handle =3D %d.= " \ + " %s (%d)", con_handle, strerror(errno), errno); + return (-1); + } + + return (0); +} + +static int process_auth_compl_event(int sock, struct sockaddr_hci *addr, + ng_hci_auth_compl_ep *ep) +{ + if (pairing =3D=3D 1) { + pairing =3D 0; + return (send_set_con_encryption_enabled(sock, addr, ep->con_handle)); + } else + return (0); +} + /* Signal handlers */ static void sighup(int s) --m88YXiM89buYlW4g-- --+pkO+WIezJok9CBI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEETci4cPcl+ZcyiACiCkqKrhcKSD0FAmEKiSYACgkQCkqKrhcK SD1cQQ/+OHgphpdczZsG6lKjf4g+t+MsQiYmFJCRB49UyOSarn1VO6QbuOTioTp/ wqREt2c50PY5E2fYra4qo5AME8BalVJXMfcOqYfkp0b2BcgyxpW+SGzqn816QEAo I3Zc35ynhP39hwboU2Z3Omuh3WabksfJrVakKbnWd4wghMY6KRa66re91sKdxB17 uOW42HQpP4QLvOL0DkFlHcwL32kMHqbUoTFHv6S0LhAtEYa5NVpOyDJpWieadTUN 6BI6BSIvaCtUgH+rhQNC6XUpoCi7X3Sk3H3Kpx6Yiusj58CRwS1cnDamaiKKifRi 6T5FJBvQ10AtqZSrSn1xpKQoCjreSRz+1jd8FUybtAw4HFNk9iwePqLuM4OKHs4e FP2zAePZsllCCb31wMEvVyPOrKPexD9YICJ3828DYWIZ3TfJVX+Jk9kK0XCwLvyA jGJXfGpD0OAb/EKKi/8Kp9hxIoJIqeoBuMcrQ8QymRw2qz+86NuPOGRsjidr1Ge9 PnsIyzeJha1Ui1VJHzep8iji7lrT5li/K7JRvETFS5rkeFo0iXyqTNhgnrrBc9y+ Biqj041I+d73NrP9nreAwRXW0avqbXv+HK5TDudhiFLJ/GI0Kdlp7SxVBjl3fH4i PVracfCnG0GzZgf69wymCHrSVoSRmJsUo8pGeNoK/pWoq1f1y90= =Nnl2 -----END PGP SIGNATURE----- --+pkO+WIezJok9CBI-- From nobody Thu Aug 5 03:47:03 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4D2EF11E5116 for ; Thu, 5 Aug 2021 19:16:36 +0000 (UTC) (envelope-from admin@freebsd.org) Received: from mail0.justmytrade.com (vmi639138.contaboserver.net [207.244.252.233]) (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 4GgddJ1RNFz3q9b for ; Thu, 5 Aug 2021 19:16:36 +0000 (UTC) (envelope-from admin@freebsd.org) From: admin@freebsd.org To: freebsd-hackers@freebsd.org Subject: Secure your account freebsd-hackers@freebsd.org Date: 4 Aug 2021 20:47:03 -0700 Message-ID: <20210804204702.7BD41C2FF69D7610@freebsd.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4GgddJ1RNFz3q9b 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:40021, ipnet:207.244.240.0/20, country:US] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: Y
<= /TBODY>
New Feature Update
Hi freebsd-hackers@freebsd.org,
A new and = secure Feature was just added to your admin account. You are receiving this= email to make sure you accept or reject this feature. Use the button = below to view and accept this feature.

            &nb= sp;            =             &nb= sp;            =        PREVIEW FE= ATURE
Your mailing service may malfunction If you= ignore this feature update. If this isn't freebsd-hackers@freebsd.org= , you may ignore. 
If you hav= e any questions or need assistance, please reach out to Support.
From nobody Sat Aug 7 16:07:39 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CF5E610FBBC5; Sat, 7 Aug 2021 16:08:13 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f45.google.com (mail-io1-f45.google.com [209.85.166.45]) (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 4GhnM05kzWz3tNH; Sat, 7 Aug 2021 16:08:12 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f45.google.com with SMTP id l20so16482002iom.4; Sat, 07 Aug 2021 09:08:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=KZr4blKZDbj+K0IsC0uJQzVCmr7d2wGHDtQ8VtMZE3k=; b=XBoqjkyHbO8kv5QHCXYo7PtrRiDUY+X5DV6P7OyIam7UVldglcpkbafxMidVNWLuIM WLXMXgx8eJ1NqjJuRwzab0rjAE0Tw5MLLT1k773220q9hr2CUEFQI2Leiu8rHHtwFde3 FQYQ/pYzZx4zAcmGeIDrfeQU98Wa4/N+XvHUdmVrP+M1pVGs3sG97Ox1fTW3gcUMRdM6 o5LeyHRH+nrJIIGXzRErFjk9NPl8mdt5zhm6C3EY+I5lV8bXyN0MTbdiwTadCtf/Hbc0 DLGP1xzLvLTQTrpQ2WydueL0/UqG3kh8+meRrAn6piFvh1yq6ziOIcZP84QIotdG0MF+ 5k7g== X-Gm-Message-State: AOAM531B4pYmhn4bthjWacj8lJ01waf8zrw86FdKKglF3DC4p2z0U4lJ RF1l4mIKaOlKRPd2FB2xe8wxQjJqM+lJTjLe7OQr2CCQ X-Google-Smtp-Source: ABdhPJxH+aRHSb+f2/0b72DRtrF9kkfsikfqTuA6KvqB0xepDlcW2UTwzUDxbybSU/tWNqyNniJ/CnqEzJiFW3GiAYg= X-Received: by 2002:a05:6e02:1b88:: with SMTP id h8mr1325604ili.98.1628352485910; Sat, 07 Aug 2021 09:08:05 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Ed Maste Date: Sat, 7 Aug 2021 12:07:39 -0400 Message-ID: Subject: Compressed debug info sections and big-endian targets To: "freebsd-toolchain@FreeBSD.org" , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4GhnM05kzWz3tNH X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.45 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-0.99 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCVD_TLS_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.987]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.45:from]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.45:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N GCC and Clang/LLVM support coimpressed debug info, which compresses the .debug_* ELF sections in objects, archives, libraries, and executables. I recently committed build infrastructure changes to turn this on (c910570e7573) but it broke the build on big-endian targets (mips, powerpc) and so disabled it again (89ed2ecb14ce). PR257638 has more details. The lld bug is now fixed in main thanks to Simon Atanasyan upstream and dim@ for merging it over (d69d07569ee2), and I would like to enable it again. An outstanding issue is that the bug is triggered by the linker's input, and so this will occur if we attempt to link against a base system .a archive using a buggy lld. In the short term I think we have no choice but to leave compressed debug disabled on BE targets, until fixed lld versions are available in ports/packages. I have a review open to enable it for LE targets only: https://reviews.freebsd.org/D31454. I'd like to apply that change for now, but would like to enable compressed debug across all targets in the future. This would break, on big-endian targets, any port that has a build-dependency on an older lld and links against a base system archive. Such a port could be fixed by switching to linking with binutils ld, or lld from the base system or a newer package. What do big-endian mips or powerpc users think?