summaryrefslogtreecommitdiffstats
path: root/lib/libc (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* Use a trap instruction that unconditionally terminates the process.visa2020-10-201-2/+2
| | | | OK deraadt@
* Retguard sigsetjmp on powerpc64.mortimer2020-10-191-5/+10
| | | | ok deraadt@
* replace ad-hoc illegal instruction with the architecturally defined onenaddy2020-10-192-4/+4
| | | | | ("permanently undefined") ok deraadt@ kettenis@
* add retguard prologue/epiloguederaadt2020-10-191-2/+4
| | | | ok mortimer
* Save and restore the FPCR register such that floating-point control modeskettenis2020-10-192-6/+14
| | | | are properly restored by longjmp(3).
* Add powerpc64 retguard macros for setjmp / longjmp.mortimer2020-10-181-5/+10
| | | | ok deraadt@
* SYS___threxit cannot fail, but this integration looks like a gadget.deraadt2020-10-1811-11/+24
| | | | | Put a hard-trap instruction after the syscall instruction. ok kettenis mortimer
* Adapt SYS.h to use retguard macros from asm.h, so that generated systemderaadt2020-10-168-46/+77
| | | | | | calls are guarded. Adapt the first few hand-written functions to this model (a few remain) ok kettenis mortimer
* Do some easy .data -> .rodata/.data.rel.ro conversionsguenther2020-10-139-23/+23
| | | | ok millert@ deraadt@
* make fixed-sized fixed-value mib[] arrays be constderaadt2020-10-1211-44/+24
| | | | ok guenther tb millert
* annoying whitespacederaadt2020-10-121-2/+2
|
* mib[2] is no longer used; ok guentherderaadt2020-10-121-2/+2
|
* Correct error returns, do not print eror message to stdout (thereotto2020-10-092-10/+17
| | | | | | is a dlerror() function for that) and mark dladdr() as PROTO_NORMAL to be able to call it from a malloc.c MALLOC_STATS leak reporting project I'm working on. ok kettenis@
* Partly revert previous commit, these changes we not supposed to go in.otto2020-10-092-4/+3
|
* As noted by tb@ previous commit only removed an unused fucntion.otto2020-10-093-7/+13
| | | | | So redo previous commit properly: Use random value for canary bytes; ok tb@.
* Use random value for canary bytes; ok tb@otto2020-10-061-23/+1
|
* Mark top-level frame for new thread in both CFI and with zeroguenther2020-10-012-2/+16
| | | | | | framepointer, so gdb knows to stop. Inspired by glibc ok kettenis@
* adjust protos for utimes/futimes to use [2], and then add documentationderaadt2020-09-301-4/+28
| | | | | regarding EINVAL for denomalized time values (sub-second out of range) ok jmc millert, discussion with kettenis
* Spell out n as en for consistency with other parts of the page.tb2020-09-131-3/+3
|
* %lln is percent ell ell n (not dee).claudio2020-09-131-4/+4
| | | | OK deraadt@
* For page-sized and larger allocations do not put the pages we'reotto2020-09-061-21/+18
| | | | | | | shaving off into the cache but unamp them. Pages in the cache get re-used and then a future grow of the first allocation will be hampered. Also make realloc a no-op for small shrinkage. ok deraadt@
* Remove duplicate definition of _null_auth.mortimer2020-08-301-3/+1
| | | | ok millert@ deraadt@
* amd64: TSC timecounter: prefix RDTSC with LFENCEcheloha2020-08-231-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Regarding RDTSC, the Intel ISA reference says (Vol 2B. 4-545): > The RDTSC instruction is not a serializing instruction. > > It does not necessarily wait until all previous instructions > have been executed before reading the counter. > > Similarly, subsequent instructions may begin execution before the > read operation is performed. > > If software requires RDTSC to be executed only after all previous > instructions have completed locally, it can either use RDTSCP (if > the processor supports that instruction) or execute the sequence > LFENCE;RDTSC. To mitigate this problem, Linux and DragonFly use LFENCE. FreeBSD and NetBSD take a more complex route: they selectively use MFENCE, LFENCE, or CPUID depending on whether the CPU is AMD, Intel, VIA or something else. Let's start with just LFENCE. We only use the TSC as a timecounter on SSE2 systems so there is no need to conditionally compile the LFENCE. We can explore conditionally using MFENCE later. Microbenchmarking on my machine (Core i7-8650) suggests a penalty of about 7-10% over a "naked" RDTSC. This is acceptable. It's a bit of a moot point though: the alternative is a considerably weaker monotonicity guarantee when comparing timestamps between threads, which is not acceptable. It's worth noting that kernel timecounting is not *exactly* like userspace timecounting. However, they are similar enough that we can use userspace benchmarks to make conjectures about possible impacts on kernel performance. Concerns about kernel performance, in particular the network stack, were the blocking issue for this patch. Regarding networking performance, claudio@ says a 10% slower nanotime(9) or nanouptime(9) is acceptable and that shaving off "tens of cycles" is a micro-optimization. There are bigger optimizations to chase down before such a difference would matter. There is additional work to be done here. We could experiment with conditionally using MFENCE. Also, the userspace TSC timecounter doesn't have access to the adjustment skews available to the kernel timecounter. pirofti@ has suggested a scheme involving RDTSCP and an array of skews mapped into user memory. deraadt@ has suggested a scheme where the skew would be kept in the TCB. However it is done, access to the skews will improve monotonicity, which remains a problem with the TSC. First proposed by kettenis@ and pirofti@. With input from pirofti@, deraadt@, guenther@, naddy@, kettenis@, and claudio@. Based on similar changes in Linux, FreeBSD, NetBSD, and DragonFlyBSD. ok deraadt@ pirofti@ kettenis@ naddy@ claudio@
* Fix append mode so it always writes to the end and expand regress.millert2020-08-171-2/+7
| | | | OK deraadt@ martijn@
* Fix handling of "w+" mode, we were only truncating for "w".millert2020-08-141-2/+2
| | | | OK martijn@ mpi@
* select.2: Xr directly to timersub(3) now that it has a dedicated manpagecheloha2020-08-131-5/+3
| | | | Reported by Fabian Raetz <fabian.raetz@gmail.com>.
* We have `pipexinq' and `pipexoutq' mbuf(9) queues to store pipex(4)mvs2020-08-041-26/+2
| | | | | | | | | | | | | related mbufs. Each mbuf(9) passed to these queues stores the pointer to corresponding pipex(4) session referenced as `m_pkthdr.ph_cookie'. When session was destroyed its reference can still be in these queues so we have use after free issue while pipexintr() dereference it. I removed `pipexinq', `pipexoutq' and pipexintr(). This not only allows us to avoid issue described above, but also removes unnecessary context switch in packet processing. Also it makes code simpler. ok mpi@ yasuoka@
* Fix two cases where we shpould compare/store 64-bit values instead ofkettenis2020-07-271-3/+3
| | | | | | 32-bit values. ok gkoehler@, drahn@
* Fix powerpc64's sbrk()gkoehler2020-07-271-3/+5
| | | | | | | Initialize __curbrk = &_end. It's a 64-bit pointer, so use ld/std instead of lwz/stw. ok drahn@
* Reference unveil(2) in system accounting and daily.8.rob2020-07-261-6/+5
| | | | | | | Reminder that unveil does not kill from brynet and gsoares. Wording tweaks from jmc; feedback from deraadt. ok jmc@, millert@, solene@, "fine with me" deraadt@
* Userland timecounter implementation for octeonvisa2020-07-181-3/+30
| | | | OK naddy@; no objections from kettenis@
* Userland timecounter for macppcgkoehler2020-07-171-2/+22
| | | | | | | Tested by cwen@ and myself. Thanks to pirofti@ for creating the userland timecounter feature. ok kettenis@ pirofti@ deraadt@ cheloha@
* "wroute" allows changes to the routing table; ok deraadtjmc2020-07-171-2/+2
|
* route and wroute were undocumented; ok florianderaadt2020-07-171-2/+7
|
* Remove obsolete LOCALE_HOME code we have never used (and never will).millert2020-07-161-146/+1
| | | | Upstream removed it in 2004. From Jan Stary.
* allow setenv LIBC_NOUSERTC to disable userland timekeeping, for ktrace.tedu2020-07-161-1/+3
| | | | ok deraadt pirofti
* Userland timecounter implementation for arm64.kettenis2020-07-151-3/+29
| | | | ok naddy@
* Fix TIB/TCB on powerpc64. Some bright sould decided that the TCB shouldkettenis2020-07-141-3/+3
| | | | | | | | | | | be 8 bytes in the 64-bit ABI just like in the 32-bit ABI. But that means there is no "spare" word in the TCB that we can use to store a pointer to our struct pthread. So we have to treat powerpc64 special. Also recognize that the thread pointer points 0x7000 bytes after the TCB. Since the TCB is 8 bytes this means that TCB_OFFSET should be 0x7008. Pointed out by guenther@; ok deraadt@
* Add usertc.c.kettenis2020-07-111-0/+1
|
* Add missing usertc.c file.kettenis2020-07-111-0/+21
|
* adjust %n description to vaguely say "pointer", becuase the followingderaadt2020-07-101-4/+6
| | | | | | list of "[size]n" includes "n" on it's own, thereby the "int" case is described correctly. ok schwarze
* As suggested by deraadt@, rewrite most of the printf(3) manual pageschwarze2020-07-101-453/+586
| | | | | | | | | | | | | | to properly show the (differing) syntaxes of all the conversion specifications, and reduce the amount of forward references from the list of modifiers to the list of specifiers. While here, properly explain %lc and %ls. Also correct RETURN VALUES, which incorrectly talked about counting characters while actually bytes are counted. Using feedback from millert@, deraadt@, tb@, and Martin Vahlensieck. OK deraadt@, millert@, and tb@ on intermediate versions of this diff and no objections from jmc@.
* adjfreq(2): limit adjustment to [-500000, +500000] ppmcheloha2020-07-091-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we recompute the scaling factor during tc_windup() there is an opportunity for arithmetic overflow if the active timecounter's adjfreq(2) adjustment is too large. If we limit the adjustment to [-500000, +500000] ppm the statement in question cannot overflow. In particular, we are concerned with the following bit of code: scale = (u_int64_t)1 << 63; scale += \ ((th->th_adjustment + th->th_counter->tc_freq_adj) / 1024) * 2199; scale /= th->th_counter->tc_frequency; th->th_scale = scale * 2; where scale is an int64_t. Overflow when we do: scale += (...) / 1024 * 2199; as th->th_counter->tc_freq_adj is currently unbounded. th->th_adjustment is limited to [-5000ppm, 5000ppm]. To see that overflow is prevented with the new bounds, consider the new edge case where th->th_counter->tc_freq_adj is 500000ppm and th->th_adjustment is 5000ppm. Both are of type int64_t. We have: int64_t th_adjustment = (5000 * 1000) << 32; /* 21474836480000000 */ int64_t tc_freq_adj = 500000000LL << 32; /* 2147483648000000000 */ scale = (u_int64_t)1 << 63; /* 9223372036854775808 */ scale += (th_adjustment + tc_freq_adj) / 1024 * 2199; /* scale += 2168958484480000000 / 1024 * 2199; */ /* scale += 4657753620480000000; */ 9223372036854775808 + 4657753620480000000 = 13881125657334775808, which less than 18446744073709551616, so we don't have overflow. On the opposite end, if th->th_counter->tc_freq_adj is -500000ppm and th->th_adjustment is -5000ppm we would have -4657753620480000000. 9223372036854775808 - 4657753620480000000 = 4565618416374775808. Again, no overflow. 500000ppm and -500000ppm are extreme adjustments. otto@ says ntpd(8) would never arrive at them naturally, so we are not at risk of breaking a working setup by imposing these restrictions. Documentation input from kettenis@. No complaints from otto@.
* Userland timecounter implementation for sparc64.kettenis2020-07-082-4/+41
| | | | ok deraadt@, pirofti@
* Clean up the amd64 userland timecounter implementation a bit:kettenis2020-07-081-10/+10
| | | | | | | | | * We don't need TC_LAST * Make internal functions static to avoid namespace pollution in libc.a * Use a switch statement to harmonize with architectures providing multiple timecounters ok deraadt@, pirofti@
* Minor tweaks in the description of %g:schwarze2020-07-061-4/+8
| | | | | | | | 1. Clarify that %G uses %F, not %f; noticed by millert@. 2. Mention that %g originally meant "general notation", see: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/libc/stdio/doprnt.s Triggered by a somewhat different patch from Ian <ropers at gmail dot com>. Feedback and OK millert@ and jmc@.
* Add support for timeconting in userland.pirofti2020-07-0642-65/+596
| | | | | | | | | | | | | | | | | | | | | | | | | | This diff exposes parts of clock_gettime(2) and gettimeofday(2) to userland via libc eliberating processes from the need for a context switch everytime they want to count the passage of time. If a timecounter clock can be exposed to userland than it needs to set its tc_user member to a non-zero value. Tested with one or multiple counters per architecture. The timing data is shared through a pointer found in the new ELF auxiliary vector AUX_openbsd_timekeep containing timehands information that is frequently updated by the kernel. Timing differences between the last kernel update and the current time are adjusted in userland by the tc_get_timecount() function inside the MD usertc.c file. This permits a much more responsive environment, quite visible in browsers, office programs and gaming (apparently one is are able to fly in Minecraft now). Tested by robert@, sthen@, naddy@, kmos@, phessler@, and many others! OK from at least kettenis@, cheloha@, naddy@, sthen@
* Use a relative branch to jump from setjmp(3) into _setjmp(4).kettenis2020-07-021-5/+4
| | | | Use correct register to reference the location where we store CR.
* Add missing comparison instruction. Load %r12 with the indirect branchkettenis2020-06-301-1/+3
| | | | address to load the correct TOC address.
* Use C versions of bcopy(3) and memmove(3) for now as the assembly versionkettenis2020-06-291-2/+2
| | | | | | of bcopy(9) doesn't work in its current state. ok deraadt@
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.