Commit Graph

340 Commits

Author SHA1 Message Date
Ed Maste
9feff969a0 Remove "All Rights Reserved" from FreeBSD Foundation sys/ copyrights
These ones were unambiguous cases where the Foundation was the only
listed copyright holder (in the associated license block).

Sponsored by:	The FreeBSD Foundation
2021-08-08 10:42:24 -04:00
Andrew Turner
a93941b439 Switch to an ifunc in the kernel for crc32c
There is no need to read the same variable to check if the CPU supports
crc32c instructions.

Reviewed by:	arichardson, kib, markj
Sponsored by:	The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D31274
2021-07-22 20:54:21 +00:00
Greg V
4211457e40 Add missing libkern/strnstr.c file
Apparently it wasn't picked up by git.

Reviewed by:		bz, hselasky, nc
Differential Revision:	https://reviews.freebsd.org/D31131
2021-07-14 17:56:03 -07:00
Alfonso Gregory
56d33e86b7 Remove incorrect __restricted labels from strcspn
strcspn should never have had the __restrict keywords. While both of
these strings are const, it may have unindended side effects. While this
is the kernel, the POSIX definition also omits restrict.

Reviewed by:	imp@
Pull Request:	https://github.com/freebsd/freebsd-src/pull/497
2021-07-14 16:11:38 -06:00
Andrew Turner
0ec3e99111 Use '.arch_extension crc' in the arm64 crc32 code
We don't care about the base architecture here, just that the crc
extension is enabled.

Sponsored by:	Innovate UK
2021-05-06 07:42:35 +00:00
Konstantin Belousov
aa3ea612be x86: remove gcov kernel support
Reviewed by:	jhb
Sponsored by:	The FreeBSD Foundation
Differential revision:	https://reviews.freebsd.org/D29529
2021-04-02 15:41:51 +03:00
Lawrence Stewart
dbbf3e3f37 random(9): Restore historical [0,2^31-1] output range and related man
documention.

Commit SVN r364219 / Git 8a0edc914f changed random(9) to be a shim around
prng32(9) and inadvertently caused random(9) to begin returning numbers in the
range [0,2^32-1] instead of [0,2^31-1], where the latter has been the documented
range for decades.

The increased output range has been identified as the source of numerous bugs in
code written against the historical output range e.g. ipfw "prob" rules and
stats(3) are known to be affected, and a non-exhaustive audit of the tree
identified other random(9) consumers which are also likely affected.

As random(9) is deprecated and slated for eventual removal in 14.0, consumers
should gradually be audited and migrated to prng(9).

Submitted by:		Loic Prylli <lprylli@netflix.com>
Obtained from:		Netflix
Reviewed by:		cem, delphij, imp
MFC after:		1 day
MFC to:			stable/13, releng/13.0
Differential Revision:	https://reviews.freebsd.org/D29385
2021-03-24 16:14:58 +11:00
Mateusz Guzik
3acea07c18 Restore the augmented strlen commentary
... lost in revert
2021-02-08 19:15:21 +00:00
Mateusz Guzik
33f0540b13 Revert "Reimplement strlen"
This reverts commit 710e45c4b8.

It breaks for some corner cases on big endian ppc64.
Given the stage of the release process it is best to revert for now.

Reported by:	jhibbits
2021-02-03 19:38:10 +00:00
Alex Richardson
83c20b8a2d tests/sys/kern/crc32: Check for SSE4.2 before using it
This avoids a SIGILL when running these tests on QEMU (which
defaults to a basic amd64 CPU without SSE4.2).

This commit also tests the table-based implementations in addition to
testing the hw-accelerated crc32 versions.

Reviewed By:	cem, kib, markj
Differential Revision: https://reviews.freebsd.org/D28395
2021-02-02 09:53:39 +00:00
Mateusz Guzik
710e45c4b8 Reimplement strlen
The previous code neglected to use primitives which can find the end
of the string without having to branch on every character.

While here augment the somewhat misleading commentary -- strlen as
implemented here leaves performance on the table, especially so for
userspace. Every arch should get a dedicated variant instead.

