This way, update builds track shlib major bumps correctly.
For example, suppose you had built Heimdal's libkrb5.so.27 and
libgssapi.so.11 linked against it, and then you updated past the recent
shlib major bump raising them to libkrb5.so.28 and libgssapi.so.12.
Without this change, the build will make the following sequence of
targets (interleaved with some others):
1. make dependall in libkrb5
2. make dependall in libgssapi
3. make install in libkrb5
4. make install in libgssapi
The existing .WAIT tags in SUBDIR ensure that (1) happens before (2)
and (3) happens before (4). Unfortunately, this sequence is wrong,
because it will produce the following effect:
1. make dependall in libkrb5 builds libkrb5.so.28
2. make dependall in libgssapi builds libgssapi.so.12, linked against
libkrb5.so.27
3. make install in libkrb5 installs libkrb5.so.28
4. make install in libgssapi installs libgssapi.so.12
Why the out-of-date libkrb5.so.27 in step (2)? Because we just pass
-L${DESTDIR}/usr/lib -lkrb5 to the linker (or the equivalent with
--sysroot and implied -L/usr/lib), and ${DESTDIR}/usr/lib still has
only libkrb5.so.27 by the time of step (2), not libkrb5.so.28.
Now any applications that link against libkrb5.so _and_ libgssapi.so
will get libkrb5.so.28 and libgssapi.so.12 -- but transitively, via
libgssapi.so.12, they will also get libkrb5.so.27, which is a recipe
for disaster.
Splicing the Heimdal library subdirectories into lib/Makefile, as
this does, ensures that we run make dependall _and_ make install in
libkrb5 _before_ make dependall in libgssapi, giving the following
correct sequence:
1. make dependall in libkrb5 builds libkrb5.so.28
2. make install in libkrb5 installs libkrb5.so.28
3. make dependall in libgssapi builds libgssapi.so.12, linked against
libkrb5.so.28
4. make install in libgssapi installs libgssapi.so.12
Note that LIBDPLIBS isn't enough here, as implemented. LIBDPLIBS
ensures that the incremental build will remake libgssapi.so. But it
doesn't ensure that the new libkrb5.so.28 is available before then,
so it doesn't prevent this problem.
We use the same mechanism for crypto/external/bsd/openssl/lib
already; this just extends it to other external library collections.
As an alternative, in principle perhaps we could teach LIBDPLIBS to
ensure that libkrb5.so comes out of the libkrb5 objdir, and not out
of ${DESTDIR}/usr/lib. But that requires some work to make happen,
and make it reliable, whereas this approach we've already confirmed
works without other adverse consequences (besides leaving
grody-looking mechanism lying around) for the libcrypto major bump
already. We need to get this pulled up to the branch so all the
other major bumps it required are handled correctly by update builds.
XXX pullup-10
strictly-aligned versions of memcmp(3), bcopy(3), memcpy(3), and
memmove(3).
This is used for 403 by ld.so.conf with machdep.no_unaligned variable.
With this library, unaligned memory accesses are significantly reduced
for 403 (from several hundreds to few tens per sec under heavy load);
only ld.elf_so (typically few times per fork) and statically-linked
binaries do such access.
This provides an extra level of side-channel and cracking resistance
compared to the pre-existing pkcs5_pbkdf2/sha1 method used for
password-based disk encryption.
Several new keygen parameters are supported:
memory (integer, in kilobytes)
parallelism (integer, usually the number of CPU cores)
version (integer, usually 19...)
We do our best to calibrate these automatically when the paramsfile
is initially generated.
lgtm riastradh@
This caused make to unconditionally take ages running useless
submakes in every subdirectory. Accidentally committed during the
MKCRYPTO option removal when I was presumably experimenting with
automating library dependency generation in lib.
Should shave a few seconds at least off every build!
This allows things that occur after lib (like do-x11) to depend on llvm
libraries already existing.
We need libexecinfo, so adding llvm after the 2nd library barrier.
software to effortlessly create and manage virtual machines via NVMM.
It is mostly complete, only nvmm_assist_mem needs to be filled -- I have
a draft for that, but it needs some more care. This Mem Assist should
not be needed when emulating a system in x2apic mode, so theoretically
the current form of libnvmm is sufficient to emulate a whole class of
systems.
Generally speaking, there are so many modes in x86 that it is difficult
to handle each corner case without introducing a ton of checks that just
slow down the common-case execution. Currently we check a limited number
of things; we may add more checks in the future if they turn out to be
needed, but that's rather low priority.
Libnvmm is compiled and installed only on amd64. A man page (reviewed by
wiz@) is provided.
support for only one ARM CPU. It used to have x86 support, but it was broken
and I removed it. The legacy PMC interface will be removed from the kernel
too. Sent on tech-kern@ yesterday, thorpej was fine.
this changes the upstream vendor from OpenSolaris to FreeBSD,
and this version is based on FreeBSD svn r315983.
in addition to the 10 years of improvements from upstream,
this version also has these NetBSD-specific enhancements:
- dtrace FBT probes can now be placed in kernel modules.
- ZFS now supports mmap().
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.
libpthread_dbg(3) is a remnant library from the M:N thread model
(pre-NetBSD-5.0) API to introspect threads within a process and for use
of debuggers.
Currently in the 1:1 model it's not used in GDB neither in LLDB and it's
not either planned to be used. It's current function to read pthread_t
structures is realizable within a regular debugger capable to
instrospect objects within a tracee (GDB, LLDB...).
Remaining users of this API can still use this library from
pkgsrc/devel/libpthread_dbg.
Sponsored by <The NetBSD Foundation>
riastradh