Messages in this thread | | | From | "Edgecombe, Rick P" <> | Subject | Re: [PATCH v3 03/12] x86/alternatives: Disable LASS when patching kernel alternatives | Date | Tue, 1 Aug 2023 21:50:14 +0000 |
| |
On Tue, 2023-08-01 at 14:10 -0700, Sohil Mehta wrote: > > Why not do stac/clac in a single place inside __text_poke()? > > It would mostly look something like this: > > diff --git a/arch/x86/kernel/alternative.c > > b/arch/x86/kernel/alternative.c > > index 0fbf8a631306..02ef08e2575d 100644 > > --- a/arch/x86/kernel/alternative.c > > +++ b/arch/x86/kernel/alternative.c > > @@ -1781,7 +1781,9 @@ static void *__text_poke(text_poke_f func, > > void *addr, const void *src, size_t l > > prev = use_temporary_mm(poking_mm); > > > > kasan_disable_current(); > > + stac(); > > func((u8 *)poking_addr + offset_in_page(addr), src, len); > > + clac(); > > kasan_enable_current(); > > > > /* > > Since, __text_poke() uses a dynamic function to call into > text_poke_memcpy() and text_poke_memset(), objtool would still > complain. > > > arch/x86/kernel/alternative.o: warning: objtool: __text_poke+0x259: > > call to {dynamic}() with UACCESS enabled > > We could change __text_poke() to not use the dynamic func but it > might > be a bit heavy handed to save a couple of lines of stac/clac calls. > The > current trade-off seems reasonable to me. > > Did you have something different in mind?
I wondered if it might be something like that. Yes, seems like an ok tradeoff.
| |