In the meantime this commit lessens the problem.

Tested with glibc test suite.

Naive test just calling strlen in a loop on Haswell (ops/s):

$(perl -e "print 'A' x 3"):
before:	211198039
after:	338626619

$(perl -e "print 'A' x 100"):
before:	83151997
after:	98285919
2021-01-29 23:48:26 +00:00
Andrew Turner
4e76e4c301 Remove obsolete code gated on _ARM_ARCH_*
This is all code only run on ARMv4 and ARMv5. Support for these have
been dropped from FreeBSD.

Differential Revision:	https://reviews.freebsd.org/D28314
2021-01-28 10:41:45 +00:00
Vladimir Kondratyev
bc86103335 libkern/strcasestr.c: Drop xlocale support and connect to build.
Reviewed by:	markj, hselasky
Differential revision:	https://reviews.freebsd.org/D27866
2021-01-08 02:18:42 +03:00
Vladimir Kondratyev
92cf602e38 Copy strcasestr.c from libc to libkern. 2021-01-08 02:18:42 +03:00
Conrad Meyer
10b1a17594 arc4random(9): Integrate with RANDOM_FENESTRASX push-reseed
There is no functional change for the existing Fortuna random(4)
implementation, which remains the default in GENERIC.

In the FenestrasX model, when the root CSPRNG is reseeded from pools due to
an (infrequent) timer, child CSPRNGs can cheaply detect this condition and
reseed.  To do so, they just need to track an additional 64-bit value in the
associated state, and compare it against the root seed version (generation)
on random reads.

This revision integrates arc4random(9) into that model without substantially
changing the design or implementation of arc4random(9).  The motivation is
that arc4random(9) is immediately reseeded when the backing random(4)
implementation has additional entropy.  This is arguably most important
during boot, when fenestrasX is reseeding at 1, 3, 9, 27, etc., second
intervals.  Today, arc4random(9) has a hardcoded 300 second reseed window.
Without this mechanism, if arc4random(9) gets weak entropy during initial
seed (and arc4random(9) is used early in boot, so this is quite possible),
it may continue to emit poorly seeded output for 5 minutes.  The FenestrasX
push-reseed scheme corrects consumers, like arc4random(9), as soon as
possible.

Reviewed by:	markm
Approved by:	csprng (markm)
Differential Revision:	https://reviews.freebsd.org/D22838
2020-10-10 21:48:06 +00:00
Mitchell Horne
66245bc536 arm64: check for CRC32 support via HWCAP
Doing it this way eliminates the assumption about homogeneous support
for the feature, since HWCAP values are only set if support is present
on all CPUs.

Reviewed by:	tuexen, markj
MFC after:	1 week
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D26032
2020-09-08 15:39:19 +00:00
Mateusz Guzik
1060326fb6 libkern: clean up empty lines in .c and .h files 2020-09-01 21:25:23 +00:00
Warner Losh
cffca129a9 Smaller crc for the boot loader.
Save 7k of text space by using simpler crc32 for standalone case. we
don't need all that fancy optimization in the boot loader, so use a
simplified version of the CRC function. We could save more by doing it
one bit at a time rather than 32, but this is the biggest savings at
the smallest performance hit.

With LUA and verfied exec, gptboot, gptzfsboot and friends are pushing
the ~530k limit and every little bit helps.

Reviewed By: allanjude
Differential Revision: https://reviews.freebsd.org/D24225
2020-09-01 04:37:55 +00:00
Conrad Meyer
8a0edc914f Add prng(9) API
Add prng(9) as a replacement for random(9) in the kernel.

There are two major differences from random(9) and random(3):

- General prng(9) APIs (prng32(9), etc) do not guarantee an
  implementation or particular sequence; they should not be used for
  repeatable simulations.

- However, specific named API families are also exposed (for now: PCG),
  and those are expected to be repeatable (when so-guaranteed by the named
  algorithm).

Some minor differences from random(3) and earlier random(9):

