Re: Oops caused by race between livepatch and ftrace

From: Joe Lawrence
Date: Tue May 21 2019 - 15:30:41 EST


On 5/20/19 5:19 PM, Joe Lawrence wrote:
On 5/20/19 5:09 PM, Johannes Erdfelt wrote:
On Mon, May 20, 2019, Joe Lawrence <joe.lawrence@xxxxxxxxxx> wrote:
These two testing scenarios might be interesting to add to our selftests
suite. Can you post or add the source(s) to livepatch-test<n>.ko to the
tarball?

I made the livepatches using kpatch-build and this simple patch:

diff --git a/fs/proc/version.c b/fs/proc/version.c
index 94901e8e700d..6b8a3449f455 100644
--- a/fs/proc/version.c
+++ b/fs/proc/version.c
@@ -12,6 +12,7 @@ static int version_proc_show(struct seq_file *m, void *v)
utsname()->sysname,
utsname()->release,
utsname()->version);
+ seq_printf(m, "example livepatch\n");
return 0;
}

I just created enough livepatches with the same source patch so that I
could reproduce the issue somewhat reliably.

I'll see if I can make something that uses klp directly.

Ah ok great, I was hoping it was a relatively simply livepatch. We
could probably reuse lib/livepatch/test_klp_livepatch.c to do this
(patching cmdline_proc_show instead).

The rest of the userspace in the initramfs is really straight forward
with the only interesting parts being a couple of shell scripts.

Yup. I'll be on PTO later this week, but I'll see about extracting the
scripts and building a pile of livepatch .ko's to see how easily it
reproduces without qemu.


D'oh -- I just remembered that klp doesn't create those klp (arch) relocation sections just yet! Without those, the window for module RO -> RW -> RO in klp_init_object_loaded is going to be really small... at least I can't reproduce it yet without those special sections. So maybe such selftests need to wait post klp-convert.


BTW, livepatching folks -- speaking of this window, does it make sense for klp_init_object_loaded() to unconditionally frob the module section permissions? Should it only bother iff it's going to apply relocations/alternatives/paravirt?

-- Joe