memfd_secret is a new syscall in linux 5.14. memfd_secret() is
disabled by default and a command-line option needs to be added to
enable it at boot time.
$ cat /proc/cmdline
[...] secretmem.enable=y
https://bugs.kde.org/451878https://lwn.net/Articles/865256/
It fixes a known iusse whose details are described at [1] and more
generally it guarantees that Valgrind is properly compiled for ulibc.
[1] https://www.mail-archive.com/valgrind-users@lists.sourceforge.net/msg05295.html
Suggested-by Michael Trimarchi <michael@amarulasolutions.com>
Co-developed-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
FreeBSD (and Darwin) use the carry flag for syscall syscall status.
That means that in the assembler for do_syscall_for_client_WRK
they have a call to LibVEX_GuestAMD64_put_rflag_c (amd64) or
LibVEX_GuestX86_put_eflag_c (x86). These also call WRK functions.
The problem is that do_syscall_for_client_WRK has carefully crafted
labels correspinding to IP addresses. If a signal interrupts
processdings, IP can be compared to these addresses so that
VG_(fixup_guest_state_after_syscall_interrupted) can work
out how to resume the syscall. But if IP is in the save
carry flag functions, the address is not recognized and
VG_(fixup_guest_state_after_syscall_interrupted) fails.
The crash in the title happens because the interrupted
syscall does not reset its status, and on the next syscall
it is expected that the status be idle.
To fix this I added global variables that get set to 1
just before calling the save carry flag functions, and cleared
just after. VG_(fixup_guest_state_after_syscall_interrupted)
can then check this and work out which section we are in
and resume the syscall correctly.
Also:
Start a new NEWS section for 3.20
Add a regtest for this and also a similar one for Bug 445032
(x86-freebsd only, new subdir).
I saw that this problem also probably exists with macOS, so I made
the same changes there (not yet tested)
commit 7b5867b1f "helgrind reports false races for printfs using
mempcpy on FILE* state" extended the helgrind-glibc-io-xsputn
suppression by also covering mempcpy (instead of __GI_mempcpy).
The test added in that commit exposed a couple of other variants
of this suppression where _IO_*xsputn* called memcpy (instead of
mempcpy) and/or had an extra indirection/function in between.
Replace the two two suppressions with one that covers all cases
where _IO_*xsputn* *mem*cpy variants with possibly another ...
function in between.
https://bugs.kde.org/show_bug.cgi?id=450962
Found this by testing the Solaris execx (the bits that are
Linux-cmpatible) test. That was giving
--28286-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
--28286-- si_code=2; Faulting address: 0x4A0095A; sp: 0x1002ca9c88
valgrind: the 'impossible' happened:
Killed by fatal signal
host stacktrace:
==28286== at 0x5803DE54: vgPlain_strcpy (m_libcbase.c:309)
==28286== by 0x5810A9B3: vgSysWrap_linux_sys_execveat_before (syswrap-linux.c:13310)
==28286== by 0x580953C9: vgPlain_client_syscall (syswrap-main.c:2234)
It's a mistake to copy the path obtained with VG_(resolve_filename) to
the client ARG2, it's unlikely to have space for the path.
Instead just copy the pointer.
We already have a suppression for helgrind which is for when glibc
uses __GI_mempcpy to manipulate internal FILE state (this was bug
352130). But since glibc-2.26 mempcpy is used instead __GI_mempcpy,
making the suppresion from the original bug obsolete.
This patch adds a new suppression using mempcpy but doesn't replace
the original suppression for older systems.
Patch adding suppression + testcase by Jesus Checa <jcheca@redhat.com>
https://bugs.kde.org/show_bug.cgi?id=450962
ht_sigchld_ignore and ht_ignore_node were defined in pub_core_signals.h
which cannot include any other tool header.
...checking header files and include directives
*** File coregrind/pub_core_signals.h must not include pub_tool_hashtable.h
So move the definition and type to pub_tool_signals.h
The paths to these files need to be fully specified in
the out of tree build case. glibc-2.X.supp is a generated file so the
full path is deliberately not specified in that case.
Also adjust the mpi include dir location as valgrind.h is
generated as well and needs to be taken out of build dir.
Also adjust the location of generated xml file. And the search paths
for the xmllint, xsltproc and xmlto programs.
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Valgrind fork+execs debuginfod-find in order to perform debuginfod
queries. Any SIGCHLD debuginfod-find sends upon termination can
mistakenly be delivered to the client running under valgrind.
To prevent this, record in a hash table the PID of each process
valgrind forks for internal use. Do not send SIGCHLD to the client
if it is from a PID in this hash table.
https://bugs.kde.org/show_bug.cgi?id=445011
We haven't ran auxprogs/change-copyright-year since we switched to git.
This means most Copyright year ranges still say 2017. The script also
doesn't work for years >= 2020. Instead of trying to figure out how to
correctly update the per file Copyright year ranges just update the
main copyright notice that the program outputs on startup.
Currently, syscall memfd_create was tested by this:
$ perl tests/vg_regtest memcheck/tests/linux/memfd.vgtest
Since memfd_secret introduced in kernel 5.14, valgrind should rename
the "memfd" test to "memfd_create" test to avoid the ambiguity, so that
user will not get confused with the "memfd_secret" test.
After this change, syscall memfd_create will be tested by:
$ perl tests/vg_regtest memcheck/tests/linux/memfd_create.vgtest
For execve valgrind would silently fail when argv was NULL or
unadressable. Make sure that this produces a warning under memcheck.
The linux kernel accepts argv[0] being NULL, but most other kernels
don't since posix says it should be non-NULL and it causes argc to
be zero which is unexpected and might cause security issues.
This adjusts some testcases so they don't rely on execve succeeding
when argv is NULL and expect warnings about argv or argv[0] being
NULL or unaddressable.
https://bugs.kde.org/show_bug.cgi?id=450437
Passing the two 128-bit vA and vB arguments doesn't work in 32-bit mode.
The clean helper was changed to compute the result for 8 indexes. The
helper is then called twice to get the result for the upper 64-bits of the
vB register and the lower 64-bits of the vB register.
The patch is an additional fix for bugzilla 451827.
The syscall to realpathat was missing the buffer size argument.
By luck, no problem on amd64 but this failed on x86.
This adds the argument and a filter for the errors (size_t can be 4 or 8 bytes)
AC_HEADER_TIME is deprecated and checks for various things, like
whether you can include both time.h and sys/time.h together. Which
is fine on all systems these days. Just check whether sys/time.h
is available. HAVE_SYS_TIME_H is used once in the code base in the
timerfd-syscall.c testcase. So even this limited check might be
overkill.
The instruction support generates too many Iops when multiple vbpermq
instructions occur together in the binary. This patch changes the
implementation to use a clean helper and thus avoid overflowing the
internal Valgrind buffer.
bugzilla 451827
For BPF_RAW_TRACEPOINT_OPEN attr->raw_tracepoint.name may be NULL.
Otherwise it should point to a valid (max 128 char) string. Only
raw_tracepoint.prog_fd needs to be set.
https://bugs.kde.org/show_bug.cgi?id=451626
The check for the scv instruction in coregrind/m_machine.c issues an scv
instruction and uses sigill to determine if the instruction is supported.
Issuing scv on systems that don't support scv, i.e. scv support is not in
HWCAPS2, generates a message in dmesg "Facility 'SCV' unavailable (12),
exception".
This patch removes the sigill based scv instruction test from
coregrind/m_machine.c. The scv support is now determined by reading the
HWCAPS2 in setup_client_stack(). VG_(machine_ppc64_set_scv_support) is
called to set the flag ppc_scv_supported in struct VexArchInfo.
The allow_scv flag is added in disInstr_PPC_WRK. The allow_scv flag is
used to ensure the host has support for scv before generating the iops for
the scv instruction.
On s390x Linux platforms the sys_ipc semtimedop call has four instead of
five parameters, where the timeout is passed in the third instead of the
fifth.
Reflect this difference in the handling of VKI_SEMTIMEDOP.
Update the libiberty demangler using the auxprogs/update-demangler
script to gcc git commit d3b2ead595467166c849950ecd3710501a5094d9.
This update includes:
- libiberty rust-demangle, ignore .suffix
- libiberty: Fix infinite recursion in rust demangler
- Update copyright years
- libiberty: support digits in cpp mangled clone names
- d-demangle: properly skip anonymous symbols
- d-demangle: remove parenthesis where it is not needed
commit ef9ac3aa0fd3ed41d74707ffe49abe9ad2797ddd
"fix avx-1 amd64 test" split off the estimate instructions
into their own testcase avx_estimate_insn.
The commit message suggested that two .exp files would be
added, one for the intel and one for the amd cases.
It seems the .exp-amd variant was forgotten. This commit
adds it.
https://bugs.kde.org/show_bug.cgi?id=413330
check_hwcaps contains code that tries to enforce Arm architecture's
rules for the support of features (FEAT_) on v8.1. Specifically for
v8.1 FEAT_RDM and FEAT_LSE (named FEAT_ATOMICS in Valgrind) are
mandatory.
But an v8.x implementation can implement any of the v8.{x+1}
features, or not, as it chooses. Also under QEMU, which tends
to implement features on an "as-demanded" basis, you sometimes
end up with an odd combination of features, which does not
strictly comply with the architecture.
So ignore the "v8.x" architecture levels, and look only only at
"is feature X present or not". Unless the features are really not
independent.
https://bugs.kde.org/show_bug.cgi?id=449494
The ISA 3.1 implemention provides the effect of ACC and VSRs
logically containing the same data. Future versions of the
hardware may define new state or redefine the backing state
of the registers.
This reworks the code to support the ACC as implemented as a logical
mapping over the VSR registers, and lays groundwork for a future
implementation utilizing a separate register file. There
is a single boolean variable, ACC_mapped_on_VSR, that can be set in
disInstr_PPC_WRK(), based on the ISA being used, to select which
implementation model to use.