- PRNG state for the general prng(9) APIs is per-CPU; this eliminates
  contention on PRNG state in SMP workloads.  Each PCPU generator in an
  SMP system produces a unique sequence.

- Better statistical properties than the Park-Miller ("minstd") PRNG
  (longer period, uniform distribution in all bits, passes
  BigCrush/PractRand analysis).

- Faster than Park-Miller ("minstd") PRNG -- no division is required to
  step PCG-family PRNGs.

For now, random(9) becomes a thin shim around prng32().  Eventually I
would like to mechanically switch consumers over to the explicit API.

Reviewed by:	kib, markj (previous version both)
Discussed with:	markm
Differential Revision:	https://reviews.freebsd.org/D25916
2020-08-13 20:48:14 +00:00
Emmanuel Vadot
353d02e927 libkern: Add arc4random_uniform
This variant get a random number up to the limit passed as the argument.
This is simply a copy of the libc version.

Sponsored-by: The FreeBSD Foundation
Reviewed by:	cem, hselasky (previous version)
Differential Revision:	https://reviews.freebsd.org/D24962
2020-05-23 17:51:06 +00:00
Pawel Biernacki
7029da5c36 Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (17 of many)
r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are
still not MPSAFE (or already are but aren’t properly marked).
Use it in preparation for a general review of all nodes.

This is non-functional change that adds annotations to SYSCTL_NODE and
SYSCTL_PROC nodes using one of the soon-to-be-required flags.

Mark all obvious cases as MPSAFE.  All entries that haven't been marked
as MPSAFE before are by default marked as NEEDGIANT

Approved by:	kib (mentor, blanket)
Commented by:	kib, gallatin, melifaro
Differential Revision:	https://reviews.freebsd.org/D23718
2020-02-26 14:26:36 +00:00
Conrad Meyer
f3bae413e9 random(9): Deprecate random(9), remove meaningless srandom(9)
srandom(9) is meaningless on SMP systems or any system with, say,
interrupts.  One could never rely on random(9) to produce a reproducible
sequence of outputs on the basis of a specific srandom() seed because the
global state was shared by all kernel contexts.  As such, removing it is
literally indistinguishable to random(9) consumers (as compared with
retaining it).

Mark random(9) as deprecated and slated for quick removal.  This is not to
say we intend to remove all fast, non-cryptographic PRNG(s) in the kernel.
It/they just won't be random(9), as it exists today, in either name or
implementation.

Before random(9) is removed, a replacement will be provided and in-tree
consumers will be converted.

Note that despite the name, the random(9) interface does not bear any
resemblance to random(3).  Instead, it is the same crummy 1988 Park-Miller
LCG used in libc rand(3).
2019-12-26 19:41:09 +00:00
Andrew Turner
849aef496d Port the NetBSD KCSAN runtime to FreeBSD.
Update the NetBSD Kernel Concurrency Sanitizer (KCSAN) runtime to work in
the FreeBSD kernel. It is a useful tool for finding data races between
threads executing on different CPUs.

This can be enabled by enabling KCSAN in the kernel config, or by using the
GENERIC-KCSAN amd64 kernel. It works on amd64 and arm64, however the later
needs a compiler change to allow -fsanitize=thread that KCSAN uses.

Sponsored by:	DARPA, AFRL
Differential Revision:	https://reviews.freebsd.org/D22315
2019-11-21 11:22:08 +00:00
Andrew Turner
44e446a1b3 Rename the macros to extract a single arm64 ID field.
Because of the previous naming scheme the old ID_AA64PFR0_EL1 macro
collided with a potential macro for the register of the same name. To fix
this collision rename these macros.

