On Mon, 10 Sep 2018 15:44:05 +1000 Michael Neuling <mi...@neuling.org> wrote:
> This stops us from doing code patching in init sections after they've > been freed. > > In this chain: > kvm_guest_init() -> > kvm_use_magic_page() -> > fault_in_pages_readable() -> > __get_user() -> > __get_user_nocheck() -> > barrier_nospec(); > > We have a code patching location at barrier_nospec() and > kvm_guest_init() is an init function. This whole chain gets inlined, > so when we free the init section (hence kvm_guest_init()), this code > goes away and hence should no longer be patched. > > We seen this as userspace memory corruption when using a memory > checker while doing partition migration testing on powervm (this > starts the code patching post migration via > /sys/kernel/mobility/migration). In theory, it could also happen when > using /sys/kernel/debug/powerpc/barrier_nospec. > > With this patch there is a small change of a race if we code patch > between the init section being freed and setting SYSTEM_RUNNING (in > kernel_init()) but that seems like an impractical time and small > window for any code patching to occur. > > cc: sta...@vger.kernel.org # 4.13+ > Signed-off-by: Michael Neuling <mi...@neuling.org> > > --- > For stable I've marked this as v4.13+ since that's when we refactored > code-patching.c but it could go back even further than that. In > reality though, I think we can only hit this since the first > spectre/meltdown changes. Which means it affects all maintained stable trees because the spectre/meltdown changes are backported. Thanks Michal