arichardson has an actual fix for the same issue that this was working
around; given that we don't build with llvm today, go ahead and revert the
workaround in advance.
config.h as a guide. In practice contributed software maintains a copy
of config.h within its build directory tree containing its Makefile.
usr.sbin/unbound is the home for its config.h.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D22983
Treat it as a synonym for GRND_NONBLOCK. The reasoning is this:
We have two choices for handling Linux's GRND_INSECURE API flag.
1. We could ignore it completely (like GRND_RANDOM). However, this might
produce the surprising result of GRND_INSECURE requests blocking, when the
Linux API does not block.
2. Alternatively, we could treat GRND_INSECURE requests as requests for
GRND_NONBLOCk. Here, the surprising result for Linux programs is that
invocations with unseeded random(4) will produce EAGAIN, rather than
garbage.
Honoring the flag in the way Linux does seems fraught. If we actually use
the output of a random(4) implementation prior to seeding, we leak some
entropy (in an information theory and also practical sense) from what will
be the initial seed to attackers (or allow attackers to arbitrary DoS
initial seeding, if we don't leak). This seems unacceptable -- it defeats
the purpose of blocking on initial seeding.
Secondary to that concern, before seeding we may have arbitrarily little
entropy collected; producing output from zero or a handful of entropy bits
does not seem particularly useful to userspace.
If userspace can accept garbage, insecure, non-random bytes, they can create
their own insecure garbage with srandom(time(NULL)) or similar. Any program
which would be satisfied with a 3-bit key CTR stream has no need for CSPRNG
bytes. So asking the kernel to produce such an output from the secure
getrandom(2) API seems inane.
For now, we've elected to emulate GRND_INSECURE as an alternative spelling
of GRND_NONBLOCK (2). Consider this API not-quite stable for now. We
guarantee it will never block. But we will attempt to monitor actual port
uptake of this bizarre API and may revise our plans for the unseeded
behavior (prior stable/13 branching).
Approved by: csprng(markm), manpages(bcr)
See also: https://lwn.net/ml/linux-kernel/cover.1577088521.git.luto@kernel.org/
See also: https://lwn.net/ml/linux-kernel/20200107204400.GH3619@mit.edu/
Differential Revision: https://reviews.freebsd.org/D23130
- Fix checks for mmap() failures. [1]
- Set the "map" and "maplen" fields of struct xlocale_collate so that
the table destructor actually does something.
- Free an already-mapped collation file before loading a new one into
the global table.
- Harmonize the prototype and definition of __collate_load_tables_l() by
adding the "static" qualifier to the latter.
PR: 243195
Reported by: cem [1]
Reviewed by: cem, yuripv
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D23109
This opens the door for other descriptor types to implement
posix_fallocate(2) as needed.
Reviewed by: kib, bcr (manpages)
Differential Revision: https://reviews.freebsd.org/D23042
When bootstrapping on powerpc64 ELFv1, it is necessary to use binutils
ld.bfd from ports for the bootstrap, as this is the only modern linker for
ELFv1 host tools.
As binutils ld.bfd is rather strict in its handling of undefined symbols,
it is necessary to pull in Support/Atomic.cpp to avoid an undefined symbol.
Reviewed by: dim, emaste
Sponsored by: Tag1 Consulting, Inc.
Differential Revision: https://reviews.freebsd.org/D23072
There is no API guarantee that realloc() will not fail when the buffer
is shrinking. Handle it by simply returning the untrimmed buffer.
While this is unlikely to ever happen in practice, it seems worth
handling just to silence static analyzer warnings.
PR: 243106
Submitted by: Hans Christian Woithe <chwoithe@yahoo.com>
MFC after: 1 week
I've been advised that the model that uses these are fairly resilient, but
we do know the proper path to use (or remove, in the case of ^/targets/...),
so go ahead and update them to reflect that.
The LSB 4.1 that I referenced omitted the varargs, and I failed to catch it.
The __vsnprintf_chk error was from just downright misreading the page. GCC6
caught all of these, but I had only tested GCC4.2.
X-MFC-With: r356356
For libssp.so, rebuild stack_protector.c with FORTIFY_SOURCE stubs that just
abort built into it.
For libssp_nonshared.a, steal stack_protector_compat.c from
^/lib/libc/secure and massage it to maintain that __stack_chk_fail_local
is a hidden symbol.
libssp is now built unconditionally regardless of {WITH,WITHOUT}_SSP in the
build environment, and the gcclibs version has been disconnected from the
build in favor of this one.
PR: 242950 (exp-run)
Reviewed by: kib, emaste, pfg, Oliver Pinter (earlier version)
Also discussed with: kan
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D22943
A future commit will rebuild this as part of libssp. The exact warnings are
fairly trivially fixed:
- No previous declaration for __stack_chk_guard
- idx is the wrong type, nitems yields a size_t
- Casting away volatile on the tmp_stack_chk_guard directly is a no-no.
Reviewed by: kib, emaste, pfg, Oliver Pinter (earlier version)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D22943
accounting for each NUMA domain. Independent keg domain locks are important
with cross-domain frees. Hashed zones are non-numa and use a single keg
lock to protect the hash table.
Reviewed by: markj, rlibby
Differential Revision: https://reviews.freebsd.org/D22829
GCC issues the warning, but with LLVM it is fatal- no matching .cprestore
with .cpload. Reserve some place on the stack and and add the proper
.cprestore to pair it with.
nop added in the !o32 branch to fill out delay slot instruction, just in
case.
Reviewed by: arichardson
Differential Revision: https://reviews.freebsd.org/D21697
The goal here is to make it so applications can take the rights one would
normally get by calling caph_limit_stream() on a descriptor and build on
them as needed.
The tentatively planned use-case is an application that takes a socket and
hooks it up to std{err,out,in} for a fork()d child. It may be feasible to
apply limitations to such descriptors as long as it's a superset of those
normally applied to stdio.
Reviewed by: markj, oshobo (prior version; sans manpage addition)
Differential Revision: https://reviews.freebsd.org/D22993
When removing a boot environment iterate over the dependents and process the
snapshots by grabbing any clones. Promote the clones we found and then
remove the target environment.
This fixes the ability to destroy a boot environment when it has been used
to spawn one or more other boot environments.
PR: 242592
Submitted by: Wes Maag <jwmaag gmail com> (with changes by myself)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D22953
Update libarchive to 3.4.1
Relevant vendor changes since last update:
Issue #351: Refactor and implement private state logic for write filters
PR #1252: RAR5 reader - verify window size for solid files (OSS-Fuzz 15482)
PR #1255: zip writer - don't append unused NUL for directories
PR #1260: Fix sparse file offset overflow on 32-bit systems
PR #1263: UNICODE filename support for reading lha/lzh format
Issue #1276: Bugfix and optimize archive_wstring_append_from_mbs()
PR #1288: Add the "xattrhdr" option to pax write options
PR #1295: 7z reader - fix reading archives with digests in PackInfo
PR #1296: RAR5 reader - verify window size for multivolume archives
PR #1297: ZIP reader - support LZMA_STREAM_END marker in 'lzma alone' files
Issue #1298: Fix a heap-buffer-overflow in archive_string_append_from_wcs()
OSS-Fuzz 19360, 19362: LHA reader - plug two memory leaks on error
Fix possible off-by-one when dealing with readlink(2)
MFC after: 2 weeks
This code was not actively maintained since it was introduced 10 years ago.
It lacks support for many later GEOM features, such as direct dispatch,
unmapped I/O, stripesize/stripeoffset, resize, etc. Plus it is the only
remaining use of GEOM nstart/nend request counters, used there to implement
live insertion/removal, questionable by itself. Plus, as number of people
commented, GEOM is not the best place for I/O scheduler, since it has
limited information about layers both above and below it, required for
efficient scheduling. Plus with the modern shift to SSDs there is just no
more significant need for this kind of scheduling.
Approved by: imp, phk, luigi
Relnotes: yes
Remove temporary compatibility layer introduced in r351729. More that 3 months
should be enough for everybody who runs HEAD to upgrade to the new kernel
already.
Reviewed by: imp, mjg (mentor)
Approved by: mjg (mentor)
Differential Revision: https://reviews.freebsd.org/D22958
Change the "count_until_fail" option of gnop, now it enables the failing
rating instead of setting them to 100%.
The original patch introduced the new flag, which sets the fail/rate to 100%
after N requests. In some cases, we don't want to have 100% of failure
probabilities. We want to start failing at some point.
For example, on the early stage, we may like to allow some read/writes requests
before having some requests delayed - when we try to mount the partition,
or when we are trying to import the pool.
Another case may be to check how scrub in ZFS will behave on different stages.
This allows us to cover more cases.
The previous behavior still may be configured.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D22632
Thanks to this option we can create more then one gnop provider from
single provider. This may be useful for temporary labeling some data
on the disk.
Reviewed by: markj, allanjude, bcr
Differential Revision: https://reviews.freebsd.org/D22304
Per the University California Regents letter, drop the so-called
"advertisement" clause.
Discussed with: bde, kargl (2017)
Differential Revision: https://reviews.freebsd.org/D22928
lock/lock_free decisions in compiled time
Summary:
Enables atomic.c in compiler_rt and forces clang to not emit a call for runtime
decision about lock/lock_free. At compiling time, if clang can't decide if
atomic operation can be lock free, it emits calls to external functions like
`__atomic_is_lock_free`, `__c11_atomic_is_lock_free` and
`__atomic_always_lock_free`, postponing decision to a runtime check. According
to LLVM code documentation, the mechanism exists due to differences between
x86_64 processors that can't be decided at runtime.
On PowerPC and PowerPCSPE (32 bits), we already know in advance it can't be lock
free, so we force the decision at compile time and avoid having to implement it
in an external library.
This patch was made after 32 bit users testing the PowePC32 bit ISO reported
llvm could not be compiled with in-base llvm due to `__atomic_load8` not
implemented.
Submitted by: alfredo.junior_eldorado.org.br
Reviewed by: jhibbits, dim
Differential Revision: https://reviews.freebsd.org/D22549
cache area. This allows us to check on bucket space for all per-cpu
buckets with a single cacheline access and fewer branches.
Reviewed by: markj, rlibby
Differential Revision: https://reviews.freebsd.org/D22825
Be explicit about it; the first mention of exFAT is for the MBR type 'ntfs',
and the reader must work back from there to the GPT type and infer that a
reference to MBR ntfs type means ms-basic-data is canonical for exFAT.
(It'd also be great if gpart had convenient aliases that did the right
thing for the partition scheme, such as 'ntfs' => ms-basic-data on GPT
schemes or 'exfat' => 'ntfs' in MBR schemes. The tool is also bad about
providing user-meaningful reasons for EINVAL failures.)
g++9 now warns about having defined an assignment operator but using the
default copy constructor, or vice versa. Avoid the issue in libdevdctl
by just using the default assignment operator too.
Reviewed by: asomers, dim
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D22887
This uses the new layout of the upstream repository, which was recently
migrated to GitHub, and converted into a "monorepo". That is, most of
the earlier separate sub-projects with their own branches and tags were
consolidated into one top-level directory, and are now branched and
tagged together.
Updating the vendor area to match this layout is next.
libmagic only depend on mkmagic if not DIRDEPS_BUILD
libpmc fix -I for libpmcstat
local.dirdeps.mk be even more careful about adding gnu/lib/csu to DIRDEPS
Reviewed by: bdrewery
Differential Revision: https://reviews.freebsd.org/D22872
- Move libxo.a build to subdirectory (lib/libxo/libxo/Makefile)
- Add .WAIT target to delay encoder build til after libxo
- Use FILES to install encoder library as csv.enc
- Update import script to put xo_config.h in new location
In original GNU libgcc, _Unwind_Backtrace is published with GCC_3.3 version
for all architectures but ARM. For ARM should be publishes with GCC_4.3.0
version. This was originally omitted in r255095, fixed in r318024 and omitted
aging in LLVM libunwind implementation in r354347.
For ARM _Unwind_Backtrace should be published as default with GCC_4.3.0
version , (because this is right original version) and again as
normal(not-default) with GCC_3.3 version (to maintain ABI compatibility
compiled/linked with wrong pre r318024 libgcc)
PR: 233664
It serves no useful purpose and wasn't as popular as its equally meritless
cousin, srandomdev(3).
Setting aside the problems with rand(3) in general, the problem with this
interface is that the seed isn't shared with the caller (other than by
attacking the output of the generator, which is trivial, but not a hallmark of
pleasant API design). The (arguable) utility of rand(3) or random(3) is as a
semi-fast simulation generator which produces consistent results from a given
seed. These are mutually at odd. Furthermore, sometimes people got the
mistaken impression that a high quality random seed meant a weak generator like
rand(3) or random(3) could be used for things like cryptographic key
generation. This is absolutely not so.
The API was never part of a standard and was not widely used in tree. Existing
in-tree uses have all been removed.
Possible replacement in out of tree codebases:
char buf[3];
time_t t;
time(t);
strftime(buf, sizeof(buf), "%S", gmtime(&t));
srand(atoi(buf));
Relnotes: yes
The settings in arith.h were not fully defined on powerpc64 after the gdtoa
switchover. Generate them using arithchk.c, similar to what AMD64 did for
r114814.
Technically, none of this is necessary in FreeBSD gdtoa, but since the other
platforms have full definitions, we might as well have full definitions
too.
Approved by: jhibbits (in irc)
Differential Revision: https://reviews.freebsd.org/D22775
r355706 added an instance of offsetof() to the UMA private kernel header
file uma_int.h. Userspace memstat_uma.c includes that header, and
chokes on offsetof() because apparently the definition in sys/types.h is
ifdef _KERNEL. Now, include sys/stddef.h which has an identical
definition.
Pointyhat to: rlibby
Sponsored by: Dell EMC Isilon
to specify an optional separator to insert before partition name;
eg if it's set to "c/", you'll get "ada0c/s1" instead of "ada0s1".
(It cannot be set to just “/“, since ada0 is a device node, not
a directory.)
Reviewed by: imp
MFC after: 2 weeks
Sponsored by: Klara Inc.
Differential Revision: https://reviews.freebsd.org/D22193
Replace with arc4random.
TACAS+ is a 1993 Cisco extension to the 1984 TACAS. Is this something we want
in base still? The directory has been substantively unmaintained since 2002,
at least.
These functions appear to intend to produce unpredictable results. Just use
arc4random.
While here, use an explicit_bzero instead of memset where the intent is clearly
to zero out a secret (clear_passphrase).
The jevents tool includes a copy of the jsmn json parser which is MIT
licensed. Upstream the MIT license appears in the jsmn.c source and a
standalone LICENSE file, but the latter is not included in the copy
contained in libpmc and the jsmn.h header carried no license information.
Add an SPDX tag to clarify the situation.
