thread allocation:
(1) Set the DTV vector up whenever an offset into the static allocation
is assigned, even if the block itself is not initialized. This has been
seen in libstdc++.
(2) Do not free a DTV block if it is part of the static thread
allocation.
functions are used for destructors of thread_local objects.
If a pending destructor exists, prevent unloading of shared objects.
Introduce __dl_cxa_refcount interface for this purpose. When the last
reference is gone and the object has been dlclose'd before, the
unloading is finalized.
Ideally, __cxa_thread_atexit_impl wouldn't exist, but libstdc++ insists
on providing __cxa_thread_atexit as direct wrapper without further
patching.
been changed to cope with more and at least Go actively creates them.
Adjust the mapping size computation to use the maximum and not depend on
PT_LOAD segments to be in order.
The COMBREL logic predates thread-safety of the dynamic linker and
breaks the use of shared locks for the common symbol lookup case. It is
unlikely to provide any benefit for lazy binding or PLT lookups, so
provide equivalent functionality in the non-PLT relocation handling loop
by checking if the symbol used by the current relocation is the same as
the one used during the last lookup. No inter-object cachine is done as
it is also unlikely to be benefical.
Testing with Firefox startup on AMD64 shows a small performance gain by
the new method.
- Don't use negative indicies to read arguments of Lua functions.
- On error, return nil, "error string".
- Use ssize_t for return values from bozo_read() and bozo_write().
- Prefer lstring especially when if saves you from appending NUL and
doing len + 1 which can potentially wraparound.
- Don't mix C allocations with Lua functions marked with "m" in the Lua
manual. Those functions may throw (longjump) and leak data allocated
by C function. In one case, I use luaL_Buffer, in the other case,
I rearranged calls a bit.
Originally, MKCRYPTO was introduced because the United States
classified cryptography as a munition and restricted its export. The
export controls were substantially relaxed fifteen years ago, and are
essentially irrelevant for software with published source code.
In the intervening time, nobody bothered to remove the option after
its motivation -- the US export restriction -- was eliminated. I'm
not aware of any other operating system that has a similar option; I
expect it is mainly out of apathy for churn that we still have it.
Today, cryptography is an essential part of modern computing -- you
can't use the internet responsibly without cryptography.
The position of the TNF board of directors is that TNF makes no
representation that MKCRYPTO=no satisfies any country's cryptography
regulations.
My personal position is that the availability of cryptography is a
basic human right; that any local laws restricting it to a privileged
few are fundamentally immoral; and that it is wrong for developers to
spend effort crippling cryptography to work around such laws.
As proposed on tech-crypto, tech-security, and tech-userlevel to no
objections:
https://mail-index.netbsd.org/tech-crypto/2017/05/06/msg000719.htmlhttps://mail-index.netbsd.org/tech-security/2017/05/06/msg000928.htmlhttps://mail-index.netbsd.org/tech-userlevel/2017/05/06/msg010547.html
P.S. Reviewing all the uses of MKCRYPTO in src revealed a lot of
*bad* crypto that was conditional on it, e.g. DES in telnet... That
should probably be removed too, but on the grounds that it is bad,
not on the grounds that it is (nominally) crypto.
relocations for _SDA_BASE_ and _SDA2_BASE_ that happened to work by
accident. They no longer happen to work when old binaries are run on
newer systems. Explicitly ignore these bogus relocations.
"really unmap the gap between the text and data rather than just removing
all access with mprotect(). the latter results in the kernel having to
keep track of that range separately since the permissions are different.
avoid calling mmap() with a size of zero."
As per toolchain/52054: src/libexec/ld.elf_so update breaks everything,
this commit is very broken for some people (but not others). chs mentioned
he has a fix, but best not to leave -current broken in the meantime.
all access with mprotect(). the latter results in the kernel having to
keep track of that range separately since the permissions are different.
avoid calling mmap() with a size of zero.
ryo