Age | Commit message (Collapse) | Author |
|
Dns lookup logic has been updated to provide a configurable compile
time selection of dns query id generation logics, including random,
where possible, instead of the previous simple counter mode.
This should make dns poison attempts more difficult. The uclibc
developers wish to thank the white hat teams which alerted the
community about the possible weakness in the dns path, given the
increased resources with adversaries today.
Given that embedded systems may or may not have sources for trying
to generate random numbers, and also to try and keep the load on
the system low, by default it uses the standard random prng based
logic to indirectly generate the ids.
However if either urandom or else if realtime clock is available on
the target, then the same is used to reseed the prng periodically
in a slightly non deterministic manner. Also additional transform
(one way where possible) is used to avoid directly exposing the
internal random sequence.
The dns lookup logic maintains its own state wrt the random prng
functions, so that other users of the library's random prng are
not affected wrt their operations with the prng.
Note to Platform developers:
If you want to change from the default prngplus based logic, to one
of the other logics provided, then during compile/config time you can
switch to one of these additional choices wrt dns query id generation,
by using make config and companions.
If your platform doesnt support urandom nor a realtime clock backed
by a source with sufficient resolution, and or for some reason if you
want to revert to previous simple counter, rather than the transformed
random prng plus logic, you can force the same at compile time by
selecting SimpleCounter mode.
If you want to increase the randomness of the generated ids, and dont
mind the increased system load and latency then you could select the
Urandom mode during config. Do note that it will be dipping into the
entropy pool maintained by ur system.
If your target has a system realtime clock available and exposed to
user space, and inturn if you want to keep the underlying logic simple,
you could try using the clock option from the config. However do note
that the clock should have nanosecond resolution to help generate ids
which are plausibly random. Also improvements to processor and or io
performance can affect this.
Wrt the URandom and Clock modes, if there is a failure with generation
of the next random value, the logic tries to fallback to simple counter
mode.
If you want to change the underlying logic to make it more random
and or more simple, look at dnsrand_setup and dnsrand_next.
Signed-off-by: hanishkvc <hanishkvc@gmail.com>
|
|
|
|
This commit adds support for Kalray VLIW family (kvx)
Kalray kv3 core is embedded in Kalray Coolidge SoC. This core which is the
third of the KV family has the following features:
32/64 bits execution mode
6-issue VLIW architecture
64 x 64bits general purpose registers
SIMD instructions
little-endian
In order to build a usable toolchain, build scripts are provided at the
following address: https://github.com/kalray/build-scripts.
Kalray uses FOSS which is available at https://github.com/kalray
This includes Linux kernel, uClibc-ng, gcc, binutils, etc.
Signed-off-by: Clément Léger <cleger@kalray.eu>
Signed-off-by: Guillaume Thouvenin <gthouvenin@kalray.eu>
Signed-off-by: Laurent Thevenoux <lthevenoux@kalray.eu>
Signed-off-by: Marc Poulhies <mpoulhies@kalray.eu>
Signed-off-by: Marius Gligor <mgligor@kalray.eu>
Signed-off-by: Yann Sionneau <ysionneau@kalray.eu>
|
|
Signed-off-by: akater <nuclearspace@gmail.com>
|
|
basically from or1k port of uClibc-ng, with fixes for structures in
pthreadtypes.h from 64 bit architectures.
18 testsuite failures counted.
|
|
|
|
* extra/Configs/Config.in: enable UCLIBC_HAS_THREADS_NATIVE on
TARGET_arm.
Signed-off-by: Christophe Lyon <christophe.lyon@st.com>
|
|
Only a simple hello world is tested in qemu system emulation.
|
|
|
|
This adds basic support for tile architecture.
Only static binaries, no ld.so or threading support.
Tested with qemu-tilegx only.
|
|
OpenBSD arc4random is using chacha20 cipher algorithm for
a long time. This copy is still based on deprecated rc4
cipher algorithm. We could either update the arc4random.c
or drop it. Drop it. Users should better use libbsd when
using arc4random interface. Musl/glibc does not have arc4random
either.
|
|
|
|
Port over NPTL/TLS support from GNU C Library.
In the first step only the slower syscall is used for TLS
access. The uClibc-ng testsuite shows 79 errors, so their
is room for bugfixes and improvements.
|
|
Follow the steps to build c-sky uclibc linux system:
1. git clone https://github.com/c-sky/buildroot.git
2. cd buildroot
3. make qemu_csky_ck810_uclibc_defconfig
4. make
Follow the buildroot/board/qemu/csky/readme.txt to run.
This buildroot toolchain is pre-build, But you can rebuild
the c-sky uclibc-ng alone and install it to the buildroot
sysroot manually.
We'll try our best to improve the uclibc-ng continuously.
Signed-off-by: Guo Ren <ren_guo@c-sky.com>
|
|
In cde74b83f9b2 "ARC: remove special CFLAGS/LDFLAGS handling" we
got rid of CONFIG_ARC_CPU_HS which was used to select ARCv2-specific
implementation of optimized string routines. So now ARCv2-tuned
memset/memcpy/strcmp are not used, instead those for ARC700 used for
both ARC700 and ARCHS.
Without uClibc config option we may only tell which CPU type we're
targeting by built-in defines of GCC. I.e. no more conditional file
inclusion in Makefiles. That leaves us only one option - merge both
implementations in 1 file and use ifdefs.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
|
|
No NPTL, no LDSO support.
Bootup with Busybox Ash in Qemu working.
Testuite shows only two failures, but mksh continue/break
support doesn't work.
|
|
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
|
|
|
|
|
|
The included RPC implementation is ipv4 only.
Other C library projects have either deprecated the internal
RPC implementation (GNU C Library) or never implemented such
functionality (musl C Library). The latest rpcbind release (0.2.4)
checks for libtirpc and does not allow to be build with uClibc-ng
RPC without patching. The common use case for RPC nowadays is to
use rpcbind together with nfs-utils to provide NFS server or client
support to a system.
The included RPC implementation does create issues with duplicate
symbol failures when statically compiling with RPC enabled.
|
|
Ported over from GNU C Library and runtime tested in Qemu.
|
|
Otherwise, buildroot rejects uClibc-ng in an external toolchain.
Signed-off-by: Alexey Neyman <stilor@att.net>
|
|
This commit includes following features.
1. Support NPTL/TLS
2. Add libm function which is used to handle FP rounding and excpetions
(ex: fclrexcpt,fedisblxcpti,feenablxcpt... )
3. Add *context function for operating user context
(ex: setcontext,getcontext,makecontext... )
4. Change the return flow from signal handler
5. Cleanup of old code
The testsuite only has 2 errors, tst-cpuclock1 and tst-cputimer1,
which are related to timing accuracy. (math and locale tests are disabled)
Signed-off-by: Vincent Ren-Wei Chen <vincentc@andestech.com>
|
|
|
|
|
|
The syscall wrappers are not required and other C libraries
do not provide them. Busybox modutils.c must be patched so
that syscall() is used for uClibc-ng.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
|
|
Remove __UCLIBC_HAS_OBSTACK__ as it isn't very uptodate and
maintained part. It shouldn't be required for any software and
mostly shipped with stuff which use it. (f.e. binutils-gdb)
|
|
This option is enabled for a long time and I see no
useful case where we should be incompatible to glibc here.
|
|
These adds the stubs from gettext-tiny 0.0.5
from here:
https://github.com/sabotage-linux/gettext-tiny
|
|
To use it enable UCLIBC_HAS_LIBICONV, then iconv_open/iconv_close
should be available.
|
|
|
|
|
|
|
|
Only static linking is supported for now.
More debugging and analyzing for ld.so, TLS and NPTL
is required. But at least you can bootup a static
root fileystem in Qemu.
|
|
Not perfect, but a starting point.
Some tests of the test suite are failing.
|
|
To analyze or debug any linuxthreads problems it is useful to
have the ability to have a full gdb on the target available.
At the moment you could only debug stuff on microblaze.
Now we can verify that linuxthreads are working fine for
every supported architecture.
|
|
|
|
|
|
Enable locale application to be build when utils are
build. Remove useless compile and link warnings.
Default to minimal locale builds.
Signed-off-by: Waldemar Brodkorb <wbx@uclibc-ng.org>
|
|
A single test with targeting ARM showed that this feature
seems bit rotted. Remove DOMULTI and simplify Makefiles.
|
|
Add support for Andes Technology NDS32 architecture.
See here http://www.andestech.com/en/index/index.htm for more
informaton. Verification of the port from an older uClibc
port was done on a sponsored AG101p board.
The testsuite only has 5 errors, three are related to
an existing bug in dlclose() with LT.old, also happening
on cris32 and m68k.
Failures to fallocate/posix_fallocate are unresolved.
Thanks to Andes Technology sponsoring the hardware and
being very helpful while doing the uClibc-ng porting.
Signed-off-by: Waldemar Brodkorb <wbx@uclibc-ng.org>
|
|
Select required features. Fix intendation.
Reported-by: Leonid Lisovskiy <lly.dev@gmail.com>
|
|
Nobody should use gcc 3.3 nowadays.
|
|
|
|
Linuxthreads.new isn't really useful with the existence
of NPTL/TLS for well supported architectures. There is no
reason to use LT.new for ARM/MIPS or other architectures
supporting NPTL/TLS. It is not available for noMMU architectures
like Blackfin or FR-V. To simplify the live of the few uClibc-ng
developers, LT.new is removed and LT.old is renamed to LT.
LINUXTHREADS_OLD -> UCLIBC_HAS_LINUXTHREADS
|
|
|
|
At least allow to build a toolchain for hppa.
Sync some headers with glibc.
|
|
syncfs() was recently added (commit dfa593d4d). But man sync(2) specifies
that syncfs() is Linux-specific. This was overlooked in the original
commit so we add it to the set of Linux-specific functions supported by
uClibc.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
|
|
Both architectures are more or less deprecated.
No Linux upstream support, no gcc support for uClinux.
|