libc cannot assume that aligned_alloc and free come from jemalloc, or that
any application providing its own malloc and free is actually providing
aligned_alloc.
Switch back to malloc and just make sure we're passing a properly aligned
stack into rfork_thread, as an application perhaps can't reasonably replace
just malloc or just free without headaches.
This unbreaks ksh93 after r361996, which provides malloc/free but no
aligned_alloc.
Reported by: freqlabs
Diagnosed by: Andrew Gierth <andrew_tao173.riddles.org.uk>
X-MFC-With: r361996
pthread_get_name_np() and pthread_set_name_np().
This re-applies r361770 after compatibility fixes.
Reviewed by: antoine, jkim, markj
Tested by: antoine (exp-run)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D25117
Some environments in which execvPe may be called have a limited amount of
stack available. Currently, it avoidably allocates a segment on the stack
large enough to hold PATH so that it may be mutated and use strsep() for
easy parsing. This logic is now rewritten to just operate on the immutable
string passed in and do the necessary math to extract individual paths,
since it will be copying out those segments to another buffer anyways and
piecing them together with the name for a full path.
Additional size is also needed for the stack in posix_spawnp(), because it
may need to push all of argv to the stack and rebuild the command with sh in
front of it. We'll make sure it's properly aligned for the new thread, but
future work should likely make rfork_thread a little easier to use by
ensuring proper alignment.
Some trivial cleanup has been done with a couple of error writes, moving
strings into char arrays for use with the less fragile sizeof().
Reported by: Andrew Gierth <andrew_tao173.riddles.org.uk>
Reviewed by: jilles, kib, Andrew Gierth
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D25038
If execve fails with ENOEXEC, execvp is expected to rebuild the command
with /bin/sh instead and try again.
The previous version did this, but overlooked two details:
argv[0] can conceivably be NULL, in which case memp would never get
terminated. We must allocate no less than three * sizeof(char *) so we can
properly terminate at all times. For the non-NULL argv standard case, we
count all the non-NULL elements and actually skip the first argument, so we
end up capturing the NULL terminator in our bcopy().
The second detail is that the spec is actually worded such that we should
have been preserving argv[0] as passed to execvp:
"[...] executed command shall be as if the process invoked the sh utility
using execl() as follows:
execl(<shell path>, arg0, file, arg1, ..., (char *)0);
where <shell path> is an unspecified pathname for the sh utility, file is
the process image file, and for execvp(), where arg0, arg1, and so on
correspond to the values passed to execvp() in argv[0], argv[1], and so on."
So we make this change at this time as well, while we're already touching
it. We decidedly can't preserve a NULL argv[0] as this would be incredibly,
incredibly fragile, so we retain our legacy behavior of using "sh" for
argv[] in this specific instance.
Some light tests are added to try and detect some components of handling the
ENOEXEC fallback; posix_spawnp_enoexec_fallback_null_argv0 is likely not
100% reliable, but it at least won't raise false-alarms and it did result in
useful failures with pre-change libc on my machine.
This is a secondary change in D25038.
Reported by: Andrew Gierth <andrew_tao173.riddles.org.uk>
Reviewed by: jilles, kib, Andrew Gierth
MFC after: 1 week
Copying the approach chosen in r309412. This fixes building the libc tests
on a macOS host since the macOS /bin/dd binary does not support status=none.
As there only seem to be two uses, this commit changes the two Makefiles.
If this becomes more common, we could also add a wrapper bootstrap script
that ignores status= and forwards the remaining args to the real dd.
Another alternative would be to remove the status flag and pipe stderr to
/dev/null, but them we lose error messages.
Reviewed By: brooks
Differential Revision: https://reviews.freebsd.org/D24785
This commit adds the priv(9) that waters down the sysctl to make it only
allow read(2) of a dirfd by the system root. Jailed root is not allowed, but
jail policy and superuser policy will abstain from allowing/denying it so
that a MAC module can fully control the policy.
Such a MAC module has been written, and can be found at:
https://people.freebsd.org/~kevans/mac_read_dir-0.1.0.tar.gz
It is expected that the MAC module won't be needed by many, as most only
need to do such diagnostics that require this behavior as system root
anyways. Interested parties are welcome to grab the MAC module above and
create a port or locally integrate it, and with enough support it could see
introduction to base. As noted in mac_read_dir.c, it is released under the
BSD 2 clause license and allows the restrictions to be lifted for only
jailed root or for all unprivileged users.
PR: 246412
Reviewed by: mckusick, kib, emaste, jilles, cy, phk, imp (all previous)
Reviewed by: rgrimes (latest version)
Differential Revision: https://reviews.freebsd.org/D24596
Historically, we've allowed read() of a directory and some filesystems will
accommodate (e.g. ufs/ffs, msdosfs). From the history department staffed by
Warner: <<EOF
pdp-7 unix seemed to allow reading directories, but they were weird, special
things there so I'm unsure (my pdp-7 assembler sucks).
1st Edition's sources are lost, mostly. The kernel allows it. The
reconstructed sources from 2nd or 3rd edition read it though.
V6 to V7 changed the filesystem format, and should have been a warning, but
reading directories weren't materially changed.
4.1b BSD introduced readdir because of UFS. UFS broke all directory reading
programs in 1983. ls, du, find, etc all had to be rewritten. readdir() and
friends were introduced here.
SysVr3 picked up readdir() in 1987 for the AT&T fork of Unix. SysVr4 updated
all the directory reading programs in 1988 because different filesystem
types were introduced.
In the 90s, these interfaces became completely ubiquitous as PDP-11s running
V7 faded from view and all the folks that initially started on V7 upgraded
to SysV. Linux never supported this (though I've not done the software
archeology to check) because it has always had a pathological diversity of
filesystems.
EOF
Disallowing read(2) on a directory has the side-effect of masking
application bugs from relying on other implementation's behavior
(e.g. Linux) of rejecting these with EISDIR across the board, but allowing
it has been a vector for at least one stack disclosure bug in the past[0].
By POSIX, this is implementation-defined whether read() handles directories
or not. Popular implementations have chosen to reject them, and this seems
sensible: the data you're reading from a directory is not structured in some
unified way across filesystem implementations like with readdir(2), so it is
impossible for applications to portably rely on this.
With this patch, we will reject most read(2) of a dirfd with EISDIR. Users
that know what they're doing can conscientiously set
bsd.security.allow_read_dir=1 to allow read(2) of directories, as it has
proven useful for debugging or recovery. A future commit will further limit
the sysctl to allow only the system root to read(2) directories, to make it
at least relatively safe to leave on for longer periods of time.
While we're adding logic pertaining to directory vnodes to vn_io_fault, an
additional assertion has also been added to ensure that we're not reaching
vn_io_fault with any write request on a directory vnode. Such request would
be a logical error in the kernel, and must be debugged rather than allowing
it to potentially silently error out.
Commented out shell aliases have been placed in root's chsrc/shrc to promote
awareness that grep may become noisy after this change, depending on your
usage.
A tentative MFC plan has been put together to try and make it as trivial as
possible to identify issues and collect reports; note that this will be
strongly re-evaluated. Tentatively, I will MFC this knob with the default as
it is in HEAD to improve our odds of actually getting reports. The future
priv(9) to further restrict the sysctl WILL NOT BE MERGED BACK, so the knob
will be a faithful reversion on stable/12. We will go into the merge
acknowledging that the sysctl default may be flipped back to restore
historical behavior at *any* point if it's warranted.
[0] https://www.freebsd.org/security/advisories/FreeBSD-SA-19:10.ufs.asc
PR: 246412
Reviewed by: mckusick, kib, emaste, jilles, cy, phk, imp (all previous)
Reviewed by: rgrimes (latest version)
MFC after: 1 month (note the MFC plan mentioned above)
Relnotes: absolutely, but will amend previous RELNOTES entry
Differential Revision: https://reviews.freebsd.org/D24596
One of the error descriptions referred to permissions; in context the
meaning was probably clear, but the prot values are properly called
protections.
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Keep link_map l_addr binary layout compatible, rename l_addr to l_base
where rtld returns map base. Provide relocbase in newly added l_addr.
This effectively reverts the patch to the initial version of D24918.
Reported by: antoine (portmgr)
Reviewed by: jhb, markj
Tested by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D24946
It previously returned the object map base address, while all other
ELF operating systems return load offset, i.e. the difference between
map base and the link base.
Explain the meaning of the field in the man page.
Stop filling the mips-only l_offs member, which is apparently unused.
PR: 246561
Requested by: Damjan Jovanovic <damjan.jov@gmail.com>
Reviewed by: emaste, jhb, cem (previous version)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D24918
functionality first appeared in FreeBSD.
Submitted by: Gordon Bergling gbergling_gmail.com
Approved by: bcr
Differential Revision: https://reviews.freebsd.org/D24677
Attempted to clean up the language around "this is a malloc'd object." May be
passed as a parameter to free(3) is a bit obtuse.
Sponsored by: Dell EMC Isilon
This option was added as a transition aide when symbol versioning was
first added. It was enabled by default in 2007 and is supported even
by the old GPLv2 binutils. Trying to disable it currently fails to
build in libc and at this point it isn't worth fixing the build.
Reported by: Michael Dexter
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D24637
sendto(2), sendmsg(2) and sendmmsg(2) return ENOTCONN if a destination
address is specified and the socket is not connected and the socket
protocol does not automatically connect ("implied connect"). Document
that. Also document the fact that the destination address is ignored
for connection-mode sockets if the socket is already connected.
PR: 245817
Submitted by: Erik Inge Bolsø <knan-bfo@modirum.com>
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D24530
Contrary to the kevent man page, EV_EOF on a fifo is not cleared by
EV_CLEAR. Modify the read and write filters to clear EV_EOF when the
fifo's PIPE_EOF flag is clear, and update the man page to document the
new behaviour.
Modify the write filter to return the amount of buffer space available
even if no readers are present. This matches the behaviour for sockets.
When reading from a pipe, only call pipeselwakeup() if some data was
actually read. This prevents the continuous re-triggering of a
EVFILT_READ event on EOF when in edge-triggered mode.
PR: 203366, 224615
Submitted by: Jan Kokemüller <jan.kokemueller@gmail.com>
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D24528
In r326576 ("use @@@ instead of @@ in __sym_default"), an earlier version of
the phabricator-discussed patch was inadvertently committed. The commit
message claims that @@@ means that weak is not needed, but that was due to a
misunderstanding of the use of weak symbols in this context by the submitted
in the first draft of the patch; the description text was not updated to
match the discussion. As discussed in phabricator, weak is needed for
symbol interposing because of the behavior of our rtld, and is widely used
elsewhere in libc.
This partial revert restores the approved version of the patch and permits
symbol interposing for openat.
Reported by: Raymond Ramsden <rramsden AT isilon.com>
Reviewed by: dim, emaste, kib (2017)
Discussed with: kib (2020)
Differential Revision: https://reviews.freebsd.org/D11653
Revert r354606 to restore r354605.
Apply one line from jemalloc commit d01b425e5d1e1 in hash_x86_128()
to fix the build with gcc, which only allows a fallthrough attribute
to appear before a case or default label.
Submitted by: jasone in r354605
Discussed with: jasone
Reviewed by: bdrewery
MFC after: never, due to gcc 4.2.1
Relnotes: yes
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D24522
If the index we're trying to convert is 0 we can avoid a potentially
expensive call to getifaddrs(). No interface has an ifindex of zero, so
we can handle this as an error: set the errno to ENXIO and return NULL.
Submitted by: Nick Rogers
Reviewed by: lutz at donnerhacke.de
MFC after: 2 weeks
Sponsored by: RG Nets
Differential Revision: https://reviews.freebsd.org/D24524
In the below-referenced PR, a case is attached of a simple reproducer that
exhibits suboptimal behavior: EVFILT_READ and EVFILT_WRITE being set in the
same kevent(2) call will only honor the first one. This is, in-fact, how
it's supposed to work.
A read of the manpage leads me to believe we could be more clear about this;
right now there's a logical leap to make in the relevant statement: "When
passed as input, it forces EV_ERROR to always be returned." -- the logical
leap being that this indicates the caller should have allocated space for
the change to be returned with EV_ERROR indicated in the events, or
subsequent filters will get dropped on the floor.
Another possible workaround that accomplishes similar effect without needing
space for all events is just setting EV_RECEIPT on the final change being
passed in; if any errored before it, the kqueue would not be drained. If we
made it to the final change with EV_RECEIPT set, then we would return that
one with EV_ERROR and still not drain the kqueue. This would seem to not be
all that advisable.
PR: 229741
MFC after: 1 week
This avoids passing garbage to sigprocmask() if the jump buffer is
invalid.
Reviewed by: mhorne
Obtained from: CheriBSD
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D24483
This saves a system call and avoids one of the (relatively rare) cases
of the kernel exporting pointers via sysctl.
As a temporary measure, keep the sysctl support to allow limited
compatability with old kernels.
Fail gracefully if ps_strings can't be found (should never happen).
Reviewed by: kib
Obtained from: CheriBSD
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D24407
This will be used by setproctitle().
Reviewed by: kib
Obtained from: CheriBSD
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D24407
This pattern is used in callbacks with void * data arguments and seems
both relatively uncommon and relatively harmless. Silence the warning
by casting through uintptr_t.
This warning is on by default in Clang 11.
Reviewed by: arichardson
Obtained from: CheriBSD (partial)
MFC after: 1 week
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D24425
Include a temporarily compatibility shim as well for kernels predating
close_range, since closefrom is used in some critical areas.
Reviewed by: markj (previous version), kib
Differential Revision: https://reviews.freebsd.org/D24399
sonewconn() emits debug-level messages when a listen socket's queue
overflows. Currently, sonewconn() tracks overflows on a global basis. It
will only log one message every 60 seconds, regardless of how many sockets
experience overflows. And, when it next logs at the end of the 60 seconds,
it records a single message referencing a single PCB with the total number
of overflows across all sockets.
This commit changes to per-socket overflow tracking. The code will now
log one message every 60 seconds per socket. And, the code will provide
per-socket queue length and overflow counts. It also provides a way to
change the period between log messages using a sysctl.
Reviewed by: jhb (previous version), bcr (manpages)
MFC after: 2 weeks
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D24316
This had been introduced to ease any pain for using slightly older kernels
with a newer libc, e.g., for bisecting a kernel across the introduction of
shm_open2(2). 6 months has passed, retire the fallback and let shm_open()
unconditionally call shm_open2().
Stale includes are removed as well.
arc4random.c: In the incredibly unbelievable circumstance where
_rs_init() fails to allocate pages, don't call abort() because of
corefile data leakage concerns, but simply _exit(). The reasoning
is _rs_init() will only fail if someone finds a way to apply
specific pressure against this failure point, for the purpose of
leaking information into a core which they can read. We don't
need a corefile in this instance to debug that. So take this
"lever" away from whoever in the future wants to do that.
arc4random.3: reference random(4)
arc4random_uniform.c: include stdint.h over sys/types.h
close_range(min, max, flags) allows for a range of descriptors to be
closed. The Python folk have indicated that they would much prefer this
interface to closefrom(2), as the case may be that they/someone have special
fds dup'd to higher in the range and they can't necessarily closefrom(min)
because they don't want to hit the upper range, but relocating them to lower
isn't necessarily feasible.
sys_closefrom has been rewritten to use kern_close_range() using ~0U to
indicate closing to the end of the range. This was chosen rather than
requiring callers of kern_close_range() to hold FILEDESC_SLOCK across the
call to kern_close_range for simplicity.
The flags argument of close_range(2) is currently unused, so any flags set
is currently EINVAL. It was added to the interface in Linux so that future
flags could be added for, e.g., "halt on first error" and things of this
nature.
This patch is based on a syscall of the same design that is expected to be
merged into Linux.
Reviewed by: kib, markj, vangyzen (all slightly earlier revisions)
Differential Revision: https://reviews.freebsd.org/D21627
This is the foundational change for the routing subsytem rearchitecture.
More details and goals are available in https://reviews.freebsd.org/D24141 .
This patch introduces concept of nexthop objects and new nexthop-based
routing KPI.
Nexthops are objects, containing all necessary information for performing
the packet output decision. Output interface, mtu, flags, gw address goes
there. For most of the cases, these objects will serve the same role as
the struct rtentry is currently serving.
Typically there will be low tens of such objects for the router even with
multiple BGP full-views, as these objects will be shared between routing
entries. This allows to store more information in the nexthop.
New KPI:
struct nhop_object *fib4_lookup(uint32_t fibnum, struct in_addr dst,
uint32_t scopeid, uint32_t flags, uint32_t flowid);
struct nhop_object *fib6_lookup(uint32_t fibnum, const struct in6_addr *dst6,
uint32_t scopeid, uint32_t flags, uint32_t flowid);
These 2 function are intended to replace all all flavours of
<in_|in6_>rtalloc[1]<_ign><_fib>, mpath functions and the previous
fib[46]-generation functions.
Upon successful lookup, they return nexthop object which is guaranteed to
exist within current NET_EPOCH. If longer lifetime is desired, one can
specify NHR_REF as a flag and get a referenced version of the nexthop.
Reference semantic closely resembles rtentry one, allowing sed-style conversion.
Additionally, another 2 functions are introduced to support uRPF functionality
inside variety of our firewalls. Their primary goal is to hide the multipath
implementation details inside the routing subsystem, greatly simplifying
firewalls implementation:
int fib4_lookup_urpf(uint32_t fibnum, struct in_addr dst, uint32_t scopeid,
uint32_t flags, const struct ifnet *src_if);
int fib6_lookup_urpf(uint32_t fibnum, const struct in6_addr *dst6, uint32_t scopeid,
uint32_t flags, const struct ifnet *src_if);
All functions have a separate scopeid argument, paving way to eliminating IPv6 scope
embedding and allowing to support IPv4 link-locals in the future.
Structure changes:
* rtentry gets new 'rt_nhop' pointer, slightly growing the overall size.
* rib_head gets new 'rnh_preadd' callback pointer, slightly growing overall sz.
Old KPI:
During the transition state old and new KPI will coexists. As there are another 4-5
decent-sized conversion patches, it will probably take a couple of weeks.
To support both KPIs, fields not required by the new KPI (most of rtentry) has to be
kept, resulting in the temporary size increase.
Once conversion is finished, rtentry will notably shrink.
More details:
* architectural overview: https://reviews.freebsd.org/D24141
* list of the next changes: https://reviews.freebsd.org/D24232
Reviewed by: ae,glebius(initial version)
Differential Revision: https://reviews.freebsd.org/D24232
This is an application of the kernel overflow fix from r357948 to
userspace, based on the algorithm developed by Bruce Evans. To keep
the ABI of the vds_timekeep stable, instead of adding the large_delta
member, MSB of both multipliers are added to quickly estimate the overflow.
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
instead of sprinkling them out over many disjoint files. This is a follow-up
to achieve the same goal in an incomplete rev.348521.
Approved by: imp
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D20520
These functions first appeared in the First Edition of Unix (or earlier in the
pdp-7 version). Just claim 1st Edition for all this. The pdp-7 code is too
fragmented at this point to extend history that far back.
While here, drop an extra conjunction from the list of error
conditions for the remaining EIO description in symlink(2).
Discussed with: mckusick (trimming duplicates)
MFC after: 2 weeks
EINTEGRITY was previously documented as a UFS-specific error for
mount(2). This documents EINTEGRITY as a filesystem-independent error
that may be reported by the backing store of a filesystem.
While here, document EIO as a filesystem-independent error for both
mount(2) and posix_fadvise(2). EIO was previously only documented for
UFS for mount(2).
Reviewed by: mckusick
Suggested by: mckusick
MFC after: 2 weeks
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D24168
For this, things are complicated. The first mention in the manual was in the 4th
edition manual (as an add on to exec(II)). The 2nd and 3rd editions didn't have
these in the manual (either as a separate page, or as an add-on to exec(II)). We
don't have good 1st, 2nd or 3rd edition distributions to look in. However,
there's a tape labeled 'last1120c' that we do have. This tape contains the last
version of the V2 edition of the C compiler on it (just after C got struct). On
this tape there was a libc.sa archive that contains source for execl and
execp. This source is sufficiently different from the V5 sources (which are the
next ones we have sources for) and have a slightly different calling convention
than later sources, suggesting that the early date for the last1120c tape is
correct (in that era, the epoch changed every year, leading to a one or two year
ambiguity on when the files could have been modified) and it should be though of
as V2. Since this was also a time of compiler development, and the calling
convetions are known to be under evolution, and since the rest of the sources in
libc.sa are consistent, that's further evidence that V2 is likely. Finally, 2nd
edition was the last version to fully support the 11/20 because it lacked many
basic features and bell labs moved off it to the 11/45 as soon as they could
afford to buy one, around this time era. The unix manuals make it sound like V3
might have supported the 11/20, but the same intro could also be read to mean it
didn't, at all, and that V3 was the first rewrite for the 11/45 ahead of the
rewrite in C that came with V4.
Taken together, the evidence leans most heavily to V2 (90% IMHO), and slightly
to V3 (8%) or possibly V4 (2%). I've not put all this in the man page, but have
left it here in case someone notices in the future that V4 is the first manual
page for it.
In a single-threaded program pthread_getspecific() always returns NULL,
so the old locale would not end up being freed.
PR: 239520
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
The current code uses a rwlock to protect the cached list, which
in turn holds a list of catentry objects, and increments reference
count while holding only read lock.
Fix this by converting the reference counter to use atomic operations.
While I'm there, also perform some clean ups around memory operations.
PR: 202636
Reported by: Henry Hu <henry.hu.sh@gmail.com>
Reviewed by: markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D24095
Crash was noticed by pkubaj building gcc9.
Apparently non dword-aligned char pointers are somewhat rare in the wild.
Reported by: pkubaj
Sponsored by: Tag1 Consulting, Inc.
when a superblock check-hash error is detected. This change clarifies
a mount that failed due to media hardware failures (EIO) from a mount
that failed due to media errors (EINTEGRITY) that can be corrected by
running fsck(8).
Sponsored by: Netflix
Summary:
POWER architecture CPUs (Book-S) require natural alignment for
cache-inhibited storage accesses. Since we can't know the caching model
for a page ahead of time, always enforce natural alignment in memcpy.
This fixes a SIGBUS in X with acceleration enabled on POWER9.
As part of this, revert r358672, it's no longer necessary with this fix.
Regression tested by alfredo.
Reviewed by: alfredo
Differential Revision: https://reviews.freebsd.org/D23969
VSX instructions were added in POWER ISA V2.06 (POWER7), but it
requires data to be word-aligned. Such requirement was removed in
ISA V2.07B (POWER8).
Since current memcpy/bcopy optimization relies on VSX instructions
handling misalignment transparently, and kernel doesn't currently
implement an alignment error handler, this optimzation should be
restrict to ISA V2.07 onwards.
SIGBUS on stxvd2x instruction was reproduced in POWER7+ CPU.
Reviewed by: luporl, jhibbits, bdragon
Approved by: jhibbits (mentor)
Differential Revision: https://reviews.freebsd.org/D23958
From POSIX,
[ENOTSUP]
The implementation does not support the combination of accesses
requested in the prot argument.
This fits the case that prot contains permissions which are not a subset
of prot_max.
Reviewed by: brooks, cem
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D23843
Also update comments for which architectures use 128 bit long doubles,
as appropriate.
The softfloat specialization routines weren't updated since they
appear to be from an upstream source which we may want to update in
the future to get a more favorable license.
Reviewed by: emaste@
Differential Revision: https://reviews.freebsd.org/D23658
Update the man page to mention that extending a file with truncate(2)
is required by POSIX as of 2008.
Reviewed by: bcr
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D23354
realpath(3) is used a lot e.g., by clang and is a major source of getcwd
and fstatat calls. This can be done more efficiently in the kernel.
This works by performing a regular lookup while saving the name and found
parent directory. If the terminal vnode is a directory we can resolve it using
usual means. Otherwise we can use the name saved by lookup and resolve the
parent.
See the review for sample syscall counts.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D23574
-Werror warnings from clang 10.0.0, such as:
lib/libc/quad/fixdfdi.c:57:12: error: implicit conversion from 'long long' to 'double' changes value from 9223372036854775807 to 9223372036854775808 [-Werror,-Wimplicit-int-float-conversion]
if (x >= QUAD_MAX)
~~ ^~~~~~~~
/usr/obj/usr/src/powerpc.powerpc/tmp/usr/include/sys/limits.h:89:19: note: expanded from macro 'QUAD_MAX'
#define QUAD_MAX (__QUAD_MAX) /* max value for a quad_t */
^~~~~~~~~~
/usr/obj/usr/src/powerpc.powerpc/tmp/usr/include/machine/_limits.h:91:20: note: expanded from macro '__QUAD_MAX'
#define __QUAD_MAX __LLONG_MAX /* max value for a quad_t */
^~~~~~~~~~~
/usr/obj/usr/src/powerpc.powerpc/tmp/usr/include/machine/_limits.h:75:21: note: expanded from macro '__LLONG_MAX'
#define __LLONG_MAX 0x7fffffffffffffffLL /* max value for a long long */
^~~~~~~~~~~~~~~~~~~~
and many instances of:
lib/libc/quad/fixunsdfdi.c:73:17: error: shift count >= width of type [-Werror,-Wshift-count-overflow]
toppart = (x - ONE_HALF) / ONE;
^~~~~~~~
lib/libc/quad/fixunsdfdi.c:45:19: note: expanded from macro 'ONE_HALF'
#define ONE_HALF (ONE_FOURTH * 2.0)
^~~~~~~~~~
lib/libc/quad/fixunsdfdi.c:44:23: note: expanded from macro 'ONE_FOURTH'
#define ONE_FOURTH (1 << (LONG_BITS - 2))
^ ~~~~~~~~~~~~~~~
lib/libc/quad/fixunsdfdi.c:73:29: error: shift count >= width of type [-Werror,-Wshift-count-overflow]
toppart = (x - ONE_HALF) / ONE;
^~~
lib/libc/quad/fixunsdfdi.c:46:15: note: expanded from macro 'ONE'
#define ONE (ONE_FOURTH * 4.0)
^~~~~~~~~~
lib/libc/quad/fixunsdfdi.c:44:23: note: expanded from macro 'ONE_FOURTH'
#define ONE_FOURTH (1 << (LONG_BITS - 2))
^ ~~~~~~~~~~~~~~~
A new syscall sigfastblock(2) is added which registers a uint32_t
variable as containing the count of blocks for signal delivery. Its
content is read by kernel on each syscall entry and on AST processing,
non-zero count of blocks is interpreted same as the signal mask
blocking all signals.
The biggest downside of the feature that I see is that memory
corruption that affects the registered fast sigblock location, would
cause quite strange application misbehavior. For instance, the process
would be immune to ^C (but killable by SIGKILL).
With consumers (rtld and libthr added), benchmarks do not show a
slow-down of the syscalls in micro-measurements, and macro benchmarks
like buildworld do not demonstrate a difference. Part of the reason is
that buildworld time is dominated by compiler, and clang already links
to libthr. On the other hand, small utilities typically used by shell
scripts have the total number of syscalls cut by half.
The syscall is not exported from the stable libc version namespace on
purpose. It is intended to be used only by our C runtime
implementation internals.
Tested by: pho
Disscussed with: cem, emaste, jilles
Sponsored by: The FreeBSD Foundation
Differential revision: https://reviews.freebsd.org/D12773
- Use a constant for the offset instead of a magic number.
- Use an addi instruction that writes to tp directly instead of a mv
that writes the result of a compiler-generated addi.
Reviewed by: mhorne
MFC after: 1 week
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D23521
libssp_nonshared.a defines one symbol, __stack_chk_fail_local. This
is used only on i386 and powerpc; other archs emit calls directly to
__stack_chk_fail. Simplify linking on other archs by omitting it.
PR: 242941 [exp-run]
This appears to have been introduced in r173763. Also fix the confusing
indentation that probably led to the bug in the first place.
PR: 243759
Diagnosed by: martin@lispworks.com
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Among the same justification as the other stdio _unlocked; in addition to an
inline version in <stdio.h>, we must provide a function in libc as well for
the functionality. This fixes the lang/gcc* builds, which want to use the
symbol from libc.
PR: 243810
Reported by: antoine, swills, Michael <michael.adm gmail com>
X-MFC-With: r357284
O_SEARCH is defined by POSIX [0] to open a directory for searching, skipping
permissions checks on the directory itself after the initial open(). This is
close to the semantics we've historically applied for O_EXEC on a directory,
which is UB according to POSIX. Conveniently, O_SEARCH on a file is also
explicitly undefined behavior according to POSIX, so O_EXEC would be a fine
choice. The spec goes on to state that O_SEARCH and O_EXEC need not be
distinct values, but they're not defined to be the same value.
This was pointed out as an incompatibility with other systems that had made
its way into libarchive, which had assumed that O_EXEC was an alias for
O_SEARCH.
This defines compatibility O_SEARCH/FSEARCH (equivalent to O_EXEC and FEXEC
respectively) and expands our UB for O_EXEC on a directory. O_EXEC on a
directory is checked in vn_open_vnode already, so for completeness we add a
NOEXECCHECK when O_SEARCH has been specified on the top-level fd and do not
re-check that when descending in namei.
[0] https://pubs.opengroup.org/onlinepubs/9699919799/
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D23247
rand(3)'s standard C API is extremely limiting, but we can do better
than the historical 32-bit state Park-Miller LCG we've shipped since
2001: r73156.
The justification provided at the time for not using random(3) was that
rand_r(3) could not be made to use the same algorithm. That is still
true. However, the irrelevance of rand_r(3) is increasingly obvious.
Since that time, POSIX has marked the interface obsolescent. rand_r(3)
never became part of the standard C library. If not for API
compatibility reasons, I would just remove rand_r(3) entirely.
So, I do not believe it is a problem for rand_r(3) and rand(3) to
diverge.
The 12 ABI is maintained with compatibility definitions, but this
revision does subtly change the API of rand(3). The sequences of
pseudorandom numbers produced in programs built against new versions of
libc will differ from programs built against prior versions of libc.
Reviewed by: kevans, markm
MFC after: no
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D23290
fflush_unlocked is currently desired in ports by sysutils/metalog, and
redefined as the locked fflush.
fputc_unlocked, fputs_unlocked, fread_unlocked, and fwrite_unlocked are
currently desired in ports by devel/elfutils, and redefined as the locked
fputs, fread, and fwrite respectively.
Reviewed by: kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D23336
The existing APIs simply pass the implicit global state to the _r variants.
No functional change.
Note that these routines are not exported from libc and are not intended to be
exported. If someone wished to export them from libc (which I would
discourage), they should first be modified to match the inconsistent parameter
type / order of the glibc public interfaces of the same names.
I know Ravi will ask, so: the eventual goal of this series is to replace
rand(3) with the implementation from random(3) (D23290). However, I'd like to
wait a bit longer on that one to see if more feedback emerges.
Reviewed by: kevans, markm
Differential Revision: https://reviews.freebsd.org/D23289
As part of the FreeBSD powerpc* flag day (1300070), the auxv numbering was
changed to match every other platform.
See D20799 for more details on that change.
While the kernel and rtld were adapted, libc was not, so old dynamic
binaries broke for reasons other than the ABI change on powerpc64.
Since it's possible to support nearly everything regarding old binaries by
adding compatibility code to libc (as besides rtld, it is the main point
where auxv is digested), we might as well provide compatibility code.
The only unhandled case remaining should be "new format libraries that call
elf_aux_info() which are dynamically linked to by old-format binaries",
which should be quite rare.
Reviewed by: jhibbits
Sponsored by: Tag1 Consulting, Inc.
Differential Revision: https://reviews.freebsd.org/D23096
In the case of an error, the RFSPAWN'd thread will write back to psa->error
with the correct exit code. Mark this as volatile as the return value is
being actively dorked up for erroneous exits on !x86.
This fixes the following tests, tested on aarch64 (only under qemu, at the
moment):
- posix_spawn/spawn_test:t_spawn_missing
- posix_spawn/spawn_test:t_spawn_nonexec
- posix_spawn/spawn_test:t_spawn_zero
Reported by: mikael
MFC after: 3 days
to port software written for Linux variant of qsort_r(3).
Reviewed by: kib, arichardson
MFC after: 2 weeks
Relnotes: yes
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D23174
Prior to introduction of this op libc's readdir would call fstatfs(2), in
effect unnecessarily copying kilobytes of data just to check fs name and a
mount flag.
Reviewed by: kib (previous version)
Differential Revision: https://reviews.freebsd.org/D23162
For copies shorter than 512 bytes, the data is copied using plain
ld/std instructions.
For 512 bytes or more, the copy is done in 3 phases:
Phase 1: copy from the src buffer until it's aligned at a 16-byte boundary
Phase 2: copy as many aligned 64-byte blocks from the src buffer as possible
Phase 3: copy the remaining data, if any
In phase 2, this code uses VSX instructions when available. Otherwise,
it uses ldx/stdx.
Submitted by: Luis Pires <lffpires_ruabrasil.org> (original version)
Reviewed by: jhibbits
Differential Revision: https://reviews.freebsd.org/D15118
Assembly optimization of strncpy for PowerPC64, using double words
instead of bytes to copy strings.
Submitted by: Leonardo Bianconi <leonardo.bianconi_eldorado.org.br> (original version)
Reviewed by: jhibbits
Differential Revision: https://reviews.freebsd.org/D15369
Assembly optimization of strcpy for PowerPC64, using double words
instead of bytes to copy strings.
Submitted by: Leonardo Bianconi <leonardo.bianconi_eldorado.org.br> (original version)
Reviewed by: jhibbits
Differential Revision: https://reviews.freebsd.org/D15368
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
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.
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
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
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.
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
Fix multiple problems in the powerpcspe floating point code.
* Endianness handling of the SPEFSCR in fenv.h was completely broken.
* Ensure SPEFSCR synchronization requirements are being met.
The __r.__d -> __r transformations were written by jhibbits.
Reviewed by: jhibbits
Differential Revision: https://reviews.freebsd.org/D22526
These functions (sigandset, sigisemptyset, sigorset) are commonly available
in at least musl libc and glibc; sigorset, at least, has proven quite useful
in qemu-bsd-user work for tracking the current process signal mask in a more
self-documenting/aesthetically pleasing manner.
Reviewed by: bapt, jilles, pfg
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D22187
Update a bunch of Makefile.depend files as
a result of adding Makefile.depend.options files
Reviewed by: bdrewery
MFC after: 1 week
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org/D22494
Leaf directories that have dependencies impacted
by options need a Makefile.depend.options file
to avoid churn in Makefile.depend
DIRDEPS for cases such as OPENSSL, TCP_WRAPPERS etc
can be set in local.dirdeps-options.mk
which can add to those set in Makefile.depend.options
See share/mk/dirdeps-options.mk
Reviewed by: bdrewery
MFC after: 1 week
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org/D22469
As mandated by POSIX. Also clarify the kill(2) manpage.
While there, restructure the code in killpg1() to use helper which
keeps overall state of the process list iteration in the killpg1_ctx
structued, later used to infer the error returned.
Reported by: amdmi3
Reviewed by: jilles
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D22621
Conditional branch and jump instructions do not always call via PLT
stubs and thus will not honor LD_PRELOAD, etc. lld warns about using
non-preemptible relocations for preemptible or unknown symbols whereas
bfd does not (at least for RISC-V).
Reviewed by: br, James Clarke
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D22658
This saves an instruction in each case as well as an extra memory
indirection via the GOT for PIC code.
Reviewed by: br, James Clarke
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D22656
o Remove All Rights Reserved from my notices
o imp@FreeBSD.org everywhere
o regularize punctiation, eliminate date ranges
o Make sure that it's clear that I don't claim All Rights reserved by listing
All Rights Reserved on same line as other copyright holders (but not
me). Other such holders are also listed last where it's clear.
Theoretically, this was breaking the size calculation for the symbol.
Noticed when doing a readthrough.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D22525
Due to ELFv1 specific code in _ctx_start.S and makecontext.c, userspace
context switching was completely broken on ELFv2.
With this change, we now pass the libthr test suite.
Approved by: jhibbits (mentor)
Differential Revision: https://reviews.freebsd.org/D22421
Add ifdefs in the assembler for soft-float compile case.
Submitted by: Hiroki Mori
Reviewed by: ray@
Differential Review: https://reviews.freebsd.org/D22352
__has_attribute(__constructor__) is a better test for clang than
defined(__clang__). Switch to it instead.
While we're already here and touching it, pfg@ nailed down when GCC actually
introduced the priority argument -- 4.3. Use that instead of our
hammer-guess of GCC >= 5 for the sake of correctness.
The preproc logic was added at the last minute to appease GCC 4.2, and
kevans@ did clearly not go back and double-check that the logic worked out
for clang builds to use the new variant.
It turns out that clang defines __GNUC__ == 4. Flip it around and check
__clang__ as well, leaving a note to remove it later.
Reported by: cem
First, this commit is a NOP on GCC <= 4.x; this decidedly doesn't work
cleanly on GCC 4.2, and it will be gone soon anyways so I chose not to dump
time into figuring out if there's a way to make it work. xtoolchain-gcc,
clocking in as GCC6, can cope with it just fine and later versions are also
generally ok with the syntax. I suspect very few users are running GCC4.2
built worlds and also experiencing potential fallout from the status quo.
For dynamically linked applications, this change also means very little.
rtld will run libc ctors before most others, so the situation is
approximately a NOP for these as well.
The real cause for this change is statically linked applications doing
almost questionable things in their constructors. qemu-user-static, for
instance, creates a thread in a global constructor for their async rcu
callbacks. In general, this works in other places-
- On OpenBSD, __stack_chk_guard is stored in an .openbsd.randomdata section
that's initialized by the kernel in the static case, or ld.so in the
dynamic case
- On Linux, __stack_chk_guard is apparently stored in TLS and such a problem
is circumvented there because the value is presumed stable in the new
thread.
On FreeBSD, the rcu thread creation ctor and __guard_setup are both unmarked
priority. qemu-user-static spins up the rcu thread prior to __guard_setup
which starts making function calls- some of these are sprinkled with the
canary. In the middle of one of these functions, __guard_setup is invoked in
the main thread and __stack_chk_guard changes- qemu-user-static is promptly
terminated for an SSP violation that didn't actually happen.
This is not an all-too-common problem. We circumvent it here by giving the
__stack_chk_guard constructor a solid priority. 200 was chosen because that
gives static applications ample range (down to 101) for working around it
if they really need to. I suspect most applications will "just work" as
expected- the default/non-prioritized flavor of __constructor__ functions
run last, and the canary is generally not expected to change as of this
point at the very least.
This took approximately three weeks of spare time debugging to pin down.
PR: 241905
Even though clang comes with a number of internal CUDA wrapper headers,
compiling sample CUDA programs will result in errors similar to:
In file included from <built-in>:1:
In file included from /usr/lib/clang/9.0.0/include/__clang_cuda_runtime_wrapper.h:204:
/usr/home/arr/cuda/var/cuda-repo-10-0-local-10.0.130-410.48/usr/local/cuda-10.0//include/crt/math_functions.hpp:2910:7: error: no matching function for call to '__isnan'
if (__isnan(a)) {
^~~~~~~
/usr/lib/clang/9.0.0/include/__clang_cuda_device_functions.h:460:16: note: candidate function not viable: call to __device__ function from __host__ function
__DEVICE__ int __isnan(double __a) { return __nv_isnand(__a); }
^
CUDA expects __isnan() and __isnanf() declarations to be available,
which are glibc specific extensions, equivalent to the regular isnan()
and isnanf().
To provide these, define __isnan() and __isnanf() as aliases of the
already existing static inline functions __inline_isnan() and
__inline_isnanf() from math.h.
Reported by: arrowd
PR: 241550
MFC after: 1 week
This warning (comparing a pointer against a zero character literal
rather than NULL) has existed since GCC 7.1.0, and was recently added to
Clang trunk.
Almost all of these are harmless, except for fwcontrol's str2node, which
needs to both guard against dereferencing a NULL pointer (though in
practice it appears none of the callers will ever pass one in), as well
as ensure it doesn't parse the empty string as node 0 due to strtol's
awkward interface.
Submitted by: James Clarke <jtrc27@jrtc27.com>
Obtained from: CheriBSD
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D21914
While FreeBSD's implementation of these expect an int inside of libc, that's an
implementation detail that we can hide from the user as it's the natural
promotion of the current mode_t type and before it is used in the kernel, it's
converted back to the narrower type that's the current definition of mode_t. As
such, documenting int is at best confusing and at worst misleading. Instead add
a note that these args are variadic and as such calling conventions may differ
from non-variadic arguments.
promoted to ints).
- `mode_t` is `uint16_t` (`sys/sys/_types.h`)
- `openat` takes variadic args
- variadic args cannot be 16-bit, and indeed the code uses int
- the manpage currently kinda implies the argument is 16-bit by saying `mode_t`
Prompted by Rust things: https://github.com/tailhook/openat/issues/21
Submitted by: Greg V at unrelenting
Differential Revision: https://reviews.freebsd.org/D21816
