Kvm elects to use tsc instead of kvm-clock when it can detect that the
TSC is invariant.
(As of commit 7539b174aef4 ("x86: kvmguest: use TSC clocksource if
invariant TSC is exposed")).
Notable cloud vendors[1] and performance engineers[2] recommend that Xen
users preferentially select tsc over xen-clocksource due the performance
penalty incurred by the latter. These articles are persuasive and
tailored to specific use cases. In order to understand the tradeoffs
around this choice more fully, this author had to reference the
documented[3] complexities around the Xen configuration, as well as the
kernel's clocksource selection algorithm. Many users may not attempt
this to correctly configure the right clock source in their guest.
The approach taken in the kvm-clock module spares users this confusion,
where possible.
Both the Intel SDM[4] and the Xen tsc documentation explain that marking
a tsc as invariant means that it should be considered stable by the OS
and is elibile to be used as a wall clock source.
In order to obtain better out-of-the-box performance, and reduce the
need for user tuning, follow kvm's approach and decrease the xen clock
rating so that tsc is preferable, if it is invariant, stable, and the
tsc will never be emulated.
Currently, when loading a kernel image via the kexec_file_load() system
call, arm64 can only use the .builtin_trusted_keys keyring to verify
a signature whereas x86 can use three more keyrings i.e.
.secondary_trusted_keys, .machine and .platform keyrings. For example,
one resulting problem is kexec'ing a kernel image would be rejected
with the error "Lockdown: kexec: kexec of unsigned images is restricted;
see man kernel_lockdown.7".
This patch set enables arm64 to make use of the same keyrings as x86 to
verify the signature kexec'ed kernel image.
Fixes: 732b7b93d849 ("arm64: kexec_file: add kernel signature verification support")
Cc: <email address hidden> # 105e10e2cf1c: kexec_file: drop weak attribute from functions
Cc: <email address hidden> # 34d5960af253: kexec: clean up arch_kexec_kernel_verify_sig
Cc: <email address hidden> # 83b7bb2d49ae: kexec, KEYS: make the code in bzImage64_verify_sig generic
Acked-by: Baoquan He <email address hidden>
Cc: <email address hidden>
Cc: <email address hidden>
Cc: <email address hidden>
Co-developed-by: Michal Suchanek <email address hidden>
Signed-off-by: Michal Suchanek <email address hidden>
Acked-by: Will Deacon <email address hidden>
Signed-off-by: Coiby Xu <email address hidden>
Signed-off-by: Mimi Zohar <email address hidden>
(cherry picked from commit 0d519cadf75184a24313568e7f489a7fc9b1be3b)
Signed-off-by: Chengen Du <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Acked-by: Roxana Nicolescu <email address hidden>
Signed-off-by: Roxana Nicolescu <email address hidden>
commit 278311e417be ("kexec, KEYS: Make use of platform keyring for
signature verify") adds platform keyring support on x86 kexec but not
arm64.
The code in bzImage64_verify_sig uses the keys on the
.builtin_trusted_keys, .machine, if configured and enabled,
.secondary_trusted_keys, also if configured, and .platform keyrings
to verify the signed kernel image as PE file.
Cc: <email address hidden>
Cc: <email address hidden>
Cc: <email address hidden>
Reviewed-by: Michal Suchanek <email address hidden>
Signed-off-by: Coiby Xu <email address hidden>
Signed-off-by: Mimi Zohar <email address hidden>
(backported from commit c903dae8941deb55043ee46ded29e84e97cd84bb)
[chengen - not to adopt the refined function, kexec_image_verify_sig]
Signed-off-by: Chengen Du <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Acked-by: Roxana Nicolescu <email address hidden>
Signed-off-by: Roxana Nicolescu <email address hidden>
The vrf-xfrm-tests tests use the hmac(md5) and cbc(des3_ede)
algorithms for performing authentication and encryption, respectively.
This causes the tests to fail when fips=1 is set, since these algorithms
are not allowed in FIPS mode. Therefore, switch from hmac(md5) and
cbc(des3_ede) to hmac(sha1) and cbc(aes), which are FIPS compliant.
Fixes: 3f251d741150 ("selftests: Add tests for vrf and xfrms")
Reviewed-by: David Ahern <email address hidden>
Signed-off-by: Magali Lemes <email address hidden>
Signed-off-by: Jakub Kicinski <email address hidden>
(cherry picked from commit cb43c60e64ca67fcc9d23bd08f51d2ab8209d9d7)
Signed-off-by: Magali Lemes <email address hidden>
Acked-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Roxana Nicolescu <email address hidden>
Signed-off-by: Roxana Nicolescu <email address hidden>
TLS selftests use the ChaCha20-Poly1305 and SM4 algorithms, which are not
FIPS compliant. When fips=1, this set of tests fails. Add a check and only
run these tests if not in FIPS mode.
Fixes: 4f336e88a870 ("selftests/tls: add CHACHA20-POLY1305 to tls selftests")
Fixes: e506342a03c7 ("selftests/tls: add SM4 GCM/CCM to tls selftests")
Reviewed-by: Jakub Kicinski <email address hidden>
Signed-off-by: Magali Lemes <email address hidden>
Signed-off-by: Jakub Kicinski <email address hidden>
(backported from commit d113c395c67b62fc0d3f2004c0afc406aca0a2b7)
[magalilemes: since there's no SM4 support for TLS in 5.15, only apply the
change to the ChaCha20-Poly1305 test case]
Signed-off-by: Magali Lemes <email address hidden>
Acked-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Roxana Nicolescu <email address hidden>
Signed-off-by: Roxana Nicolescu <email address hidden>
Before executing each test from a fixture, FIXTURE_SETUP is run once.
When SKIP is used in FIXTURE_SETUP, the setup function returns early
but the test still proceeds to run, unless another SKIP macro is used
within the test definition, leading to some code repetition. Therefore,
allow tests to be skipped directly from the setup function.
Suggested-by: Jakub Kicinski <email address hidden>
Signed-off-by: Magali Lemes <email address hidden>
Signed-off-by: Jakub Kicinski <email address hidden>
(backported from commit 372b304c1e517c4d3e5b6ca6c9cfb20f027c3b03)
[magalilemes: a clean cherry-pick would require 63e6b2a4
("selftests/harness: Run TEARDOWN for ASSERT failures"). However,
it suffices to just manually change the if condition that conflicts.]
Signed-off-by: Magali Lemes <email address hidden>
Acked-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Roxana Nicolescu <email address hidden>
Signed-off-by: Roxana Nicolescu <email address hidden>