Sponsored by:	DARPA, AFRL
2019-10-30 10:06:57 +00:00
Xin LI
21aae72489 Remove zlib 1.0.4 from kernel.
PR:		229763
Reviewed by:	emaste, Yoshihiro Ota <ota j email ne jp>
Differential Revision:	https://reviews.freebsd.org/D21375
2019-08-25 17:13:00 +00:00
Conrad Meyer
2b0ebb77e4 libkern: Implement strchrnul(3) 2019-08-19 22:53:05 +00:00
Xin LI
0ed1d6fb00 Allow Kernel to link in both legacy libkern/zlib and new sys/contrib/zlib,
with an eventual goal to convert all legacl zlib callers to the new zlib
version:

 * Move generic zlib shims that are not specific to zlib 1.0.4 to
   sys/dev/zlib.
 * Connect new zlib (1.2.11) to the zlib kernel module, currently built
   with Z_SOLO.
 * Prefix the legacy zlib (1.0.4) with 'zlib104_' namespace.
 * Convert sys/opencrypto/cryptodeflate.c to use new zlib.
 * Remove bundled zlib 1.2.3 from ZFS and adapt it to new zlib and make
   it depend on the zlib module.
 * Fix Z_SOLO build of new zlib.

PR:		229763
Submitted by:	Yoshihiro Ota <ota j email ne jp>
Reviewed by:	markm (sys/dev/zlib/zlib_kmod.c)
Relnotes:	yes
Differential Revision:	https://reviews.freebsd.org/D19706
2019-08-01 06:35:33 +00:00
Warner Losh
710becdd96 Remove pre-FreeBSD 7.0 compatibility. 2019-07-19 18:38:47 +00:00
Xin LI
f89d207279 Separate kernel crc32() implementation to its own header (gsb_crc32.h) and
rename the source to gsb_crc32.c.

This is a prerequisite of unifying kernel zlib instances.

PR:		229763
Submitted by:	Yoshihiro Ota <ota at j.email.ne.jp>
Differential Revision:	https://reviews.freebsd.org/D20193
2019-06-17 19:49:08 +00:00
Mateusz Guzik
5e57adc874 random(4): depessimize arc4random
- __predict_false reseeding on entry as it is almost never true.
- don't blindly atomic_cmpset as on x86 it ends up dirtying the cacheline.
it almost ever succeeds per above
- fetch the timestamp prior to getting the cpu number

Reviewed by:	cem
Approved by:	secteam (delphij)
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D20242
2019-05-12 06:32:46 +00:00
Conrad Meyer
6b97c2e306 Revert r346410 and r346411
libkern in .PATH has too many filename conflicts with libc and my -DNO_CLEAN
tinderbox didn't catch that ahead of time.  Mea culpa.
2019-04-19 22:08:17 +00:00
Conrad Meyer
7deb4b1964 libkern: Bring in arc4random_uniform(9) from libc
It is a useful arc4random wrapper in the kernel for much the same reasons as
in userspace.  Move the source to libkern (because kernel build is
restricted to sys/, but userspace can include any file it likes) and build
kernel and libc versions from the same source file.

Copy the documentation from arc4random_uniform(3) to the section 9 page.

While here, add missing arc4random_buf(9) symlink.

Sponsored by:	Dell EMC Isilon
2019-04-19 20:05:47 +00:00
Conrad Meyer
3782136ff1 random(4): Restore availability tradeoff prior to r346250
As discussed in that commit message, it is a dangerous default.  But the
safe default causes enough pain on a variety of platforms that for now,
restore the prior default.

Some of this is self-induced pain we should/could do better about; for
example, programmatic CI systems and VM managers should introduce entropy
from the host for individual VM instances.  This is considered a future work
item.

On modern x86 and Power9 systems, this may be wholly unnecessary after
D19928 lands (even in the non-ideal case where early /boot/entropy is
unavailable), because they have fast hardware random sources available early
in boot.  But D19928 is not yet landed and we have a host of architectures
which do not provide fast random sources.

This change adds several tunables and diagnostic sysctls, documented
thoroughly in UPDATING and sys/dev/random/random_infra.c.

PR:		230875 (reopens)
Reported by:	adrian, jhb, imp, and probably others
Reviewed by:	delphij, imp (earlier version), markm (earlier version)
Discussed with:	adrian
Approved by:	secteam(delphij)
Relnotes:	yeah
Security:	related
Differential Revision:	https://reviews.freebsd.org/D19944
2019-04-18 20:48:54 +00:00
Conrad Meyer
13774e8228 random(4): Block read_random(9) on initial seeding
read_random() is/was used, mostly without error checking, in a lot of
very sensitive places in the kernel -- including seeding the widely used
arc4random(9).

