The fix for commit e923b0537d28 ("KVM: selftests: Fix target thread to be migrated in rseq_test")
added a call to gettid() which was only added to glibc-2.30 and fails to
compile with older glibc versions.
rseq_test.c: In function 'main':
rseq_test.c:230:33: warning: implicit declaration of function 'gettid'; did you mean 'getgid'? [-Wimplicit-function-declaration]
(void *)(unsigned long)gettid());
^~~~~~
getgid
Switch the call to syscall(SYS_gettid) which was the original advice in the
gettid(2) NOTES section and which works with both new and older glibc versions.
Fixes: e923b0537d28 ("KVM: selftests: Fix target thread to be migrated in rseq_test")
Cc: stable(a)vger.kernel.org # v5.15
Signed-off-by: Liam Merwick <liam.merwick(a)oracle.com>
---
Verified with glibc-2.28 and glibc-2.34 and ensured test case from e923b0537d28 still passes.
tools/testing/selftests/kvm/rseq_test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/kvm/rseq_test.c b/tools/testing/selftests/kvm/rseq_test.c
index fac248a43666..6f88da7e60be 100644
--- a/tools/testing/selftests/kvm/rseq_test.c
+++ b/tools/testing/selftests/kvm/rseq_test.c
@@ -227,7 +227,7 @@ int main(int argc, char *argv[])
ucall_init(vm, NULL);
pthread_create(&migration_thread, NULL, migration_worker,
- (void *)(unsigned long)gettid());
+ (void *)(unsigned long)syscall(SYS_gettid));
for (i = 0; !done; i++) {
vcpu_run(vcpu);
--
2.31.1
ATTENTION
BUSINESS PARTNER,
I AM LUMAR CASEY WORKING WITH AN INSURANCE FINANCIAL INSTITUTE, WITH
MY POSITION AND PRIVILEGES I WAS ABLE TO SOURCE OUT AN OVER DUE
PAYMENT OF 12.8 MILLION POUNDS THAT IS NOW SECURED WITH A SHIPPING
DIPLOMATIC OUTLET.
I AM SEEKING YOUR PARTNERSHIP TO RECEIVE THIS CONSIGNMENT AS AS MY
PARTNER TO INVEST THIS FUND INTO A PROSPEROUS INVESTMENT VENTURE IN
YOUR COUNTRY.
I AWAIT YOUR REPLY TO ENABLE US PROCEED WITH THIS BUSINESS PARTNERSHIP TOGETHER.
REGARDS,
LUMAR CASEY
On Wed, Sep 07, 2022 at 01:42:16PM +0800, kernel test robot wrote:
Hi!
>
> Hi Kees Cook,
>
> the patch "[PATCH 1/2] fortify: Add run-time WARN for cross-field memcpy()"
> raises a persistent WARNING as below report in our tests.
>
> according to commit message, we understand this is kind of expected. but
> we don't have enough knowledge if it reveals a real issue in kernel source
> code and what the next step could be.
>
> so we still report FYI.
>
> if you think it's unnecessary for us to make out this kind of report, please
> let us know. we will consider how to refine our report rules. Thanks a lot!
>
> below is the full report.
It seems that the idea is to continue reporting these warnings, as they
help us identify the places that need to be audited and determine how to
refactor the code (in case it's a false positive), or how to properly fix
it (in case it's an actual bug).
In this case, it seems that the issue was already addressed by this patch:
https://lore.kernel.org/linux-hardening/20220903043749.3102675-1-keescook@c…
Thanks
--
Gustavo
¿Necesita un préstamo?
Ofrecemos todo tipo de préstamos al 3%, envíenos un correo electrónico ahora si está interesado para obtener más información. solo a través de este correo electrónico: suntrustinvestmentloans(a)gmail.com
Hi, Reinette, thanks for your great contribution for EDMM Linux kernel patch. I am trying to follow the newest patch now, and I have some questions on it.
It seems that `sgx_enclave_restrict_permissions()` is able to do permission restrictions for multiple enclave’s pages. After driver invokes ENCLS[EMODPR] to restrict the page’s permission, it should then invoke ENCLS[ETRACK] and send IPIs to ensure stale TLB entries have been flushed. Only in this way, ENCLU[EACCEPT] inside enclave can only succeed.
Current implementation invokes `sgx_enclave_etrack(encl)` after every `__emodpr(…)` in the for loop. My question is:
Can we move the `sgx_enclave_etrack(encl)` out of the for loop? After doing so, `sgx_enclave_etrack(encl)` is invoked **one** time for multiple enclave pages’ permission restriction, instead of N times (N = `modp -> length / PAGE_SIZE`). We may gain some performance optimization from it.
Please correct my if my understanding is incorrect. Looking forward to your reply and Thanks for your time!
BR,
Bojun
Currently our SVE syscall ABI documentation does not reflect the actual
implemented ABI, it says that register state not shared with FPSIMD
becomes undefined on syscall when in reality we always clear it. Since
changing this would cause a change in the observed kernel behaviour
there is a substantial desire to avoid taking advantage of the
documented ABI so instead let's document what we actually do so it's
clear that it is in reality an ABI.
There has been some pushback on tightening the documentation in the past
but it is hard to see who that helps, it makes the implementation
decisions less clear and makes it harder for people to discover and make
use of the actual ABI. The main practical concern is that qemu's user
mode does not currently flush the registers.
v3:
- Rebase onto v6.0-rc3.
v2:
- Rebase onto v6.0-rc1.
Mark Brown (3):
kselftest/arm64: Correct buffer allocation for SVE Z registers
arm64/sve: Document our actual ABI for clearing registers on syscall
kselftest/arm64: Enforce actual ABI for SVE syscalls
Documentation/arm64/sve.rst | 2 +-
.../testing/selftests/arm64/abi/syscall-abi.c | 61 ++++++++++++-------
2 files changed, 41 insertions(+), 22 deletions(-)
base-commit: b90cb1053190353cc30f0fef0ef1f378ccc063c5
--
2.30.2
This series has a few small enhancements for the existing standalone
floating point stress tests and then builds on those with a kselftest
integrated program which gives those a very quick spin from within
kselftest, as well as having an option to set a custom timeout to allow
for use with longer soak testing. This makes it much easier to get
thorough testing of the floating point state management logic, rather
than requiring custom setup for coverage of the various vector lengths
in the system as is needed at present.
It might be nice in future to extend this to attach to some or all of
the test programs with ptrace and read/write their registers as another
means of potentially triggering race conditions or corruption but that's
definitely another step.
v2:
- Rebase onto v6.0-rc3.
- Announce the results of enumeration before we start everything.
Mark Brown (4):
kselftest/arm64: Always encourage preemption for za-test
kselftest/arm64: Count SIGUSR2 deliveries in FP stress tests
kselftest/arm64: Install signal handlers before output in FP stress
tests
kselftest/arm64: kselftest harness for FP stress tests
tools/testing/selftests/arm64/fp/.gitignore | 1 +
tools/testing/selftests/arm64/fp/Makefile | 5 +-
.../testing/selftests/arm64/fp/asm-offsets.h | 1 +
tools/testing/selftests/arm64/fp/fp-stress.c | 535 ++++++++++++++++++
.../testing/selftests/arm64/fp/fpsimd-test.S | 51 +-
tools/testing/selftests/arm64/fp/sve-test.S | 51 +-
tools/testing/selftests/arm64/fp/za-test.S | 58 +-
7 files changed, 641 insertions(+), 61 deletions(-)
create mode 100644 tools/testing/selftests/arm64/fp/fp-stress.c
base-commit: b90cb1053190353cc30f0fef0ef1f378ccc063c5
--
2.30.2
These patches improve the coverage of ZA signal contexts a bit, adding
some validation that the actual data is correct and covering the case
where ZA is not enabled.
v2:
- Rebase onto v6.0-rc3.
Mark Brown (2):
kselftest/arm64: Tighten up validation of ZA signal context
kselftest/arm64: Add a test for signal frames with ZA disabled
.../arm64/signal/testcases/za_no_regs.c | 119 ++++++++++++++++++
.../arm64/signal/testcases/za_regs.c | 16 ++-
2 files changed, 134 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/arm64/signal/testcases/za_no_regs.c
base-commit: b90cb1053190353cc30f0fef0ef1f378ccc063c5
--
2.30.2
The arm64 architecture originally made the signal context a fixed size
structure containing a linked list of records with the various kinds of
register and other state which may be present. When SVE was implemented
it was realised that it supported implementations with more state than
could fit in that structure so a new record type EXTRA_CONTEXT was
introduced allowing the signal context to be extended beyond the
original size. Unfortunately the signal handling tests can not cope with
these EXTRA_CONTEXT records at all - some support was implemented but it
simply never worked.
v2:
- Rebase onto v6.0-rc3
Mark Brown (10):
kselftest/arm64: Enumerate SME rather than SVE vector lengths for
za_regs
kselftest/arm64: Validate signal ucontext in place
kselftest/arm64: Fix validatation termination record after
EXTRA_CONTEXT
kselftest/arm64: Fix validation of EXTRA_CONTEXT signal context
location
kselftest/arm64: Remove unneeded protype for validate_extra_context()
kselftest/arm64: Only validate each signal context once
kselftest/arm64: Validate contents of EXTRA_CONTEXT blocks
kselftest/arm64: Preserve any EXTRA_CONTEXT in handle_signal_copyctx()
kselftest/arm64: Allow larger buffers in get_signal_context()
kselftest/arm64: Include larger SVE and SME VLs in signal tests
.../arm64/signal/test_signals_utils.c | 59 +++++++++++++++++--
.../arm64/signal/test_signals_utils.h | 5 +-
.../testcases/fake_sigreturn_bad_magic.c | 2 +-
.../testcases/fake_sigreturn_bad_size.c | 2 +-
.../fake_sigreturn_bad_size_for_magic0.c | 2 +-
.../fake_sigreturn_duplicated_fpsimd.c | 2 +-
.../testcases/fake_sigreturn_misaligned_sp.c | 2 +-
.../testcases/fake_sigreturn_missing_fpsimd.c | 2 +-
.../testcases/fake_sigreturn_sme_change_vl.c | 2 +-
.../testcases/fake_sigreturn_sve_change_vl.c | 2 +-
.../selftests/arm64/signal/testcases/sme_vl.c | 2 +-
.../arm64/signal/testcases/ssve_regs.c | 25 +++-----
.../arm64/signal/testcases/sve_regs.c | 23 +++-----
.../selftests/arm64/signal/testcases/sve_vl.c | 2 +-
.../arm64/signal/testcases/testcases.c | 48 +++++++++++----
.../arm64/signal/testcases/testcases.h | 9 ++-
.../arm64/signal/testcases/za_regs.c | 28 ++++-----
17 files changed, 137 insertions(+), 80 deletions(-)
base-commit: b90cb1053190353cc30f0fef0ef1f378ccc063c5
--
2.30.2