This option cannot be set in distrib/common/Makefile.distrib as it's too
late, after including <bsd.own.mk> that will set MKSANITIZER.
This makes generation of ramdisk for amd64 with MKSANITIZER=yes successful.
Introduce a new variable SANITIZERFLAGS that contains all the sanitizer
specific flags. These flags are designed to be passed to CFLAGS, CXXFLAGS
and LDFLAGS.
Pass SANITIZERFLAGS in bsd.prog.mk rules to CFLAGS, CXXFLAGS and LDFLAGS.
Pass SANITIZERFLAGS in bsd.lib.mk rules to *_pic.a build flags. The *_pic.a
libraries are designed to construct .so libraries. All .so libraries with
few exceptions are expected to be prebuilt with a sanitizer. Another
purpuse of *_pic.a files can be constructing static PIE programs, however
they are not supported as of now and there is no sanitization of static
programs either.
Once MKSTATICPIE will be supported, it will be initially incompatible with
MKSANITIZER.
This change also makes it easier to build other targets like kernel and
kernel modules without userland sanitizers.
No functional change intended for MKSANITIZER=no users.
Disable LD flags (-Wl,-Bstatic and -Wl,-Bdynamic) with enabled MKSANITIZER.
These options are incompatible with the current design of sanitizers,
because they cause duplication of symbols into programs and thus symbols
from the interceptors from sanitizers cannot be linked.
This change makes effectively mounting /usr required for dhcp programs like
dhclient(8).
As of today typical sanitizers require dynamic executables, while
crunchgen(1) programs are produced with static properties.
Lack of specified -s will:
- generate a Makefile file with NOSANITIZER=
- build programs that are dependencies with NOSANITIZER=
In future there is an option to handle sanitization in statically linked
programs.
An idea with -s LGTM by <christos>
These utilities (elf32, elf32_compat, elf64, liblldb) share code with the
ELF dynamic loader that is not being sanitized and its symbols are
installed into sanitized programs (in particular __tls_get_addr()).
Additionally libldd is used in rescue that is not expected to be sanitized
as of today.
When rip_input() is called as inetsw[].pr_input, rip_iput() is always called
with holding softnet_lock, that is, in case of !defined(NET_MPSAFE) it is
acquired in ipintr(), otherwise(defined(NET_MPSAFE)) it is acquire in
PR_WRAP_INPUT macro.
However, some function calls rip_input() directly without holding softnet_lock.
That causes assertion failure in sbappendaddr().
rip6_input() and icmp6_rip6_input() are also required softnet_lock for the same
reason.
XSAVE as it should be, only xen case checks the flag now; need to
investigate further why exactly the fault happens for the xen
no-xsave case
pointed out by maxv
only use XSAVE when the the CPUID OSXSAVE bit is set, as this seems to be
reliable indication
tested with Xen 4.2.6 DOM0/DOMU on Intel CPU, without and with no-xsave flag,
so should work also on those AMD CPUs, which have XSAVE disabled by default;
also tested with Xen DOM0 4.8.3
fixes PR kern/50332 by Torbjorn Granlund; sorry it took three years to address
XXX pullup netbsd-8
A preemption could occur in the middle, and we don't want that to happen,
because the context switch would use the partially-constructed fpu state.
The procedure becomes:
splhigh
unbusy the current cpu's fpu
create a new fpu state in memory
install the state on the current cpu's fpu
splx
Disabling preemption also ensures that x86_fpu_eager doesn't change in
the middle.
In LazyFPU mode we drop IPL_HIGH right away.
Add more KASSERTs.
A context switch (preemption) could occur between
fpusave_lwp(l1, true);
and
memcpy(pcb2, pcb1, sizeof(struct pcb));
In this case, l1's FPU state is re-installed on the current CPU, and
pcb1->pcb_fpcpu becomes non NULL. While it's fine to have l1's state
installed, we don't want to indicate l2's state is installed too.
With lazy fpu this was not a problem, because the context-switch would
not re-install the state, so pcb1->pcb_fpcpu was NULL.
Should fix PR/53383.
