Re: svn commit: r368820 - head
On Mon, Dec 21, 2020 at 08:26:02AM -0600, Kyle Evans wrote: > On Mon, Dec 21, 2020 at 8:24 AM Rodney W. Grimes > wrote: > > > > > On Sun, 20 Dec 2020 15:46:12 +0100 > > > "Hartmann, O." wrote: > > > > > > > On Sun, 20 Dec 2020 02:59:44 + (UTC) > > > > Li-Wen Hsu wrote: > > > > > > > > > Author: lwhsu > > > > > Date: Sun Dec 20 02:59:44 2020 > > > > > New Revision: 368820 > > > > > URL: https://svnweb.freebsd.org/changeset/base/368820 > > > > > > > > > > Log: > > > > > Mark the repository as being converted to Git. > > > > > > > > > > This is the last Subversion commit to src. > > > > > > > > > > Sponsored by: The FreeBSD Foundation > > > > > > > > > > Modified: > > > > > head/README > > > > > head/README.md > > > > > > > > > > Modified: head/README > > > > > == > > > > > --- head/README Sat Dec 19 22:04:46 2020(r368819) > > > > > +++ head/README Sun Dec 20 02:59:44 2020(r368820) > > > > > @@ -1,3 +1,5 @@ > > > > > +This repository is being converted from Subversion to Git. > > > > > + > > > > > This is the top level of the FreeBSD source directory. This file > > > > > was last revised on: > > > > > $FreeBSD$ > > > > > > > > > > Modified: head/README.md > > > > > == > > > > > --- head/README.mdSat Dec 19 22:04:46 2020(r368819) > > > > > +++ head/README.mdSun Dec 20 02:59:44 2020(r368820) > > > > > @@ -1,3 +1,5 @@ > > > > > +This repository is being converted from Subversion to Git. > > > > > + > > > > > FreeBSD Source: > > > > > --- > > > > > This is the top level of the FreeBSD source directory. This file > > > > > ___ > > > > > svn-src-h...@freebsd.org mailing list > > > > > https://lists.freebsd.org/mailman/listinfo/svn-src-head > > > > > To unsubscribe, send any mail to > > > > > "svn-src-head-unsubscr...@freebsd.org" > > > > > > > > Is this message of yours also the last message concerning the source > > > > changes? Since then > > > > you published this message, no further logs ran into list > > > > svn-src-h...@freebsd.org. > > > > > > > > > > Take a look at this https://wiki.freebsd.org/git. Write access to > > > Subversion has been disabled. > > > > I think the bigger question is why as a committer have I not seen ANY > > commits to git since this cut over? Is it a) none have happened in 24 > > hours, > > or b) commit mail is no longer going to developers as it use to? > > > > According to the wiki, the repo conversion is not yet done so no > commits have been made. =) And for those who don't know, the wiki page to pay attention to is: https://wiki.freebsd.org/git Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: svn commit: r368163 - in head: sbin/ifconfig sys/dev/if_wg sys/dev/if_wg/include sys/dev/if_wg/include/crypto sys/dev/if_wg/include/sys sys/dev/if_wg/include/zinc sys/dev/if_wg/module sys/dev/if_w
On Sun, Nov 29, 2020 at 07:38:04PM +, Matt Macy wrote: > Author: mmacy > Date: Sun Nov 29 19:38:03 2020 > New Revision: 368163 > URL: https://svnweb.freebsd.org/changeset/base/368163 > > Log: > Import kernel WireGuard support > > Data path largely shared with the OpenBSD implementation by > Matt Dunwoodie > > Reviewed by:gre...@freebsd.org > MFC after: 1 month > Sponsored by: Rubicon LLC, (Netgate) > Differential Revision: https://reviews.freebsd.org/D26137 RELNOTES: yes? Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: svn commit: r368141 - in head/sys/arm: allwinner annapurna/alpine arm freescale/imx include mv versatile
On Sun, Nov 29, 2020 at 08:40:12AM +, Michal Meloun wrote: > Author: mmel > Date: Sun Nov 29 08:40:12 2020 > New Revision: 368141 > URL: https://svnweb.freebsd.org/changeset/base/368141 > > Log: > Remove the pre-ARMv6 and pre-INTRNG code. > ARM has required ARMV6+ and INTRNg for some time now, so remove > always false #ifdefs and unconditionally do always true #ifdefs. > > .sv_flags = > -#if __ARM_ARCH >= 6 > SV_ASLR | SV_SHP | SV_TIMEKEEP | SV_RNG_SEED_VER | > -#endif > SV_ABI_FREEBSD | SV_ILP32 | SV_ASLR, This causes SV_ASLR to be set twice. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: svn commit: r367692 - head/sys/sys
Are there any kernel modules (in base, in ports, or out-of-both-trees)
that access struct ucred?
On Sat, Nov 14, 2020 at 09:51:47PM +0100, Mateusz Guzik wrote:
> I don't think so, it does not change any APIs
>
> On 11/14/20, Shawn Webb wrote:
> > On Sat, Nov 14, 2020 at 07:20:37PM +, Mateusz Guzik wrote:
> >> Author: mjg
> >> Date: Sat Nov 14 19:20:37 2020
> >> New Revision: 367692
> >> URL: https://svnweb.freebsd.org/changeset/base/367692
> >>
> >> Log:
> >> cred: reorder cr_audit to be closer to the lock
> >>
> >> This makes cr_uid avoid sharing.
> >>
> >> Modified:
> >> head/sys/sys/ucred.h
> >>
> >> Modified: head/sys/sys/ucred.h
> >> ==
> >> --- head/sys/sys/ucred.h Sat Nov 14 19:19:27 2020(r367691)
> >> +++ head/sys/sys/ucred.h Sat Nov 14 19:20:37 2020(r367692)
> >> @@ -63,6 +63,7 @@ struct ucred {
> >>struct mtx cr_mtx;
> >>u_int cr_ref; /* (c) reference count */
> >>u_int cr_users; /* (c) proc + thread using this cred */
> >> + struct auditinfo_addr cr_audit; /* Audit properties. */
> >> #define cr_startcopy cr_uid
> >>uid_t cr_uid; /* effective user id */
> >>uid_t cr_ruid;/* real user id */
> >> @@ -78,7 +79,6 @@ struct ucred {
> >>void*cr_pspare2[2]; /* general use 2 */
> >> #define cr_endcopy cr_label
> >>struct label*cr_label; /* MAC label */
> >> - struct auditinfo_addr cr_audit; /* Audit properties. */
> >>gid_t *cr_groups; /* groups */
> >>int cr_agroups; /* Available groups */
> >>gid_t cr_smallgroups[XU_NGROUPS]; /* storage for small groups */
> >
> > Hey Mateusz,
> >
> > Since this changes KBI, does __FreeBSD_version need bumping?
> >
> > Thanks,
> >
> > --
> > Shawn Webb
> > Cofounder / Security Engineer
> > HardenedBSD
> >
> > GPG Key ID: 0xFF2E67A277F8E1FA
> > GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2
> > https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
> >
>
>
> --
> Mateusz Guzik
--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD
GPG Key ID: 0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2
https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
signature.asc
Description: PGP signature
Re: svn commit: r367692 - head/sys/sys
On Sat, Nov 14, 2020 at 07:20:37PM +, Mateusz Guzik wrote:
> Author: mjg
> Date: Sat Nov 14 19:20:37 2020
> New Revision: 367692
> URL: https://svnweb.freebsd.org/changeset/base/367692
>
> Log:
> cred: reorder cr_audit to be closer to the lock
>
> This makes cr_uid avoid sharing.
>
> Modified:
> head/sys/sys/ucred.h
>
> Modified: head/sys/sys/ucred.h
> ==
> --- head/sys/sys/ucred.h Sat Nov 14 19:19:27 2020(r367691)
> +++ head/sys/sys/ucred.h Sat Nov 14 19:20:37 2020(r367692)
> @@ -63,6 +63,7 @@ struct ucred {
> struct mtx cr_mtx;
> u_int cr_ref; /* (c) reference count */
> u_int cr_users; /* (c) proc + thread using this cred */
> + struct auditinfo_addr cr_audit; /* Audit properties. */
> #define cr_startcopy cr_uid
> uid_t cr_uid; /* effective user id */
> uid_t cr_ruid;/* real user id */
> @@ -78,7 +79,6 @@ struct ucred {
> void*cr_pspare2[2]; /* general use 2 */
> #define cr_endcopy cr_label
> struct label*cr_label; /* MAC label */
> - struct auditinfo_addr cr_audit; /* Audit properties. */
> gid_t *cr_groups; /* groups */
> int cr_agroups; /* Available groups */
> gid_t cr_smallgroups[XU_NGROUPS]; /* storage for small groups */
Hey Mateusz,
Since this changes KBI, does __FreeBSD_version need bumping?
Thanks,
--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD
GPG Key ID: 0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2
https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
signature.asc
Description: PGP signature
Re: svn commit: r367651 - head/usr.sbin/bhyve
On Fri, Nov 13, 2020 at 07:47:16PM +, Rebecca Cran wrote:
> Author: bcran
> Date: Fri Nov 13 19:47:16 2020
> New Revision: 367651
> URL: https://svnweb.freebsd.org/changeset/base/367651
>
> Log:
> bhyve: update smbiostbl.c to bump the version and release date
>
> Since lots of work has been done on bhyve since 2014, increase the version
> to 13.0 to match 13-CURRENT, and update the release date.
>
> Reviewed by:grehan
> Differential Revision: https://reviews.freebsd.org/D27147
>
> Modified:
> head/usr.sbin/bhyve/smbiostbl.c
>
> Modified: head/usr.sbin/bhyve/smbiostbl.c
> ==
> --- head/usr.sbin/bhyve/smbiostbl.c Fri Nov 13 19:22:53 2020
> (r367650)
> +++ head/usr.sbin/bhyve/smbiostbl.c Fri Nov 13 19:47:16 2020
> (r367651)
> @@ -51,6 +51,9 @@ __FBSDID("$FreeBSD$");
>
> #define SMBIOS_BASE 0xF1000
>
> +#define FIRMWARE_VERSION "13.0"
> +#define FIRMWARE_RELEASE_DATE "11/10/2020"
Style nit: shouldn't there be a tab between #define and the macro?
Thanks,
--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD
GPG Key ID: 0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2
https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
signature.asc
Description: PGP signature
Re: svn commit: r367577 - in head: share/mk sys/conf tools/build/options
On Tue, Nov 10, 2020 at 07:17:29PM +, Brooks Davis wrote: > On Tue, Nov 10, 2020 at 07:15:14PM +, Brooks Davis wrote: > > Author: brooks > > Date: Tue Nov 10 19:15:13 2020 > > New Revision: 367577 > > URL: https://svnweb.freebsd.org/changeset/base/367577 > > > > Log: > > Support initializing stack variables on function entry > > > > There are two options: > >- WITH_INIT_ALL_ZERO: Zero all variables on the stack. > >- WITH_INIT_ALL_PATTERN: Initialize variables with well-defined patterns. > > > > The exact pattern are a compiler implementation detail and vary by type. > > They are somewhat documented in the LLVM commit message: > > https://reviews.llvm.org/rL349442 > > I've used WITH_INIT_ALL_* to match Microsoft's InitAll feature rather > > than naming them after the LLVM specific compiler flags. > > > > In a range of consumer products, options like these are used in > > both debug and production builds with debugs builds using patterns > > (intended to provoke crashes on use of uninitialized values) and > > production using zeros (deemed more likely to lead to harmless > > misbehavior or NULL-pointer dereferences). > > We've tested this extensively in CheriBSD on RISC-V, in the wild it's > probably most tested on Arm64 and x86. > > Despite the silly compiler flag you'll spot in the code, the zeroing > option isn't going away in practice as Apple, Google, and Microsoft all > ship with this feature in some of their products. HardenedBSD's testing of this last year on amd64 have (privately) shown the feature to really hinder performance on more complex applications (like when applied to clang/lld). A build of base without init all zero applied to clang/lld would take around 1.5 hours on my system. A build with it applied to clang/lld took around four hours, if my memory serves correctly. I would probably advise against applying it system-wide. But YMMV. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: svn commit: r367304 - in head: share/man/man5 share/mk tools/build/options usr.bin usr.bin/clang usr.bin/clang/llvm-cxxfilt
On Wed, Nov 04, 2020 at 11:26:51AM -0500, Ed Maste wrote: > On Tue, 3 Nov 2020 at 14:57, Dimitry Andric wrote: > > > > Author: dim > > Date: Tue Nov 3 19:57:28 2020 > > New Revision: 367304 > > URL: https://svnweb.freebsd.org/changeset/base/367304 > > > > Log: > > Add WITH_LLVM_CXXFILT option to install llvm-cxxfilt as c++filt > > A previous argument against the LLVM versions of binutils replacements > is that they were excessively large, but this does not look like a > substantial problem here. LLVM's cxxfilt is indeed many times the size > of ELF Tool Chain's, but still small enough that for a tool chain > component it's not a concern, in my opinion. > > ELF Tool Chain: > $ size obj/c++filt >text databss dec hex filename > 66966 1008 8400 76374 0x12a56 obj/c++filt > > LLVM: > $ size obj/llvm-cxxfilt > text databss dec hex filename > 378138 1756 9165 389059 0x5efc3 obj/llvm-cxxfilt > > A remaining issue is that both nm and addr2line can also demangle C++ symbols. This brings a question: is there any guidance as to what FreeBSD considers "too large of a component" for a toolchain component (or any other various components, like src.git/stand)? I ask mostly out of curiousity. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: svn commit: r367114 - head/sys/netinet6
On Wed, Oct 28, 2020 at 08:22:21PM +, Alexander V. Chernikov wrote: > Author: melifaro > Date: Wed Oct 28 20:22:20 2020 > New Revision: 367114 > URL: https://svnweb.freebsd.org/changeset/base/367114 > > Log: > Fix use-after-free in icmp6_notify_error(). > > Reported by:Maxime Villard > Reviewed by:markj > MFC after: 3 days Does this need a CVE? Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: svn commit: r365984 - head/usr.bin/calendar/calendars
On Tue, Sep 22, 2020 at 09:18:43PM +0200, Gordon Bergling wrote: > On Tue, Sep 22, 2020 at 09:01:46PM +0300, Andriy Gapon wrote: > > On 22/09/2020 06:06, Conrad Meyer wrote: > > > Big ol plus one from me. > > > > > > On Mon, Sep 21, 2020 at 4:16 PM Cy Schubert > > > wrote: > > >> > > >> In message <202009212255.08lmtpsp078...@repo.freebsd.org>, Greg Lehey > > >> writes: > > >>> Author: grog > > >>> Date: Mon Sep 21 22:55:51 2020 > > >>> New Revision: 365984 > > >>> URL: https://svnweb.freebsd.org/changeset/base/365984 > > >>> > > >>> Log: > > >>> Remove claim that Allied Forces created "West Germany" in 1953. I can > > >>> find no historic substantiation for such a claim. The Federal > > >>> Republic of Germany was created by Germans on 23 May 1949, as also > > >>> noted in this file. > > >>> > > >>> Modified: > > >>> head/usr.bin/calendar/calendars/calendar.history > > >>> > > >>> Modified: head/usr.bin/calendar/calendars/calendar.history > > >>> = > > >>> = > > >>> --- head/usr.bin/calendar/calendars/calendar.history Mon Sep 21 > > >>> 22:52:57 202 > > >>> 0 (r365983) > > >>> +++ head/usr.bin/calendar/calendars/calendar.history Mon Sep 21 > > >>> 22:55:51 202 > > >>> 0 (r365984) > > >>> @@ -521,7 +521,6 @@ > > >>> 09/20Magellan leaves Spain on the first Round the World > > >>> passage, 151 > > >>> 9 > > >>> 09/20The Roxy Theater opens in Hollywood, 1973 > > >>> 09/21J. R. R. Tolkien's The Hobbit is published, 1937 > > >>> -09/22Allied forces form the independent nation West Germany, > > >>> 1953 > > >>> 09/22US President Lincoln issues the Emancipation > > >>> Proclamation, 1862 > > >>> 09/22Special prosecutor Leon Jeworski subpoenas US President > > >>> Nixon, > > >>> 1974 > > >>> 09/22The first Soviet atomic bomb explodes, 1949 > > >>> > > >> > > >> Does this file still need to be in FreeBSD? It may have been a novelty > > >> back > > >> in the day but IMO calendar.history has nothing to do with BSD, computers > > >> or anything else of interest to FreeBSD. At the very least this file > > >> should > > >> be moved to ports or better yet, removed entirely. I simply don't see the > > >> point of it being in the tree and distributed with an O/S, any O/S. > > > > I think that the only reason for this file's existence in the source tree > > is for > > Greg's staving off the commit bit reaper. > > No offense meant. > > > > P.S. > > And occasional flame wars, it seems. > > We already had a similar discussion in march 2020 after r358561 [1]. > > In the short, the calendar utility has it's historic place, even it's > just more a kind of tradition, like adding yourself as a FreeBSD committer > to calendar.freebsd. > > [1] https://lists.freebsd.org/pipermail/svn-src-all/2020-March/thread.html Would it make sense to prune calendar entries to only BSD-related entries? Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: svn commit: r364482 - head/lib/libc++
On Sat, Aug 22, 2020 at 04:17:33PM +0200, Dimitry Andric wrote: > On 22 Aug 2020, at 16:07, Shawn Webb wrote: > > > > On Sat, Aug 22, 2020 at 12:05:11PM +, Dimitry Andric wrote: > >> Author: dim > >> Date: Sat Aug 22 12:05:11 2020 > >> New Revision: 364482 > >> URL: https://svnweb.freebsd.org/changeset/base/364482 > >> > >> Log: > >> Add a few new source files to libc++, in particular the implementation > >> part of std::random_shuffle. These were split off at some point by > >> upstream, but I forgot to add them to our Makefile. > >> > >> This should allow some ports which use std::random_shuffle to correctly > >> link again. > >> > >> Reported by: thierry > >> PR: 248795 > >> MFC after:6 weeks > >> X-MFX-With: r364284 > >> > >> Modified: > >> head/lib/libc++/Makefile > >> > >> Modified: head/lib/libc++/Makefile > >> == > >> --- head/lib/libc++/Makefile Sat Aug 22 11:59:14 2020 > >> (r364481) > >> +++ head/lib/libc++/Makefile Sat Aug 22 12:05:11 2020 > >> (r364482) > >> @@ -16,6 +16,8 @@ SHLIB_LDSCRIPT= libc++.ldscript > >> > >> SRCS+= algorithm.cpp > >> SRCS+= any.cpp > >> +SRCS+=atomic.cpp > >> +SRCS+=barrier.cpp > >> SRCS+= bind.cpp > >> SRCS+= charconv.cpp > >> SRCS+= chrono.cpp > >> @@ -38,6 +40,7 @@ SRCS+= mutex_destructor.cpp > >> SRCS+= new.cpp > >> SRCS+= optional.cpp > >> SRCS+= random.cpp > >> +SRCS+=random_shuffle.cpp > >> SRCS+= regex.cpp > >> SRCS+= shared_mutex.cpp > >> SRCS+= stdexcept.cpp > > > > There's also these files: > > > > https://github.com/HardenedBSD/hardenedBSD/commit/9410e679cc7888311f6efaf251f8d9a311c5b19d > > We intentionally don't build a number of the lldb plugins, so these > should not be needed. Did you get build failures otherwise? We did, likely because we use more llvm tools than our upstream FreeBSD. We set WITH_CLANG_EXTRAS by default. We also use CFI and SafeStack. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: svn commit: r364482 - head/lib/libc++
On Sat, Aug 22, 2020 at 12:05:11PM +, Dimitry Andric wrote: > Author: dim > Date: Sat Aug 22 12:05:11 2020 > New Revision: 364482 > URL: https://svnweb.freebsd.org/changeset/base/364482 > > Log: > Add a few new source files to libc++, in particular the implementation > part of std::random_shuffle. These were split off at some point by > upstream, but I forgot to add them to our Makefile. > > This should allow some ports which use std::random_shuffle to correctly > link again. > > Reported by:thierry > PR: 248795 > MFC after: 6 weeks > X-MFX-With: r364284 > > Modified: > head/lib/libc++/Makefile > > Modified: head/lib/libc++/Makefile > == > --- head/lib/libc++/Makefile Sat Aug 22 11:59:14 2020(r364481) > +++ head/lib/libc++/Makefile Sat Aug 22 12:05:11 2020(r364482) > @@ -16,6 +16,8 @@ SHLIB_LDSCRIPT= libc++.ldscript > > SRCS+= algorithm.cpp > SRCS+= any.cpp > +SRCS+= atomic.cpp > +SRCS+= barrier.cpp > SRCS+= bind.cpp > SRCS+= charconv.cpp > SRCS+= chrono.cpp > @@ -38,6 +40,7 @@ SRCS+= mutex_destructor.cpp > SRCS+= new.cpp > SRCS+= optional.cpp > SRCS+= random.cpp > +SRCS+= random_shuffle.cpp > SRCS+= regex.cpp > SRCS+= shared_mutex.cpp > SRCS+= stdexcept.cpp There's also these files: https://github.com/HardenedBSD/hardenedBSD/commit/9410e679cc7888311f6efaf251f8d9a311c5b19d Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: svn commit: r364402 - head/sys/kern
On Wed, Aug 19, 2020 at 11:51:10AM -0600, Warner Losh wrote:
> On Wed, Aug 19, 2020 at 11:48 AM Shawn Webb
> wrote:
>
> > On Wed, Aug 19, 2020 at 11:44:42AM -0600, Warner Losh wrote:
> > > On Wed, Aug 19, 2020 at 11:26 AM Shawn Webb
> > > wrote:
> > >
> > > > On Wed, Aug 19, 2020 at 05:10:05PM +, Warner Losh wrote:
> > > > > Author: imp
> > > > > Date: Wed Aug 19 17:10:04 2020
> > > > > New Revision: 364402
> > > > > URL: https://svnweb.freebsd.org/changeset/base/364402
> > > > >
> > > > > Log:
> > > > > Add VFS FS events for mount and unmount to devctl/devd
> > > > >
> > > > > Report when a filesystem is mounted, remounted or unmounted via
> > devd,
> > > > along with
> > > > > details about the mount point and mount options.
> > > > >
> > > > > Discussed with: kib@
> > > > > Reviewed by: kirk@ (prior version)
> > > > > Sponsored by: Netflix
> > > > > Diffential Revision: https://reviews.freebsd.org/D25969
> > > > >
> > > > > Modified:
> > > > > head/sys/kern/vfs_mount.c
> > > > >
> > > > > Modified: head/sys/kern/vfs_mount.c
> > > > >
> > > >
> > ==
> > > > > --- head/sys/kern/vfs_mount.c Wed Aug 19 17:09:58 2020
> > (r364401)
> > > > > +++ head/sys/kern/vfs_mount.c Wed Aug 19 17:10:04 2020
> > (r364402)
> > > > > @@ -42,6 +42,7 @@ __FBSDID("$FreeBSD$");
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > +#include
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > @@ -101,6 +102,8 @@ MTX_SYSINIT(mountlist, _mtx,
> > "mountlist",
> > > > MT
> > > > > EVENTHANDLER_LIST_DEFINE(vfs_mounted);
> > > > > EVENTHANDLER_LIST_DEFINE(vfs_unmounted);
> > > > >
> > > > > +static void dev_vfs_event(const char *type, struct mount *mp, bool
> > > > donew);
> > > > > +
> > > > > /*
> > > > > * Global opts, taken by all filesystems
> > > > > */
> > > > > @@ -1020,6 +1023,7 @@ vfs_domount_first(
> > > > > VOP_UNLOCK(vp);
> > > > > EVENTHANDLER_DIRECT_INVOKE(vfs_mounted, mp, newdp, td);
> > > > > VOP_UNLOCK(newdp);
> > > > > + dev_vfs_event("MOUNT", mp, false);
> > > > > mountcheckdirs(vp, newdp);
> > > > > vn_seqc_write_end(vp);
> > > > > vn_seqc_write_end(newdp);
> > > > > @@ -1221,6 +1225,7 @@ vfs_domount_update(
> > > > > if (error != 0)
> > > > > goto end;
> > > > >
> > > > > + dev_vfs_event("REMOUNT", mp, true);
> > > > > if (mp->mnt_opt != NULL)
> > > > > vfs_freeopts(mp->mnt_opt);
> > > > > mp->mnt_opt = mp->mnt_optnew;
> > > > > @@ -1839,6 +1844,7 @@ dounmount(struct mount *mp, int flags, struct
> > > > thread *
> > > > > TAILQ_REMOVE(, mp, mnt_list);
> > > > > mtx_unlock(_mtx);
> > > > > EVENTHANDLER_DIRECT_INVOKE(vfs_unmounted, mp, td);
> > > > > + dev_vfs_event("UNMOUNT", mp, false);
> > > > > if (coveredvp != NULL) {
> > > > > coveredvp->v_mountedhere = NULL;
> > > > > vn_seqc_write_end(coveredvp);
> > > > > @@ -2425,4 +2431,72 @@ kernel_vmount(int flags, ...)
> > > > >
> > > > > error = kernel_mount(ma, flags);
> > > > > return (error);
> > > > > +}
> > > > > +
> > > > > +/* Map from mount options to printable formats. */
> > > > > +static struct mntoptnames optnames[] = {
> > > > > + MNTOPT_NAMES
> > > > > +};
> > > > > +
> > > > > +static void
> > > > > +dev_vfs_event_mntopt(struct sbuf *sb, const char *what, struct
> > > > vfsoptlist *opts)
> > > > > +{
> > > > > + struct vfsopt *opt;
> > > >
Re: svn commit: r364402 - head/sys/kern
On Wed, Aug 19, 2020 at 11:44:42AM -0600, Warner Losh wrote:
> On Wed, Aug 19, 2020 at 11:26 AM Shawn Webb
> wrote:
>
> > On Wed, Aug 19, 2020 at 05:10:05PM +, Warner Losh wrote:
> > > Author: imp
> > > Date: Wed Aug 19 17:10:04 2020
> > > New Revision: 364402
> > > URL: https://svnweb.freebsd.org/changeset/base/364402
> > >
> > > Log:
> > > Add VFS FS events for mount and unmount to devctl/devd
> > >
> > > Report when a filesystem is mounted, remounted or unmounted via devd,
> > along with
> > > details about the mount point and mount options.
> > >
> > > Discussed with: kib@
> > > Reviewed by: kirk@ (prior version)
> > > Sponsored by: Netflix
> > > Diffential Revision: https://reviews.freebsd.org/D25969
> > >
> > > Modified:
> > > head/sys/kern/vfs_mount.c
> > >
> > > Modified: head/sys/kern/vfs_mount.c
> > >
> > ==
> > > --- head/sys/kern/vfs_mount.c Wed Aug 19 17:09:58 2020(r364401)
> > > +++ head/sys/kern/vfs_mount.c Wed Aug 19 17:10:04 2020(r364402)
> > > @@ -42,6 +42,7 @@ __FBSDID("$FreeBSD$");
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -101,6 +102,8 @@ MTX_SYSINIT(mountlist, _mtx, "mountlist",
> > MT
> > > EVENTHANDLER_LIST_DEFINE(vfs_mounted);
> > > EVENTHANDLER_LIST_DEFINE(vfs_unmounted);
> > >
> > > +static void dev_vfs_event(const char *type, struct mount *mp, bool
> > donew);
> > > +
> > > /*
> > > * Global opts, taken by all filesystems
> > > */
> > > @@ -1020,6 +1023,7 @@ vfs_domount_first(
> > > VOP_UNLOCK(vp);
> > > EVENTHANDLER_DIRECT_INVOKE(vfs_mounted, mp, newdp, td);
> > > VOP_UNLOCK(newdp);
> > > + dev_vfs_event("MOUNT", mp, false);
> > > mountcheckdirs(vp, newdp);
> > > vn_seqc_write_end(vp);
> > > vn_seqc_write_end(newdp);
> > > @@ -1221,6 +1225,7 @@ vfs_domount_update(
> > > if (error != 0)
> > > goto end;
> > >
> > > + dev_vfs_event("REMOUNT", mp, true);
> > > if (mp->mnt_opt != NULL)
> > > vfs_freeopts(mp->mnt_opt);
> > > mp->mnt_opt = mp->mnt_optnew;
> > > @@ -1839,6 +1844,7 @@ dounmount(struct mount *mp, int flags, struct
> > thread *
> > > TAILQ_REMOVE(, mp, mnt_list);
> > > mtx_unlock(_mtx);
> > > EVENTHANDLER_DIRECT_INVOKE(vfs_unmounted, mp, td);
> > > + dev_vfs_event("UNMOUNT", mp, false);
> > > if (coveredvp != NULL) {
> > > coveredvp->v_mountedhere = NULL;
> > > vn_seqc_write_end(coveredvp);
> > > @@ -2425,4 +2431,72 @@ kernel_vmount(int flags, ...)
> > >
> > > error = kernel_mount(ma, flags);
> > > return (error);
> > > +}
> > > +
> > > +/* Map from mount options to printable formats. */
> > > +static struct mntoptnames optnames[] = {
> > > + MNTOPT_NAMES
> > > +};
> > > +
> > > +static void
> > > +dev_vfs_event_mntopt(struct sbuf *sb, const char *what, struct
> > vfsoptlist *opts)
> > > +{
> > > + struct vfsopt *opt;
> > > +
> > > + if (opts == NULL || TAILQ_EMPTY(opts))
> > > + return;
> > > + sbuf_printf(sb, " %s=\"", what);
> > > + TAILQ_FOREACH(opt, opts, link) {
> > > + if (opt->name[0] == '\0' || (opt->len > 0 && *(char
> > *)opt->value == '\0'))
> > > + continue;
> > > + devctl_safe_quote_sb(sb, opt->name);
> > > + if (opt->len > 0) {
> > > + sbuf_putc(sb, '=');
> > > + devctl_safe_quote_sb(sb, opt->value);
> > > + }
> > > + sbuf_putc(sb, ';');
> > > + }
> > > + sbuf_putc(sb, '"');
> > > +}
> > > +
> > > +#define DEVCTL_LEN 1024
> > > +static void
> > > +dev_vfs_event(const char *type, struct mount *mp, bool donew)
> > > +{
> > > + const uint8_t *cp;
>
Re: svn commit: r364402 - head/sys/kern
On Wed, Aug 19, 2020 at 05:10:05PM +, Warner Losh wrote:
> Author: imp
> Date: Wed Aug 19 17:10:04 2020
> New Revision: 364402
> URL: https://svnweb.freebsd.org/changeset/base/364402
>
> Log:
> Add VFS FS events for mount and unmount to devctl/devd
>
> Report when a filesystem is mounted, remounted or unmounted via devd, along
> with
> details about the mount point and mount options.
>
> Discussed with: kib@
> Reviewed by: kirk@ (prior version)
> Sponsored by: Netflix
> Diffential Revision: https://reviews.freebsd.org/D25969
>
> Modified:
> head/sys/kern/vfs_mount.c
>
> Modified: head/sys/kern/vfs_mount.c
> ==
> --- head/sys/kern/vfs_mount.c Wed Aug 19 17:09:58 2020(r364401)
> +++ head/sys/kern/vfs_mount.c Wed Aug 19 17:10:04 2020(r364402)
> @@ -42,6 +42,7 @@ __FBSDID("$FreeBSD$");
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -101,6 +102,8 @@ MTX_SYSINIT(mountlist, _mtx, "mountlist", MT
> EVENTHANDLER_LIST_DEFINE(vfs_mounted);
> EVENTHANDLER_LIST_DEFINE(vfs_unmounted);
>
> +static void dev_vfs_event(const char *type, struct mount *mp, bool donew);
> +
> /*
> * Global opts, taken by all filesystems
> */
> @@ -1020,6 +1023,7 @@ vfs_domount_first(
> VOP_UNLOCK(vp);
> EVENTHANDLER_DIRECT_INVOKE(vfs_mounted, mp, newdp, td);
> VOP_UNLOCK(newdp);
> + dev_vfs_event("MOUNT", mp, false);
> mountcheckdirs(vp, newdp);
> vn_seqc_write_end(vp);
> vn_seqc_write_end(newdp);
> @@ -1221,6 +1225,7 @@ vfs_domount_update(
> if (error != 0)
> goto end;
>
> + dev_vfs_event("REMOUNT", mp, true);
> if (mp->mnt_opt != NULL)
> vfs_freeopts(mp->mnt_opt);
> mp->mnt_opt = mp->mnt_optnew;
> @@ -1839,6 +1844,7 @@ dounmount(struct mount *mp, int flags, struct thread *
> TAILQ_REMOVE(, mp, mnt_list);
> mtx_unlock(_mtx);
> EVENTHANDLER_DIRECT_INVOKE(vfs_unmounted, mp, td);
> + dev_vfs_event("UNMOUNT", mp, false);
> if (coveredvp != NULL) {
> coveredvp->v_mountedhere = NULL;
> vn_seqc_write_end(coveredvp);
> @@ -2425,4 +2431,72 @@ kernel_vmount(int flags, ...)
>
> error = kernel_mount(ma, flags);
> return (error);
> +}
> +
> +/* Map from mount options to printable formats. */
> +static struct mntoptnames optnames[] = {
> + MNTOPT_NAMES
> +};
> +
> +static void
> +dev_vfs_event_mntopt(struct sbuf *sb, const char *what, struct vfsoptlist
> *opts)
> +{
> + struct vfsopt *opt;
> +
> + if (opts == NULL || TAILQ_EMPTY(opts))
> + return;
> + sbuf_printf(sb, " %s=\"", what);
> + TAILQ_FOREACH(opt, opts, link) {
> + if (opt->name[0] == '\0' || (opt->len > 0 && *(char
> *)opt->value == '\0'))
> + continue;
> + devctl_safe_quote_sb(sb, opt->name);
> + if (opt->len > 0) {
> + sbuf_putc(sb, '=');
> + devctl_safe_quote_sb(sb, opt->value);
> + }
> + sbuf_putc(sb, ';');
> + }
> + sbuf_putc(sb, '"');
> +}
> +
> +#define DEVCTL_LEN 1024
> +static void
> +dev_vfs_event(const char *type, struct mount *mp, bool donew)
> +{
> + const uint8_t *cp;
> + struct mntoptnames *fp;
> + struct sbuf sb;
> + struct statfs *sfp = >mnt_stat;
> + char *buf;
> +
> + buf = malloc(DEVCTL_LEN, M_MOUNT, M_WAITOK);
> + if (buf == NULL)
> + return;
buf can't be NULL.
> + sbuf_new(, buf, DEVCTL_LEN, SBUF_FIXEDLEN);
> + sbuf_cpy(, "mount-point=\"");
> + devctl_safe_quote_sb(, sfp->f_mntonname);
> + sbuf_cat(, "\" mount-dev=\"");
> + devctl_safe_quote_sb(, sfp->f_mntfromname);
> + sbuf_cat(, "\" mount-type=\"");
> + devctl_safe_quote_sb(, sfp->f_fstypename);
> + sbuf_cat(, "\" fsid=0x");
> + cp = (const uint8_t *)>f_fsid.val[0];
> + for (int i = 0; i < sizeof(sfp->f_fsid); i++)
> + sbuf_printf(, "%02x", cp[i]);
> + sbuf_printf(, " owner=%u flags=\"", sfp->f_owner);
> + for (fp = optnames; fp->o_opt != 0; fp++) {
> + if ((mp->mnt_flag & fp->o_opt) != 0) {
> + sbuf_cat(, fp->o_name);
> + sbuf_putc(, ';');
>
Re: svn commit: r364310 - in head/sys: kern vm
On Tue, Aug 18, 2020 at 01:03:25AM +0300, Andriy Gapon wrote: > On 17/08/2020 18:37, Gleb Smirnoff wrote: > > Author: glebius > > Date: Mon Aug 17 15:37:08 2020 > > New Revision: 364310 > > URL: https://svnweb.freebsd.org/changeset/base/364310 > > > > Log: > > With INVARIANTS panic immediately if M_WAITOK is requested in a > > non-sleepable context. Previously only _sleep() would panic. > > This will catch misuse of M_WAITOK at development stage rather > > than at stress load stage. > > > > Reviewed by: markj > > Differential Revision:https://reviews.freebsd.org/D26027 > > I think that there is going to be a lot of fallout from this. > Will you handle it? > A warning from WITNESS is one thing, a panic is another. Hint: There may also be fallout downstream. ;P Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: svn commit: r363842 - head/sys/compat/linuxkpi/common/include/linux
If you use git, you can easily cherry-pick the fix from HardenedBSD:
https://github.com/HardenedBSD/hardenedBSD/commit/e7ee74598b987fdc702614668b7ea85884289cf1
On Tue, Aug 11, 2020 at 02:31:26PM +0200, Mateusz Guzik wrote:
> Hi. This remains unfixed.
>
> On 8/4/20, Emmanuel Vadot wrote:
> > On Tue, 4 Aug 2020 13:11:02 -0500
> > Alan Cox wrote:
> >
> >>
> >> On 8/4/20 10:25 AM, Emmanuel Vadot wrote:
> >> > Author: manu
> >> > Date: Tue Aug 4 15:25:22 2020
> >> > New Revision: 363842
> >> > URL: https://svnweb.freebsd.org/changeset/base/363842
> >> >
> >> > Log:
> >> >linuxkpi: Add clear_bit_unlock
> >> >
> >> >This calls clear_bit and adds a memory barrier.
> >> >
> >> >Sponsored by: The FreeBSD Foundation
> >> >
> >> >Reviewed by: hselasky
> >> >MFC after:1 week
> >> >Differential Revision:https://reviews.freebsd.org/D25943
> >> >
> >> > Modified:
> >> >head/sys/compat/linuxkpi/common/include/linux/bitops.h
> >> >
> >> > Modified: head/sys/compat/linuxkpi/common/include/linux/bitops.h
> >> > ==
> >> > --- head/sys/compat/linuxkpi/common/include/linux/bitops.h Tue Aug
> >> > 4
> >> > 15:00:02 2020(r363841)
> >> > +++ head/sys/compat/linuxkpi/common/include/linux/bitops.h Tue Aug
> >> > 4
> >> > 15:25:22 2020(r363842)
> >> > @@ -275,6 +275,13 @@ find_next_zero_bit(const unsigned long *addr,
> >> > unsigned
> >> > #definetest_bit(i, a)
> >> > \
> >> > !!(READ_ONCE(((volatile const unsigned long *)(a))[BIT_WORD(i)]) &
> >> > BIT_MASK(i))
> >> >
> >> > +static inline void
> >> > +clear_bit_unlock(long bit, volatile unsigned long *var)
> >> > +{
> >> > +clear_bit(bit, var);
> >> > +wmb();
> >>
> >>
> >> For an unlock operation, the memory barrier should come before the
> >> clear_bit() call, not after.?? See, for example, the alpha implementation
> >> in Linux.?? Also, the correct "spelling" for this memory barrier in
> >> FreeBSD would be atomic_thread_fence_rel(). See, for example, the
> >> comment at the top of sys/amd64/include/atomic.h.
> >
> > Ah yes, thanks. I probably got lost looking for the linux implem but
> > that does make sense, I'll fix that probably tomorow.
> >
> > Thanks.
> >
> >>
> >> > +}
> >> > +
> >> > static inline int
> >> > test_and_clear_bit(long bit, volatile unsigned long *var)
> >> > {
> >
> >
> > --
> > Emmanuel Vadot
> >
>
>
> --
> Mateusz Guzik
> ___
> svn-src-all@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-all
> To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD
GPG Key ID: 0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2
https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
signature.asc
Description: PGP signature
Re: svn commit: r362769 - in head/sys: amd64/linux amd64/linux32 arm64/linux compat/linux i386/linux
On Mon, Jun 29, 2020 at 12:42:49PM -0500, Kyle Evans wrote: > On Mon, Jun 29, 2020 at 10:27 AM Shawn Webb > wrote: > > > > Hey Kyle, > > > > On Mon, Jun 29, 2020 at 03:09:14AM +, Kyle Evans wrote: > > > Author: kevans > > > Date: Mon Jun 29 03:09:14 2020 > > > New Revision: 362769 > > > URL: https://svnweb.freebsd.org/changeset/base/362769 > > > > > > Log: > > > linuxolator: implement memfd_create syscall > > > > > > This effectively mirrors our libc implementation, but with minor > > > fudging -- > > > name needs to be copied in from userspace, so we just copy it straight > > > into > > > stack-allocated memfd_name into the correct position rather than > > > allocating > > > memory that needs to be cleaned up. > > > > > > The sealing-related fcntl(2) commands, F_GET_SEALS and F_ADD_SEALS, have > > > also been implemented now that we support them. > > > > > > Note that this implementation is still not quite at feature parity > > > w.r.t. > > > the actual Linux version; some caveats, from my foggy memory: > > > > > > - Need to implement SHM_GROW_ON_WRITE, default for memfd (in progress) > > > - LTP wants the memfd name exposed to fdescfs > > > - Linux allows open() of an fdescfs fd with O_TRUNC to truncate after > > > dup. > > > (?) > > > > > > Interested parties can install and run LTP from ports (devel/linux-ltp) > > > to > > > confirm any fixes. > > > > > > PR: 240874 > > > Reviewed by:kib, trasz > > > Differential Revision: https://reviews.freebsd.org/D21845 > > > > RELNOTES? > > > > > > > > Modified: > > > head/sys/amd64/linux/linux_dummy.c > > > head/sys/amd64/linux32/linux32_dummy.c > > > head/sys/arm64/linux/linux_dummy.c > > > head/sys/compat/linux/linux.c > > > head/sys/compat/linux/linux.h > > > head/sys/compat/linux/linux_file.c > > > head/sys/compat/linux/linux_file.h > > > head/sys/i386/linux/linux_dummy.c > > > > Should __FreeBSD_version be bumped? > > > > I'm roping in trasz@, because I'm unsure on either of these points -- > I haven't paid attention and don't know if we typically include linux > syscalls that we implement in relnotes, and given that this commit > only really affects pre-compiled Linux binaries I'm not sure if > there's any utility in bumping __FreeBSD_version; presumably ports > folks can't do anything differently here, and binaries will work just > the same. Hey Kyle, I assumed as much, but I wasn't entirely sure. I thought I'd just ask anyways. Thanks for the clarification. :) -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: svn commit: r362769 - in head/sys: amd64/linux amd64/linux32 arm64/linux compat/linux i386/linux
Hey Kyle, On Mon, Jun 29, 2020 at 03:09:14AM +, Kyle Evans wrote: > Author: kevans > Date: Mon Jun 29 03:09:14 2020 > New Revision: 362769 > URL: https://svnweb.freebsd.org/changeset/base/362769 > > Log: > linuxolator: implement memfd_create syscall > > This effectively mirrors our libc implementation, but with minor fudging -- > name needs to be copied in from userspace, so we just copy it straight into > stack-allocated memfd_name into the correct position rather than allocating > memory that needs to be cleaned up. > > The sealing-related fcntl(2) commands, F_GET_SEALS and F_ADD_SEALS, have > also been implemented now that we support them. > > Note that this implementation is still not quite at feature parity w.r.t. > the actual Linux version; some caveats, from my foggy memory: > > - Need to implement SHM_GROW_ON_WRITE, default for memfd (in progress) > - LTP wants the memfd name exposed to fdescfs > - Linux allows open() of an fdescfs fd with O_TRUNC to truncate after dup. > (?) > > Interested parties can install and run LTP from ports (devel/linux-ltp) to > confirm any fixes. > > PR: 240874 > Reviewed by:kib, trasz > Differential Revision: https://reviews.freebsd.org/D21845 RELNOTES? > > Modified: > head/sys/amd64/linux/linux_dummy.c > head/sys/amd64/linux32/linux32_dummy.c > head/sys/arm64/linux/linux_dummy.c > head/sys/compat/linux/linux.c > head/sys/compat/linux/linux.h > head/sys/compat/linux/linux_file.c > head/sys/compat/linux/linux_file.h > head/sys/i386/linux/linux_dummy.c Should __FreeBSD_version be bumped? Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: svn commit: r361870 - in head/sys/geom: . label
On Sat, Jun 06, 2020 at 02:19:16PM +, Conrad Meyer wrote: > Author: cem > Date: Sat Jun 6 14:19:16 2020 > New Revision: 361870 > URL: https://svnweb.freebsd.org/changeset/base/361870 > > Log: > Revert r361838 Why? -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: svn commit: r361790 - head/sbin/ifconfig
On Sat, Jun 06, 2020 at 03:20:57AM +0700, Eugene Grosbein wrote: > 05.06.2020 4:45, Shawn Webb wrote: > > >> Modified: head/sbin/ifconfig/ifconfig.8 > >> == > >> --- head/sbin/ifconfig/ifconfig.8 Thu Jun 4 14:15:39 2020 > >> (r361789) > >> +++ head/sbin/ifconfig/ifconfig.8 Thu Jun 4 14:44:44 2020 > >> (r361790) > > > > Hey Eugene, > > > > Does the manpage need a date bump? > > It was already bumped that day with previous commit by avg. > Sorry for late reply. No worries. I didn't catch the prior date bump. Thanks for the clarification! :) -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: svn commit: r361790 - head/sbin/ifconfig
On Thu, Jun 04, 2020 at 02:44:45PM +, Eugene Grosbein wrote: > Author: eugen > Date: Thu Jun 4 14:44:44 2020 > New Revision: 361790 > URL: https://svnweb.freebsd.org/changeset/base/361790 > > Log: > ifconfig(8): make it possible to filter output by interface group. > > Now options -g/-G allow to select/unselect interfaces by groups > in the "ifconfig -a" output just like already existing -d/-u. > > Examples: > > to exclude loopback from the list: ifconfig -a -G lo > to show vlan interfaces only: ifconfig -a -g vlan > to show tap interfaces that are up: ifconfig -aug tap > > Arguments to -g/-G may be shell patterns and both may be specified. > Later options -g/-G override previous ones. > > MFC after: 2 weeks > Relnotes: yes > Differential Revision: https://reviews.freebsd.org/D25029 > > Modified: > head/sbin/ifconfig/ifconfig.8 > head/sbin/ifconfig/ifconfig.c > > Modified: head/sbin/ifconfig/ifconfig.8 > == > --- head/sbin/ifconfig/ifconfig.8 Thu Jun 4 14:15:39 2020 > (r361789) > +++ head/sbin/ifconfig/ifconfig.8 Thu Jun 4 14:44:44 2020 > (r361790) Hey Eugene, Does the manpage need a date bump? Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: svn commit: r361275 - in head/sys: conf dev/hyperv/hvsock dev/hyperv/include dev/hyperv/vmbus modules/hyperv modules/hyperv/hvsock sys
On Wed, May 20, 2020 at 11:03:59AM +, Wei Hu wrote: > Author: whu > Date: Wed May 20 11:03:59 2020 > New Revision: 361275 > URL: https://svnweb.freebsd.org/changeset/base/361275 > > Log: > HyperV socket implementation for FreeBSD > > This change adds Hyper-V socket feature in FreeBSD. New socket address > family AF_HYPERV and its kernel support are added. > > Submitted by: Wei Hu > Reviewed by:Dexuan Cui > Relnotes: yes > Sponsored by: Microsoft > Differential Revision: https://reviews.freebsd.org/D24061 Hey Wei Hu, Would it be good to bump __FreeBSD_version after a change like this? Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: svn commit: r359950 - head/usr.sbin/bhyve
Thanks, Conrad! I'll test out the change tomorrow after the HardenedBSD auto-sync scripts run tonight. I'll report back tomorrow. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc On Sun, Apr 19, 2020 at 04:55:37PM -0700, Conrad Meyer wrote: > Committed in r360107, if you don't mind rebooting to try the patch. I > will work on the slightly more complicated additional steps mentioned > earlier, but those will take a little more time. > > Thanks again, > Conrad > > On Sun, Apr 19, 2020 at 4:50 PM Conrad Meyer wrote: > > > > https://reviews.freebsd.org/D24507 :-) > > > > On Sun, Apr 19, 2020 at 4:45 PM Peter Grehan wrote: > > > > > > > Unless there is an ABI problem, I think we should probably go > > > > ahead and bump VM_MAX_MEMMAPS > > > > > > That's a reasonable fix - double it (or more) until it's made dynamic. > > > The VGA code is another (future) client of this, and it would allow > > > other things like multiple frame buffers. > > > > > > later, > > > > > > Peter. signature.asc Description: PGP signature
Re: svn commit: r359950 - head/usr.sbin/bhyve
On Mon, Apr 20, 2020 at 02:32:23AM +0300, Yuri Pankov wrote: > Shawn Webb wrote: > > This is the full output from bhyve: > > > > fbuf frame buffer base: 0x69191a0 [sz 16777216] > > bhyve: bootrom_alloc: vm_mmap_mapseg: No space left on device > > bhyve: vmgenc_init: bootrom_alloc > > I wonder if it's coincidence, and you really didn't have 16G to wire at that > moment, and after reverting the commit it was there (reboot?) -- I was > getting the same error well before this change when I had almost all of the > memory eaten by ZFS ARC, I was looking at r359949 as possible candidate, but > limiting that memory hog did make the issue disappear. Good thought, but this was on a fresh reboot on my laptop with 64GB ECC RAM. At the time bhyve was started, I had 55GB memory free. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: svn commit: r359950 - head/usr.sbin/bhyve
This is the full output from bhyve: fbuf frame buffer base: 0x69191a0 [sz 16777216] bhyve: bootrom_alloc: vm_mmap_mapseg: No space left on device bhyve: vmgenc_init: bootrom_alloc Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc On Sun, Apr 19, 2020 at 04:04:16PM -0700, Conrad Meyer wrote: > Hey Shawn, > > I will take a look. Thanks for the report and especially the repro example. > What sort of bad symptoms are you observing (or will it be super obvious > when I try this)? > > Thanks, > Conrad > > On Sun, Apr 19, 2020 at 15:53 Shawn Webb wrote: > > > On Wed, Apr 15, 2020 at 02:00:18AM +, Conrad Meyer wrote: > > > Author: cem > > > Date: Wed Apr 15 02:00:17 2020 > > > New Revision: 359950 > > > URL: https://svnweb.freebsd.org/changeset/base/359950 > > > > > > Log: > > > bhyve(8): Add VM Generation Counter ACPI device > > > > > > Add an implementatation of the 'Virtual Machine Generation ID' spec to > > > Bhyve. The spec provides a randomly generated GUID (at bhyve start) in > > > device memory, along with an ACPI device with _CID VM_Gen_Counter and > > ADDR > > > evaluating to a Package pointing at that GUID. > > > > > > A GPE is defined which Notifies the ACPI Device when the generation > > changes > > > (such as when a snapshot is rolled back). At this time, Bhyve does not > > > support snapshotting, so the GPE is never actually raised. > > > > > > Suggested by: rpokala > > > Discussed with: grehan > > > Differential Revision: https://reviews.freebsd.org/D23165 > > > > > > Added: > > > head/usr.sbin/bhyve/vmgenc.c (contents, props changed) > > > head/usr.sbin/bhyve/vmgenc.h (contents, props changed) > > > Modified: > > > head/usr.sbin/bhyve/Makefile > > > head/usr.sbin/bhyve/acpi.c > > > head/usr.sbin/bhyve/acpi.h > > > head/usr.sbin/bhyve/bhyverun.c > > > head/usr.sbin/bhyve/pm.c > > > > Hey Conrad, > > > > Something about this commit broke bhyve in UEFI mode. Reverting this > > specific change caused bhyve to work again. Here's a sample command: > > > > /usr/obj/usr/src/amd64.amd64/usr.sbin/bhyve/bhyve \ > > -c 4 \ > > -m 16g \ > > -H \ > > -A \ > > -P \ > > -S \ > > -g 0 \ > > -s 0:0,hostbridge \ > > -s 1:0,lpc \ > > -s 29,fbuf,tcp=127.0.0.1:5910,w=1024,h=768,wait \ > > -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \ > > -s 2:0,virtio-net,tap1 \ > > -s 3:0,virtio-blk,/dev/zvol/rpool/bhyve/hbsd-cross-dso-cfi-01/disk-01 \ > > -l com1,/dev/nmdm-hbsd-cross-dso-cfi-01-A \ > > -s 31:0,ahci-cd,/ISO/HardenedBSD/12-stable_amd64/2020-04-19_disc1.iso \ > > hbsd-cdcfi-01 > > > > Thanks, > > > > -- > > Shawn Webb > > Cofounder / Security Engineer > > HardenedBSD > > > > GPG Key ID: 0xFF2E67A277F8E1FA > > GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 > > > > https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc > > signature.asc Description: PGP signature
Re: svn commit: r359950 - head/usr.sbin/bhyve
On Wed, Apr 15, 2020 at 02:00:18AM +, Conrad Meyer wrote: > Author: cem > Date: Wed Apr 15 02:00:17 2020 > New Revision: 359950 > URL: https://svnweb.freebsd.org/changeset/base/359950 > > Log: > bhyve(8): Add VM Generation Counter ACPI device > > Add an implementatation of the 'Virtual Machine Generation ID' spec to > Bhyve. The spec provides a randomly generated GUID (at bhyve start) in > device memory, along with an ACPI device with _CID VM_Gen_Counter and ADDR > evaluating to a Package pointing at that GUID. > > A GPE is defined which Notifies the ACPI Device when the generation changes > (such as when a snapshot is rolled back). At this time, Bhyve does not > support snapshotting, so the GPE is never actually raised. > > Suggested by: rpokala > Discussed with: grehan > Differential Revision: https://reviews.freebsd.org/D23165 > > Added: > head/usr.sbin/bhyve/vmgenc.c (contents, props changed) > head/usr.sbin/bhyve/vmgenc.h (contents, props changed) > Modified: > head/usr.sbin/bhyve/Makefile > head/usr.sbin/bhyve/acpi.c > head/usr.sbin/bhyve/acpi.h > head/usr.sbin/bhyve/bhyverun.c > head/usr.sbin/bhyve/pm.c Hey Conrad, Something about this commit broke bhyve in UEFI mode. Reverting this specific change caused bhyve to work again. Here's a sample command: /usr/obj/usr/src/amd64.amd64/usr.sbin/bhyve/bhyve \ -c 4 \ -m 16g \ -H \ -A \ -P \ -S \ -g 0 \ -s 0:0,hostbridge \ -s 1:0,lpc \ -s 29,fbuf,tcp=127.0.0.1:5910,w=1024,h=768,wait \ -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \ -s 2:0,virtio-net,tap1 \ -s 3:0,virtio-blk,/dev/zvol/rpool/bhyve/hbsd-cross-dso-cfi-01/disk-01 \ -l com1,/dev/nmdm-hbsd-cross-dso-cfi-01-A \ -s 31:0,ahci-cd,/ISO/HardenedBSD/12-stable_amd64/2020-04-19_disc1.iso \ hbsd-cdcfi-01 Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: svn commit: r360068 - in head/sys: kern net sys
On Sun, Apr 19, 2020 at 04:19:06PM +0200, Kristof Provost wrote:
> On 19 Apr 2020, at 15:33, Ronald Klop wrote:
> > On Sat, 18 Apr 2020 09:50:30 +0200, Kristof Provost
> > wrote:
> >
> > > Author: kp
> > > Date: Sat Apr 18 07:50:30 2020
> > > New Revision: 360068
> > > URL: https://svnweb.freebsd.org/changeset/base/360068
> > >
> > > Log:
> > > ethersubr: Make the mac address generation more robust
> > > If we create two (vnet) jails and create a bridge interface in each
> > > we end up
> > > with the same mac address on both bridge interfaces.
> > > These very often conflicts, resulting in same mac address in both
> > > jails.
> > > Mitigate this problem by including the jail name in the mac address.
> > > Reviewed by: kevans, melifaro
> > > MFC after: 1 week
> > > Differential Revision: https://reviews.freebsd.org/D24383
> > >
> > > Modified:
> > > head/sys/kern/kern_jail.c
> > > head/sys/net/if_ethersubr.c
> > > head/sys/sys/jail.h
> > >
> > > Modified: head/sys/kern/kern_jail.c
> > > ==
> > > --- head/sys/kern/kern_jail.c Sat Apr 18 03:14:16 2020
> > > (r360067)
> > > +++ head/sys/kern/kern_jail.c Sat Apr 18 07:50:30 2020
> > > (r360068)
> > > @@ -2920,6 +2920,15 @@ getcredhostid(struct ucred *cred, unsigned
> > > long *hosti
> > > mtx_unlock(>cr_prison->pr_mtx);
> > > }
> > > +void
> > > +getjailname(struct ucred *cred, char *name, size_t len)
> > > +{
> > > +
> > > + mtx_lock(>cr_prison->pr_mtx);
> > > + strlcpy(name, cred->cr_prison->pr_name, len);
> > > + mtx_unlock(>cr_prison->pr_mtx);
> > > +}
> > > +
> > > #ifdef VIMAGE
> > > /*
> > > * Determine whether the prison represented by cred owns
> > >
> > > Modified: head/sys/net/if_ethersubr.c
> > > ==
> > > --- head/sys/net/if_ethersubr.c Sat Apr 18 03:14:16 2020
> > > (r360067)
> > > +++ head/sys/net/if_ethersubr.c Sat Apr 18 07:50:30 2020
> > > (r360068)
> > > @@ -1419,27 +1419,39 @@ ether_8021q_frame(struct mbuf **mp, struct
> > > ifnet *ife,
> > > /*
> > > * Allocate an address from the FreeBSD Foundation OUI. This uses a
> > > - * cryptographic hash function on the containing jail's UUID and
> > > the interface
> > > - * name to attempt to provide a unique but stable address.
> > > Pseudo-interfaces
> > > - * which require a MAC address should use this function to allocate
> > > - * non-locally-administered addresses.
> > > + * cryptographic hash function on the containing jail's name, UUID
> > > and the
> > > + * interface name to attempt to provide a unique but stable address.
> > > + * Pseudo-interfaces which require a MAC address should use this
> > > function to
> > > + * allocate non-locally-administered addresses.
> > > */
> > > void
> > > ether_gen_addr(struct ifnet *ifp, struct ether_addr *hwaddr)
> > > {
> > > -#define ETHER_GEN_ADDR_BUFSIZ HOSTUUIDLEN + IFNAMSIZ + 2
> > > SHA1_CTX ctx;
> > > - char buf[ETHER_GEN_ADDR_BUFSIZ];
> > > + char *buf;
> > > char uuid[HOSTUUIDLEN + 1];
> > > uint64_t addr;
> > > int i, sz;
> > > char digest[SHA1_RESULTLEN];
> > > + char jailname[MAXHOSTNAMELEN];
> > > getcredhostuuid(curthread->td_ucred, uuid, sizeof(uuid));
> > > - sz = snprintf(buf, ETHER_GEN_ADDR_BUFSIZ, "%s-%s", uuid,
> > > ifp->if_xname);
> > > + /* If each (vnet) jail would also have a unique hostuuid this
> > > would not
> > > + * be necessary. */
> > > + getjailname(curthread->td_ucred, jailname, sizeof(jailname));
> > > + sz = asprintf(, M_TEMP, "%s-%s-%s", uuid, if_name(ifp),
> > > + jailname);
> > > + if (sz < 0) {
> > > + /* Fall back to a random mac address. */
> >
> >
> > I was wondering if it would be valuable to give this fall back something
> > like:
> >
> >printf("%s: unable to create fixed mac address; using random
> > mac address", if_name(ifp));
> >
> > This will only be printed in rare ci
Re: svn commit: r359949 - head/usr.sbin/bhyve
On Wed, Apr 15, 2020 at 01:58:51AM +, Conrad Meyer wrote: > Author: cem > Date: Wed Apr 15 01:58:51 2020 > New Revision: 359949 > URL: https://svnweb.freebsd.org/changeset/base/359949 > > Log: > bhyve(8): Add bootrom allocation abstraction > > To allow more general use of the bootrom region, separate initialization > from > allocation, and allocation from loading a file. > > The bootrom segment is the high 16MB of the low 4GB region. > > Each allocation in the segment creates a new mapping with specified > protection. > By default, allocation begins at the low end of the range. However, the > BOOTROM_ALLOC_TOP flag is provided to locate a provided bootrom in the high > region it is expected to be in. > > The existing ROM-file loading code is refactored to use the new interface. > > Reviewed by:grehan (earlier version) > Differential Revision: https://reviews.freebsd.org/D24422 Hey Conrad, Is there any way you'd have a change of heart and support MFC'ing? I'm sure many people, including myself, would be ever so grateful not to have to maintain their own MFC's of your work. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: svn commit: r353937 - in head/share: man/man5 mk
On Wed, Oct 23, 2019 at 05:02:45PM +, Dimitry Andric wrote: > Author: dim > Date: Wed Oct 23 17:02:45 2019 > New Revision: 353937 > URL: https://svnweb.freebsd.org/changeset/base/353937 > > Log: > Build toolchain components as dynamically linked executables by default > > Summary: > Historically, we have built toolchain components such as cc, ld, etc as > statically linked executables. One of the reasons being that you could > sometimes save yourself from botched upgrades, by e.g. recompiling a > "known good" libc and reinstalling it. > > In this day and age, we have boot environments, virtual machine > snapshots, cloud backups, and other much more reliable methods to > restore systems to working order. So I think the time is ripe to flip > this default, and link the toolchain components dynamically, just like > almost all other executables on FreeBSD. > > Maybe at some point they can even become PIE executables by default! :) They have been on HardenedBSD for a few years now. :) Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
Re: svn commit: r353456 - head/usr.sbin/pciconf
On Sat, Oct 12, 2019 at 10:27:57PM +, Scott Long wrote: > Author: scottl > Date: Sat Oct 12 22:27:57 2019 > New Revision: 353456 > URL: https://svnweb.freebsd.org/changeset/base/353456 > > Log: > Change from the non-standard nomenclature of "chip" and "card" to the > standard nomenclature of "device" and "vendor" with the "sub" variants. > This changes the printed format, so anything that scrapes and parses > this will need to be adapted. No compatibility shims are provided, > but this will not be MFC'd. > > Reviewed by:jhb, emaste, gtetlow > Approved by: jhb, emaste, gtetlow Relnotes: ? RELNOTES: ? UPDATING: ? -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
Re: svn commit: r351729 - in head: lib/libc/gen lib/libc/sys sys/compat/freebsd32 sys/kern sys/sys
On Tue, Sep 03, 2019 at 07:47:40AM -0400, Shawn Webb wrote: > On Tue, Sep 03, 2019 at 11:45:23AM +, Brooks Davis wrote: > > On Tue, Sep 03, 2019 at 07:35:05AM -0400, Shawn Webb wrote: > > > Hey Mateusz, > > > > > > On Tue, Sep 03, 2019 at 04:16:31AM +, Mateusz Guzik wrote: > > > > Author: mjg > > > > Date: Tue Sep 3 04:16:30 2019 > > > > New Revision: 351729 > > > > URL: https://svnweb.freebsd.org/changeset/base/351729 > > > > > > > > Log: > > > > Add sysctlbyname system call > > > > > > > > Previously userspace would issue one syscall to resolve the sysctl > > > > and then > > > > another one to actually use it. Do it all in one trip. > > > > > > > > Fallback is provided in case newer libc happens to be running on an > > > > older > > > > kernel. > > > > > > > > Submitted by: Pawel Biernacki > > > > Reported by: kib, brooks > > > > Differential Revision:https://reviews.freebsd.org/D17282 > > > > > > > > Modified: > > > ... snip ... > > > > head/sys/sys/param.h > > > > > > ... snip ... > > > > > > > > > > > Modified: head/sys/sys/param.h > > > > == > > > > --- head/sys/sys/param.hMon Sep 2 21:57:57 2019 > > > > (r351728) > > > > +++ head/sys/sys/param.hTue Sep 3 04:16:30 2019 > > > > (r351729) > > > > @@ -60,7 +60,7 @@ > > > > * in the range 5 to 9. > > > > */ > > > > #undef __FreeBSD_version > > > > -#define __FreeBSD_version 1300044 /* Master, propagated to > > > > newvers */ > > > > +#define __FreeBSD_version 1300045 /* Master, propagated to > > > > newvers */ > > > > > > To an outsider, it seems that __FreeBSD_version tends to be bumped in > > > a separate commit. Am I remembering that right? > > > > It should be bumped in the same commit, but people forget or the bump > > they have in their review turns into a no-op because someone else does a > > bump in the interim (the latter has bit me several times). > > Interesting. Thanks for the clarification! One thought for making the version bump a seperate commit is if the original commit needed to be reverted, the commit can be reverted wholesale (well, from the perspective of __FreeBSD_version) without worry of accidentally decrementing the version number to a prior value. That's my "need-more-caffeine" verbose way of saying "separating the version bump from the actual work allows for easier maintenance of the version number, helping ensure an always-increasing number." Sorry if I sound dry here. My ten-month-old puppy is tiring me out way faster than I can tire him out. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
Re: svn commit: r351729 - in head: lib/libc/gen lib/libc/sys sys/compat/freebsd32 sys/kern sys/sys
On Tue, Sep 03, 2019 at 09:32:27AM -0500, Justin Hibbits wrote: > On Tue, 3 Sep 2019 10:20:35 -0400 > Shawn Webb wrote: > > > On Tue, Sep 03, 2019 at 07:47:40AM -0400, Shawn Webb wrote: > > > On Tue, Sep 03, 2019 at 11:45:23AM +, Brooks Davis wrote: > > > > On Tue, Sep 03, 2019 at 07:35:05AM -0400, Shawn Webb wrote: > > > > > Hey Mateusz, > > > > > > > > > > On Tue, Sep 03, 2019 at 04:16:31AM +, Mateusz Guzik wrote: > > > > > > Author: mjg > > > > > > Date: Tue Sep 3 04:16:30 2019 > > > > > > New Revision: 351729 > > > > > > URL: https://svnweb.freebsd.org/changeset/base/351729 > > > > > > > > > > > > Log: > > > > > > Add sysctlbyname system call > > > > > > > > > > > > Previously userspace would issue one syscall to resolve the > > > > > > sysctl and then another one to actually use it. Do it all in > > > > > > one trip. > > > > > > Fallback is provided in case newer libc happens to be > > > > > > running on an older kernel. > > > > > > > > > > > > Submitted by: Pawel Biernacki > > > > > > Reported by: kib, brooks > > > > > > Differential Revision: > > > > > > https://reviews.freebsd.org/D17282 > > > > > > > > > > > > Modified: > > > > > ... snip ... > > > > > > head/sys/sys/param.h > > > > > > > > > > ... snip ... > > > > > > > > > > > > > > > > > Modified: head/sys/sys/param.h > > > > > > == > > > > > > --- head/sys/sys/param.hMon Sep 2 21:57:57 > > > > > > 2019(r351728) +++ head/sys/sys/param.h Tue Sep > > > > > > 3 04:16:30 2019(r351729) @@ -60,7 +60,7 @@ > > > > > > * in the range 5 to 9. > > > > > > */ > > > > > > #undef __FreeBSD_version > > > > > > -#define __FreeBSD_version 1300044 /* Master, > > > > > > propagated to newvers */ +#define __FreeBSD_version > > > > > > 1300045 /* Master, propagated to newvers */ > > > > > > > > > > To an outsider, it seems that __FreeBSD_version tends to be > > > > > bumped in a separate commit. Am I remembering that right? > > > > > > > > It should be bumped in the same commit, but people forget or the > > > > bump they have in their review turns into a no-op because someone > > > > else does a bump in the interim (the latter has bit me several > > > > times). > > > > > > Interesting. Thanks for the clarification! > > > > One thought for making the version bump a seperate commit is if the > > original commit needed to be reverted, the commit can be reverted > > wholesale (well, from the perspective of __FreeBSD_version) without > > worry of accidentally decrementing the version number to a prior > > value. > > > > That's my "need-more-caffeine" verbose way of saying "separating the > > version bump from the actual work allows for easier maintenance of the > > version number, helping ensure an always-increasing number." > > > > Sorry if I sound dry here. My ten-month-old puppy is tiring me out way > > faster than I can tire him out. > > > > Thanks, > > > > I always thought convention was separate commits to ease MFCs. The few > times I've bumped __FreeBSD_version I've done it explicitly as a > followup commit for that reason. Guess I now know better :) I should also note that I'm looking at this from an outsider's perspective, which may not reflect the same perspective as an insider's. :) -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
Re: svn commit: r346263 - head/contrib/tcpdump
On Tue, Apr 16, 2019 at 04:12:42AM +, Mariusz Zaborski wrote: > Author: oshogbo > Date: Tue Apr 16 04:12:41 2019 > New Revision: 346263 > URL: https://svnweb.freebsd.org/changeset/base/346263 > > Log: > tcpdump: disable Capsicum if -E option is provided. > > The -E is used to provide a secret for decrypting IPsec. > The secret may be provided through command line or as the file. > The problem is that tcpdump doesn't support yet opening files in capability > mode > and the file may contain a list of the files to open. > > As a workaround, for now, let's just disable capsicum if the -E > the option is provided. > > PR: 236819 > MFC after: 2 weeks > > Modified: > head/contrib/tcpdump/tcpdump.c > > Modified: head/contrib/tcpdump/tcpdump.c > == > --- head/contrib/tcpdump/tcpdump.cTue Apr 16 02:48:04 2019 > (r346262) > +++ head/contrib/tcpdump/tcpdump.cTue Apr 16 04:12:41 2019 > (r346263) > @@ -2063,7 +2063,8 @@ main(int argc, char **argv) > } > > #ifdef HAVE_CAPSICUM > - cansandbox = (VFileName == NULL && zflag == NULL); > + cansandbox = (VFileName == NULL && zflag == NULL && > + ndo->ndo_espsecret == NULL); > #ifdef HAVE_CASPER > cansandbox = (cansandbox && (ndo->ndo_nflag || capdns != NULL)); > #else Is there any documentation anywhere telling users that Capsicum support will be disabled under certain circumstances? Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
Re: svn commit: r345982 - in head: include lib/libc/sys sys/cddl/compat/opensolaris/sys sys/compat/cloudabi sys/compat/freebsd32 sys/compat/linux sys/kern sys/sys sys/ufs/ffs
No worries. Thanks for the correction!
--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD
Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2
On Sun, Apr 07, 2019 at 06:11:58PM +0200, Mariusz Zaborski wrote:
> In the https://wiki.freebsd.org/AddingSyscalls we mentions that we need to
> bump
> __FreeBSD_version. I confirmed that with Warner. So this was my mistake.
>
> Thanks Shawn.
> --
> Mariusz Zaborski
> oshogbo//vx | http://oshogbo.vexillium.org
> FreeBSD committer | https://freebsd.org
> Software developer| http://wheelsystems.com
> If it's not broken, let's fix it till it is!!1
>
> On Sun, Apr 07, 2019 at 08:35:07AM -0700, Cy Schubert wrote:
> > In message <201904071510.x37fa7tm050...@gndrsh.dnsmgr.net>, "Rodney W.
> > Grimes"
> > writes:
> > > > On April 7, 2019 7:11:52 AM PDT, Shawn Webb
> > > > wr
> > > ote:
> > > > >On Sat, Apr 06, 2019 at 09:34:26AM +, Mariusz Zaborski wrote:
> > > > >> Author: oshogbo
> > > > >> Date: Sat Apr 6 09:34:26 2019
> > > > >> New Revision: 345982
> > > > >> URL: https://svnweb.freebsd.org/changeset/base/345982
> > > > >>
> > > > >> Log:
> > > > >> Introduce funlinkat syscall that always us to check if we are
> > > > >removing
> > > > >> the file associated with the given file descriptor.
> > > > >>
> > > > >> Reviewed by: kib, asomers
> > > > >> Reviewed by: cem, jilles, brooks (they reviewed previous
> > > > >> version)
> > > > >> Discussed with:pjd, and many others
> > > > >> Differential Revision: https://reviews.freebsd.org/D14567
> > > > >
> > > > >Hey Mariusz,
> > > > >
> > > > >Is __FreeBSD_version supposed to be bumped after adding new syscalls?
> > > > >I can't remember off-hand.
> > > > >
> > > > >Thanks,
> > > >
> > > > I don't think so. Why force the rebuild of all ports through poudriere
> > > > over
> > > something that would never affect any of them?
> > >
> > > So that you can if version >= foo to know it is safe to use the new
> > > syscal?
> > > Or if version < foo you must use the old way.
> >
> > Granted. However we do need something to avoid gratuitous rebuilds of
> > ports.
> >
> > Personally, my poudriere script adjusts the pkg version
> > ($JAILPATH/data/packages/${JAIL}-${PORTS}/.building/.jailversion) with
> > that of the jail version (reported by poudriere jail -i -j $JAIL),
> > rebuilding all ports when I (the human) determines when the machine
> > should rebuild all ports with -c.
> >
> > In that regard FreeBSD version bumps occasionally seem a little
> > gratuitous. Using the same indicator to tell whether software should be
> > able to use a new feature and when ports build infrastructure should
> > summarily delete all packages forcing a rebuild of absolutely
> > everything is probably not the best.
> >
> > Just throwing out an idea, what if poudriere considers the first N
> > bytes of __FreeBSD_version significant? Having said that, looking at
> > __FreeBSD_version, I don't think we have enough digits to do what I was
> > planning on suggesting. But, you get the idea of what I'm driving at.
> > Maybe a new macro such as __FreeBSD_ports that is incremented every
> > time a change that affects ports?
> >
> > Anyhow, I'm not too terribly concerned as what I have (selfishly
> > speaking) works. But we may as a group might want to consider this at
> > some point to build some efficiency into the ports part of the equation.
> >
> >
> > --
> > Cheers,
> > Cy Schubert
> > FreeBSD UNIX: Web: http://www.FreeBSD.org
> >
> > The need of the many outweighs the greed of the few.
> >
> >
signature.asc
Description: PGP signature
Re: svn commit: r346023 - head/usr.bin/strings
On Mon, Apr 08, 2019 at 03:35:48AM +, Mariusz Zaborski wrote: > Author: oshogbo > Date: Mon Apr 8 03:35:47 2019 > New Revision: 346023 > URL: https://svnweb.freebsd.org/changeset/base/346023 > > Log: > strings: disable Casper support while building native-xtools Why? -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
Re: svn commit: r345982 - in head: include lib/libc/sys sys/cddl/compat/opensolaris/sys sys/compat/cloudabi sys/compat/freebsd32 sys/compat/linux sys/kern sys/sys sys/ufs/ffs
On Sat, Apr 06, 2019 at 09:34:26AM +, Mariusz Zaborski wrote: > Author: oshogbo > Date: Sat Apr 6 09:34:26 2019 > New Revision: 345982 > URL: https://svnweb.freebsd.org/changeset/base/345982 > > Log: > Introduce funlinkat syscall that always us to check if we are removing > the file associated with the given file descriptor. > > Reviewed by:kib, asomers > Reviewed by:cem, jilles, brooks (they reviewed previous version) > Discussed with: pjd, and many others > Differential Revision: https://reviews.freebsd.org/D14567 Hey Mariusz, Is __FreeBSD_version supposed to be bumped after adding new syscalls? I can't remember off-hand. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
Re: svn commit: r351729 - in head: lib/libc/gen lib/libc/sys sys/compat/freebsd32 sys/kern sys/sys
On Tue, Sep 03, 2019 at 11:45:23AM +, Brooks Davis wrote: > On Tue, Sep 03, 2019 at 07:35:05AM -0400, Shawn Webb wrote: > > Hey Mateusz, > > > > On Tue, Sep 03, 2019 at 04:16:31AM +, Mateusz Guzik wrote: > > > Author: mjg > > > Date: Tue Sep 3 04:16:30 2019 > > > New Revision: 351729 > > > URL: https://svnweb.freebsd.org/changeset/base/351729 > > > > > > Log: > > > Add sysctlbyname system call > > > > > > Previously userspace would issue one syscall to resolve the sysctl and > > > then > > > another one to actually use it. Do it all in one trip. > > > > > > Fallback is provided in case newer libc happens to be running on an > > > older > > > kernel. > > > > > > Submitted by: Pawel Biernacki > > > Reported by:kib, brooks > > > Differential Revision: https://reviews.freebsd.org/D17282 > > > > > > Modified: > > ... snip ... > > > head/sys/sys/param.h > > > > ... snip ... > > > > > > > > Modified: head/sys/sys/param.h > > > == > > > --- head/sys/sys/param.h Mon Sep 2 21:57:57 2019(r351728) > > > +++ head/sys/sys/param.h Tue Sep 3 04:16:30 2019(r351729) > > > @@ -60,7 +60,7 @@ > > > * in the range 5 to 9. > > > */ > > > #undef __FreeBSD_version > > > -#define __FreeBSD_version 1300044/* Master, propagated to > > > newvers */ > > > +#define __FreeBSD_version 1300045/* Master, propagated to > > > newvers */ > > > > To an outsider, it seems that __FreeBSD_version tends to be bumped in > > a separate commit. Am I remembering that right? > > It should be bumped in the same commit, but people forget or the bump > they have in their review turns into a no-op because someone else does a > bump in the interim (the latter has bit me several times). Interesting. Thanks for the clarification! -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
Re: svn commit: r351729 - in head: lib/libc/gen lib/libc/sys sys/compat/freebsd32 sys/kern sys/sys
Hey Mateusz, On Tue, Sep 03, 2019 at 04:16:31AM +, Mateusz Guzik wrote: > Author: mjg > Date: Tue Sep 3 04:16:30 2019 > New Revision: 351729 > URL: https://svnweb.freebsd.org/changeset/base/351729 > > Log: > Add sysctlbyname system call > > Previously userspace would issue one syscall to resolve the sysctl and then > another one to actually use it. Do it all in one trip. > > Fallback is provided in case newer libc happens to be running on an older > kernel. > > Submitted by: Pawel Biernacki > Reported by:kib, brooks > Differential Revision: https://reviews.freebsd.org/D17282 > > Modified: ... snip ... > head/sys/sys/param.h ... snip ... > > Modified: head/sys/sys/param.h > == > --- head/sys/sys/param.h Mon Sep 2 21:57:57 2019(r351728) > +++ head/sys/sys/param.h Tue Sep 3 04:16:30 2019(r351729) > @@ -60,7 +60,7 @@ > * in the range 5 to 9. > */ > #undef __FreeBSD_version > -#define __FreeBSD_version 1300044/* Master, propagated to newvers */ > +#define __FreeBSD_version 1300045/* Master, propagated to newvers */ To an outsider, it seems that __FreeBSD_version tends to be bumped in a separate commit. Am I remembering that right? Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
Re: svn commit: r351522 - in head: sbin/ifconfig share/man/man4 sys/conf sys/kern sys/modules sys/modules/ktls_ocf sys/net sys/netinet sys/netinet/tcp_stacks sys/netinet6 sys/opencrypto sys/sys tools/
On Mon, Aug 26, 2019 at 05:14:42PM -0700, John Baldwin wrote: > On 8/26/19 5:01 PM, John Baldwin wrote: > > Author: jhb > > Date: Tue Aug 27 00:01:56 2019 > > New Revision: 351522 > > URL: https://svnweb.freebsd.org/changeset/base/351522 > > > > Log: > > Add kernel-side support for in-kernel TLS. > > The length of the commit message notwithstanding, there is still quite a bit > more work to do on this front. Making use of KTLS requires an SSL library > that understands the new functionality, and for the full performance gain > you want an application that makes use of SSL_sendfile. Netflix has both > of these in the form of patches to OpenSSL and nginx. I'm currently working > on a patchset suitable for merging into upstream OpenSSL's master (the > Linux KTLS patches are merged into OpenSSL master already, so the FreeBSD > patches are fairly small). Hey John, Thanks a lot for working to get this in! I'm curious if there's any desire to help LibreSSL adopt same/similar patches as OpenSSL. Doing so would help LibreSSL on FreeBSD maintain feature parity with OpenSSL. I respect your opinion and would love to hear your thoughts. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
Re: svn commit: r351423 - in head: . sbin/ping6 sbin/ping6/tests
On Sun, Aug 25, 2019 at 08:50:11PM -0700, Conrad Meyer wrote:
> On Sun, Aug 25, 2019 at 6:47 PM Shawn Webb wrote:
> > I wonder if something like this could be done:
>
> Something like it could be; I suggested so two hours ago.
>
> > Somewhere in ping(8):
> > bool ping6_compat;
> > if (strcmp(argv[0], "ping6")) {
> > ping6_compat = true;
>
> You've gotten the sense of the basic C89 function strcmp() backwards.
> Maybe it's a security feature that way? You can add HardenedStrcmp to
> your Easy Feature Comparison page.
I'll keep that in mind should FreeBSD implement it, enabling us to
adopt it. :)
Thanks,
--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD
Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID: 0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2
signature.asc
Description: PGP signature
Re: svn commit: r351423 - in head: . sbin/ping6 sbin/ping6/tests
On Mon, Aug 26, 2019 at 04:20:56AM +0900, Hiroki Sato wrote:
> Hi,
>
> Alan Somers wrote
> in <201908231522.x7nfmluj068...@repo.freebsd.org>:
>
> as> Author: asomers
> as> Date: Fri Aug 23 15:22:20 2019
> as> New Revision: 351423
> as> URL: https://svnweb.freebsd.org/changeset/base/351423
> as>
> as> Log:
> as> ping6: Rename options for better consistency with ping
> as>
> as> Now equivalent options have the same flags, and nonequivalent options
> have
> as> different flags. This is a prelude to merging the two commands.
> as>
> as> Submitted by: J?n Su?an
> as> MFC:Never
> as> Sponsored by: Google LLC (Google Summer of Code 2019)
> as> Differential Revision: https://reviews.freebsd.org/D21345
>
> I have an objection on renaming the existing option flags in ping6(8)
> for compatibility with ping(8).
>
> Is it sufficient to add INET6 support to ping(8) with consistent
> flags and keep CLI of ping6(8) backward compatible? People have used
> ping6(8) for >15 years, so it is too late to rename the flags. I do
> not think the renaming is useful if "ping -6 localhost" or "ping ::1"
> works.
I wonder if something like this could be done:
Somewhere in ping(8):
bool ping6_compat;
if (strcmp(argv[0], "ping6")) {
ping6_compat = true;
}
...
if (ping6_compat) {
do_this();
} else {}
do_that();
}
And sbin/ping/Makefile:
LINKS+=sbin/ping sbin/ping6
(Note that I didn't check if sbin/ping/Makefile already set LINKS. If
it doesn't, it'd be "LINKS=", of course.)
Then, ping(8) and ping6(8) still are the same binary and backwards
compat is maintained, at least until spray paints the neon pink bike
shed. (Note: I am in no way saying this discussion is a bike shed. I'm
_only_ making a joke as a nod to the idiomatic expression.)
Thanks,
--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD
Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID: 0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2
signature.asc
Description: PGP signature
Re: svn commit: r350420 - in head: include lib/libc/stdio
On Mon, Jul 29, 2019 at 07:02:16PM +, Mark Johnston wrote: > Author: markj > Date: Mon Jul 29 19:02:16 2019 > New Revision: 350420 > URL: https://svnweb.freebsd.org/changeset/base/350420 > > Log: > Add mkostempsat(3). > > This is a variant of mkostemps() which takes a directory descriptor and > returns a descriptor for a tempfile relative to that directory. Unlike > the other mktemp functions, mkostempsat() can be used in capability > mode. Out of curiosity, is __FreeBSD_version typically bumped when a new public symbol is added to libc? Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
Re: svn commit: r350315 - in head/sys: kern sys
On Thu, Jul 25, 2019 at 11:48:39AM -0500, Kyle Evans wrote:
> On Thu, Jul 25, 2019 at 11:46 AM Shawn Webb
> wrote:
> >
> > Hey Rick,
> >
> > On Thu, Jul 25, 2019 at 05:46:17AM +, Rick Macklem wrote:
> > > Author: rmacklem
> > > Date: Thu Jul 25 05:46:16 2019
> > > New Revision: 350315
> > > URL: https://svnweb.freebsd.org/changeset/base/350315
> > >
> > > Log:
> > > Add kernel support for a Linux compatible copy_file_range(2) syscall.
> > >
> > > This patch adds support to the kernel for a Linux compatible
> > > copy_file_range(2) syscall and the related VOP_COPY_FILE_RANGE(9).
> > > This syscall/VOP can be used by the NFSv4.2 client to implement the
> > > Copy operation against an NFSv4.2 server to do file copies locally on
> > > the server.
> > > The vn_generic_copy_file_range() function in this patch can be used
> > > by the NFSv4.2 server to implement the Copy operation.
> > > Fuse may also me able to use the VOP_COPY_FILE_RANGE() method.
> > >
> > > vn_generic_copy_file_range() attempts to maintain holes in the output
> > > file in the range to be copied, but may fail to do so if the input and
> > > output files are on different file systems with different
> > > _PC_MIN_HOLE_SIZE
> > > values.
> > >
> > > Separate commits will be done for the generated syscall files and
> > > userland
> > > changes. A commit for a compat32 syscall will be done later.
> > >
> > > Reviewed by:kib, asomers (plus comments by brooks, jilles)
> > > Relnotes: yes
> > > Differential Revision: https://reviews.freebsd.org/D20584
> > >
> > > Modified:
> > > head/sys/kern/syscalls.master
> > > head/sys/kern/vfs_default.c
> > > head/sys/kern/vfs_syscalls.c
> > > head/sys/kern/vfs_vnops.c
> > > head/sys/kern/vnode_if.src
> > > head/sys/sys/syscallsubr.h
> > > head/sys/sys/vnode.h
> > >
> > > Modified: head/sys/kern/syscalls.master
> > > ==
> > > --- head/sys/kern/syscalls.master Thu Jul 25 03:55:05 2019
> > > (r350314)
> > > +++ head/sys/kern/syscalls.master Thu Jul 25 05:46:16 2019
> > > (r350315)
> > > @@ -3175,6 +3175,16 @@
> > > int flag
> > > );
> > > }
> > > +569 AUE_NULLSTD {
> > > + ssize_t copy_file_range(
> > > + int infd,
> > > + _Inout_opt_ off_t *inoffp,
> > > + int outfd,
> > > + _Inout_opt_ off_t *outoffp,
> > > + size_t len,
> > > + unsigned int flags
> > > + );
> > > + }
> > >
> > > ; Please copy any additions and changes to the following compatability
> > > tables:
> > > ; sys/compat/freebsd32/syscalls.master
> > >
> > > Modified: head/sys/kern/vfs_default.c
> > > ==
> > > --- head/sys/kern/vfs_default.c Thu Jul 25 03:55:05 2019
> > > (r350314)
> > > +++ head/sys/kern/vfs_default.c Thu Jul 25 05:46:16 2019
> > > (r350315)
> > > @@ -83,6 +83,7 @@ static int dirent_exists(struct vnode *vp, const char
> > > static int vop_stdis_text(struct vop_is_text_args *ap);
> > > static int vop_stdunset_text(struct vop_unset_text_args *ap);
> > > static int vop_stdadd_writecount(struct vop_add_writecount_args *ap);
> > > +static int vop_stdcopy_file_range(struct vop_copy_file_range_args *ap);
> > > static int vop_stdfdatasync(struct vop_fdatasync_args *ap);
> > > static int vop_stdgetpages_async(struct vop_getpages_async_args *ap);
> > >
> > > @@ -140,6 +141,7 @@ struct vop_vector default_vnodeops = {
> > > .vop_set_text = vop_stdset_text,
> > > .vop_unset_text = vop_stdunset_text,
> > > .vop_add_writecount = vop_stdadd_writecount,
> > > + .vop_copy_file_range = vop_stdcopy_file_range,
> > > };
> > >
> > > /*
> > > @@ -1210,6 +1212,17 @@ vfs_stdnosync (mp, waitfor)
> > > {
> > >
> > > return (0);
> > > +}
> > > +
> > > +static int
> > > +
Re: svn commit: r350315 - in head/sys: kern sys
e *invp, *outvp;
> + int error;
> + size_t retlen;
> + void *rl_rcookie, *rl_wcookie;
> + off_t savinoff, savoutoff;
> +
> + infp = outfp = NULL;
> + rl_rcookie = rl_wcookie = NULL;
> + savinoff = -1;
> + error = 0;
> + retlen = 0;
> +
> + if (flags != 0) {
> + error = EINVAL;
> + goto out;
> + }
> + if (len > SSIZE_MAX)
> + /*
> + * Although the len argument is size_t, the return argument
> + * is ssize_t (which is signed). Therefore a size that won't
> + * fit in ssize_t can't be returned.
> + */
> + len = SSIZE_MAX;
> +
> + /* Get the file structures for the file descriptors. */
> + error = fget_read(td, infd, _read_rights, );
> + if (error != 0)
> + goto out;
> + error = fget_write(td, outfd, _write_rights, );
> + if (error != 0)
> + goto out;
> +
> + /* Set the offset pointers to the correct place. */
> + if (inoffp == NULL)
> + inoffp = >f_offset;
> + if (outoffp == NULL)
> + outoffp = >f_offset;
> + savinoff = *inoffp;
> + savoutoff = *outoffp;
Should these two lines, saving the old inoffp and outoffp, be moved
before the two conditionals above?
Thanks,
--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD
Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID: 0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2
signature.asc
Description: PGP signature
Re: svn commit: r350049 - head/contrib/amd/amd
On Tue, Jul 16, 2019 at 01:41:06PM -0700, John Baldwin wrote: > On 7/16/19 12:44 PM, Shawn Webb wrote: > > On Tue, Jul 16, 2019 at 04:03:08PM +, Brooks Davis wrote: > >> Author: brooks > >> Date: Tue Jul 16 16:03:08 2019 > >> New Revision: 350049 > >> URL: https://svnweb.freebsd.org/changeset/base/350049 > >> > >> Log: > >> Fix two mismatches between function declaration and definition. > >> > >> In both cases, function pointer arguments were inconsistently declared > >> and the result worked because of C's odd rules around function pointer > >> (de)references. With a stricter compiler these fail to compile. > > > > And, with CFI applied to the kernel, would cause a panic. :) > > > > Good catch and thanks for the great work! > > How would an incorrect function prototype in userland cause a kernel panic? Another good catch! I misread the intent of the patch. Sorry for the line noise. -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
Re: svn commit: r350049 - head/contrib/amd/amd
On Tue, Jul 16, 2019 at 04:03:08PM +, Brooks Davis wrote: > Author: brooks > Date: Tue Jul 16 16:03:08 2019 > New Revision: 350049 > URL: https://svnweb.freebsd.org/changeset/base/350049 > > Log: > Fix two mismatches between function declaration and definition. > > In both cases, function pointer arguments were inconsistently declared > and the result worked because of C's odd rules around function pointer > (de)references. With a stricter compiler these fail to compile. And, with CFI applied to the kernel, would cause a panic. :) Good catch and thanks for the great work! -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
Re: svn commit: r349896 - head/contrib/telnet/telnet
On Fri, Jul 12, 2019 at 01:30:25AM +1000, Bruce Evans wrote:
> On Thu, 11 Jul 2019, Enji Cooper wrote:
>
> > > On Jul 10, 2019, at 3:36 PM, Philip Paeps wrote:
> > >
> > > Author: philip
> > > Date: Wed Jul 10 22:36:14 2019
> > > New Revision: 349896
> > > URL: https://svnweb.freebsd.org/changeset/base/349896
> > >
> > > Log:
> > > telnet: fix minor style violation
> > >
> > > While here also fix a very unlikely NULL pointer dereference.
>
> I see no fix here.
>
> > > Modified: head/contrib/telnet/telnet/commands.c
> > > ==
> > > --- head/contrib/telnet/telnet/commands.c Wed Jul 10 22:23:59 2019
> > > (r349895)
> > > +++ head/contrib/telnet/telnet/commands.c Wed Jul 10 22:36:14 2019
> > > (r349896)
> > > @@ -45,6 +45,7 @@ __FBSDID("$FreeBSD$");
> > > #include
> > > #include
> > >
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -1654,11 +1655,13 @@ env_init(void)
> > > || (strncmp((char *)ep->value, "unix:", 5) == 0))) {
> > > char hbuf[256+1];
> > > char *cp2 = strchr((char *)ep->value, ':');
> > > +size_t buflen;
>
> This adds a different type of style bug (indentation via spaces instead of
> tabs).
>
> > >
> > > gethostname(hbuf, sizeof(hbuf));
> > > hbuf[sizeof(hbuf)-1] = '\0';
> > > -unsigned int buflen = strlen(hbuf) + strlen(cp2) + 1;
> > > + buflen = strlen(hbuf) + strlen(cp2) + 1;
> > > cp = (char *)malloc(sizeof(char)*buflen);
> > > + assert(cp != NULL);
> >
> > This will unfortunately still segfault if assert is compiled out of the
> > system as a no-op (-DNDEBUG).
>
> telnet is unlikely to be compiled with -DNDEBUG, since it didn't use assert()
> before and this commit doesn't change its Makefile to control its new use
> of assert().
>
> Any it doesn't fix the error either. On must arches, it turns a nice
> restartable null pointer trap into an unrestartable abort(). The program
> crashes in both cases.
We're getting into theory, since this particular bug isn't vulnerable
to this particular issue I'm about to bring up, but it is possible to
map at NULL on FreeBSD, given a sysctl has been explicitly toggled by
an administrative user.
I've found it's best to adhere to good defensive programming
techniques, even in cases where doing so may not make immediate sense.
Future developers, even the code's original author(s), may be grateful
later as they make changes.
Thus, even if this particular potential NULL pointer dereference isn't
exploitable in any meaningful way, adherence to defensive programming
practices will help both now and later.
One thing I love about FreeBSD is how it strives to deliver high
quality, correct code. It seems strange that more characters have been
written in emails about the lack of asprintf usage than it would've
taken to actually write the patch to fix it.
Thanks,
--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD
Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID: 0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2
signature.asc
Description: PGP signature
Re: svn commit: r349896 - head/contrib/telnet/telnet
On Thu, Jul 11, 2019 at 01:02:15AM -0700, Enji Cooper wrote:
>
> > On Jul 10, 2019, at 3:36 PM, Philip Paeps wrote:
> >
> > Author: philip
> > Date: Wed Jul 10 22:36:14 2019
> > New Revision: 349896
> > URL: https://svnweb.freebsd.org/changeset/base/349896
> >
> > Log:
> > telnet: fix minor style violation
> >
> > While here also fix a very unlikely NULL pointer dereference.
> >
> > Submitted by: Shawn Webb
> >
> > Modified:
> > head/contrib/telnet/telnet/commands.c
> >
> > Modified: head/contrib/telnet/telnet/commands.c
> > ==
> > --- head/contrib/telnet/telnet/commands.c Wed Jul 10 22:23:59 2019
> > (r349895)
> > +++ head/contrib/telnet/telnet/commands.c Wed Jul 10 22:36:14 2019
> > (r349896)
> > @@ -45,6 +45,7 @@ __FBSDID("$FreeBSD$");
> > #include
> > #include
> >
> > +#include
> > #include
> > #include
> > #include
> > @@ -1654,11 +1655,13 @@ env_init(void)
> > || (strncmp((char *)ep->value, "unix:", 5) == 0))) {
> > char hbuf[256+1];
> > char *cp2 = strchr((char *)ep->value, ':');
> > +size_t buflen;
> >
> > gethostname(hbuf, sizeof(hbuf));
> > hbuf[sizeof(hbuf)-1] = '\0';
> > -unsigned int buflen = strlen(hbuf) + strlen(cp2) + 1;
> > + buflen = strlen(hbuf) + strlen(cp2) + 1;
> > cp = (char *)malloc(sizeof(char)*buflen);
> > + assert(cp != NULL);
>
> This will unfortunately still segfault if assert is compiled out of the
> system as a no-op (-DNDEBUG).
>
> I genuinely think using asprintf instead is the way to go, as Eitan and
> Warner brought up, since it reduces complexity in the program.
https://gist.github.com/d49121a3e9a14b93868360edf32673f1
Thanks,
--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD
Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID: 0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2
signature.asc
Description: PGP signature
Re: svn commit: r349890 - head/contrib/telnet/telnet
On Wed, Jul 10, 2019 at 04:40:25PM -0600, Warner Losh wrote: > On Wed, Jul 10, 2019 at 4:29 PM Shawn Webb > wrote: > > > On Wed, Jul 10, 2019 at 04:22:18PM -0400, Shawn Webb wrote: > > > On Wed, Jul 10, 2019 at 03:19:44PM -0500, Justin Hibbits wrote: > > > > On Wed, 10 Jul 2019 15:55:48 -0400 > > > > Shawn Webb wrote: > > > > > > > > > On Wed, Jul 10, 2019 at 05:42:04PM +, Philip Paeps wrote: > > > > > > Author: philip > > > > > > Date: Wed Jul 10 17:42:04 2019 > > > > > > New Revision: 349890 > > > > > > URL: https://svnweb.freebsd.org/changeset/base/349890 > > > > > > > > > > > > Log: > > > > > > telnet: fix a couple of snprintf() buffer overflows > > > > > > > > > > > > Obtained from:Juniper Networks > > > > > > MFC after:1 week > > > > > > > > > > > > Modified: > > > > > > head/contrib/telnet/telnet/commands.c > > > > > > head/contrib/telnet/telnet/telnet.c > > > > > > head/contrib/telnet/telnet/utilities.c > > > > > > > > > > > > Modified: head/contrib/telnet/telnet/commands.c > > > > > > > > == > > > > > > --- head/contrib/telnet/telnet/commands.c Wed Jul 10 > > > > > > 17:21:59 2019 (r349889) +++ > > > > > > head/contrib/telnet/telnet/commands.c Wed Jul 10 17:42:04 > > > > > > 2019(r349890) @@ -1655,10 +1655,11 @@ env_init(void) char > > > > > > hbuf[256+1]; char *cp2 = strchr((char *)ep->value, ':'); > > > > > > > > > > > > - gethostname(hbuf, 256); > > > > > > - hbuf[256] = '\0'; > > > > > > - cp = (char *)malloc(strlen(hbuf) + strlen(cp2) + > > > > > > 1); > > > > > > - sprintf((char *)cp, "%s%s", hbuf, cp2); > > > > > > + gethostname(hbuf, sizeof(hbuf)); > > > > > > + hbuf[sizeof(hbuf)-1] = '\0'; > > > > > > +unsigned int buflen = strlen(hbuf) + strlen(cp2) + > > > > > > 1; > > > > > > > > > > buflen should be defined with the rest of the variables in the code > > > > > block above this one. > > > > > > > > Agreed. > > > > > > > > > > > > > > > + cp = (char *)malloc(sizeof(char)*buflen); > > > > > > > > > > Lack of NULL check here leads to > > > > > > > > > > > + snprintf((char *)cp, buflen, "%s%s", hbuf, cp2); > > > > > > > > > > potential NULL pointer deref here. > > > > > > > > I'm not sure if this is actually a problem. env_init() is called > > > > exactly once, at the beginning of main(), and the environment size is > > > > fully constrained by the OS. > > > > > > > > That said, this file it the only one in this component that does not > > > > check the return value of malloc(). All other uses, outside of this > > > > file, check and error. > > > > > > While fixing the style(9) violation above, we could still take care of > > > the potential NULL deref at the same time. If anything, just for code > > > correctness reasons? > > > > Here's a patch: > > > > https://gist.github.com/579685c0252673c3ad92d2536c3486c7 > > > Any reason to not use asprintf instead of malloc + snprintf? Because the existing code already used malloc + snprintf. And this is contrib/telnet/telnet, which arguably should be `rm -rf`ed. ;) The bike shed is now glow-in-the-dark neon green. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
Re: svn commit: r349890 - head/contrib/telnet/telnet
On Wed, Jul 10, 2019 at 04:22:18PM -0400, Shawn Webb wrote: > On Wed, Jul 10, 2019 at 03:19:44PM -0500, Justin Hibbits wrote: > > On Wed, 10 Jul 2019 15:55:48 -0400 > > Shawn Webb wrote: > > > > > On Wed, Jul 10, 2019 at 05:42:04PM +, Philip Paeps wrote: > > > > Author: philip > > > > Date: Wed Jul 10 17:42:04 2019 > > > > New Revision: 349890 > > > > URL: https://svnweb.freebsd.org/changeset/base/349890 > > > > > > > > Log: > > > > telnet: fix a couple of snprintf() buffer overflows > > > > > > > > Obtained from:Juniper Networks > > > > MFC after:1 week > > > > > > > > Modified: > > > > head/contrib/telnet/telnet/commands.c > > > > head/contrib/telnet/telnet/telnet.c > > > > head/contrib/telnet/telnet/utilities.c > > > > > > > > Modified: head/contrib/telnet/telnet/commands.c > > > > == > > > > --- head/contrib/telnet/telnet/commands.c Wed Jul 10 > > > > 17:21:59 2019 (r349889) +++ > > > > head/contrib/telnet/telnet/commands.c Wed Jul 10 17:42:04 > > > > 2019(r349890) @@ -1655,10 +1655,11 @@ env_init(void) char > > > > hbuf[256+1]; char *cp2 = strchr((char *)ep->value, ':'); > > > > > > > > - gethostname(hbuf, 256); > > > > - hbuf[256] = '\0'; > > > > - cp = (char *)malloc(strlen(hbuf) + strlen(cp2) + > > > > 1); > > > > - sprintf((char *)cp, "%s%s", hbuf, cp2); > > > > + gethostname(hbuf, sizeof(hbuf)); > > > > + hbuf[sizeof(hbuf)-1] = '\0'; > > > > +unsigned int buflen = strlen(hbuf) + strlen(cp2) + > > > > 1; > > > > > > buflen should be defined with the rest of the variables in the code > > > block above this one. > > > > Agreed. > > > > > > > > > + cp = (char *)malloc(sizeof(char)*buflen); > > > > > > Lack of NULL check here leads to > > > > > > > + snprintf((char *)cp, buflen, "%s%s", hbuf, cp2); > > > > > > potential NULL pointer deref here. > > > > I'm not sure if this is actually a problem. env_init() is called > > exactly once, at the beginning of main(), and the environment size is > > fully constrained by the OS. > > > > That said, this file it the only one in this component that does not > > check the return value of malloc(). All other uses, outside of this > > file, check and error. > > While fixing the style(9) violation above, we could still take care of > the potential NULL deref at the same time. If anything, just for code > correctness reasons? Here's a patch: https://gist.github.com/579685c0252673c3ad92d2536c3486c7 Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
Re: svn commit: r349890 - head/contrib/telnet/telnet
On Wed, Jul 10, 2019 at 03:19:44PM -0500, Justin Hibbits wrote: > On Wed, 10 Jul 2019 15:55:48 -0400 > Shawn Webb wrote: > > > On Wed, Jul 10, 2019 at 05:42:04PM +, Philip Paeps wrote: > > > Author: philip > > > Date: Wed Jul 10 17:42:04 2019 > > > New Revision: 349890 > > > URL: https://svnweb.freebsd.org/changeset/base/349890 > > > > > > Log: > > > telnet: fix a couple of snprintf() buffer overflows > > > > > > Obtained from: Juniper Networks > > > MFC after: 1 week > > > > > > Modified: > > > head/contrib/telnet/telnet/commands.c > > > head/contrib/telnet/telnet/telnet.c > > > head/contrib/telnet/telnet/utilities.c > > > > > > Modified: head/contrib/telnet/telnet/commands.c > > > == > > > --- head/contrib/telnet/telnet/commands.c Wed Jul 10 > > > 17:21:59 2019 (r349889) +++ > > > head/contrib/telnet/telnet/commands.c Wed Jul 10 17:42:04 > > > 2019 (r349890) @@ -1655,10 +1655,11 @@ env_init(void) char > > > hbuf[256+1]; char *cp2 = strchr((char *)ep->value, ':'); > > > > > > - gethostname(hbuf, 256); > > > - hbuf[256] = '\0'; > > > - cp = (char *)malloc(strlen(hbuf) + strlen(cp2) + > > > 1); > > > - sprintf((char *)cp, "%s%s", hbuf, cp2); > > > + gethostname(hbuf, sizeof(hbuf)); > > > + hbuf[sizeof(hbuf)-1] = '\0'; > > > +unsigned int buflen = strlen(hbuf) + strlen(cp2) + > > > 1; > > > > buflen should be defined with the rest of the variables in the code > > block above this one. > > Agreed. > > > > > > + cp = (char *)malloc(sizeof(char)*buflen); > > > > Lack of NULL check here leads to > > > > > + snprintf((char *)cp, buflen, "%s%s", hbuf, cp2); > > > > potential NULL pointer deref here. > > I'm not sure if this is actually a problem. env_init() is called > exactly once, at the beginning of main(), and the environment size is > fully constrained by the OS. > > That said, this file it the only one in this component that does not > check the return value of malloc(). All other uses, outside of this > file, check and error. While fixing the style(9) violation above, we could still take care of the potential NULL deref at the same time. If anything, just for code correctness reasons? Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
Re: svn commit: r349890 - head/contrib/telnet/telnet
On Wed, Jul 10, 2019 at 05:42:04PM +, Philip Paeps wrote: > Author: philip > Date: Wed Jul 10 17:42:04 2019 > New Revision: 349890 > URL: https://svnweb.freebsd.org/changeset/base/349890 > > Log: > telnet: fix a couple of snprintf() buffer overflows > > Obtained from: Juniper Networks > MFC after: 1 week > > Modified: > head/contrib/telnet/telnet/commands.c > head/contrib/telnet/telnet/telnet.c > head/contrib/telnet/telnet/utilities.c > > Modified: head/contrib/telnet/telnet/commands.c > == > --- head/contrib/telnet/telnet/commands.c Wed Jul 10 17:21:59 2019 > (r349889) > +++ head/contrib/telnet/telnet/commands.c Wed Jul 10 17:42:04 2019 > (r349890) > @@ -1655,10 +1655,11 @@ env_init(void) > char hbuf[256+1]; > char *cp2 = strchr((char *)ep->value, ':'); > > - gethostname(hbuf, 256); > - hbuf[256] = '\0'; > - cp = (char *)malloc(strlen(hbuf) + strlen(cp2) + 1); > - sprintf((char *)cp, "%s%s", hbuf, cp2); > + gethostname(hbuf, sizeof(hbuf)); > + hbuf[sizeof(hbuf)-1] = '\0'; > +unsigned int buflen = strlen(hbuf) + strlen(cp2) + 1; buflen should be defined with the rest of the variables in the code block above this one. > + cp = (char *)malloc(sizeof(char)*buflen); Lack of NULL check here leads to > + snprintf((char *)cp, buflen, "%s%s", hbuf, cp2); potential NULL pointer deref here. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
Re: svn commit: r349343 - in head: stand/common stand/efi/loader sys/kern sys/sys
On Mon, Jun 24, 2019 at 08:34:54PM +, Warner Losh wrote: > Author: imp > Date: Mon Jun 24 20:34:53 2019 > New Revision: 349343 > URL: https://svnweb.freebsd.org/changeset/base/349343 > > Log: > Move to using a common kernel path between the boot / laoder bits and > the kernel. I wonder if there'd be any advantage to wrapping these macros in #ifdef and providing the plumbing such that users could overwrite these defaults in their kernel configuration files. I'm just thinking out loud. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
Re: svn commit: r349243 - head/sys/cam
+1 for M_ZERO.
--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD
Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID: 0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2
On Thu, Jun 20, 2019 at 04:59:48PM -0600, Scott Long wrote:
> Hi Alexander,
>
> I???m not a fan of removing the M_ZERO. I understand your argument that
> lengths are provided elsewhere, but having the buffer be zero???d is defensive
> against future bugs that might leak buffer contents. GETATTR isn???t
> typically
> in a performance path, is there any measurable benefit to this?
>
> Thanks,
> Scott
>
>
> > On Jun 20, 2019, at 2:29 PM, Alexander Motin wrote:
> >
> > Author: mav
> > Date: Thu Jun 20 20:29:42 2019
> > New Revision: 349243
> > URL: https://svnweb.freebsd.org/changeset/base/349243
> >
> > Log:
> > Optimize xpt_getattr().
> >
> > Do not allocate temporary buffer for attributes we are going to return
> > as-is, just make sure to NUL-terminate them. Do not zero temporary 64KB
> > buffer for CDAI_TYPE_SCSI_DEVID, XPT tells us how much data it filled
> > and there are also length fields inside the returned data also.
> >
> > MFC after: 2 weeks
> > Sponsored by: iXsystems, Inc.
> >
> > Modified:
> > head/sys/cam/cam_xpt.c
> >
> > Modified: head/sys/cam/cam_xpt.c
> > ==
> > --- head/sys/cam/cam_xpt.c Thu Jun 20 20:06:19 2019(r349242)
> > +++ head/sys/cam/cam_xpt.c Thu Jun 20 20:29:42 2019(r349243)
> > @@ -1253,6 +1253,7 @@ xpt_getattr(char *buf, size_t len, const char *attr, s
> > cdai.ccb_h.func_code = XPT_DEV_ADVINFO;
> > cdai.flags = CDAI_FLAG_NONE;
> > cdai.bufsiz = len;
> > + cdai.buf = buf;
> >
> > if (!strcmp(attr, "GEOM::ident"))
> > cdai.buftype = CDAI_TYPE_SERIAL_NUM;
> > @@ -1262,14 +1263,14 @@ xpt_getattr(char *buf, size_t len, const char
> > *attr, s
> > strcmp(attr, "GEOM::lunname") == 0) {
> > cdai.buftype = CDAI_TYPE_SCSI_DEVID;
> > cdai.bufsiz = CAM_SCSI_DEVID_MAXLEN;
> > + cdai.buf = malloc(cdai.bufsiz, M_CAMXPT, M_NOWAIT);
> > + if (cdai.buf == NULL) {
> > + ret = ENOMEM;
> > + goto out;
> > + }
> > } else
> > goto out;
> >
> > - cdai.buf = malloc(cdai.bufsiz, M_CAMXPT, M_NOWAIT|M_ZERO);
> > - if (cdai.buf == NULL) {
> > - ret = ENOMEM;
> > - goto out;
> > - }
> > xpt_action((union ccb *)); /* can only be synchronous */
> > if ((cdai.ccb_h.status & CAM_DEV_QFRZN) != 0)
> > cam_release_devq(cdai.ccb_h.path, 0, 0, 0, FALSE);
> > @@ -1334,13 +1335,15 @@ xpt_getattr(char *buf, size_t len, const char
> > *attr, s
> > ret = EFAULT;
> > }
> > } else {
> > - ret = 0;
> > - if (strlcpy(buf, cdai.buf, len) >= len)
> > + if (cdai.provsiz < len) {
> > + cdai.buf[cdai.provsiz] = 0;
> > + ret = 0;
> > + } else
> > ret = EFAULT;
> > }
> >
> > out:
> > - if (cdai.buf != NULL)
> > + if ((char *)cdai.buf != buf)
> > free(cdai.buf, M_CAMXPT);
> > return ret;
> > }
> >
>
> ___
> svn-src-all@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-all
> To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
signature.asc
Description: PGP signature
Re: svn commit: r349176 - head/sys/dev/random
On Tue, Jun 18, 2019 at 12:46:44PM -0700, Cy Schubert wrote: > In message <20190618185512.e2nbzwbtvxz2azge@mutt-hbsd>, Shawn Webb > writes: > > > > --mmc352mzirnzscxj > > Content-Type: text/plain; charset=us-ascii > > Content-Disposition: inline > > Content-Transfer-Encoding: quoted-printable > > > > On Tue, Jun 18, 2019 at 06:50:58PM +, Conrad Meyer wrote: > > > Author: cem > > > Date: Tue Jun 18 18:50:58 2019 > > > New Revision: 349176 > > > URL: https://svnweb.freebsd.org/changeset/base/349176 > > >=20 > > > Log: > > > random(4): Fix a regression in short AES mode reads > > > =20 > > > In r349154, random device reads of size < 16 bytes (AES block size) were > > > accidentally broken to loop forever. Correct the loop condition for sm= > > all > > > reads. > > > =20 > > > Reported by:pho > > > Reviewed by:delphij > > > Approved by:secteam(delphij) > > > Differential Revision: https://reviews.freebsd.org/D20686 > > > > Hey Conrad, > > > > Thanks for fixing this issue! Any plans to MFC? > > Why? Whoops. I didn't catch the condition on the revision number. Sorry for the line noise! -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
Re: svn commit: r349176 - head/sys/dev/random
On Tue, Jun 18, 2019 at 06:50:58PM +, Conrad Meyer wrote: > Author: cem > Date: Tue Jun 18 18:50:58 2019 > New Revision: 349176 > URL: https://svnweb.freebsd.org/changeset/base/349176 > > Log: > random(4): Fix a regression in short AES mode reads > > In r349154, random device reads of size < 16 bytes (AES block size) were > accidentally broken to loop forever. Correct the loop condition for small > reads. > > Reported by:pho > Reviewed by:delphij > Approved by:secteam(delphij) > Differential Revision: https://reviews.freebsd.org/D20686 Hey Conrad, Thanks for fixing this issue! Any plans to MFC? Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
Re: svn commit: r348843 - head/sys/vm
On Tue, Jun 11, 2019 at 01:33:23AM +1000, Bruce Evans wrote: > On Mon, 10 Jun 2019, Shawn Webb wrote: > > > On Mon, Jun 10, 2019 at 03:07:11AM +, Doug Moore wrote: > > > ... > > > Log: > > > There are times when a len==0 parameter to mmap is okay. But on a > > > 32-bit machine, a len parameter just a few bytes short of 4G, rounded > > > up to a page boundary and hitting zero then, is not okay. Return > > > failure in that case. > > > ... > > > /* Adjust size for rounding (on both ends). */ > > > size += pageoff;/* low end... */ > > > - size = (vm_size_t) round_page(size);/* hi end */ > > > + /* Check for rounding up to zero. */ > > > + if (round_page(size) < size) > > > + return (EINVAL); > > > > The mmap(2) manpage says that len==0 results in EINVAL, so the manpage > > needs updating. > > The man page doesn't say that only len == 0 results in EINVAL, so it is > not incorrect. https://github.com/freebsd/freebsd/blob/master/lib/libc/sys/mmap.2#L451-L455 Tons of error conditions listed, one of which is len==0. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
Re: svn commit: r348843 - head/sys/vm
Sounds good! I think the manpage still might still need a change to match the current behavior, or perhaps matching something similar to that vm_mmap.c comment. But that comment brings another question: what's the definition of "old binaries"? a.out? Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 On Mon, Jun 10, 2019 at 09:19:55AM -0500, Doug Moore wrote: > This comment appears in vm_mmap.c: > > * Mapping of length 0 is only allowed for old binaries. > > and my intent was to say, to whoever wrote that comment, that I was not > disallowing the mapping of length zero with this change.? I was only > intending to affect a case in which the length was transformed to zero, > and which was the problem that Peter Holm reported. > > Doug Moore > > On 6/10/19 8:00 AM, Shawn Webb wrote: > > On Mon, Jun 10, 2019 at 03:07:11AM +, Doug Moore wrote: > >> Author: dougm > >> Date: Mon Jun 10 03:07:10 2019 > >> New Revision: 348843 > >> URL: https://svnweb.freebsd.org/changeset/base/348843 > >> > >> Log: > >> There are times when a len==0 parameter to mmap is okay. But on a > >> 32-bit machine, a len parameter just a few bytes short of 4G, rounded > >> up to a page boundary and hitting zero then, is not okay. Return > >> failure in that case. > >> > >> Reported by: pho > >> Reviewed by: alc, kib (mentor) > >> Tested by: pho > >> Differential Revision: https://reviews.freebsd.org/D20580 > >> > >> Modified: > >> head/sys/vm/vm_mmap.c > >> > >> Modified: head/sys/vm/vm_mmap.c > >> == > >> --- head/sys/vm/vm_mmap.c Sun Jun 9 22:55:21 2019(r348842) > >> +++ head/sys/vm/vm_mmap.c Mon Jun 10 03:07:10 2019(r348843) > >> @@ -257,7 +257,10 @@ kern_mmap(struct thread *td, uintptr_t addr0, size_t s > >> > >>/* Adjust size for rounding (on both ends). */ > >>size += pageoff;/* low end... */ > >> - size = (vm_size_t) round_page(size);/* hi end */ > >> + /* Check for rounding up to zero. */ > >> + if (round_page(size) < size) > >> + return (EINVAL); > > The mmap(2) manpage says that len==0 results in EINVAL, so the manpage > > needs updating. > > > > I'm curious what "there are times" refers to. Can you or the original > > reporter elaborate those cases? > > > > Thanks a lot! > > signature.asc Description: PGP signature
Re: svn commit: r348843 - head/sys/vm
On Mon, Jun 10, 2019 at 03:07:11AM +, Doug Moore wrote: > Author: dougm > Date: Mon Jun 10 03:07:10 2019 > New Revision: 348843 > URL: https://svnweb.freebsd.org/changeset/base/348843 > > Log: > There are times when a len==0 parameter to mmap is okay. But on a > 32-bit machine, a len parameter just a few bytes short of 4G, rounded > up to a page boundary and hitting zero then, is not okay. Return > failure in that case. > > Reported by: pho > Reviewed by: alc, kib (mentor) > Tested by: pho > Differential Revision: https://reviews.freebsd.org/D20580 > > Modified: > head/sys/vm/vm_mmap.c > > Modified: head/sys/vm/vm_mmap.c > == > --- head/sys/vm/vm_mmap.c Sun Jun 9 22:55:21 2019(r348842) > +++ head/sys/vm/vm_mmap.c Mon Jun 10 03:07:10 2019(r348843) > @@ -257,7 +257,10 @@ kern_mmap(struct thread *td, uintptr_t addr0, size_t s > > /* Adjust size for rounding (on both ends). */ > size += pageoff;/* low end... */ > - size = (vm_size_t) round_page(size);/* hi end */ > + /* Check for rounding up to zero. */ > + if (round_page(size) < size) > + return (EINVAL); The mmap(2) manpage says that len==0 results in EINVAL, so the manpage needs updating. I'm curious what "there are times" refers to. Can you or the original reporter elaborate those cases? Thanks a lot! -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
Re: svn commit: r348802 - head/sys/amd64/amd64
On Sat, Jun 08, 2019 at 04:03:34PM +, Konstantin Belousov wrote: > Author: kib > Date: Sat Jun 8 16:03:34 2019 > New Revision: 348802 > URL: https://svnweb.freebsd.org/changeset/base/348802 > > Log: > Remove lazy FPU switch support from amd64. > > It is incompatible with some future features. Hey Kostik, Great work! I'm curious what those future features could be. Can you elaborate a little more? :) Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
Re: svn commit: r348611 - in head/sys: conf kern
On Tue, Jun 04, 2019 at 01:07:10PM +, Ed Maste wrote: > Author: emaste > Date: Tue Jun 4 13:07:10 2019 > New Revision: 348611 > URL: https://svnweb.freebsd.org/changeset/base/348611 > > Log: > Expose the kernel's build-ID through sysctl > > After our migration (of certain architectures) to lld the kernel is built > with a unique build-ID. Make it available via a sysctl and uname(1) to > allow the user to identify their running kernel. > > Submitted by: Ali Mashtizadeh > MFC after: 2 weeks > Relnotes: Yes > Event: Waterloo Hackathon 2019 > Differential Revision: https://reviews.freebsd.org/D20326 Does this impact reproducible builds at all? Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
Re: svn commit: r348504 - in head: lib/clang/libllvm tools/build/mk usr.bin/clang
On Sun, Jun 02, 2019 at 04:04:21AM +, Kyle Evans wrote: > Author: kevans > Date: Sun Jun 2 04:04:21 2019 > New Revision: 348504 > URL: https://svnweb.freebsd.org/changeset/base/348504 > > Log: > llvm-symbolizer: Move out of CLANG_EXTRAS, into CLANG > > ASAN reports become a lot more useful with llvm-symbolizer in $PATH, and the > build is not much more time-consuming. The added benefit is that the > resulting reports will actually include symbol information; without, thread > trace information includes a bunch of addresses that immediately resolve to > an inline function in > ^/contrib/compiler-rt/lib/sanitizer_common/sanitizer_common.h and take a > little more effort to examine. > > Reviewed by:emaste > MFC after: 1 week > Differential Revision: https://reviews.freebsd.org/D20484 > > Modified: > head/lib/clang/libllvm/Makefile > head/tools/build/mk/OptionalObsoleteFiles.inc > head/usr.bin/clang/Makefile > > Modified: head/lib/clang/libllvm/Makefile > == > --- head/lib/clang/libllvm/Makefile Sun Jun 2 02:38:44 2019 > (r348503) > +++ head/lib/clang/libllvm/Makefile Sun Jun 2 04:04:21 2019 > (r348504) > @@ -523,7 +523,7 @@ SRCS_EXT+= > DebugInfo/PDB/PDBSymbolTypeVTableShape.cpp > SRCS_EXT+= DebugInfo/PDB/PDBSymbolUnknown.cpp > SRCS_EXT+= DebugInfo/PDB/PDBSymbolUsingNamespace.cpp > SRCS_EXT+= DebugInfo/PDB/UDTLayout.cpp > -SRCS_EXT+= DebugInfo/Symbolize/DIPrinter.cpp > +SRCS_MIW+= DebugInfo/Symbolize/DIPrinter.cpp > SRCS_MIW+= DebugInfo/Symbolize/SymbolizableObjectFile.cpp > SRCS_MIW+= DebugInfo/Symbolize/Symbolize.cpp Is SRCS_MIW the right spelling? Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
Re: svn commit: r346263 - head/contrib/tcpdump
On Tue, Apr 16, 2019 at 04:12:42AM +, Mariusz Zaborski wrote: > Author: oshogbo > Date: Tue Apr 16 04:12:41 2019 > New Revision: 346263 > URL: https://svnweb.freebsd.org/changeset/base/346263 > > Log: > tcpdump: disable Capsicum if -E option is provided. > > The -E is used to provide a secret for decrypting IPsec. > The secret may be provided through command line or as the file. > The problem is that tcpdump doesn't support yet opening files in capability > mode > and the file may contain a list of the files to open. > > As a workaround, for now, let's just disable capsicum if the -E > the option is provided. > > PR: 236819 > MFC after: 2 weeks > > Modified: > head/contrib/tcpdump/tcpdump.c > > Modified: head/contrib/tcpdump/tcpdump.c > == > --- head/contrib/tcpdump/tcpdump.cTue Apr 16 02:48:04 2019 > (r346262) > +++ head/contrib/tcpdump/tcpdump.cTue Apr 16 04:12:41 2019 > (r346263) > @@ -2063,7 +2063,8 @@ main(int argc, char **argv) > } > > #ifdef HAVE_CAPSICUM > - cansandbox = (VFileName == NULL && zflag == NULL); > + cansandbox = (VFileName == NULL && zflag == NULL && > + ndo->ndo_espsecret == NULL); > #ifdef HAVE_CASPER > cansandbox = (cansandbox && (ndo->ndo_nflag || capdns != NULL)); > #else Is there any documentation anywhere telling users that Capsicum support will be disabled under certain circumstances? Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
Re: svn commit: r346023 - head/usr.bin/strings
On Mon, Apr 08, 2019 at 03:35:48AM +, Mariusz Zaborski wrote: > Author: oshogbo > Date: Mon Apr 8 03:35:47 2019 > New Revision: 346023 > URL: https://svnweb.freebsd.org/changeset/base/346023 > > Log: > strings: disable Casper support while building native-xtools Why? -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
Re: svn commit: r345982 - in head: include lib/libc/sys sys/cddl/compat/opensolaris/sys sys/compat/cloudabi sys/compat/freebsd32 sys/compat/linux sys/kern sys/sys sys/ufs/ffs
No worries. Thanks for the correction!
--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD
Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2
On Sun, Apr 07, 2019 at 06:11:58PM +0200, Mariusz Zaborski wrote:
> In the https://wiki.freebsd.org/AddingSyscalls we mentions that we need to
> bump
> __FreeBSD_version. I confirmed that with Warner. So this was my mistake.
>
> Thanks Shawn.
> --
> Mariusz Zaborski
> oshogbo//vx | http://oshogbo.vexillium.org
> FreeBSD committer | https://freebsd.org
> Software developer| http://wheelsystems.com
> If it's not broken, let's fix it till it is!!1
>
> On Sun, Apr 07, 2019 at 08:35:07AM -0700, Cy Schubert wrote:
> > In message <201904071510.x37fa7tm050...@gndrsh.dnsmgr.net>, "Rodney W.
> > Grimes"
> > writes:
> > > > On April 7, 2019 7:11:52 AM PDT, Shawn Webb
> > > > wr
> > > ote:
> > > > >On Sat, Apr 06, 2019 at 09:34:26AM +, Mariusz Zaborski wrote:
> > > > >> Author: oshogbo
> > > > >> Date: Sat Apr 6 09:34:26 2019
> > > > >> New Revision: 345982
> > > > >> URL: https://svnweb.freebsd.org/changeset/base/345982
> > > > >>
> > > > >> Log:
> > > > >> Introduce funlinkat syscall that always us to check if we are
> > > > >removing
> > > > >> the file associated with the given file descriptor.
> > > > >>
> > > > >> Reviewed by: kib, asomers
> > > > >> Reviewed by: cem, jilles, brooks (they reviewed previous
> > > > >> version)
> > > > >> Discussed with:pjd, and many others
> > > > >> Differential Revision: https://reviews.freebsd.org/D14567
> > > > >
> > > > >Hey Mariusz,
> > > > >
> > > > >Is __FreeBSD_version supposed to be bumped after adding new syscalls?
> > > > >I can't remember off-hand.
> > > > >
> > > > >Thanks,
> > > >
> > > > I don't think so. Why force the rebuild of all ports through poudriere
> > > > over
> > > something that would never affect any of them?
> > >
> > > So that you can if version >= foo to know it is safe to use the new
> > > syscal?
> > > Or if version < foo you must use the old way.
> >
> > Granted. However we do need something to avoid gratuitous rebuilds of
> > ports.
> >
> > Personally, my poudriere script adjusts the pkg version
> > ($JAILPATH/data/packages/${JAIL}-${PORTS}/.building/.jailversion) with
> > that of the jail version (reported by poudriere jail -i -j $JAIL),
> > rebuilding all ports when I (the human) determines when the machine
> > should rebuild all ports with -c.
> >
> > In that regard FreeBSD version bumps occasionally seem a little
> > gratuitous. Using the same indicator to tell whether software should be
> > able to use a new feature and when ports build infrastructure should
> > summarily delete all packages forcing a rebuild of absolutely
> > everything is probably not the best.
> >
> > Just throwing out an idea, what if poudriere considers the first N
> > bytes of __FreeBSD_version significant? Having said that, looking at
> > __FreeBSD_version, I don't think we have enough digits to do what I was
> > planning on suggesting. But, you get the idea of what I'm driving at.
> > Maybe a new macro such as __FreeBSD_ports that is incremented every
> > time a change that affects ports?
> >
> > Anyhow, I'm not too terribly concerned as what I have (selfishly
> > speaking) works. But we may as a group might want to consider this at
> > some point to build some efficiency into the ports part of the equation.
> >
> >
> > --
> > Cheers,
> > Cy Schubert
> > FreeBSD UNIX: Web: http://www.FreeBSD.org
> >
> > The need of the many outweighs the greed of the few.
> >
> >
signature.asc
Description: PGP signature
Re: svn commit: r345982 - in head: include lib/libc/sys sys/cddl/compat/opensolaris/sys sys/compat/cloudabi sys/compat/freebsd32 sys/compat/linux sys/kern sys/sys sys/ufs/ffs
On Sat, Apr 06, 2019 at 09:34:26AM +, Mariusz Zaborski wrote: > Author: oshogbo > Date: Sat Apr 6 09:34:26 2019 > New Revision: 345982 > URL: https://svnweb.freebsd.org/changeset/base/345982 > > Log: > Introduce funlinkat syscall that always us to check if we are removing > the file associated with the given file descriptor. > > Reviewed by:kib, asomers > Reviewed by:cem, jilles, brooks (they reviewed previous version) > Discussed with: pjd, and many others > Differential Revision: https://reviews.freebsd.org/D14567 Hey Mariusz, Is __FreeBSD_version supposed to be bumped after adding new syscalls? I can't remember off-hand. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
Re: svn commit: r344861 - in stable/11: sbin/fsck_ffs sbin/fsdb sys/ufs/ffs
On Thu, Mar 07, 2019 at 09:17:55PM -0600, Kyle Evans wrote: > On Thu, Mar 7, 2019 at 8:33 PM Shawn Webb wrote: > > > > On Wed, Mar 06, 2019 at 11:59:56PM +, Kirk McKusick wrote: > > > Author: mckusick > > > Date: Wed Mar 6 23:59:56 2019 > > > New Revision: 344861 > > > URL: https://svnweb.freebsd.org/changeset/base/344861 > > > > > > Log: > > > MFC of 344552 and 344732 > > > > > > Have fsck_ffs adjust size for files with hole at end > > > > > > Tighten last lbn calculation > > > > > > Sponsored by: Netflix > > > > > > [.. snip ..] > > > > Hey Kirk, > > > > This MFC breaks buildworld: > > > > http://jenkins.hardenedbsd.org/jenkins/job/HardenedBSD-11-STABLE-amd64/904/console > > > > I'll take a look at providing a patch to fix it soon, unless you're > > able to get to it before I am. > > > > I believe kib MFC'd the missing bits earlier today in r344885 and > r344887. stable/11 and stable/12 are both happy again in CI. Good catch! Thanks for the clarification! -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: svn commit: r344861 - in stable/11: sbin/fsck_ffs sbin/fsdb sys/ufs/ffs
11/sbin/fsdb/fsdb.cWed Mar 6 23:59:56 2019
> (r344861)
> @@ -157,6 +157,7 @@ CMDFUNC(chctime); /* Change ctime */
> CMDFUNC(chatime);/* Change atime */
> CMDFUNC(chinum); /* Change inode # of dirent */
> CMDFUNC(chname); /* Change dirname of dirent */
> +CMDFUNC(chsize); /* Change size */
>
> struct cmdtable cmds[] = {
> { "help", "Print out help", 1, 1, FL_RO, helpfn },
> @@ -186,6 +187,7 @@ struct cmdtable cmds[] = {
> { "chgrp", "Change group of current inode to GROUP", 2, 2, FL_WR,
> chgroup },
> { "chflags", "Change flags of current inode to FLAGS", 2, 2, FL_WR,
> chaflags },
> { "chgen", "Change generation number of current inode to GEN", 2, 2,
> FL_WR, chgen },
> + { "chsize", "Change size of current inode to SIZE", 2, 2, FL_WR, chsize
> },
> { "btime", "Change btime of current inode to BTIME", 2, 2, FL_WR,
> chbtime },
> { "mtime", "Change mtime of current inode to MTIME", 2, 2, FL_WR,
> chmtime },
> { "ctime", "Change ctime of current inode to CTIME", 2, 2, FL_WR,
> chctime },
> @@ -1009,6 +1011,31 @@ CMDFUNCSTART(chgen)
> }
> DIP_SET(curinode, di_gen, gen);
> inodirty();
> +printactive(0);
> +return rval;
> +}
> +
> +CMDFUNCSTART(chsize)
> +{
> +int rval = 1;
> +off_t size;
> +char *cp;
> +
> +if (!checkactive())
> + return 1;
> +
> +size = strtoll(argv[1], , 0);
> +if (cp == argv[1] || *cp != '\0') {
> + warnx("bad size `%s'", argv[1]);
> + return 1;
> +}
> +
> +if (size < 0) {
> + warnx("size set to negative (%jd)\n", (intmax_t)size);
> + return(1);
> +}
> +DIP_SET(curinode, di_size, size);
> +inodirty(curinode);
> printactive(0);
> return rval;
> }
>
> Modified: stable/11/sys/ufs/ffs/ffs_alloc.c
> ==
> --- stable/11/sys/ufs/ffs/ffs_alloc.c Wed Mar 6 23:54:55 2019
> (r344860)
> +++ stable/11/sys/ufs/ffs/ffs_alloc.c Wed Mar 6 23:59:56 2019
> (r344861)
> @@ -2688,6 +2688,8 @@ ffs_fserr(fs, inum, cp)
> * the count to zero will cause the inode to be freed.
> * adjblkcnt(inode, amt) - adjust the number of blocks used by the
> * inode by the specified amount.
> + * adjsize(inode, size) - set the size of the inode to the
> + * specified size.
> * adjndir, adjbfree, adjifree, adjffree, adjnumclusters(amt) -
> * adjust the superblock summary.
> * freedirs(inode, count) - directory inodes [inode..inode + count - 1]
> @@ -2729,6 +2731,9 @@ SYSCTL_PROC(_vfs_ffs, FFS_ADJ_REFCNT, adjrefcnt, CTLFL
> static SYSCTL_NODE(_vfs_ffs, FFS_ADJ_BLKCNT, adjblkcnt, CTLFLAG_WR,
> sysctl_ffs_fsck, "Adjust Inode Used Blocks Count");
>
> +static SYSCTL_NODE(_vfs_ffs, FFS_SET_SIZE, setsize, CTLFLAG_WR,
> + sysctl_ffs_fsck, "Set the inode size");
> +
> static SYSCTL_NODE(_vfs_ffs, FFS_ADJ_NDIR, adjndir, CTLFLAG_WR,
> sysctl_ffs_fsck, "Adjust number of directories");
>
> @@ -2875,6 +2880,23 @@ sysctl_ffs_fsck(SYSCTL_HANDLER_ARGS)
> break;
> ip = VTOI(vp);
> DIP_SET(ip, i_blocks, DIP(ip, i_blocks) + cmd.size);
> + ip->i_flag |= IN_CHANGE | IN_MODIFIED;
> + error = ffs_update(vp, 1);
> + vput(vp);
> + break;
> +
> + case FFS_SET_SIZE:
> +#ifdef DEBUG
> + if (fsckcmds) {
> + printf("%s: set inode %jd size to %jd\n",
> + mp->mnt_stat.f_mntonname, (intmax_t)cmd.value,
> + (intmax_t)cmd.size);
> + }
> +#endif /* DEBUG */
> + if ((error = ffs_vget(mp, (ino_t)cmd.value, LK_EXCLUSIVE, )))
> + break;
> + ip = VTOI(vp);
> + DIP_SET(ip, i_size, cmd.size);
> ip->i_flag |= IN_CHANGE | IN_MODIFIED;
> error = ffs_update(vp, 1);
> vput(vp);
>
> Modified: stable/11/sys/ufs/ffs/fs.h
> ==
> --- stable/11/sys/ufs/ffs/fs.hWed Mar 6 23:54:55 2019
> (r344860)
> +++ stable/11/sys/ufs/ffs/fs.hWed Mar 6 23:59:56 2019
> (r344861)
> @@ -219,7 +219,8 @@
> #define FFS_UNLINK 14 /* remove a name in the
> filesystem */
> #define FFS_SET_INODE 15 /* update an on-disk inode */
> #define FFS_SET_BUFOUTPUT 16 /* set buffered writing on
> descriptor */
> -#define FFS_MAXID 16 /* number of valid ffs ids */
> +#define FFS_SET_SIZE17 /* set inode size */
> +#define FFS_MAXID 17 /* number of valid ffs ids */
Hey Kirk,
This MFC breaks buildworld:
http://jenkins.hardenedbsd.org/jenkins/job/HardenedBSD-11-STABLE-amd64/904/console
I'll take a look at providing a patch to fix it soon, unless you're
able to get to it before I am.
Thanks,
--
Shawn Webb
Cofounder and Security Engineer
HardenedBSD
Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
signature.asc
Description: PGP signature
Re: svn commit: r344913 - head/sys/dev/random
Hey Conrad, On Fri, Mar 08, 2019 at 01:17:20AM +, Conrad Meyer wrote: > Author: cem > Date: Fri Mar 8 01:17:20 2019 > New Revision: 344913 > URL: https://svnweb.freebsd.org/changeset/base/344913 > > Log: > Fortuna: Add Chacha20 as an alternative stream cipher > > Chacha20 with a 256 bit key and 128 bit counter size is a good match for an > AES256-ICM replacement. > > In userspace, Chacha20 is typically marginally slower than AES-ICM on > machines with AESNI intrinsics, but typically much faster than AES on > machines without special intrinsics. ChaCha20 does well on typical modern > architectures with SIMD instructions, which includes most types of machines > FreeBSD runs on. > > In the kernel, we can't (or don't) make use of AESNI intrinsics for > random(4) anyway. So even on amd64, using Chacha provides a modest > performance improvement in random device throughput today. > > This change makes the stream cipher used by random(4) configurable at boot > time with the 'kern.random.use_chacha20_cipher' tunable. > > Very rough, non-scientific measurements at the /dev/random device, on a > GENERIC-NODEBUG amd64 VM with 'pv', show a factor of 2.2x higher throughput > for Chacha20 over the existing AES-ICM mode. > > Reviewed by:delphij, markm > Approved by:secteam (delphij) > Differential Revision: https://reviews.freebsd.org/D19475 > > Modified: > head/sys/dev/random/fortuna.c > head/sys/dev/random/hash.c > head/sys/dev/random/hash.h > head/sys/dev/random/uint128.h > > Modified: head/sys/dev/random/hash.c > == > --- head/sys/dev/random/hash.cFri Mar 8 01:04:19 2019 > (r344912) > +++ head/sys/dev/random/hash.cFri Mar 8 01:17:20 2019 > (r344913) > +/* Validate that full Chacha IV is as large as the 128-bit counter */ > +_Static_assert(CHACHA_STATELEN == RANDOM_BLOCKSIZE, ""); > + > +/* > + * Experimental Chacha20-based PRF for Fortuna keystream primitive. For now, > + * disabled by default. But we may enable it in the future. > + * > + * Benefits include somewhat faster keystream generation compared with > + * unaccelerated AES-ICM. > + */ > +bool random_chachamode = false; > +#ifdef _KERNEL > +SYSCTL_BOOL(_kern_random, OID_AUTO, use_chacha20_cipher, CTLFLAG_RDTUN, > +_chachamode, 0, > +"If non-zero, use the ChaCha20 cipher for randomdev PRF. " > +"If zero, use AES-ICM cipher for randomdev PRF (default)."); > +#endif I'm curious if that sysctl node could be documented in a manpage, perhaps the random(4) manpage would be a good candidate for updating. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: svn commit: r344487 - in head/sys: conf gnu/gcov
On Tue, Feb 26, 2019 at 10:18:45AM -0700, Warner Losh wrote: > On Tue, Feb 26, 2019 at 8:46 AM Shawn Webb > wrote: > > > On Mon, Feb 25, 2019 at 06:18:42PM -0800, Rodney W. Grimes wrote: > > > > > The modest increase in activation energy for that task seems worth it > > > > > for the short-term gains of reduced integration cost (this code will > > > > > greatly improve our ZFS-on-Linux test coverage.) > > > > > > > > > > Rod rightly points out that we haven't accepted SPDX tags alone as > > > > > license statements. The standard GPL v2.0 boiler plate should be > > added > > > > > to this file along side the tag. > > > > > > > > I've copied the full copyright attribution that is in the > > > > corresponding files on Linux. Is there some reason why FreeBSD > > > > requires the files to be inflated with the full license text where the > > > > original lacks it? > > > > > > I think for a few reasons, I doubt you copied the whole distribution > > > that this file came from, as I am sure that distribution included > > > a LICENSE file. Second if you actually read the GPL v2 documentation > > > and follow what it says it says you must do this, just because some > > > one else does not follow the rules of what the GPL v2 says does not > > > give us to knowingling not do it. Third this is a particular dangerious > > > area for BSD to be mixing a GPL code with its kernel, to my knowlege > > > we have never had any gpl code in the kernel, no have we ever > > > allowed it, but thats a seperate argument, that should be made. > > > > Would the arm64 DTS/DTB files count as "GPL code in the kernel?" > > > > No. dts gets compiled into dtb. dtb is a separate work loaded by the boot > loader. While one can compile it into the kernel, we don't ship like that. > > There's also a question as to whether or not these files are text > representation of the hardware, and there being only one way to represent > it (making it not copyrightable under at least US case law since it's a > database). That question hasn't been litigated. Many hardware companies > also dual license the dts. Since we're not incorporating it into the > kernel, but merely using it as a standardized table (there's a separate > group that controls the dts/dtb spec), I think we're safe from that angle > as well. > > There's benefit from having it in-tree because the version of the spec > evolves over time, and having the right version makes it harder to push > this off into a port. Also, having them in-tree makes the project's > compliance with GPL a no-op because it's all there in the open in a tagged > VCS. > > tl;dr: I don't think this is an issue. Awesome. Thanks for the clarification. I'm now curious if this is documented outside of random emails in svn-src-all@. I'm 100% sure I'm not the only one who needed clarification on DTS/DTB licensing, especially in the context of FreeBSD. > > > > I, too, would like less GPL in project, both in userland in kernel. > > But, I can understand the desire for gcov. Note that I'm not > > advocating either way that FreeBSD perform an action. ;) > > > > Given this is for TEST kernels, there's no issue here. While we'd like to > be GPL free, let's not cut off our nose to spite our face. Given the > interactions between different bits, the FreeBSD selling point of "well > integrated" I think trumps the purity arguments because it's not code > anybody would ever ship (and if they did, they'd get the proper warnings). Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: svn commit: r344487 - in head/sys: conf gnu/gcov
On Tue, Feb 26, 2019 at 08:27:40AM -0800, Rodney W. Grimes wrote: > > On Mon, Feb 25, 2019 at 06:18:42PM -0800, Rodney W. Grimes wrote: > > > > > The modest increase in activation energy for that task seems worth it > > > > > for the short-term gains of reduced integration cost (this code will > > > > > greatly improve our ZFS-on-Linux test coverage.) > > > > > > > > > > Rod rightly points out that we haven't accepted SPDX tags alone as > > > > > license statements. The standard GPL v2.0 boiler plate should be > > > > > added > > > > > to this file along side the tag. > > > > > > > > I've copied the full copyright attribution that is in the > > > > corresponding files on Linux. Is there some reason why FreeBSD > > > > requires the files to be inflated with the full license text where the > > > > original lacks it? > > > > > > I think for a few reasons, I doubt you copied the whole distribution > > > that this file came from, as I am sure that distribution included > > > a LICENSE file. Second if you actually read the GPL v2 documentation > > > and follow what it says it says you must do this, just because some > > > one else does not follow the rules of what the GPL v2 says does not > > > give us to knowingling not do it. Third this is a particular dangerious > > > area for BSD to be mixing a GPL code with its kernel, to my knowlege > > > we have never had any gpl code in the kernel, no have we ever > > > allowed it, but thats a seperate argument, that should be made. > > > > Would the arm64 DTS/DTB files count as "GPL code in the kernel?" > > > > I, too, would like less GPL in project, both in userland in kernel. > > But, I can understand the desire for gcov. Note that I'm not > > advocating either way that FreeBSD perform an action. ;) > > Didnt we just remove an inbase, compiling BSD licensed chunk of > code called DRM and move it to ports. So if that was possible > this should be very rapidly applied here and this issue goes away. DRM != DTS/DTB -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: svn commit: r344487 - in head/sys: conf gnu/gcov
On Mon, Feb 25, 2019 at 06:18:42PM -0800, Rodney W. Grimes wrote: > > > The modest increase in activation energy for that task seems worth it > > > for the short-term gains of reduced integration cost (this code will > > > greatly improve our ZFS-on-Linux test coverage.) > > > > > > Rod rightly points out that we haven't accepted SPDX tags alone as > > > license statements. The standard GPL v2.0 boiler plate should be added > > > to this file along side the tag. > > > > I've copied the full copyright attribution that is in the > > corresponding files on Linux. Is there some reason why FreeBSD > > requires the files to be inflated with the full license text where the > > original lacks it? > > I think for a few reasons, I doubt you copied the whole distribution > that this file came from, as I am sure that distribution included > a LICENSE file. Second if you actually read the GPL v2 documentation > and follow what it says it says you must do this, just because some > one else does not follow the rules of what the GPL v2 says does not > give us to knowingling not do it. Third this is a particular dangerious > area for BSD to be mixing a GPL code with its kernel, to my knowlege > we have never had any gpl code in the kernel, no have we ever > allowed it, but thats a seperate argument, that should be made. Would the arm64 DTS/DTB files count as "GPL code in the kernel?" I, too, would like less GPL in project, both in userland in kernel. But, I can understand the desire for gcov. Note that I'm not advocating either way that FreeBSD perform an action. ;) Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: svn commit: r344316 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
On Tue, Feb 19, 2019 at 11:35:56PM +, Pawel Jakub Dawidek wrote: > Author: pjd > Date: Tue Feb 19 23:35:55 2019 > New Revision: 344316 > URL: https://svnweb.freebsd.org/changeset/base/344316 > > Log: > The way ZFS searches for its vdevs is the following: first it looks for > a vdev that has the same name as the one stored in metadata and that has > all VDEV labels in place. If it cannot find a GEOM provider with the given > name and all VDEV labels it will scan all GEOM providers for the best match > (the most VDEV labels available), but here the name is ignored. > > In case the ZFS pool is created, eg. using GPT partition label: > > # zpool create tank /dev/gpt/tank > > everything works, and on every import ZFS will pick /dev/gpt/tank and > not /dev/da0p4. > > The problem occurs when da0p4 is extended and ZFS is unable to find all > VDEV labels in /dev/gpt/tank anymore (the VDEV labels stored at the end > of the partition are now somewhere else). In this case it will scan all > GEOM providers and will pick the first one with the best match, ie. da0p4. > > Fix this problem by checking the VDEV/provider name even if we get the same > match. If the name is the same as the one we have in pool's metadata, prefer > this GEOM provider. > > Reported by:oshogbo, Michal Mroz > Tested by: Michal Mroz > Obtained from: Fudo Security > > Modified: > head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c At the risk of painting a bikeshed a lovely color of neon purple, I'm curious about if/how these types of commits get merged upstream to (OpenZFS|Illumos|ZFS On Linux|where ever ZFS upstream is now|I'm very confused|is anyone else confused where upstream is?). Who is upstream? Is work like this going to remain as a downstream patch to ZFS? Or is FreeBSD going to work to upstream this type of work? I hope my curiousity doesn't offend anyone. ;) Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: svn commit: r343633 - head/usr.bin/shar
On Thu, Jan 31, 2019 at 03:29:03PM -0800, Bryan Drewery wrote: > On 1/31/19 3:21 PM, Bryan Drewery wrote: > > Author: bdrewery > > Date: Thu Jan 31 23:21:18 2019 > > New Revision: 343633 > > URL: https://svnweb.freebsd.org/changeset/base/343633 > > > > Log: > > Shar files may be seen as binary by grep. > > > > Suggest using -a to egrep to properly see executed commands. > > > > This is a minor improvement to the manpage. A better improvement > > would be removal or gigantic warnings. > > I dare someone to remove this utility. > There may still be documentation suggesting its use somewhere due to > pre-bugzilla days but now we can do proper binary attachments I believe. The recommended way to submit a new port is with a shar: https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-submitting.html :D -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: svn commit: r342283 - in head: release/amd64 release/arm64 release/i386 release/tools share/man/man8 tools/boot tools/tools/nanobsd/embedded usr.sbin/bsdinstall/partedit usr.sbin/bsdinstall/script
On Thu, Dec 20, 2018 at 01:11:20PM -0700, Rebecca Cran wrote:
> On December 20, 2018 at 12:51:36 PM, Shawn Webb (shawn.w...@hardenedbsd.org)
> wrote:
>
> Are there any other bits of the build process that touch files outside??
> of ${MAKEOBJDIRPREFIX}???
>
>
> Grepping for ???/tmp??? shows lots of other scripts that use /tmp .
Thanks!
--
Shawn Webb
Cofounder and Security Engineer
HardenedBSD
Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
signature.asc
Description: PGP signature
Re: svn commit: r342283 - in head: release/amd64 release/arm64 release/i386 release/tools share/man/man8 tools/boot tools/tools/nanobsd/embedded usr.sbin/bsdinstall/partedit usr.sbin/bsdinstall/script
On Thu, Dec 20, 2018 at 07:39:37PM +, Rebecca Cran wrote:
> Author: bcran
> Date: Thu Dec 20 19:39:37 2018
> New Revision: 342283
> URL: https://svnweb.freebsd.org/changeset/base/342283
>
> Log:
> Rework UEFI ESP generation
>
> Currently, the installer uses pre-created 800KB FAT12 filesystems that
> it dd's onto the ESP partition.
> This changeset improves that by having the installer generate a FAT32
> filesystem directly onto the ESP using newfs_msdos and then copying
> loader.efi into /EFI/freebsd.
> For live installs it then runs efibootmgr to add a FreeBSD boot entry
> in the BIOS.
>
> Sponsored by: Netflix
> Differential Revision: https://reviews.freebsd.org/D17947
>
> Modified:
> head/release/amd64/make-memstick.sh
> head/release/amd64/mkisoimages.sh
> head/release/arm64/make-memstick.sh
> head/release/i386/make-memstick.sh
> head/release/tools/vmimage.subr
> head/share/man/man8/uefi.8
> head/tools/boot/install-boot.sh
> head/tools/boot/rootgen.sh
> head/tools/tools/nanobsd/embedded/common
> head/usr.sbin/bsdinstall/partedit/gpart_ops.c
> head/usr.sbin/bsdinstall/partedit/partedit_arm64.c
> head/usr.sbin/bsdinstall/partedit/partedit_x86.c
> head/usr.sbin/bsdinstall/scripts/bootconfig
> head/usr.sbin/bsdinstall/scripts/zfsboot
>
> Modified: head/release/amd64/make-memstick.sh
> ==
> --- head/release/amd64/make-memstick.sh Thu Dec 20 19:27:46 2018
> (r342282)
> +++ head/release/amd64/make-memstick.sh Thu Dec 20 19:39:37 2018
> (r342283)
> @@ -12,6 +12,9 @@
>
> set -e
>
> +scriptdir=$(dirname $(realpath $0))
> +. ${scriptdir}/../../tools/boot/install-boot.sh
> +
> PATH=/bin:/usr/bin:/sbin:/usr/sbin
> export PATH
>
> @@ -36,11 +39,16 @@ makefs -B little -o label=FreeBSD_Install -o version=2
> rm ${1}/etc/fstab
> rm ${1}/etc/rc.conf.local
>
> +# Make an ESP in a file.
> +espfilename=$(mktemp /tmp/efiboot.XX)
> +make_esp_file ${espfilename} ${fat32min} ${1}/boot/loader.efi
Hey Rebecca,
Are there any other bits of the build process that touch files outside
of ${MAKEOBJDIRPREFIX}?
Thanks,
--
Shawn Webb
Cofounder and Security Engineer
HardenedBSD
Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
signature.asc
Description: PGP signature
Re: svn commit: r339898 - head/lib/libc/amd64/sys
On Tue, Oct 30, 2018 at 12:11:30AM +, Konstantin Belousov wrote: > Author: kib > Date: Tue Oct 30 00:11:30 2018 > New Revision: 339898 > URL: https://svnweb.freebsd.org/changeset/base/339898 > > Log: > Convert amd64_get/set_fs/gsbase to ifunc. > > Note that this is the first use of ifuncs in our userspace. Hey Kostik, It appears this commit broke building/linking libc with LTO. I'm running into this assertion from clang/lld 7.0.0 (from the projects/clang700-import feature branch): https://github.com/HardenedBSD/hardenedBSD-playground/blob/hardened/current/cross-dso-cfi/contrib/llvm/include/llvm/Support/Casting.h#L255 I'm likely going to file a bug report upstream in llvm. I'm wondering if lld doesn't support mixing ifuncs and LTO. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: svn commit: r340707 - head/usr.sbin/bhyve
On Tue, Nov 20, 2018 at 10:21:19PM +, Marcelo Araujo wrote:
> Author: araujo
> Date: Tue Nov 20 22:21:19 2018
> New Revision: 340707
> URL: https://svnweb.freebsd.org/changeset/base/340707
>
> Log:
> Define AHCI_PORT_IDENT and increase by 1 the VTBLK_BLK_ID_BYTES
> to avoid buffer accessed out of bounds, also switch to snprintf(3).
>
> PR: 200859
> Submitted by: Caglar
> Obtained from: https://github.com/mist64/xhyve/pull/24
> MFC after: 4 weeks
> Sponsored by: iXsystems Inc.
>
> Modified:
> head/usr.sbin/bhyve/pci_ahci.c
> head/usr.sbin/bhyve/pci_virtio_block.c
>
> Modified: head/usr.sbin/bhyve/pci_ahci.c
> ==
> --- head/usr.sbin/bhyve/pci_ahci.cTue Nov 20 22:12:10 2018
> (r340706)
> +++ head/usr.sbin/bhyve/pci_ahci.cTue Nov 20 22:21:19 2018
> (r340707)
> @@ -105,7 +105,7 @@ enum sata_fis_type {
> * ATA commands
> */
> #define ATA_SF_ENAB_SATA_SF 0x10
> -#define ATA_SATA_SF_AN 0x05
> +#define ATA_SATA_SF_AN 0x05
> #define ATA_SF_DIS_SATA_SF 0x90
>
> /*
> @@ -119,6 +119,8 @@ static FILE *dbg;
> #endif
> #define WPRINTF(format, arg...) printf(format, ##arg)
>
> +#define AHCI_PORT_IDENT 20 + 1
> +
> struct ahci_ioreq {
> struct blockif_req io_req;
> struct ahci_port *io_pr;
> @@ -136,7 +138,7 @@ struct ahci_port {
> struct pci_ahci_softc *pr_sc;
> uint8_t *cmd_lst;
> uint8_t *rfis;
> - char ident[20 + 1];
> + char ident[AHCI_PORT_IDENT];
> int port;
> int atapi;
> int reset;
> @@ -2374,7 +2376,8 @@ pci_ahci_init(struct vmctx *ctx, struct pci_devinst *p
> MD5Init();
> MD5Update(, opts, strlen(opts));
> MD5Final(digest, );
> - sprintf(sc->port[p].ident, "BHYVE-%02X%02X-%02X%02X-%02X%02X",
> + snprintf(sc->port[p].ident, AHCI_PORT_IDENT,
> + "BHYVE-%02X%02X-%02X%02X-%02X%02X",
> digest[0], digest[1], digest[2], digest[3], digest[4],
> digest[5]);
>
>
> Modified: head/usr.sbin/bhyve/pci_virtio_block.c
> ==
> --- head/usr.sbin/bhyve/pci_virtio_block.cTue Nov 20 22:12:10 2018
> (r340706)
> +++ head/usr.sbin/bhyve/pci_virtio_block.cTue Nov 20 22:21:19 2018
> (r340707)
> @@ -61,7 +61,7 @@ __FBSDID("$FreeBSD$");
> #define VTBLK_S_IOERR1
> #define VTBLK_S_UNSUPP 2
>
> -#define VTBLK_BLK_ID_BYTES 20
> +#define VTBLK_BLK_ID_BYTES 20 + 1
>
> /* Capability bits */
> #define VTBLK_F_SEG_MAX (1 << 2)/* Maximum request
> segments */
> @@ -344,7 +344,8 @@ pci_vtblk_init(struct vmctx *ctx, struct pci_devinst *
> MD5Init();
> MD5Update(, opts, strlen(opts));
> MD5Final(digest, );
> - sprintf(sc->vbsc_ident, "BHYVE-%02X%02X-%02X%02X-%02X%02X",
> + snprintf(sc->vbsc_ident, VTBLK_BLK_ID_BYTES,
> + "BHYVE-%02X%02X-%02X%02X-%02X%02X",
> digest[0], digest[1], digest[2], digest[3], digest[4], digest[5]);
>
> /* setup virtio block config space */
Hey Marcelo,
Thanks for committing this. Could VTBLK_BLK_ID_BYTES and
AHCI_PORT_IDENT be merged into the same macro, defined in
usr.sbin/bhyve/pci_emul.h? Especially since both equate to the same
value.
Thanks,
--
Shawn Webb
Cofounder and Security Engineer
HardenedBSD
Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
signature.asc
Description: PGP signature
Re: svn commit: r340640 - head/lib/libc
On Mon, Nov 19, 2018 at 06:12:39PM +, Ed Maste wrote: > Author: emaste > Date: Mon Nov 19 18:12:39 2018 > New Revision: 340640 > URL: https://svnweb.freebsd.org/changeset/base/340640 > > Log: > libc: forcibly disable BIND_NOW > > Building libc WITH_BIND_NOW results in segfault at process start. For > now force BIND_NOW off until the root cause can be identified and fixed. > > PR: 23 > Sponsored by: The FreeBSD Foundation > > Modified: > head/lib/libc/Makefile > > Modified: head/lib/libc/Makefile > == > --- head/lib/libc/MakefileMon Nov 19 17:33:44 2018(r340639) > +++ head/lib/libc/MakefileMon Nov 19 18:12:39 2018(r340640) > @@ -6,6 +6,8 @@ SHLIBDIR?= /lib > > .include > > +# BIND_NOW in libc results in segfault at startup (PR 23) > +MK_BIND_NOW= no Since the use of ifunc in libc is only applicable to amd64, I wonder if it would be best to disable BIND_NOW in lib/libc/amd64/Makefile.inc. I don't believe there's any need to disable BIND_NOW for libc on other architectures. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: svn commit: r339936 - head/sys/amd64/vmm/amd
On Wed, Oct 31, 2018 at 06:50:53AM -0400, Ed Maste wrote: > On Wed, 31 Oct 2018 at 10:07, Shawn Webb wrote: > > > > Does this need a /* FALLTHROUGH */ comment to appease the Coverity > > Gods? > > No, successive case statements without intervening bodies is a widely > used idiom well understood by all reasonable tools. Good catch. Thanks for the clarification! -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: svn commit: r339936 - head/sys/amd64/vmm/amd
On Wed, Oct 31, 2018 at 01:27:44AM +, Marcelo Araujo wrote: > Author: araujo > Date: Wed Oct 31 01:27:44 2018 > New Revision: 339936 > URL: https://svnweb.freebsd.org/changeset/base/339936 > > Log: > Merge cases with upper block. > This is a cosmetic change only to simplify code. > > Reported by:anish > Sponsored by: iXsystems Inc. > > Modified: > head/sys/amd64/vmm/amd/svm_msr.c > > Modified: head/sys/amd64/vmm/amd/svm_msr.c > == > --- head/sys/amd64/vmm/amd/svm_msr.c Tue Oct 30 23:09:04 2018 > (r339935) > +++ head/sys/amd64/vmm/amd/svm_msr.c Wed Oct 31 01:27:44 2018 > (r339936) > @@ -122,11 +122,7 @@ svm_rdmsr(struct svm_softc *sc, int vcpu, u_int num, u > case MSR_MTRR16kBase ... MSR_MTRR16kBase + 1: > case MSR_MTRR64kBase: > case MSR_SYSCFG: > - *result = 0; > - break; > case MSR_AMDK8_IPM: > - *result = 0; > - break; > case MSR_EXTFEATURES: > *result = 0; > break; Does this need a /* FALLTHROUGH */ comment to appease the Coverity Gods? Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: svn commit: r339511 - in head: . share/mk tools/build/options
On Sun, Oct 21, 2018 at 12:27:59AM +, Ed Maste wrote:
> Author: emaste
> Date: Sun Oct 21 00:27:59 2018
> New Revision: 339511
> URL: https://svnweb.freebsd.org/changeset/base/339511
>
> Log:
> Introduce src.conf knob to build userland with retpoline
>
> WITH_RETPOLINE enables -mretpoline vulnerability mitigation in userland
> for CVE-2017-5715.
>
> Reported by:Peter Malcom
> Reviewed by:markj
> MFC after: 1 week
> Sponsored by: The FreeBSD Foundation
> Differential Revision: https://reviews.freebsd.org/D17421
>
> Added:
> head/tools/build/options/WITH_RETPOLINE (contents, props changed)
> Modified:
> head/Makefile.inc1
> head/share/mk/bsd.lib.mk
> head/share/mk/bsd.opts.mk
> head/share/mk/bsd.prog.mk
>
> Modified: head/Makefile.inc1
> ==
> --- head/Makefile.inc1Sun Oct 21 00:20:40 2018(r339510)
> +++ head/Makefile.inc1Sun Oct 21 00:27:59 2018(r339511)
> @@ -659,7 +659,7 @@ BSARGS= DESTDIR= \
> -DNO_PIC MK_PROFILE=no -DNO_SHARED \
> -DNO_CPU_CFLAGS MK_WARNS=no MK_CTF=no \
> MK_CLANG_EXTRAS=no MK_CLANG_FULL=no \
> - MK_LLDB=no MK_TESTS=no \
> + MK_LLDB=no MK_RETPOLINE=no MK_TESTS=no \
> MK_INCLUDES=yes
>
> BMAKE= \
> @@ -680,7 +680,7 @@ TMAKE=\
> -DNO_LINT \
> -DNO_CPU_CFLAGS MK_WARNS=no MK_CTF=no \
> MK_CLANG_EXTRAS=no MK_CLANG_FULL=no \
> - MK_LLDB=no MK_TESTS=no
> + MK_LLDB=no MK_RETPOLINE=no MK_TESTS=no
>
> # cross-tools stage
> # TOOLS_PREFIX set in BMAKE
> @@ -703,7 +703,7 @@ KTMAKE= \
> SSP_CFLAGS= \
> MK_HTML=no -DNO_LINT MK_MAN=no \
> -DNO_PIC MK_PROFILE=no -DNO_SHARED \
> - -DNO_CPU_CFLAGS MK_WARNS=no MK_CTF=no
> + -DNO_CPU_CFLAGS MK_RETPOLINE=no MK_WARNS=no MK_CTF=no
>
> # world stage
> WMAKEENV=${CROSSENV} \
> @@ -2383,6 +2383,7 @@ NXBMAKEARGS+= \
> MK_OFED=no \
> MK_OPENSSH=no \
> MK_PROFILE=no \
> + MK_RETPOLINE=no \
> MK_SENDMAIL=no \
> MK_SVNLITE=no \
> MK_TESTS=no \
>
> Modified: head/share/mk/bsd.lib.mk
> ==
> --- head/share/mk/bsd.lib.mk Sun Oct 21 00:20:40 2018(r339510)
> +++ head/share/mk/bsd.lib.mk Sun Oct 21 00:27:59 2018(r339511)
> @@ -69,6 +69,12 @@ TAGS+= package=${PACKAGE:Uruntime}
> TAG_ARGS=-T ${TAGS:[*]:S/ /,/g}
> .endif
>
> +.if ${MK_RETPOLINE} != "no"
> +CFLAGS+= -mretpoline
> +CXXFLAGS+= -mretpoline
> +LDFLAGS+= -Wl,-zretpolineplt
> +.endif
> +
> .if ${MK_DEBUG_FILES} != "no" && empty(DEBUG_FLAGS:M-g) && \
> empty(DEBUG_FLAGS:M-gdwarf*)
> CFLAGS+= ${DEBUG_FILES_CFLAGS}
>
> Modified: head/share/mk/bsd.opts.mk
> ==
> --- head/share/mk/bsd.opts.mk Sun Oct 21 00:20:40 2018(r339510)
> +++ head/share/mk/bsd.opts.mk Sun Oct 21 00:27:59 2018(r339511)
> @@ -72,6 +72,7 @@ __DEFAULT_NO_OPTIONS = \
> CCACHE_BUILD \
> CTF \
> INSTALL_AS_USER \
> +RETPOLINE \
> STALE_STAGED
[snip]
We at HardenedBSD have had Retpoline enabled in 12 userland and kernel
for a few months now. I've found it to be safe to enable by default.
Thanks,
--
Shawn Webb
Cofounder and Security Engineer
HardenedBSD
Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
signature.asc
Description: PGP signature
Re: svn commit: r338861 - head/lib/libc
On Fri, Sep 21, 2018 at 01:11:46PM -0700, Xin Li wrote:
> On 9/21/18 10:49, Ed Maste wrote:
> > Author: emaste
> > Date: Fri Sep 21 17:49:37 2018
> > New Revision: 338861
> > URL: https://svnweb.freebsd.org/changeset/base/338861
> >
> > Log:
> > libc: require ifunc-capable linker for amd64/i386
> >
> > We expect to introduce optimized libc routines in the near future,
> > which requires use of a linker that supports ifuncs.
> >
> > Approved by: re (gjb, kib)
> > Sponsored by: The FreeBSD Foundation
> >
> > Modified:
> > head/lib/libc/Makefile
> >
> > Modified: head/lib/libc/Makefile
> > ==
> > --- head/lib/libc/Makefile Fri Sep 21 17:44:05 2018(r338860)
> > +++ head/lib/libc/Makefile Fri Sep 21 17:49:37 2018(r338861)
> > @@ -21,6 +21,11 @@ LIBC_ARCH=${MACHINE_ARCH}
> > LIBC_ARCH=${MACHINE_CPUARCH}
> > .endif
> >
> > +.if (${LIBC_ARCH} == amd64 || ${LIBC_ARCH} == i386) && \
> > +defined(LINKER_FEATURES) && ${LINKER_FEATURES:Mifunc} == ""
> > +.error ${LIBC_ARCH} libc requires linker ifunc support
> > +.endif
> > +
> > # All library objects contain FreeBSD revision strings by default; they
> > may be
> > # excluded as a space-saving measure. To produce a library that does
> > # not contain these strings, add -DSTRIP_FBSDID (see ) to
> > CFLAGS
>
> It seems that this would break bootstraping from a FreeBSD -CURRENT
> before ifunc?
It does. The HardenedBSD nightly build server is running 11-STABLE and
now cannot build 12-CURRENT:
https://jenkins.hardenedbsd.org/jenkins/job/HardenedBSD-CURRENT-amd64/1332/console
Thanks,
--
Shawn Webb
Cofounder and Security Engineer
HardenedBSD
Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
signature.asc
Description: PGP signature
Re: svn commit: r338802 - head/sys/vm
On Wed, Sep 19, 2018 at 06:12:29PM +0200, Mateusz Guzik wrote:
> On Wed, Sep 19, 2018 at 6:08 PM, Shawn Webb
> wrote:
>
> > On Wed, Sep 19, 2018 at 04:02:34PM +, Mateusz Guzik wrote:
> > > Author: mjg
> > > Date: Wed Sep 19 16:02:33 2018
> > > New Revision: 338802
> > > URL: https://svnweb.freebsd.org/changeset/base/338802
> > >
> > > Log:
> > > vm: check for empty kstack cache before locking
> > >
> > > The current cache logic checks the total number of stacks in the
> > kernel,
> > > which even on small boxes significantly exceeds the 128 limit (e.g. an
> > > 8-way box with zfs has almost 800 stacks allocated).
> > >
> > > Stacks are cached earlier for each main thread.
> > >
> > > As a result the code is rarely executed, but when it is then (on boxes
> > like
> > > the above) it always fails. Since there are no provisions made for
> > NUMA and
> > > release time is approaching, just do a quick check to avoid acquiring
> > the
> > > lock.
> > >
> > > Approved by:re (kib)
> > >
> > > Modified:
> > > head/sys/vm/vm_glue.c
> > >
> > > Modified: head/sys/vm/vm_glue.c
> > >
> > ==
> > > --- head/sys/vm/vm_glue.c Wed Sep 19 15:39:16 2018(r338801)
> > > +++ head/sys/vm/vm_glue.c Wed Sep 19 16:02:33 2018(r338802)
> > > @@ -327,7 +327,7 @@ vm_thread_new(struct thread *td, int pages)
> > > else if (pages > KSTACK_MAX_PAGES)
> > > pages = KSTACK_MAX_PAGES;
> > >
> > > - if (pages == kstack_pages) {
> > > + if (pages == kstack_pages && kstack_cache != NULL) {
> > > mtx_lock(_cache_mtx);
> > > if (kstack_cache != NULL) {
> > > ks_ce = kstack_cache;
> >
> > Since kstack_cache is guaranteed not to be NULL, can the second
> > conditional that checks for kstack_cache not being NULL be removed?
> >
> >
> The one with the lock held? By the time we get there someone else might
> have removed the last cached stack making the pointer NULL.
>
> Checking a condition before locking and then checking again is a common
> optimization pattern for cases where the condition is likely false.
Ah, I understand now. Thanks for the clarification!
--
Shawn Webb
Cofounder and Security Engineer
HardenedBSD
Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
signature.asc
Description: PGP signature
Re: svn commit: r338802 - head/sys/vm
On Wed, Sep 19, 2018 at 04:02:34PM +, Mateusz Guzik wrote:
> Author: mjg
> Date: Wed Sep 19 16:02:33 2018
> New Revision: 338802
> URL: https://svnweb.freebsd.org/changeset/base/338802
>
> Log:
> vm: check for empty kstack cache before locking
>
> The current cache logic checks the total number of stacks in the kernel,
> which even on small boxes significantly exceeds the 128 limit (e.g. an
> 8-way box with zfs has almost 800 stacks allocated).
>
> Stacks are cached earlier for each main thread.
>
> As a result the code is rarely executed, but when it is then (on boxes like
> the above) it always fails. Since there are no provisions made for NUMA and
> release time is approaching, just do a quick check to avoid acquiring the
> lock.
>
> Approved by:re (kib)
>
> Modified:
> head/sys/vm/vm_glue.c
>
> Modified: head/sys/vm/vm_glue.c
> ==
> --- head/sys/vm/vm_glue.c Wed Sep 19 15:39:16 2018(r338801)
> +++ head/sys/vm/vm_glue.c Wed Sep 19 16:02:33 2018(r338802)
> @@ -327,7 +327,7 @@ vm_thread_new(struct thread *td, int pages)
> else if (pages > KSTACK_MAX_PAGES)
> pages = KSTACK_MAX_PAGES;
>
> - if (pages == kstack_pages) {
> + if (pages == kstack_pages && kstack_cache != NULL) {
> mtx_lock(_cache_mtx);
> if (kstack_cache != NULL) {
> ks_ce = kstack_cache;
Since kstack_cache is guaranteed not to be NULL, can the second
conditional that checks for kstack_cache not being NULL be removed?
Thanks,
--
Shawn Webb
Cofounder and Security Engineer
HardenedBSD
Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
signature.asc
Description: PGP signature
Re: svn commit: r338494 - head/sys/cam/ctl
On Thu, Sep 06, 2018 at 08:24:32AM -0700, John Baldwin wrote: > On 9/6/18 7:54 AM, Shawn Webb wrote: > > On Thu, Sep 06, 2018 at 02:03:10PM +, Alexander Motin wrote: > >> Author: mav > >> Date: Thu Sep 6 14:03:10 2018 > >> New Revision: 338494 > >> URL: https://svnweb.freebsd.org/changeset/base/338494 > >> > >> Log: > >> Add missing copyin() to access LUN and port ioctl arguments. > >> > >> Somehow this was working even after PTI in, at least on amd64, and got > >> broken by something only very recently. > > > > Is anyone investigating why the direct access still worked? > > PTI doesn't disable kernel access to user pages, it only disables > translation of kernel virtual addresses while in user mode. The thing that > catches this type of access is SMAP (which was only recently enabled on > x86). Whoops. Blonde moment. I blame the lack of caffeine in my body when I wrote the email. Too many acronyms to keep track of when tired. ;) Thanks for the clarification. -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: svn commit: r338494 - head/sys/cam/ctl
On Thu, Sep 06, 2018 at 02:03:10PM +, Alexander Motin wrote: > Author: mav > Date: Thu Sep 6 14:03:10 2018 > New Revision: 338494 > URL: https://svnweb.freebsd.org/changeset/base/338494 > > Log: > Add missing copyin() to access LUN and port ioctl arguments. > > Somehow this was working even after PTI in, at least on amd64, and got > broken by something only very recently. Is anyone investigating why the direct access still worked? Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: svn commit: r336919 - head/sys/dev/efidev
On Mon, Jul 30, 2018 at 05:40:27PM +, Kyle Evans wrote:
> Author: kevans
> Date: Mon Jul 30 17:40:27 2018
> New Revision: 336919
> URL: https://svnweb.freebsd.org/changeset/base/336919
>
> Log:
> efirt: Add tunable to allow disabling EFI Runtime Services
>
> Leading up to enabling EFIRT in GENERIC, allow runtime services to be
> disabled with a new tunable: efi.rt_disabled. This makes it so that EFIRT
> can be disabled easily in case we run into some buggy UEFI implementation
> and fail to boot.
>
> Discussed with: imp, kib
> MFC after: 1 week
>
> Modified:
> head/sys/dev/efidev/efirt.c
>
> Modified: head/sys/dev/efidev/efirt.c
> ==
> --- head/sys/dev/efidev/efirt.c Mon Jul 30 17:03:15 2018
> (r336918)
> +++ head/sys/dev/efidev/efirt.c Mon Jul 30 17:40:27 2018
> (r336919)
> @@ -133,7 +133,12 @@ efi_init(void)
> struct efi_md *map;
> caddr_t kmdp;
> size_t efisz;
> + int rt_disabled;
>
> + rt_disabled = 0;
> + TUNABLE_INT_FETCH("efi.rt_disabled", _disabled);
Would it be a good idea to document this tunable in loader(8)?
Thanks,
--
Shawn Webb
Cofounder and Security Engineer
HardenedBSD
Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
signature.asc
Description: PGP signature
Re: svn commit: r336744 - in head: sbin/pfctl/tests/files share/mk
On Thu, Jul 26, 2018 at 11:11:05AM -0600, Brad Davis wrote:
> On Thu, Jul 26, 2018, at 11:09 AM, Shawn Webb wrote:
> > On Thu, Jul 26, 2018 at 05:05:34PM +, Brad Davis wrote:
> > > Author: brd
> > > Date: Thu Jul 26 17:05:33 2018
> > > New Revision: 336744
> > > URL: https://svnweb.freebsd.org/changeset/base/336744
> > >
> > > Log:
> > > Convert bsd.files.mk to support DIRS and simplify by only having one
> > > install
> > > target.
> > >
> > > Also update the pfctl tests Makefile to work with this change.
> > >
> > > Approved by:bapt (mentor)
> > > Differential Revision: https://reviews.freebsd.org/D16430
> > >
> > > Modified:
> > > head/sbin/pfctl/tests/files/Makefile
> > > head/share/mk/bsd.files.mk
> > >
> > > Modified: head/sbin/pfctl/tests/files/Makefile
> > > ==
> > > --- head/sbin/pfctl/tests/files/Makefile Thu Jul 26 16:51:23 2018
> > > (r336743)
> > > +++ head/sbin/pfctl/tests/files/Makefile Thu Jul 26 17:05:33 2018
> > > (r336744)
> > > @@ -4,9 +4,7 @@ TESTSDIR= ${TESTSBASE}/sbin/pfctl/files
> > > BINDIR= ${TESTSDIR}
> > >
> > > # We use ${.CURDIR} as workaround so that the glob patterns work.
> > > -FILES= ${.CURDIR}/pf.in
> > > -FILES+= ${.CURDIR}/pf.include
> > > -FILES+= ${.CURDIR}/pf.ok
> > > +FILES!= echo ${.CURDIR}/pf.in ${.CURDIR}/pf.include
> > > ${.CURDIR}/pf.ok
> >
> > Should this use ${ECHO} instead of echo?
>
> No, that wouldn't work at all with the !=.
I thought that might be the case, but I just wanted to make sure.
Thanks for the clarification.
--
Shawn Webb
Cofounder and Security Engineer
HardenedBSD
Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
signature.asc
Description: PGP signature
Re: svn commit: r336744 - in head: sbin/pfctl/tests/files share/mk
On Thu, Jul 26, 2018 at 05:05:34PM +, Brad Davis wrote:
> Author: brd
> Date: Thu Jul 26 17:05:33 2018
> New Revision: 336744
> URL: https://svnweb.freebsd.org/changeset/base/336744
>
> Log:
> Convert bsd.files.mk to support DIRS and simplify by only having one install
> target.
>
> Also update the pfctl tests Makefile to work with this change.
>
> Approved by:bapt (mentor)
> Differential Revision: https://reviews.freebsd.org/D16430
>
> Modified:
> head/sbin/pfctl/tests/files/Makefile
> head/share/mk/bsd.files.mk
>
> Modified: head/sbin/pfctl/tests/files/Makefile
> ==
> --- head/sbin/pfctl/tests/files/Makefile Thu Jul 26 16:51:23 2018
> (r336743)
> +++ head/sbin/pfctl/tests/files/Makefile Thu Jul 26 17:05:33 2018
> (r336744)
> @@ -4,9 +4,7 @@ TESTSDIR= ${TESTSBASE}/sbin/pfctl/files
> BINDIR= ${TESTSDIR}
>
> # We use ${.CURDIR} as workaround so that the glob patterns work.
> -FILES= ${.CURDIR}/pf.in
> -FILES+= ${.CURDIR}/pf.include
> -FILES+= ${.CURDIR}/pf.ok
> +FILES!= echo ${.CURDIR}/pf.in ${.CURDIR}/pf????.include
> ${.CURDIR}/pf.ok
Should this use ${ECHO} instead of echo?
Thanks,
--
Shawn Webb
Cofounder and Security Engineer
HardenedBSD
Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
signature.asc
Description: PGP signature
Re: svn commit: r336203 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/patches contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drivers
t; >>> > > > > well. > >>> > > > > I haven't had time to debug it properly (which is why I've never > >>> > > > > reported > >>> > > > > it) > >>> > > > > >>> > > > I plan on trying out the latest from upstream beyond the patch Cy > >>> > > > sent > >>> > > > along earlier to see if it's perhaps been addressed elsewhere in the > >>> > > > past two years since this release was made. > >>> > > > >>> > > A point of reference. I've had no issues here with any of the networks > >>> > > I use. All the networks I use are either WPA-PSK or open. The last > >>> > > WPA-EAP I used was at former $JOB a few years ago. However, at the > >>> > > Link > >>> > > Lounge just outside where $JOB is at my wifi would disconnect every 30 > >>> > > minutes using our old wpa 2.5, requiring a netif restart. 2.6 resolved > >>> > > that issue. > >>> > > > >>> > > Upline git commit 0adc9b28b39d414d5febfff752f6a1576f785c85 also looks > >>> > > interesting. > >>> > > > >>> > > ommit 0adc9b28b39d414d5febfff752f6a1576f785c85 > >>> > > Author: Jouni Malinen > >>> > > Date: Sun Oct 1 12:32:57 2017 +0300 > >>> > > > >>> > > Fix PTK rekeying to generate a new ANonce > >>> > > > >>> > > The Authenticator state machine path for PTK rekeying ended up > >>> > > bypassing > >>> > > the AUTHENTICATION2 state where a new ANonce is generated when > >>> > > going > >>> > > directly to the PTKSTART state since there is no need to try to > >>> > > determine the PMK again in such a case. This is far from ideal > >>> > > since the > >>> > > new PTK would depend on a new nonce only from the supplicant. > >>> > > > >>> > > Fix this by generating a new ANonce when moving to the PTKSTART > >>> > > state > >>> > > for the purpose of starting new 4-way handshake to rekey PTK. > >>> > > > >>> > > Signed-off-by: Jouni Malinen > >>> > > > >>> > > > >>> > > I suspect a timeout because reason=1 in Kyle's log. > >>> > > >>> > > >>> > I have two systems experienced wifi connection issues after recent HEAD > >>> > update. > >>> > Both of them experiencing frequent up/down wlan0 events on boot so > >>> > wireles > >>> s > >>> > connection can not negotiate DHCP requests, possibly due to fact that > >>> > both > >>> > connecting to the same AP. > >>> > AP capabilities list: > >>> > > >>> > * f8:1a:67:56:16:161 54M -74:-96 100 EPS WPA WME ATH WPS > >>> > > >>> > Interesting enough that switching wpa_supplicant to version 2.6 from > >>> > ports > >>> > fixes that issue completely. > >>> > > >>> > Hopefully it helps. > >>> > > >>> > Thank you. > >>> > >>> I've imported all the patches in the port, from our upline into base. > >>> Some were already committed to > >>> -- > >>> Cheers, > >>> Cy Schubert > >>> FreeBSD UNIX: Web: http://www.FreeBSD.org > >>> > >>> The need of the many outweighs the greed of the few. > >>> base 2.5 others not. This should bring base up to par with the port, > >>> address the remaining security issues, and probably fix this thread too. > >> > >> exmh. I had my cursor in the wrong place when I hit send. > >> > >> I've imported all the patches in the port, from our upline into base. > >> Some were already committed to base 2.5 others not. This should bring > >> base up to par with the port, address the remaining security issues, > >> and probably fix this thread too. > >> > > > > FWIW- with ports 2.6 I've confirmed that instead of the reassociation I get: > > > > Jul 19 18:17:30 shiva wpa_supplicant[34199]: wlan0: WPA: Group > > rekeying completed with ... [GTK=CCMP] > > > > I'll try with base 2.6 now that you've updated with all of these patches. > > Alright, base 2.6 is still no good here. I note that there's still > some diff between ports and base [1] (about 252 lines of diff to sort > through, nothing serious... I removed the obviously-for-libressl > diff). > > Some of it looks kind of suspicious, but I'd guess the changes in > ./src/rsn_supp/wpa.c are mostly what make the difference for me. How > much of this really needs to stick around, given that ports > wpa_supplicant is actually pretty stable? (Attempting to read between the lines, forgive me if I misinterpreted.) Some of the systems I've set up recently are more easily set up with wireless. Running a 100ft cable in an office building isn't that fun. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: svn commit: r336289 - head/sys/security/mac_veriexec
Hey Stephen,
On Sat, Jul 14, 2018 at 05:21:17PM +, Stephen J. Kiernan wrote:
> Author: stevek
> Date: Sat Jul 14 17:21:16 2018
> New Revision: 336289
> URL: https://svnweb.freebsd.org/changeset/base/336289
>
> Log:
> Add mpo_vnode_check_setmode MAC method to MAC/veriexec.
> In the method, disallow changing SUID/SGID on verified files.
>
> Obtained from: Juniper Networks, Inc.
>
> Modified:
> head/sys/security/mac_veriexec/mac_veriexec.c
>
> Modified: head/sys/security/mac_veriexec/mac_veriexec.c
> ==
> --- head/sys/security/mac_veriexec/mac_veriexec.c Sat Jul 14 17:20:27
> 2018(r336288)
> +++ head/sys/security/mac_veriexec/mac_veriexec.c Sat Jul 14 17:21:16
> 2018(r336289)
> @@ -550,6 +550,38 @@ mac_veriexec_vnode_check_open(struct ucred *cred, stru
> }
>
> /**
> + * @brief Check mode changes on file to ensure they should be allowed.
> + *
> + * We cannot allow chmod of SUID or SGID on verified files.
> + *
> + * @param cred credentials to use
> + * @param vp vnode of the file to open
> + * @param label vnode label assigned to the vnode
> + * @param mode mode flags to set
> + *
> + * @return 0 if the mode change should be allowed, EAUTH otherwise.
> + */
> +static int
> +mac_veriexec_vnode_check_setmode(struct ucred *cred, struct vnode *vp,
> +struct label *label __unused, mode_t mode)
> +{
> + int error;
> +
> + if ((mac_veriexec_state & VERIEXEC_STATE_ENFORCE) == 0)
> + return (0);
> +
> + /*
> + * Do not allow chmod (set-[gu]id) of verified file
> + */
> + error = mac_veriexec_check_vp(cred, vp, VVERIFY);
> + if (error == EAUTH) /* it isn't verified */
Is EAUTH the right error to return? errno(2) shows that EAUTH
signifies: "Authentication error. Attempted to use an invalid
authentication ticket to mount a NFS file system."
Perhaps EPERM would be better suited?
> + return (0);
> + if (error == 0 && (mode & (S_ISUID|S_ISGID)) != 0)
> + return (EAUTH);
> + return (0);
> +}
> +
> +/**
> * @internal
> * @brief Initialize the mac_veriexec MAC policy
> *
> @@ -673,6 +705,7 @@ static struct mac_policy_ops mac_veriexec_ops =
> .mpo_proc_check_debug = mac_veriexec_proc_check_debug,
> .mpo_vnode_check_exec = mac_veriexec_vnode_check_exec,
> .mpo_vnode_check_open = mac_veriexec_vnode_check_open,
> + .mpo_vnode_check_setmode = mac_veriexec_vnode_check_setmode,
> .mpo_vnode_copy_label = mac_veriexec_copy_label,
> .mpo_vnode_destroy_label = mac_veriexec_vnode_destroy_label,
> .mpo_vnode_init_label = mac_veriexec_vnode_init_label,
Thanks,
--
Shawn Webb
Cofounder and Security Engineer
HardenedBSD
Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
signature.asc
Description: PGP signature
Re: svn commit: r335690 - head/sys/kern
On Wed, Jun 27, 2018 at 07:42:52AM -0600, Warner Losh wrote:
> On Wed, Jun 27, 2018 at 12:59 AM, Oliver Pinter <
> oliver.pin...@hardenedbsd.org> wrote:
>
> >
> >
> > On Wednesday, June 27, 2018, Warner Losh wrote:
> >
> >> Author: imp
> >> Date: Wed Jun 27 04:11:09 2018
> >> New Revision: 335690
> >> URL: https://svnweb.freebsd.org/changeset/base/335690
> >>
> >> Log:
> >> Fix devctl generation for core files.
> >>
> >> We have a problem with vn_fullpath_global when the file exists. Work
> >> around it by printing the full path if the core file name starts with /,
> >> or current working directory followed by the filename if not.
> >>
> >> Sponsored by: Netflix
> >> Differential Review: https://reviews.freebsd.org/D16026
> >>
> >> Modified:
> >> head/sys/kern/kern_sig.c
> >>
> >> Modified: head/sys/kern/kern_sig.c
> >>
> >> ==
> >> --- head/sys/kern/kern_sig.cWed Jun 27 04:10:48 2018(r335689)
> >> +++ head/sys/kern/kern_sig.cWed Jun 27 04:11:09 2018(r335690)
> >> @@ -3431,24 +3431,6 @@ out:
> >> return (0);
> >> }
> >>
> >> -static int
> >> -coredump_sanitise_path(const char *path)
> >> -{
> >> - size_t i;
> >> -
> >> - /*
> >> -* Only send a subset of ASCII to devd(8) because it
> >> -* might pass these strings to sh -c.
> >> -*/
> >> - for (i = 0; path[i]; i++)
> >> - if (!(isalpha(path[i]) || isdigit(path[i])) &&
> >> - path[i] != '/' && path[i] != '.' &&
> >> - path[i] != '-')
> >> - return (0);
> >
> >
> > This part of code existed to prevent shell code injection via file names.
> > After this commit we lose this.
> >
>
> It's devd's job to prevent that, not the kernel's.
Has devd been updated? Or is this particular vulnerability manifest
again?
--
Shawn Webb
Cofounder and Security Engineer
HardenedBSD
Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
signature.asc
Description: PGP signature
Re: svn commit: r334719 - in head: cddl/lib/libdtrace lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys
On Wed, Jun 06, 2018 at 03:45:57PM +, Sean Bruno wrote: > Author: sbruno > Date: Wed Jun 6 15:45:57 2018 > New Revision: 334719 > URL: https://svnweb.freebsd.org/changeset/base/334719 > > Log: > Load balance sockets with new SO_REUSEPORT_LB option. > > This patch adds a new socket option, SO_REUSEPORT_LB, which allow multiple > programs or threads to bind to the same port and incoming connections will > be > load balanced using a hash function. > > Most of the code was copied from a similar patch for DragonflyBSD. > > However, in DragonflyBSD, load balancing is a global on/off setting and can > not > be set per socket. This patch allows for simultaneous use of both the > current > SO_REUSEPORT and the new SO_REUSEPORT_LB options on the same system. > > Required changes to structures: > Globally change so_options from 16 to 32 bit value to allow for more > options. > Add hashtable in pcbinfo to hold all SO_REUSEPORT_LB sockets. > > Limitations: > As DragonflyBSD, a load balance group is limited to 256 pcbs (256 programs > or > threads sharing the same socket). > > This is a substantially different contribution as compared to its original > incarnation at svn r332894 and reverted at svn r332967. Thanks to rwatson@ > for the substantive feedback that is included in this commit. > > Submitted by: Johannes Lundberg > Obtained from: DragonflyBSD > Relnotes: Yes > Sponsored by: Limelight Networks > Differential Revision: https://reviews.freebsd.org/D11003 Hey Sean, This is a rather interesting and useful feature. Thank you for committing it. It seems there are some security trade-offs being made for applications that opt-in to this feature: third-party applications, potentially malicious, could bind to the port. I wonder if we could prevent malicious abuse of this feature by introducing a random cookie. When a developer sets this option, the developer must specify a random value as a cookie. Applications who want to share the port, then, must also specify the cookie (perhaps via another socket option?). What are your thoughts? I'm CC'ing Johannes to get his thoughts as well. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: svn commit: r334216 - head/usr.sbin/bhyve
On Fri, May 25, 2018 at 10:08:46PM +0300, Konstantin Belousov wrote:
> On Fri, May 25, 2018 at 06:54:40PM +, Marcelo Araujo wrote:
> > Author: araujo
> > Date: Fri May 25 18:54:40 2018
> > New Revision: 334216
> > URL: https://svnweb.freebsd.org/changeset/base/334216
> >
> > Log:
> > After a long discussion about assert(3), we gonna use a HardenedBSD
> > approach to chek strdup(3) memory allocation.
> >
> > Submitted by: Shaw Webb <shawn.w...@hardenedbsd.org>
> > Reported by: brooks
> > Obtained from:HardenedBSD
> >
> > Modified:
> > head/usr.sbin/bhyve/bhyverun.c
> >
> > Modified: head/usr.sbin/bhyve/bhyverun.c
> > ==
> > --- head/usr.sbin/bhyve/bhyverun.c Fri May 25 18:11:13 2018
> > (r334215)
> > +++ head/usr.sbin/bhyve/bhyverun.c Fri May 25 18:54:40 2018
> > (r334216)
> > @@ -193,7 +193,8 @@ topology_parse(const char *opt)
> > c = 1, n = 1, s = 1, t = 1;
> > ns = false, scts = false;
> > str = strdup(opt);
> > - assert(str != NULL);
> > + if (str == NULL)
> > + goto out;
> >
> > while ((cp = strsep(, ",")) != NULL) {
> > if (sscanf(cp, "%i%n", , ) == 1) {
> > @@ -225,6 +226,7 @@ topology_parse(const char *opt)
> > goto out;
> > }
> > free(str);
> > + str = NULL;
> >
> > /*
> > * Range check 1 <= n <= UINT16_MAX all values
> > @@ -253,7 +255,8 @@ topology_parse(const char *opt)
> > return(0);
> >
> > out:
> > - free(str);
> > + if (str != NULL)
> This check is useless. Free(3) is fine handling NULL argument.
Good catch. Thanks!
--
Shawn Webb
Cofounder and Security Engineer
HardenedBSD
Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
signature.asc
Description: PGP signature
Re: svn commit: r334199 - head/usr.sbin/bhyve
On Sat, May 26, 2018 at 02:57:29AM +0800, Marcelo Araujo wrote: > Thanks Shawn, > > I think there are plenty of places to fix this case! Thanks for the extra > work :D. Any time. I'm glad to help. If you'd like, I might have time on Sunday to audit bhyve's code to find and fix more of these cases. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: svn commit: r334199 - head/usr.sbin/bhyve
On Sat, May 26, 2018 at 02:26:33AM +0800, Marcelo Araujo wrote: > 2018-05-26 2:21 GMT+08:00 Brooks Davis <bro...@freebsd.org>: > > > On Sat, May 26, 2018 at 01:56:28AM +0800, Marcelo Araujo wrote: > > > 2018-05-26 1:44 GMT+08:00 Brooks Davis <bro...@freebsd.org>: > > > > > > > On Sat, May 26, 2018 at 01:21:33AM +0800, Marcelo Araujo wrote: > > > > > On Sat, May 26, 2018, 1:11 AM Eitan Adler <li...@eitanadler.com> > > wrote: > > > > > > > > > > > On 25 May 2018 at 08:23, Marcelo Araujo <araujobsdp...@gmail.com> > > > > wrote: > > > > > > > > > > > > > > > > > > > > > On Fri, May 25, 2018, 11:11 PM Brooks Davis <bro...@freebsd.org> > > > > wrote: > > > > > > >> > > > > > > >> On Fri, May 25, 2018 at 02:07:05AM +, Marcelo Araujo wrote: > > > > > > >> > Author: araujo > > > > > > >> > Date: Fri May 25 02:07:05 2018 > > > > > > >> > New Revision: 334199 > > > > > > >> > URL: https://svnweb.freebsd.org/changeset/base/334199 > > > > > > >> > > > > > > > >> > Log: > > > > > > >> > Fix a memory leak on topology_parse(). > > > > > > >> > > > > > > > >> > strdup(3) allocates memory for a copy of the string, does > > the > > > > copy > > > > > > and > > > > > > >> > returns a pointer to it. If there is no sufficient memory > > NULL > > > > is > > > > > > >> > returned > > > > > > >> > and the global errno is set to ENOMEM. > > > > > > >> > We do a sanity check to see if it was possible to allocate > > > > enough > > > > > > >> > memory. > > > > > > >> > > > > > > > >> > Also as we allocate memory, we need to free this memory > > used. > > > > Or it > > > > > > >> > will > > > > > > >> > going out of scope leaks the storage it points to. > > > > > > >> > > > > > > > >> > Reviewed by:rgrimes > > > > > > >> > MFC after: 3 weeks. > > > > > > >> > X-MFC: r332298 > > > > > > >> > Sponsored by: iXsystems Inc. > > > > > > >> > Differential Revision: https://reviews.freebsd.org/ > > D15550 > > > > > > >> > > > > > > > >> > Modified: > > > > > > >> > head/usr.sbin/bhyve/bhyverun.c > > > > > > >> > > > > > > > >> > Modified: head/usr.sbin/bhyve/bhyverun.c > > > > > > >> > > > > > > > >> > > > > > > > > > > > == > > > > > > >> > --- head/usr.sbin/bhyve/bhyverun.cFri May 25 01:38:59 2018 > > > > > > >> > (r334198) > > > > > > >> > +++ head/usr.sbin/bhyve/bhyverun.cFri May 25 02:07:05 2018 > > > > > > >> > (r334199) > > > > > > >> > @@ -193,6 +193,7 @@ topology_parse(const char *opt) > > > > > > >> > c = 1, n = 1, s = 1, t = 1; > > > > > > >> > ns = false, scts = false; > > > > > > >> > str = strdup(opt); > > > > > > >> > + assert(str != NULL); > > > > > > >> > > > > > > >> Using assert seems like an odd choice when you've already added > > a > > > > > > >> failure path and the strsep will crash immediately if assert is > > > > elided. > > > > > > > > > > > > > > > > > > > > > Just to make a better point, I had the same discussion about > > > > assert(3) in > > > > > > > another review, we don't do NDEBUG even for RELEASE. > > > > > > > > > > > > IMHO we only use assert for asserting things ought to never be > > false > > > > > > except in buggy code. Using assert for handling is poor pr
Re: svn commit: r318736 - in head: cddl/lib/libzfs contrib/compiler-rt/lib/sanitizer_common contrib/openbsm/libbsm include lib/libarchive lib/libc/gen lib/libc/include lib/libc/sys lib/libkvm lib/libm
On Tue, May 23, 2017 at 09:29:05AM +, Konstantin Belousov wrote: > Author: kib > Date: Tue May 23 09:29:05 2017 > New Revision: 318736 > URL: https://svnweb.freebsd.org/changeset/base/318736 > > Log: > Commit the 64-bit inode project. > > Extend the ino_t, dev_t, nlink_t types to 64-bit ints. Modify > struct dirent layout to add d_off, increase the size of d_fileno > to 64-bits, increase the size of d_namlen to 16-bits, and change > the required alignment. Increase struct statfs f_mntfromname[] and > f_mntonname[] array length MNAMELEN to 1024. > > ABI breakage is mitigated by providing compatibility using versioned > symbols, ingenious use of the existing padding in structures, and > by employing other tricks. Unfortunately, not everything can be > fixed, especially outside the base system. For instance, third-party > APIs which pass struct stat around are broken in backward and > forward incompatible ways. > > Kinfo sysctl MIBs ABI is changed in backward-compatible way, but > there is no general mechanism to handle other sysctl MIBS which > return structures where the layout has changed. It was considered > that the breakage is either in the management interfaces, where we > usually allow ABI slip, or is not important. > > Struct xvnode changed layout, no compat shims are provided. > > For struct xtty, dev_t tty device member was reduced to uint32_t. > It was decided that keeping ABI compat in this case is more useful > than reporting 64-bit dev_t, for the sake of pstat. > > Update note: strictly follow the instructions in UPDATING. Build > and install the new kernel with COMPAT_FREEBSD11 option enabled, > then reboot, and only then install new world. > > Credits: The 64-bit inode project, also known as ino64, started life > many years ago as a project by Gleb Kurtsou (gleb). Kirk McKusick > (mckusick) then picked up and updated the patch, and acted as a > flag-waver. Feedback, suggestions, and discussions were carried > by Ed Maste (emaste), John Baldwin (jhb), Jilles Tjoelker (jilles), > and Rick Macklem (rmacklem). Kris Moore (kris) performed an initial > ports investigation followed by an exp-run by Antoine Brodin (antoine). > Essential and all-embracing testing was done by Peter Holm (pho). > The heavy lifting of coordinating all these efforts and bringing the > project to completion were done by Konstantin Belousov (kib). > > Sponsored by: The FreeBSD Foundation (emaste, kib) > Differential revision: https://reviews.freebsd.org/D10439 > > Modified: > head/contrib/openbsm/libbsm/bsm_wrappers.c Hey Kostik, Did the OpenBSM changes ever make it upstream to the OpenBSM project? I'm looking through the commits of the OpenBSM project and it looks like they never did. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: svn commit: r331880 - stable/11/etc
On Mon, Apr 09, 2018 at 09:33:38AM -0500, Kyle Evans wrote:
> On Mon, Apr 9, 2018 at 9:29 AM, Shawn Webb <shawn.w...@hardenedbsd.org> wrote:
> > On Mon, Apr 02, 2018 at 03:28:48PM +, Kyle Evans wrote:
> >> Author: kevans
> >> Date: Mon Apr 2 15:28:48 2018
> >> New Revision: 331880
> >> URL: https://svnweb.freebsd.org/changeset/base/331880
> >>
> >> Log:
> >> MFC r328331: Support configuring arbitrary limits(1) for any rc.conf
> >> daemon
> >>
> >> Usage is ${name}_limits, and the argument is any flags accepted by
> >> limits(1), such as `-n 100' (e.g. only allow 100 open files).
> >
> > A HardenedBSD user has reported an issue with this commit:
> >
> > https://twitter.com/0x666c7578/status/982901931969597440
> >
>
> The mariadb ports should be good with this after ports r466451,
> tracking PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227205
Awesome. Thanks!
--
Shawn Webb
Cofounder and Security Engineer
HardenedBSD
Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
signature.asc
Description: PGP signature
