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.
o add search-word support for CGI
o fix a security issue in CGI suffix handler support which would
allow remote code execution, from shm@netbsd.org
o -C option supports now CGI scripts only
will be included in the HTTP reply. We define this as we are about to
add an authentication method that may need to have a conversation with
the client.
- don't call getpwuid(0) if we don't need to, or fail it it fails,
and remove the 'username' member of bozohttpd_t since it is not
used outside of bozo_setup().
- bozostrdup() gains a request parameter, and uses it to determine
what sort of error handling is required
- bozo_strdup() dies
- size_arrays() reduced slightly, pushing error handling into the caller
- convert to size_t for some array indices
- bozo_set_pref() and bozo_init_prefs() gain httpd parameters
- apply a bunch of manual CSE to vastly reduce the number of times the
string "request->hr_httpd" appears.
- CGI parse_header() takes a request not httpd now
XXX: lua glue updated to call bozo_init_prefs() with htttpd parameter,
but i'm only guessing here.
code duplication.
Note that bozo_strdup is different that bozostrdup; the _ routines exit
loging error to syslog or stderr, whereas the non _ routines send error
responses to the http client.
Stop using Lua builtin print function and replace them with http.* ones.
httpd.print and http.write wraps SSL support when needed.
Print http headers, without them browser may interpret page as raw text.
No need to hardcode prefix path in the form.
Add comments for a user with tips how to use this script.
Patch by Travis Paul
Closes PR misc/50502
free it. Allocating from the stack does not return null, and freeing it
will have unpredictable results. use malloc instead.
- now we are using malloc remove -Wno-stack-protector kludge
* add redirects to ~user translation
* fix bugs around ~user translation
* add schema detection for absolute redirects
* fixed few memory leaks
* bunch of minor tweaks
* removed -r support
* smarter redirects
OK mrg@
Therefore, storing the value in the superblock and reading it out
again is silly and offers the opportunity for it to become corrupted.
So, don't do that (most of the code already didn't) and use the
existing constant instead. Initialize new 32-bit superblocks with
the value for the sake of old userland programs, but don't keep the
value in the 64-bit superblock at all.
(approved by Margo Seltzer)
This prevents regressions in the ulfs code when switching to the new
accessors. Note that while adding byteswapping to the other accessors
is straightforward, I haven't done it yet; and that also is not enough
to make LFS_EI work, because there are places lying around that bypass
the accessors for one reason and another and all of them need to be
updated. That is going to have to wait for a later day as LFS_EI is
not on the critical path right now.
(This part changes the native lfs code; the ufs-derived code already
has 64 vs. 32 logic, but as aspects of it are unsafe, and don't
entirely interoperate cleanly with the lfs 64/32 stuff, pass 2 will be
rehashing that.)
Also make note of a cleaner limitation: it seems that when it goes to
coalesce discontiguous files, it mallocs an array with one BLOCK_INFO
for every block in the file. Therefore, with 64-bit LFS, on a 32-bit
platform it will be possible to have files large enough to overflow
the cleaner's address space. Currently these will be skipped and cause
warnings via syslog.
At some point someone should rewrite the logic to coalesce files to
use chunks of some reasonable size, as discontinuity between such
chunks is immaterial and mallocing this much space is silly and
fragile. Also, the kernel only accepts up to 65536 blocks at a time
for bmapv and markv, so processing more than this at once probably
isn't useful and may not even work currently. I don't want to change
this around just now as it's not entirely trivial.
Add pieces of support for using both superblock types where
convenient, and specifically to the superblock accessors, but don't
actually enable it anywhere.
First substantive step on PR 50000.
This contains all the accessor functions and macros out of lfs.h.
Add an include of lfs_accessors.h after all uses of lfs.h... except
for code that wants to define its own struct lfs-alike that the
accessors are supposed to play along with. For these, set STRUCT_LFS
and include lfs_accessors.h after the necessary structure has been
defined, so that lfs_accessors.h can emit functions in terms of it.
(This changes the rest of the code over; all the accessors were
already added.)
The difference between this commit and the previous one is arbitrary,
but the previous one passed the regression tests on its own so I'm
keeping it separate to help with any bisections that might be needed
in the future.
superblock. This will allow switching between 32/64 bit forms on the
fly; it will also allow handling LFS_EI reasonably tidily. (That
currently doesn't work on the superblock.)
It also gets rid of cpp abuse in the form of fake structure member
macros.
Also, instead of doing sleep/wakeup on &lfs_avail and &lfs_nextseg
inside the on-disk superblock, add extra elements to the in-memory
struct lfs for this. (XXX: these should be changed to condvars, but
not right now)
XXX: this migrates a structure needed by the lfs code in libsa (struct
salfs) into lfs.h, where it doesn't belong, but for the time being
this is necessary in order to allow the accessors (and the various
lfs macros and other goop that relies on them) to compile.
This fixes the most of lockups i observed with Open vSwitch
on NetBSD/amd64. ("most of" because it still occasionally
locks up because of other problems. see PR/49816)
function symbol with an implementation choosen at run time.
Refactor calls to functions by address in ld.elf_so to create temporary
function descriptors on the stack, if the address is not leaked outside.
Limitations:
- no support for initialising static storage with function pointers
- no support for unnamed resolver functions
Inspired by FreeBSD's r228435 by kib@freebsd.org.
- handle errors in many places they weren't properly
- make SSL_accept() an error the main code notices
- expand bozo_ssl_err() to include bozo_ssl_warn(), bozo_clear_ssl_queue()
- remove empty bozo_ssl_flush()
relocs with 64bit targets, like GLOB_DAT.
Change some instruction patterns used for PLT slots, so -current
objdump -d shows what the comment says.
Fix encoding of %lox() in PLT slots "close" to -1.
Enhance debug output slightly.
a new stack frame, back up the PC by 7 and return back to the calls so it
will be reinvoked. (This is by far the most common way it gets invoked).
Otherwise rebuild a new callframe and jump to the routine.
Nothing to do for lazy bindings.
Record DT_PPC64_GLINK and make _rtld_bind return it.
When resolving a JMP_SLOT, copy the source function descriptor into the PLTGOT
