> > > > "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
>
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 W
V_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/
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 0
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 Fingerprin
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 b
omplex
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 YMM
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
GP
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
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
> >
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
> >
CS+= 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
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 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
> >
p->o_opt != 0; fp++) {
> + if ((mp->mnt_flag & fp->o_opt) != 0) {
> + sbuf_cat(, fp->o_name);
> + sbuf_putc(, ';');
> + }
> + }
> + sbuf_putc(, '"');
> + dev_vfs_event_mntopt(, &quo
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
_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.
> >
> >>
&
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
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 Web
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
Ha
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/ifc
fconfig/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:
reebsd.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.m
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
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:
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
bsd-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 Fingerp
gt; >
> >printf("%s: unable to create fixed mac address; using random
> > mac address", if_name(ifp));
> >
> > This will only be printed in rare circumstances. But in that case will
> > provide valuable information.
&g
> 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 the
namically, 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:
s 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.
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: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 +,
p;& (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:
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
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: 0x6A8
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
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 0
er, 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
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 l
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):
> > boo
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
s() 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
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
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)
> +
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
> >&
tch 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
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
96
> >
> > Log:
> > telnet: fix minor style violation
> >
> > While here also fix a very unlikely NULL pointer dereference.
> >
> > Submitted by: Shawn Webb
> >
> > Modified:
> &
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, 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:
>
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
> >
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
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-ifi
+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
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
> > C
l 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: 0xFF2E67A277F
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.
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
m_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" r
compatible 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..
t; 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.
bolUnknown.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
p;& (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:
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
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
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: 0x6A8
; +"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
Hardened
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 i
; 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. ;
t;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-ifi
stream 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
Cofou
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/porte
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}???
>
>
> Grepp
> 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 ${MAKEOB
rrent/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-875
);
> - 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]);
>
>
ude
>
> +# 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 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
&
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
=
> --- 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 \
>
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
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
> >
{
> 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
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
> >&
nts.
>
> 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-
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: 0x6A84658
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
&
${.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
Harde
>> > > 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-
.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_i
t; >> - for (i = 0; path[i]; i++)
> >> - if (!(isalpha(path[i]) || isdigit(path[i])) &&
> >> - path[i] != '/' && path[i] != '.' &&
> >> - path[i] != '-')
> >> -
per 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 Se
@ 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 *
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
Desc
> > > > > > IMHO we only use assert for asserting things ought to never be
> > false
> > > > > > except in buggy code. Using assert for handling is poor practice.
> > > > > >
> > > > >
> > > > > Again, in thi
erential 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
On Wed, Mar 14, 2018 at 05:20:00PM -0600, Alan Somers wrote:
> On Wed, Mar 14, 2018 at 5:11 PM, Shawn Webb <shawn.w...@hardenedbsd.org>
> wrote:
>
> > On Wed, Mar 14, 2018 at 05:06:09PM -0600, Alan Somers wrote:
> > > On Wed, Mar 14, 2018 at 4:56 PM, Shawn We
On Wed, Mar 14, 2018 at 05:06:09PM -0600, Alan Somers wrote:
> On Wed, Mar 14, 2018 at 4:56 PM, Shawn Webb <shawn.w...@hardenedbsd.org>
> wrote:
>
> > On Wed, Mar 14, 2018 at 04:51:27PM -0600, Alan Somers wrote:
> > > On Wed, Mar 14, 2018 at 4:50 PM, Shawn We
On Wed, Mar 14, 2018 at 04:51:27PM -0600, Alan Somers wrote:
> On Wed, Mar 14, 2018 at 4:50 PM, Shawn Webb <shawn.w...@hardenedbsd.org>
> wrote:
>
> > On Sun, Feb 25, 2018 at 02:29:43PM +, Alan Somers wrote:
> > > Author: asomers
> > > Date: Sun Feb 25 1
1 - 100 of 174 matches
Mail list logo