Most uses, especially arc4random(9), should block until the device is seeded
rather than proceeding with a bogus or empty seed.  I did not spy any
obvious kernel consumers where blocking would be inappropriate (in the
sense that lack of entropy would be ok -- I did not investigate locking
angle thoroughly).  In many instances, arc4random_buf(9) or that family
of APIs would be more appropriate anyway; that work was done in r345865.

A minor cleanup was made to the implementation of the READ_RANDOM function:
instead of using a variable-length array on the stack to temporarily store
all full random blocks sufficient to satisfy the requested 'len', only store
a single block on the stack.  This has some benefit in terms of reducing
stack usage, reducing memcpy overhead and reducing devrandom output leakage
via the stack.  Additionally, the stack block is now safely zeroed if it was
used.

One caveat of this change is that the kern.arandom sysctl no longer returns
zero bytes immediately if the random device is not seeded.  This means that
FreeBSD-specific userspace applications which attempted to handle an
unseeded random device may be broken by this change.  If such behavior is
needed, it can be replaced by the more portable getrandom(2) GRND_NONBLOCK
option.

On any typical FreeBSD system, entropy is persisted on read/write media and
used to seed the random device very early in boot, and blocking is never a
problem.

This change primarily impacts the behavior of /dev/random on embedded
systems with read-only media that do not configure "nodevice random".  We
toggle the default from 'charge on blindly with no entropy' to 'block
indefinitely.'  This default is safer, but may cause frustration.  Embedded
system designers using FreeBSD have several options.  The most obvious is to
plan to have a small writable NVRAM or NAND to persist entropy, like larger
systems.  Early entropy can be fed from any loader, or by writing directly
to /dev/random during boot.  Some embedded SoCs now provide a fast hardware
entropy source; this would also work for quickly seeding Fortuna.  A 3rd
option would be creating an embedded-specific, more simplistic random
module, like that designed by DJB in [1] (this design still requires a small
rewritable media for forward secrecy).  Finally, the least preferred option
might be "nodevice random", although I plan to remove this in a subsequent
revision.

To help developers emulate the behavior of these embedded systems on
ordinary workstations, the tunable kern.random.block_seeded_status was
added.  When set to 1, it blocks the random device.

I attempted to document this change in random.4 and random.9 and ran into a
bunch of out-of-date or irrelevant or inaccurate content and ended up
rototilling those documents more than I intended to.  Sorry.  I think
they're in a better state now.

PR:		230875
Reviewed by:	delphij, markm (earlier version)
Approved by:	secteam(delphij), devrandom(markm)
Relnotes:	yes
Differential Revision:	https://reviews.freebsd.org/D19744
2019-04-15 18:40:36 +00:00
Matt Macy
744799ead2 Add non-sleepable strdup variant strdup_flags
debugfs expects to do non-sleepable allocations

Reviewed by:	hps@
MFC after:	1 week
Sponsored by:	iX Systems
Differential Revision:	https://reviews.freebsd.org/D19259
2019-02-20 20:48:10 +00:00
Ed Maste
05bc9aa78f mcount: tidy up ANSIfication
libc/gmon's mcount was ANSIfied in r124180, with libkern following over
a decade later, in r325988, but some minor discrepancies remained.
Update libc/gmon's mexitcount to an ANSI C function definition, and use
(void) for libkern-only functions that take no arguments.

Reported by:	bde
2018-10-20 22:39:35 +00:00
Conrad Meyer
e38b830780 Sync strlcpy with userland version, again
No functional change.

Please remember to update libkern copies of libc functions when you update
libc.

Sponsored by:	Dell EMC Isilon
2018-06-21 17:35:13 +00:00
Conrad Meyer
3d825c42ca str(r)chr: Replace union abuse with __DECONST
Writing one union member and reading another is technically illegal C,
although we do it in many places in the tree.  Use the __DECONST macro
instead, which is (technically) a valid C construct.

