Whenever we get an -EFAULT, we failed to read in guest 2 physical
address space. Such addressing exceptions are reported via a program
intercept to the nested hypervisor.
We faked the intercept, we have to return to guest 2. Instead, right
now we would be returning -EFAULT from the intercept handler, eventually
crashing the VM.
Addressing exceptions can only happen if the g2->g3 page tables
reference invalid g2 addresses (say, either a table or the final page is
not accessible - so something that basically never happens in sane
environments.
Identified by manual code inspection.
Fixes: a3508fbe9dc6 ("KVM: s390: vsie: initial support for nested virtualization")
Cc: <stable(a)vger.kernel.org> # v4.8+
Signed-off-by: David Hildenbrand <david(a)redhat.com>
---
arch/s390/kvm/vsie.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/s390/kvm/vsie.c b/arch/s390/kvm/vsie.c
index 076090f9e666..4f6c22d72072 100644
--- a/arch/s390/kvm/vsie.c
+++ b/arch/s390/kvm/vsie.c
@@ -1202,6 +1202,7 @@ static int vsie_run(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page)
scb_s->iprcc = PGM_ADDRESSING;
scb_s->pgmilc = 4;
scb_s->gpsw.addr = __rewind_psw(scb_s->gpsw, 4);
+ rc = 1;
}
return rc;
}
--
2.25.1
In case we have a region 1 ASCE, our shadow/g3 address can have any value.
Unfortunately, (-1UL << 64) is undefined and triggers sometimes,
rejecting valid shadow addresses when trying to walk our shadow table
hierarchy.
The result is that the prefix cannot get mapped and will loop basically
forever trying to map it (-EAGAIN loop).
After all, the broken check is only a sanity check, our table shadowing
code in kvm_s390_shadow_tables() already checks these conditions, injecting
proper translation exceptions. Turn it into a WARN_ON_ONCE().
Fixes: 4be130a08420 ("s390/mm: add shadow gmap support")
Tested-by: Janosch Frank <frankja(a)linux.ibm.com>
Reported-by: Janosch Frank <frankja(a)linux.ibm.com>
Cc: <stable(a)vger.kernel.org> # v4.8+
Signed-off-by: David Hildenbrand <david(a)redhat.com>
---
arch/s390/mm/gmap.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/s390/mm/gmap.c b/arch/s390/mm/gmap.c
index 2fbece47ef6f..b93dd54b234a 100644
--- a/arch/s390/mm/gmap.c
+++ b/arch/s390/mm/gmap.c
@@ -787,14 +787,18 @@ static void gmap_call_notifier(struct gmap *gmap, unsigned long start,
static inline unsigned long *gmap_table_walk(struct gmap *gmap,
unsigned long gaddr, int level)
{
+ const int asce_type = gmap->asce & _ASCE_TYPE_MASK;
unsigned long *table;
if ((gmap->asce & _ASCE_TYPE_MASK) + 4 < (level * 4))
return NULL;
if (gmap_is_shadow(gmap) && gmap->removed)
return NULL;
- if (gaddr & (-1UL << (31 + ((gmap->asce & _ASCE_TYPE_MASK) >> 2)*11)))
+
+ if (WARN_ON_ONCE(asce_type != _ASCE_TYPE_REGION1 &&
+ gaddr & (-1UL << (31 + (asce_type >> 2) * 11))))
return NULL;
+
table = gmap->table;
switch (gmap->asce & _ASCE_TYPE_MASK) {
case _ASCE_TYPE_REGION1:
--
2.25.1
On 3/31/20 7:08 PM, David Miller wrote:
> From: Bruno Meneguele <bmeneg(a)redhat.com>
> Date: Tue, 31 Mar 2020 10:06:30 -0300
>
>> A testing message was brought by 13d0f7b814d9 ("net/bpfilter: fix dprintf
>> usage for /dev/kmsg") but should've been deleted before patch submission.
>> Although it doesn't cause any harm to the code or functionality itself, it's
>> totally unpleasant to have it displayed on every loop iteration with no real
>> use case. Thus remove it unconditionally.
>>
>> Fixes: 13d0f7b814d9 ("net/bpfilter: fix dprintf usage for /dev/kmsg")
>> Signed-off-by: Bruno Meneguele <bmeneg(a)redhat.com>
>
> Applied, thanks.
>
As the commit this fixes was included in a stable release (at least 5.4.29[0],
I did not checked others - sorry) it could make sense to backport this also
to the 5.4 stable tree?
Per documentation[1], I checked the netdev and Greg's queues, but did not found
it to be included anywhere yet.
I hope I handled this request somewhat correctly, please tell me if I should
propose the backported patch more directly to the respective stable list. As is,
the patch[2] applies fine here on top of 5.4.30.
cheers,
Thomas
[0]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=…
[1]: https://www.kernel.org/doc/html/latest/networking/netdev-FAQ.html#q-how-can…
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/patch/?id=41…