Szabolcs Nagy [Fri, 18 Mar 2022 06:55:31 +0000 (06:55 +0000)]
cheri: fix invalid pointer use after realloc in localealias
This code updates pointers to a reallocated buffer to point to the new
buffer. It is not conforming (does arithmetics with freed pointers),
but it also creates invalid capabilities because the provenance is
derived from the original freed pointers instead of the new buffer.
Change the arithmetics so provenance is derived from the new buffer.
The conformance issue is not fixed.
Szabolcs Nagy [Mon, 12 Jul 2021 10:11:05 +0000 (11:11 +0100)]
cheri: fix pointer tagging in tsearch
USE_MALLOC_LOW_BIT should work for capabilities too, but we need to
ensure that pointer provenance is right: the red/black flag is
computed as uintptr_t, but with uintptr_t | uintptr_t it's not clear
which side provides the provenance.
So use unsigned int type for the flag (which is the type used in case
of !USE_MALLOC_LOW_BIT anyway), then unsigned int | uintptr_t works.
The type of RED is corrected too to match unsigned int.
Szabolcs Nagy [Tue, 1 Mar 2022 09:44:14 +0000 (09:44 +0000)]
cheri: rseq: remove const to avoid readonly permission
Using const on the definition does not work for a pure capability ABI:
the capability permissions when accessing the object will be read only.
Use a hack to hide the public declaration in the TU where the const
objects are initialized. (This should work on non-capability targets
too, but to err on the safe side only enable the hack on capability
targets.)
Szabolcs Nagy [Fri, 15 Jul 2022 18:33:23 +0000 (19:33 +0100)]
TODO(gcc): cheri: work around a gcc bug in _dl_setup_stack_chk_guard
morello purecap gcc in some cases inlines 16byte memcpy as a capability
load, which is wrong if the source or dest may be unaligned.
stack guard only needs random for the address portion since only that
part is compared, so 8 byte is enough with 64 bit addresses, but the
current code is only right on little endian systems.
TODO(ddc): aarch64: morello: purecap support in the CSU
Purecap ABI versions of start.S, crti.S and crtn.S.
TODO: must not use ddc but caps from auxv
TODO: start.S: dynamic linked case is now detected by x0 != 0 (ld.so passes
__rtld_fini there), but the value of c0 on entry is not abi, just that
it has to be passed back to the libc start code in c5, so ideally the
linker should be fixed to reliably emit __rela_dyn_start when a static
exe must self relocate.
Szabolcs Nagy [Fri, 15 Jul 2022 13:10:53 +0000 (14:10 +0100)]
aarch64: morello: fix missing variadic argument in fcntl
In fcntl va_arg is currently used even if the caller did not pass
any variadic arguments. This is undefined behaviour and does not
work with the Morello purecap ABI, so use a helper macro.
When the argument is missing, the result of the helper macro is
arbitrary as it will be ignored by the kernel, we just have to
ensure it does not cause a runtime crash.
Szabolcs Nagy [Fri, 11 Jun 2021 11:52:26 +0000 (12:52 +0100)]
cheri: headers: Define {u}intptr_t and {u}intcap_t for CHERI
The CHERI pure capability programming model for C requires special
definition of {u}intptr_t.
Only the pure capability model is supported for hosted compilation,
but for freestanding compilation there is limited support for other
(hybrid capability) programming models too, which require new
{u}intcap_t type definitions.
Szabolcs Nagy [Tue, 26 Apr 2022 14:29:04 +0000 (15:29 +0100)]
aarch64: morello: Use separate lp64 and morello sysdep directories
Provide separate directories for lp64 and purecap abi related sysdep
functionality.
purecap may be better name than morello, but we started with morello
and that is more future compatible with alternative cheri-like
extensions on top of aarch64.
Szabolcs Nagy [Mon, 26 Jul 2021 19:31:38 +0000 (16:31 -0300)]
libio: adjust _IO_FILE / _IO_FILE_complete for 128 bit pointers
The size of the reserved space has to be adjusted because it underflows
with 16 byte pointers. With the new value there should be enough space
for 2 more pointers in the struct on CHERI targets.
Szabolcs Nagy [Wed, 8 Jun 2022 13:09:28 +0000 (14:09 +0100)]
Fix the symbolic link of multilib dirs
If dir contains several / then 'ln -s . $dir' does not link it to the
current directory. Use the existing rellns.sh script to compute the
correct relative path to .
Szabolcs Nagy [Fri, 29 Jul 2022 07:00:06 +0000 (08:00 +0100)]
aarch64: fix extension header write in getcontext and swapcontext
The extension header is two 32bit words and in the last header both
should be 0. There is plenty space in the __reserved area, but it's
better not to write more than we mean to.
Reviewed-by: Sunil K Pandey <skpgkp2@gmail.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
(cherry picked from commit e03f5ccd6cc8f829416156eac75acee501626c1f)
Tom Honermann [Sun, 24 Jul 2022 05:11:43 +0000 (01:11 -0400)]
stdlib: Suppress gcc diagnostic that char8_t is a keyword in C++20 in uchar.h.
gcc 13 issues the following diagnostic for the uchar.h header when the
-Wc++20-compat option is enabled in C++ modes that do not enable char8_t
as a builtin type (C++17 and earlier by default; subject to _GNU_SOURCE
and the gcc -f[no-]char8_t option).
warning: identifier ‘char8_t’ is a keyword in C++20 [-Wc++20-compat]
This change modifies the uchar.h header to suppress the diagnostic through
the use of '#pragma GCC diagnostic' directives for gcc 10 and later (the
-Wc++20-compat option was added in gcc version 10). Unfortunately, a bug
in gcc currently prevents those directives from having the intended effect
as reported at https://gcc.gnu.org/PR106423. A patch for that issue has
been submitted and is available in the email thread archive linked below.
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598736.html
stdlib: Tuned down tst-arc4random-thread internal parameters
With new arc4random implementation, the internal parameters might
require a lot of runtime and/or trigger some contention on older
kernels (which might trigger spurious timeout failures).
Also, since we are now testing getrandom entropy instead of an
userspace RNG, there is no much need to extensive testing.
With this change the tst-arc4random-thread goes from about 1m to
5s on a Ryzen 9 with 5.15.0-41-generic.
Checked on x86_64-linux-gnu.
Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
Rather than buffering 16 MiB of entropy in userspace (by way of
chacha20), simply call getrandom() every time.
This approach is doubtlessly slower, for now, but trying to prematurely
optimize arc4random appears to be leading toward all sorts of nasty
properties and gotchas. Instead, this patch takes a much more
conservative approach. The interface is added as a basic loop wrapper
around getrandom(), and then later, the kernel and libc together can
work together on optimizing that.
This prevents numerous issues in which userspace is unaware of when it
really must throw away its buffer, since we avoid buffering all
together. Future improvements may include userspace learning more from
the kernel about when to do that, which might make these sorts of
chacha20-based optimizations more possible. The current heuristic of 16
MiB is meaningless garbage that doesn't correspond to anything the
kernel might know about. So for now, let's just do something
conservative that we know is correct and won't lead to cryptographic
issues for users of this function.
This patch might be considered along the lines of, "optimization is the
root of all evil," in that the much more complex implementation it
replaces moves too fast without considering security implications,
whereas the incremental approach done here is a much safer way of going
about things. Once this lands, we can take our time in optimizing this
properly using new interplay between the kernel and userspace.
getrandom(0) is used, since that's the one that ensures the bytes
returned are cryptographically secure. But on systems without it, we
fallback to using /dev/urandom. This is unfortunate because it means
opening a file descriptor, but there's not much of a choice. Secondly,
as part of the fallback, in order to get more or less the same
properties of getrandom(0), we poll on /dev/random, and if the poll
succeeds at least once, then we assume the RNG is initialized. This is a
rough approximation, as the ancient "non-blocking pool" initialized
after the "blocking pool", not before, and it may not port back to all
ancient kernels, though it does to all kernels supported by glibc
(≥3.2), so generally it's the best approximation we can do.
The motivation for including arc4random, in the first place, is to have
source-level compatibility with existing code. That means this patch
doesn't attempt to litigate the interface itself. It does, however,
choose a conservative approach for implementing it.
Cc: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> Cc: Florian Weimer <fweimer@redhat.com> Cc: Cristian Rodríguez <crrodriguez@opensuse.org> Cc: Paul Eggert <eggert@cs.ucla.edu> Cc: Mark Harris <mark.hsj@gmail.com> Cc: Eric Biggers <ebiggers@kernel.org> Cc: linux-crypto@vger.kernel.org Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
projects / thirdparty / glibc.git / log
