> > > > "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
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 th
inder 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
again
n: 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: 0xFF2E
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
tter 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
> > i
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/9410e679cc7888311f6efaf251f8d9a311c5b
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
> >
> + sbuf_printf(&sb, "%02x", cp[i]);
> + sbuf_printf(&sb, " owner=%u flags=\"", sfp->f_owner);
> + for (fp = optnames; fp->o_opt != 0; fp++) {
> + if ((mp->mnt_flag & fp->o_opt) != 0) {
> +
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
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
l/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
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 circumstances. But in that case will
> > provid
> 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
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:
ill 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..
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 +,
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:
> > >
andbox && (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+XM
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 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
ws.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:
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
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
ready, 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
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
e 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-
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, &cap_read_rights, &infp);
> + if (error != 0)
> + goto out;
> + error = fget_write(td, outfd, &cap_write_rights, &outfp
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
> >&
od 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
riginal 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 str
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
> >
f 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
Harden
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
HardenedBS
+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
Cofou
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&qu
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:l
es
> 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..
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
andbox && (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+XM
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
ws.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:
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
> >
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 */
> +
aCha20 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
C
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 perfo
nt 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
Harde
ver 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,
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
stab
> 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 ${M
ed/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 Signa
p;mdctx, opts, strlen(opts));
> MD5Final(digest, &mdctx);
> - 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], diges
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_NO
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(&kstack_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
Cof
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
> >&
> 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-
LE_INT_FETCH("efi.rt_disabled", &rt_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:
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
rom 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
> &
.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_vn
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
Cofoun
_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)
&g
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
sig
> > > > except in buggy code. Using assert for handling is poor practice.
> > > > > >
> > > > >
> > > > > Again, in this case we are using it all over the place and we must
> > > > replace
> > > > > it. Also we should document it in somewhere perhaps in the assert(3)
> > > > > otherwise myself and others will keep using it. If you use find, not
> > only
> > > > > myself is using it to check strdup! So what is the suggestion to
> > handle
> > > > > assert(3)? Deprecated it?
> > > >
> > > > Code that uses assert() in place of error handling is wrong and should
> > > > be fixed. assert(condition) means that condition must never happen
> > > > and if it does a bug has occurred (or the programmers assumptions are
> > > > wrong). In this case failure would not be due to a bug, but do to
> > > > resource exhaustion which is expected to be handled.
> > > >
> > >
> > > I agree with you! We have plenty of place that use strdup(3) without
> > check
> > > the errno ENOMEN return; so do you think would be better bypass a errno
> > > ENOMEN without check it and have a crash, or better abort(3) using
> > > assert(3) in case we have no memory available to allocated the memory
> > for a
> > > copy of a string?
> >
> > The correct code here would be one of:
> >
> > str = strdup(opt);
> > if (str == NULL)
> > goto out;
> >
>
> No, it is not the correct code! If we go out and free(str) we have nothing
> to free, because we even didn't allocated memory for str.
Hey Marcelo,
I've authored this commit, which fixes the issues Brooks brought up
(and with which I agree):
https://github.com/HardenedBSD/hardenedBSD/commit/9c05b8def2c33e3889430cc2f54be0402a257366
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
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 n
On Mon, Apr 09, 2018 at 09:33:38AM -0500, Kyle Evans wrote:
> On Mon, Apr 9, 2018 at 9:29 AM, Shawn Webb 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
1 - 100 of 187 matches
Mail list logo
