Age | Commit message (Collapse) | Author |
|
from Josiah Frentsos <jfrent at tilde dot team>
|
|
- on guenther's advice, remove NOTES: the text is either not relevant
or already described correctly elsewhere
ok guenther
|
|
from FreeBSD and NetBSD.
ok kettenis@ jmc@ espie@
|
|
|
|
of built-in cancelation points.
|
|
it either failed, or succeeded but didn't put a status into infop.
ok millert@
|
|
as sigvec already does; remove the one inconsistent colon
from creat(3) in this same text
original diff from josiah frentsos
|
|
is ELF" world. Eliminate use of them in landisk code.
ok deraadt@
|
|
is ELF" world. Eliminate use of them in amd64, arm64, armv7, i386,
macppc, mips64, and sparc64 code.
ok deraadt@ jca@ krw@
|
|
is ELF" world. Eliminate use of them in powerpc64 code.
ok gkoehler@
|
|
is ELF" world. Eliminate use of them in m88k code.
ok aoyama@
|
|
Compiling libc on i386 results in compiler warnings for bcmp, bzero, bcopy,
brk, and sbrk. Use ENTRY_NB instead of ENTRY to avoid this.
ok jca millert
|
|
NB for "No Binding". This gets us rid of clang-13 warnings about
a global symbol redefined as weak. Mostly a copy of what guenther@
already implemented on other archs. ok guenther@ tb@
|
|
_C_LABEL() was useful in the a.out->ELF transition days, way before
RISC-V was a thing.
Also drop uses of _ASM_LABEL() while here, suggested by guenther@
ok guenther@
|
|
Programs assume that a successful call to getaddrinfo(3) validates the
input as "safe", but that's not true. Characters like '$', '`', '\n'
or '*' can traverse the DNS without problems, but have special
meaning, for example a shell.
There is a function res_hnok() already in libc, but it validates if a
string is a host name, which is too strict in practice. For example
foo-.example.com is not a valid host name, but is used on the
Internet.
Posix has this to say:
"The getaddrinfo() function shall translate the name of a service
location (for example, a host name)"
It hints that the input should be a host name, but it does not
restrict it to it.
This introduces a function hnok_lenient() which restricts the input to
getaddrinfo(3) to the set [A-z0-9-_.]. Additionally two consecutive
dots ('.') are not allowed nor can the string start with - or '.'.
glibc introduced a similar restriction years ago, so this should not
cause problems.
It has been known in the DNS community for years, probably decades
that getaddrinfo(3) is too lenient what it accepts, but it has always
been kicked down the road as "not a DNS problem". Unfortunately this
information never made it out of the DNS community and no coordinated
effort happened to have this addressed in operating systems.
David Leadbeater recently demonstrated how ssh(1) and ftp(1) are too
trusting with what getaddrinfo(3) accepts. Both have been fixed
independently of this.
Input deraadt, eric
OK millert, deraadt
|
|
uppercase.
While here use the correct idiom of casting to unsigned char.
OK millert, farewell to ultrix deraadt
|
|
|
|
|
|
while here, wrap some long lines;
|
|
(SRTT) instead of the timestamp option. Since the timestamp option is
disabled on some OSs (eg. Windows) or dropped by some
firewalls/routers, in such a case the window size had been fixed at
16KB, this limits throughput at very low on high latency networks.
Also replace "tcp_now" from 2HZ tick counter to binuptime in
milliseconds to calculate the SRTT better.
tested by krw matthieu jmatthew dlg djm stu stsp
ok claudio
|
|
|
|
|
|
PROT_READ | PROT_WRITE to the less permissive PROT_READ. This one-way
operation is permitted for an introductory period to observe how software
uses this mechanism. It may change to require explicit mutable region
annotation with __attribute__((section(".openbsd.mutable"))) and explicit
calls to mimmutable().
^^^ Decided we'll do that for now, since we've only discovered one program
trying to be clever so far (chrome is trying to do something smart, and
mimmutable makes it even better)
discussed with kettenis and robert
|
|
because a loader may want to perform text relocations wrapped inside
mprotect permission flips. So static TEXTREL binaries need to perform
this operation themselves, at this fairly late point.
ok kettenis
|
|
Tested by gkoehler@.
ok gkoehler@
|
|
Minor bump to both libc and libpthread: make sure you install a new kernel!
ok millert@, deraadt@
|
|
the lock, when it is correctly initialized after the lock
ok otto millert
|
|
while here, wrap long line
|
|
mandoc suggestions & help from jmc
|
|
that the kernel and ld.so will know not to mark it immutable. malloc
handles the read/write transitions by itself.
|
|
|
|
DEC standard 144 bad sector information is no longer a thing. As
evidenced by bad144(8) moving to the attic 16 years ago.
ok miod@, who points out that badsect(8) is now the nail sticking
out.
|
|
|
|
ok kettenis
|
|
Explicitly mention that most programs do not need to call tzset() directly.
OK deraadt@ jmc@ benno@
|
|
Other absolutes paths are still rejected.
|
|
|
|
From enh AT google.com:
The existing test is wrong for LP64, where size_t has twice as many
relevant bits as int, not just one. (Found by inspection by
rprichard.)
Looks good to deraadt@ and millert@
|
|
ok deraadt
|
|
Noted by pjanzen@ with input from deraadt@.
|
|
tweaks from cheloha@; ok deraadt@, sthen@, cheloha@
|
|
Reading time zone files from user-controlled paths can result in
pledge(2) or unveil(2) violations. We also ignore files that contain
a '.' character to avoid paths containing ".." or hidden files.
Work with and OK deraadt@
|
|
from josiah frentsos, tweaked by schwarze
ok schwarze
|
|
armv7; ok mbuhl@
|
|
|
|
Feedback tb@, miod@, jca@
OK jca@
|
|
for the rounding functions.
Input from kettenis@,
OK miod@
|
|
0-127, where immediate addressing can be used to load the system call number
in r0, rather than performing a memory load using pc-relative addressing.
No functional change, but rm(1) runs a couple cycles faster per file now.
|
|
(d_sbsize).
ok otto@ as part of larger diff
|
|
c99 6.11.5:
"The placement of a storage-class specifier other than at the beginning
of the declaration specifiers in a declaration is an obsolescent
feature."
ok guenther@
|