Trivial style(9) cleanups to touched lines while here.

Sponsored by:	Dell EMC Isilon
2018-06-04 18:47:14 +00:00
Mateusz Guzik
ba96f37758 Use __builtin for various mem* and b* (e.g. bzero) routines.
Some of the routines were using artificially limited builtin already,
drop the explicit limit.

The use of builtins allows quite often allows the compiler to elide the call
or most zeroing to begin with. For instance, if the target object is 32 bytes
in size and gets zeroed + has 16 bytes initialized, the compiler can just
add code to zero out the rest.

Note not all the primites have asm variants and some of the existing ones
are not optimized. Maintaines are strongly encourage to take a look
(regardless of this change).
2018-06-02 18:03:35 +00:00
Mateusz Guzik
97e8984893 libkern: tidy up memset
1. Remove special-casing of 0 as it just results in an extra function call.
This is clearly pessimal.
2. Drop the inline stuff. For the most part it is much better served with
__builtin_memset (coming later).
3. Move the declaration to systm.h to match other funcs.

Archs are encouraged to implement the variant for their own platform so that
this implementation can be dropped.
2018-06-02 17:57:09 +00:00
Bruce Evans
dbe3061729 Fix recent breakages of kernel profiling, mostly on i386 (high resolution
kernel profiling remains broken).

memmove() was broken using ALTENTRY().  ALTENTRY() is only different from
ENTRY() in the profiling case, and its use in that case was sort of
backwards.  The backwardness magically turned memmove() into memcpy()
instead of completely breaking it.  Only the high resolution parts of
profiling itself were broken.  Use ordinary ENTRY() for memmove().
Turn bcopy() into a tail call to memmove() to reduce complications.
This gives slightly different pessimizations and profiling lossage.
The pessimizations are minimized by not using a frame pointer() for
bcopy().

Calls to profiling functions from exception trampolines were not
relocated.  This caused crashes on the first exception.  Fix this using
function pointers.

Addresses of exception handlers in trampolines were not relocated.  This
caused unknown offsets in the profiling data.  Relocate by abusing
setidt_disp as for pmc although this is slower than necessary and
requires namespace pollution.  pmc seems to be missing some relocations.
Stack traces and lots of other things in debuggers need similar relocations.

Most user addresses were misclassified as unknown kernel addresses and
then ignored.  Treat all unknown addresses as user. Now only user
addresses in the kernel text range are significantly misclassified (as
known kernel addresses).

The ibrs functions didn't preserve enough registers.  This is the only
recent breakage on amd64.  Although these functions are written in
asm, in the profiling case they call profiling functions which are
mostly for the C ABI, so they only have to save call-used registers.
They also have to save arg and return registers in some cases and
actually save them in all cases to reduce complications.  They end up
saving all registers except %ecx on i386 and %r10 and %r11 on amd64.
Saving these is only needed for 1 caller on each of amd64 and i386.
Save them there.  This is slightly simpler.

Remove saving %ecx in handle_ibrs_exit on i386.  Both handle_ibrs_entry
and handle_ibrs_exit use %ecx, but only the latter needed to or did
save it.  But saving it there doesn't work for the profiling case.

amd64 has more automatic saving of the most common scratch registers
%rax, %rcx and %rdx (its complications for %r10 are from unusual use
of %r10 by SYSCALL).  Thus profiling of handle_ibrs_exit_rs() was not
broken, and I didn't simplify the saving by moving the saving of these
registers from it to the caller.
2018-06-02 04:25:09 +00:00
Warner Losh
c6f7141fc0 Protect bzero call against macro expansion
Shortly, we'll be moving to defining bzero and memset in terms of
__builting_memset. To do that, we can't have macro calls to bzero in
the fallback impelmentation of memset. Normal calls to bzero are fine.
All 4 architectures that use this have their own copies of bzero, so
there's no mutual recursion issue between memset and bcopy.
2018-05-24 23:20:10 +00:00
Warner Losh
509b94387a This is no unreferenced, so retire it.
Differential Revision: https://reviews.freebsd.org/D15374
2018-05-24 21:11:38 +00:00
Xin LI
b6f7731dba Remove "All rights reserved" from my files.
See r333391 for the rationale.

