We're currently using the x86_64 qemu for i386 builds. While this is not
incorrect, it's probably more sensible to use the i386 one, which will
at least fail properly if we accidentally were to build a 64-bit kernel.
Signed-off-by: David Gow <davidgow(a)google.com>
---
tools/testing/kunit/qemu_configs/i386.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/kunit/qemu_configs/i386.py b/tools/testing/kunit/qemu_configs/i386.py
index 52b80be40e4b..4463ebefd567 100644
--- a/tools/testing/kunit/qemu_configs/i386.py
+++ b/tools/testing/kunit/qemu_configs/i386.py
@@ -4,7 +4,7 @@ QEMU_ARCH = QemuArchParams(linux_arch='i386',
kconfig='''
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y''',
- qemu_arch='x86_64',
+ qemu_arch='i386',
kernel_path='arch/x86/boot/bzImage',
kernel_command_line='console=ttyS0',
extra_qemu_params=[])
--
2.36.0.550.gb090851708-goog
Hello,
are you looking for more business clients?
We would like to start working with you as a partner in acquiring or exchanging leads, which directly translates into mutual benefits in the form of an increased client portfolio.
We work in the sector of internet marketing and as one of the first in Europe SEO Agencies we’ve introduced the SEO 360 service which allows your clients to gain the access to original SEO consultations.
By choosing to work with us you receive support in achieving your business goals, and help in handling Digital Marketing for your clients.
We support over 237 partner companies. We have one of the biggest executive departments in Europe at our disposal, we’ve prepared over 2000 campaigns in Europe and 200 in the USA and Canada.
Are you interested in the details of our partnership programme?
Yours sincerely,
Luca Gauthier
If a memop fails due to key checked protection, after already having
written to the guest, don't indicate suppression to the guest, as that
would imply that memory wasn't modified.
This could be considered a fix to the code introducing storage key
support, however this is a bug in KVM only if we emulate an
instructions writing to an operand spanning multiple pages, which I
don't believe we do.
v2 -> v3
* tweak commit message
* explicitly reset the protection code to 0 on termination
* use variable to pass termination arg
* add documentation
* fix magic constant in selftest
Given the changes I did not pick up the r-b's.
v1 -> v2
* Reword commit message of patch 1
Janis Schoetterl-Glausch (2):
KVM: s390: Don't indicate suppression on dirtying, failing memop
KVM: s390: selftest: Test suppression indication on key prot exception
Documentation/virt/kvm/api.rst | 6 +++
arch/s390/kvm/gaccess.c | 22 +++++++++--
tools/testing/selftests/kvm/s390x/memop.c | 46 ++++++++++++++++++++++-
3 files changed, 69 insertions(+), 5 deletions(-)
Range-diff against v2:
1: b5725a836f1a ! 1: e1dae6522b22 KVM: s390: Don't indicate suppression on dirtying, failing memop
@@ Commit message
Instruction execution can end in different ways, one of which is
suppression, which requires that the instruction execute like a no-op.
A writing memop that spans multiple pages and fails due to key
- protection can modified guest memory, as a result, the likely
- correct ending is termination. Therefore do not indicate a
+ protection may have modified guest memory, as a result, the likely
+ correct ending is termination. Therefore, do not indicate a
suppressing instruction ending in this case.
Signed-off-by: Janis Schoetterl-Glausch <scgl(a)linux.ibm.com>
+ ## Documentation/virt/kvm/api.rst ##
+@@ Documentation/virt/kvm/api.rst: in case of KVM_S390_MEMOP_F_CHECK_ONLY), the ioctl returns a positive
+ error number indicating the type of exception. This exception is also
+ raised directly at the corresponding VCPU if the flag
+ KVM_S390_MEMOP_F_INJECT_EXCEPTION is set.
++On protection exceptions, unless specified otherwise, the injected
++translation-exception identifier (TEID) indicates suppression.
+
+ If the KVM_S390_MEMOP_F_SKEY_PROTECTION flag is set, storage key
+ protection is also in effect and may cause exceptions if accesses are
+ prohibited given the access key designated by "key"; the valid range is 0..15.
+ KVM_S390_MEMOP_F_SKEY_PROTECTION is available if KVM_CAP_S390_MEM_OP_EXTENSION
+ is > 0.
++Since the accessed memory may span multiple pages and those pages might have
++different storage keys, it is possible that a protection exception occurs
++after memory has been modified. In this case, if the exception is injected,
++the TEID does not indicate suppression.
+
+ Absolute read/write:
+ ^^^^^^^^^^^^^^^^^^^^
+
## arch/s390/kvm/gaccess.c ##
@@ arch/s390/kvm/gaccess.c: enum prot_type {
PROT_TYPE_IEP = 4,
@@ arch/s390/kvm/gaccess.c: enum prot_type {
-static int trans_exc(struct kvm_vcpu *vcpu, int code, unsigned long gva,
- u8 ar, enum gacc_mode mode, enum prot_type prot)
+static int trans_exc_ending(struct kvm_vcpu *vcpu, int code, unsigned long gva, u8 ar,
-+ enum gacc_mode mode, enum prot_type prot, bool suppress)
++ enum gacc_mode mode, enum prot_type prot, bool terminate)
{
struct kvm_s390_pgm_info *pgm = &vcpu->arch.pgm;
struct trans_exc_code_bits *tec;
@@ arch/s390/kvm/gaccess.c: static int trans_exc(struct kvm_vcpu *vcpu, int code, unsigned long gva,
-
- switch (code) {
- case PGM_PROTECTION:
-- switch (prot) {
-- case PROT_TYPE_IEP:
-- tec->b61 = 1;
-- fallthrough;
-- case PROT_TYPE_LA:
-- tec->b56 = 1;
-- break;
-- case PROT_TYPE_KEYC:
-- tec->b60 = 1;
-- break;
-- case PROT_TYPE_ALC:
-- tec->b60 = 1;
-- fallthrough;
-- case PROT_TYPE_DAT:
-- tec->b61 = 1;
-- break;
-+ if (suppress) {
-+ switch (prot) {
-+ case PROT_TYPE_IEP:
-+ tec->b61 = 1;
-+ fallthrough;
-+ case PROT_TYPE_LA:
-+ tec->b56 = 1;
-+ break;
-+ case PROT_TYPE_KEYC:
-+ tec->b60 = 1;
-+ break;
-+ case PROT_TYPE_ALC:
-+ tec->b60 = 1;
-+ fallthrough;
-+ case PROT_TYPE_DAT:
-+ tec->b61 = 1;
-+ break;
-+ }
+ tec->b61 = 1;
+ break;
}
++ if (terminate) {
++ tec->b56 = 0;
++ tec->b60 = 0;
++ tec->b61 = 0;
++ }
fallthrough;
case PGM_ASCE_TYPE:
+ case PGM_PAGE_TRANSLATION:
@@ arch/s390/kvm/gaccess.c: static int trans_exc(struct kvm_vcpu *vcpu, int code, unsigned long gva,
return code;
}
@@ arch/s390/kvm/gaccess.c: static int trans_exc(struct kvm_vcpu *vcpu, int code, u
+static int trans_exc(struct kvm_vcpu *vcpu, int code, unsigned long gva, u8 ar,
+ enum gacc_mode mode, enum prot_type prot)
+{
-+ return trans_exc_ending(vcpu, code, gva, ar, mode, prot, true);
++ return trans_exc_ending(vcpu, code, gva, ar, mode, prot, false);
+}
+
static int get_vcpu_asce(struct kvm_vcpu *vcpu, union asce *asce,
unsigned long ga, u8 ar, enum gacc_mode mode)
{
@@ arch/s390/kvm/gaccess.c: int access_guest_with_key(struct kvm_vcpu *vcpu, unsigned long ga, u8 ar,
+ data += fragment_len;
ga = kvm_s390_logical_to_effective(vcpu, ga + fragment_len);
}
- if (rc > 0)
+- if (rc > 0)
- rc = trans_exc(vcpu, rc, ga, ar, mode, prot);
-+ rc = trans_exc_ending(vcpu, rc, ga, ar, mode, prot,
-+ (mode != GACC_STORE) || (idx == 0));
++ if (rc > 0) {
++ bool terminate = (mode == GACC_STORE) && (idx > 0);
++
++ rc = trans_exc_ending(vcpu, rc, ga, ar, mode, prot, terminate);
++ }
out_unlock:
if (need_ipte_lock)
ipte_unlock(vcpu);
2: 434d96c63cb5 ! 2: d3a152fe6aec KVM: s390: selftest: Test suppression indication on key prot exception
@@ Commit message
Signed-off-by: Janis Schoetterl-Glausch <scgl(a)linux.ibm.com>
## tools/testing/selftests/kvm/s390x/memop.c ##
+@@
+ #include <string.h>
+ #include <sys/ioctl.h>
+
++#include <linux/bits.h>
++
+ #include "test_util.h"
+ #include "kvm_util.h"
+
@@ tools/testing/selftests/kvm/s390x/memop.c: static int err_memop_ioctl(struct test_vcpu vcpu, struct kvm_s390_mem_op *ksmo)
#define SIDA_OFFSET(o) ._sida_offset = 1, .sida_offset = (o)
#define AR(a) ._ar = 1, .ar = (a)
@@ tools/testing/selftests/kvm/s390x/memop.c: static void test_errors_key(void)
+ struct test_default t = test_default_init(guest_error_key);
+ uint64_t prefix;
+ uint64_t teid;
++ uint64_t teid_mask = BIT(63 - 56) | BIT(63 - 60) | BIT(63 - 61);
+ uint64_t psw[2];
+
+ HOST_SYNC(t.vcpu, STAGE_INITED);
@@ tools/testing/selftests/kvm/s390x/memop.c: static void test_errors_key(void)
+ HOST_SYNC(t.vcpu, STAGE_IDLED);
+ MOP(t.vm, ABSOLUTE, READ, &teid, sizeof(teid), GADDR(prefix + 168));
+ /* Bits 56, 60, 61 form a code, 0 being the only one allowing for termination */
-+ ASSERT_EQ(teid & 0x4c, 0);
++ ASSERT_EQ(teid & teid_mask, 0);
+
+ kvm_vm_free(t.kvm_vm);
+}
base-commit: c5eb0a61238dd6faf37f58c9ce61c9980aaffd7a
--
2.32.0
Check that size would not overflow before calculation (and return
-EOVERFLOW if it will), to prevent potential out-of-bounds write
with the following copy_from_user. Add the same check
to kprobe_multi_resolve_syms in case it will be called from elsewhere
in the future.
Fixes: 0dcac272540613d4 ("bpf: Add multi kprobe link")
Signed-off-by: Eugene Syromiatnikov <esyr(a)redhat.com>
---
kernel/trace/bpf_trace.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index d8553f4..e90c4ce7 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -2358,6 +2358,8 @@ kprobe_multi_resolve_syms(const void __user *usyms, u32 cnt,
unsigned int i;
char *func;
+ if (check_mul_overflow(cnt, sizeof(*syms), &size))
+ return -EOVERFLOW;
size = cnt * sizeof(*syms);
syms = kvzalloc(size, GFP_KERNEL);
if (!syms)
@@ -2429,6 +2431,8 @@ int bpf_kprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *pr
if (!cnt)
return -EINVAL;
+ if (check_mul_overflow(cnt, (u32)sizeof(*addrs), &size))
+ return -EOVERFLOW;
size = cnt * sizeof(*addrs);
addrs = kvmalloc(size, GFP_KERNEL);
if (!addrs)
--
2.1.4