These entries should have never been present since they only exist for
compat with FreeBSD 6.x (and older) binaries. This was missed in r296572.
Technically this breaks the ABI by removing versioned symbols. However,
no binaries should be linked against these symbols. No release has
shipped with a header that contained a prototype for these functions.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D5615
Further to r240152 (i386) and r240178 (amd64), hide the .cerror symbol
so that it is not exported if symbol versioning is not in use. Without
this change WITHOUT_SYMVER libc contains .text relocations for .cerror,
as described in LLVM PR 26813 (http://llvm.org/pr26813).
This is a no-op for the regular build as the symbol version script
already controls .cerror visibility.
PR: 207712
Submitted by: Rafael Espíndola
Reviewed by: jilles, kib
Differential Revision: https://reviews.freebsd.org/D5571
There is also a small portability crutch, also present in NetBSD,
to allow compiling on a system that doesn't define O_CLOEXEC.
Approved by: rpaulo (mentor)
Obtained from: NetBSD (r1.17, r1.18)
Differential Revision: https://reviews.freebsd.org/D5549
Avoid casting gymnastics that lead to pointer aliasing by introducing an
inline function as done in NetBSD (but without #if0'd WIP code).
Obtained from: NetBSD (CVS Rev. 1.24, 1.25)
According to POSIX, The mbtowc() function shall fail if:
[EILSEQ] An invalid character sequence is detected.
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D5496
Obtained from: OpenBSD (Ingo Schwarze)
MFC after: 1 month
Add missing Symbol.map entry for __aligned_alloc.
Add weak-->strong symbol binding for
{malloc_stats_print,mallctl,mallctlnametomib,mallctlbymib} -->
{__malloc_stats_print,__mallctl,__mallctlnametomib,__mallctlbymib}. These
bindings complete the set necessary to allow applications to replace all
malloc-related symbols.
The rest of the manpage already referenced 'dstsize' but did not rename
the variable in the prototype in r257646.
MFC after: 3 days
Sponsored by: EMC / Isilon Storage Division
After calling the cap_init(3) function Casper will fork from it's original
process, using pdfork(2). Forking from a process has a lot of advantages:
1. We have the same cwd as the original process.
2. The same uid, gid and groups.
3. The same MAC labels.
4. The same descriptor table.
5. The same routing table.
6. The same umask.
7. The same cpuset(1).
From now services are also in form of libraries.
We also removed libcapsicum at all and converts existing program using Casper
to new architecture.
Discussed with: pjd, jonathan, ed, drysdale@google.com, emaste
Partially reviewed by: drysdale@google.com, bdrewery
Approved by: pjd (mentor)
Differential Revision: https://reviews.freebsd.org/D4277
These are no longer needed after the recent 'beforebuild: depend' changes
and hooking DIRDEPS_BUILD into a subset of FAST_DEPEND which supports
skipping 'make depend'.
Sponsored by: EMC / Isilon Storage Division
make sure the changes are on disk. The people at pfSense noticed that
it didn't always make it to the disk soon enough with soft updates.
Differential Revision: https://reviews.freebsd.org/D5186
Reviewed by: garga, vangyzen, bapt, se
MFC after: 1 week
documented and easy to miss.
At the same time, it's pretty important for anyone who is trying to use
SEEK_HOLE/SEEK_DATA in real app. Try to bridge that gap by making that
description more pronounced and also document how it affects failure codes.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D5162
In such cases return ENOMEM. This is a limitation of our
implementation, alternatively you may consider getline(3).
Differential Revision: https://reviews.freebsd.org/D442 (Partial)
Obtained from: Apple Inc. (Libc 997.90.3)
Relnotes: yes
POSIX.1-2008 requires that successful completion simply return a
non-negative integer. We have regularly returned a constant value.
Another, equally valid, implementation convention implies returning
the number of bytes written.
Adopt this last convention to be in line with what Apple's libc
does. POSIX also explicitly notes:
Note that this implementation convention cannot be adhered to for strings
longer than {INT_MAX} bytes as the value would not be representable in the
return type of the function. For backwards-compatibility, implementations
can return the number of bytes for strings of up to {INT_MAX} bytes, and
return {INT_MAX} for all longer strings.
Developers shouldn't depend specifically on either convention but
the change may help port software from Apple.
Differential Revision: https://reviews.freebsd.org/D442 (Partial)
Obtained from: Apple Inc. (Libc 997.90.3 with changes)
Relnotes: yes
do not participate in the global symbols namespace, but rtld locks are
still replaced and functions are interposed. In particular,
__pthread_map_stacks_exec is resolved to the libc version. If a
library is loaded later, which requires adjustment of the stack
protection mode, rtld calls into libc __pthread_map_stacks_exec due to
the symbols scope. The libc version might recurse into binder and
recursively acquire rtld bind lock, causing the hang.
Make libc __pthread_map_stacks_exec() interposed, which synchronizes
rtld locks and version of the stack exec hook when libthr loaded,
regardless of the symbol scope control or symbol resolution order.
The __pthread_map_stacks_exec() symbol is removed from the private
version in libthr since libc symbol now operates correctly in presence
of libthr.
Reported and tested by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
time ago, but for some reason it was not. Basically, without this change
dlopen(3)'ing an empty .so file would just cause application to dump core
with SIGSEGV.
Make sure the file has enough data for at least the ELF header before
mmap'ing it.
Add a test case to check that dlopen an empty file return an error.
There were a separate discussion as to whether it should be SIGBUS
instead when you try to access region mapped from an empty file,
but it's definitely SIGSEGV now, so if anyone want to check that please
be my guest.
Reviewed by: mjg, cem
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D5112
wraps sendmsg(2) and recvmsg(2) into batch send and receive operation.
The goal of this implementation is only to provide API compatibility
with Linux.
The cancellation behaviour of the functions is not quite right, but
due to relative rare use of cancellation it is considered acceptable
comparing with the complexity of the correct implementation. If
functions are reimplemented as syscalls, the fix would come almost
trivial. The direct use of the syscall trampolines instead of libc
wrappers for sendmsg(2) and recvmsg(2) is to avoid data loss on
cancellation.
Submitted by: Boris Astardzhiev <boris.astardzhiev@gmail.com>
Discussed with: jilles (cancellation behaviour)
MFC after: 1 month
This avoids reproducing the lex logic which had dependencies set wrong
and used an intermediate file for modifying the YY_BUF_SIZE.
This has only been possible since flex 2.5.37 was imported in r250873,
which uses #ifndef YY_BUF_SIZE.
MFC after: 2 weeks
Sponsored by: EMC / Isilon Storage Division
nslexer.o depends on nsparser.h, which is already added by bsd.lib.mk
and .depend.
This reverts r237402.
MFC after: 2 weeks
Sponsored by: EMC / Isilon Storage Division
intended behaviour in its man page. Simplify tty_drain() to match.
Don't call ttydevsw methods in tty_flush() if the device is gone
since we now sometimes call it then.
The flushing was supposed to be implemented by passing the FNONBLOCK
flag to VOP_CLOSE() for revoke(). The tty driver is one of the few
that can block in close and was one of the fewer that knew about this.
This almost worked in FreeBSD-1 and similarly in Net/2. These
versions only almost worked because there was and is considerable
confusion between IO_NDELAY and FNONBLOCK (aka O_NONBLOCK). IO_NDELAY
is only valid for VOP_READ() and VOP_WRITE(). For other VOPs it has
the same value as O_SHLOCK. But since vfs_subr.c and tty.c
consistently used the wrong flag and the O_SHLOCK flag is rarely set,
this mostly worked. It also gave the feature than applications could
get the non-blocking close by abusing O_SHLOCK.
This was first broken then fixed in 1995. I changed only the tty
driver to use FNONBLOCK, as a hack to get non-blocking via the normal
flag FNONBLOCK for last closes. I didn't know about revoke()'s use
of IO_NDELAY or change it to be consistent, so revoke() was broken.
Then I changed revoke() to match.
This was next broken in 1997 then fixed in 1998. Importing Lite2 made
the flags inconsistent again by undoing the fix only in vfs_subr.c.
This was next broken in 2008 by replacing everything in tty.c and not
checking any flags in last close. Other bugs in draining limited the
resulting unbounded waits to drain in some cases.
It is now possible to fix this better using the new FREVOKE flag.
Just restore flushing for revoke() for now. Don't restore or undo any
hacks for ordinary last closes yet. But remove dead code in the
1-second relative timeout (r272789). This did extra work to extend
the buggy draining for revoke() for as long as possible. The 1-second
timeout made this not very long by usually flushing after 1 second.
Submitted by: bde
MFC after: 2 weeks
by application closing its stdin (i.e. STDIN_FILENO) prior to
calling readpassphrase WITHOUT setting RPP_STDIN. What happens
then is that the readpassphrase would open /dev/tty, and since
file descriptors are reused, the call would return first unused
fd, which is 0 which is also STDIN_FILENO. Then due to the usage
of "input != STDIN_FILENO" in the code to do its logic, that
would result in noecho flags not set on that file descriptor,
which was original issue I've been trying to fix.
In addition to that, the readpassphrase() would leak file
descriptor on its way out, so fix that one as well.
This problem can be tested with:
$ ssh-add - < /tmp/myprivate.key
The password will not be hidden as it should and ktrace will
show:
53326 ssh-add CALL open(0x80142443c,0x100002<O_RDWR|O_CLOEXEC>,<unused>0x165f030)
53326 ssh-add NAMI "/dev/tty"
53326 ssh-add RET open 0
53326 ssh-add CALL sigprocmask(SIG_SETMASK,0x802eb1324,0x7fffffffd5e0)
53326 ssh-add RET sigprocmask 0
53326 ssh-add CALL sigaction(SIGALRM,0x7fffffffd630,0x7fffffffd610)
Instead of:
57690 ssh-add CALL open(0x80142443c,0x100002<O_RDWR|O_CLOEXEC>,<unused>0x165f030)
57690 ssh-add NAMI "/dev/tty"
57690 ssh-add RET open 4
57690 ssh-add CALL ioctl(0x4,TIOCGETA,0x7fffffffd860)
57690 ssh-add RET ioctl 0
57690 ssh-add CALL ioctl(0x4,TIOCSETAF,0x7fffffffd680)
57690 ssh-add RET ioctl 0
57690 ssh-add CALL sigprocmask(SIG_SETMASK,0x802eb1324,0x7fffffffd620)
57690 ssh-add RET sigprocmask 0
57690 ssh-add CALL sigaction(SIGALRM,0x7fffffffd670,0x7fffffffd650)
For the case when the key is read from the file.
Technically this can also be workaround'ed at the application side
by not closing the STDIN_FILENO in the first place, but readpassphrase(3)
doesn't need to make any assumptions about that. Plus the file descriptor
leak confirms that this is an oversight, rather than a deliberate behaviour.
MFC after: 1 week