MFC after:	1 week
2018-05-10 06:41:08 +00:00
Warner Losh
baaa3c4d60 Simplify things a little
Rather than include a copy for memmove to call bcopy to call memcpy
(which handles overlapping copies), make memmove a strong reference to
memcpy to save the two calls.

Differential Revision: https://reviews.freebsd.org/D15374
2018-05-10 02:31:48 +00:00
Warner Losh
5aa07b053a Move MI-ish bcopy routine to libkern
riscv and powerpc have nearly identical bcopy.c that's
supposed to be mostly MI. Move it to the MI libkern.

Differential Revision: https://reviews.freebsd.org/D15374
2018-05-10 02:31:38 +00:00
David Bright
2b08b42bae iconv uses strlen directly on user supplied memory
`iconv_sysctl_add` from `sys/libkern/iconv.c` incorrectly limits the
size of user strings, such that several out of bounds reads could have
been possible.

static int
iconv_sysctl_add(SYSCTL_HANDLER_ARGS)
{
	struct iconv_converter_class *dcp;
	struct iconv_cspair *csp;
	struct iconv_add_in din;
	struct iconv_add_out dout;
	int error;

	error = SYSCTL_IN(req, &din, sizeof(din));
	if (error)
		return error;
	if (din.ia_version != ICONV_ADD_VER)
		return EINVAL;
	if (din.ia_datalen > ICONV_CSMAXDATALEN)
		return EINVAL;
	if (strlen(din.ia_from) >= ICONV_CSNMAXLEN)
		return EINVAL;
	if (strlen(din.ia_to) >= ICONV_CSNMAXLEN)
		return EINVAL;
	if (strlen(din.ia_converter) >= ICONV_CNVNMAXLEN)
		return EINVAL;
...

Since the `din` struct is directly copied from userland, there is no
guarantee that the strings supplied will be NULL terminated. The
`strlen` calls could continue reading past the designated buffer
sizes.

Declaration of `struct iconv_add_in` is found in `sys/sys/iconv.h`:

struct iconv_add_in {
	int	ia_version;
	char	ia_converter[ICONV_CNVNMAXLEN];
	char	ia_to[ICONV_CSNMAXLEN];
	char	ia_from[ICONV_CSNMAXLEN];
	int	ia_datalen;
	const void *ia_data;
};

Our strings are followed by the `ia_datalen` member, which is checked
before the `strlen` calls:

if (din.ia_datalen > ICONV_CSMAXDATALEN)

Since `ICONV_CSMAXDATALEN` has value `0x41000` (and is `unsigned`),
this ensures that `din.ia_datalen` contains at least 1 byte of 0, so
it is not possible to trigger a read out of bounds of the `struct`
however, this code is fragile and could introduce subtle bugs in the
future if the `struct` is ever modified.

PR:		207302
Submitted by:	CTurt <cturt@hardenedbsd.org>
Reported by:	CTurt <cturt@hardenedbsd.org>
Reviewed by:	jhb, vangyzen
MFC after:	1 week
Sponsored by:	Dell EMC
Differential Revision:	https://reviews.freebsd.org/D14521
2018-02-26 18:23:36 +00:00
Ed Maste
85b648927a libkern: use nul for terminating char rather than 0
Akin to the change made in r188080 for lib/libc/string/.

Reported by:	bde
Sponsored by:	The FreeBSD Foundation
2018-02-13 19:17:48 +00:00
Pedro F. Giffuni
2cc7a55540 SPDX: fix wrong license ID tag in libkern. 2017-12-28 01:20:30 +00:00
Pedro F. Giffuni
8a36da99de sys/kern: adoption of SPDX licensing ID tags.
Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
2017-11-27 15:20:12 +00:00