Messages in this thread | | | Date | Tue, 3 Oct 2023 18:41:57 +0200 | From | Peter Zijlstra <> | Subject | Re: Linux 6.6-rc3 (DEBUG_VIRTUAL is unhappy on x86) |
| |
On Tue, Oct 03, 2023 at 05:36:27PM +0530, Sumit Garg wrote: > Hi Linus, > > On 10/2/23 02:18, Linus Torvalds wrote: > > On Sun, 1 Oct 2023 at 07:17, Hyeonggon Yoo <42.hyeyoo@gmail.com> wrote: > > > > > Peter Zijlstra (1): > > > > > x86,static_call: Fix static-call vs return-thunk > > > > Hello, the commit above caused a crash on x86 kernel with > > > > CONFIG_DEBUG_VIRTUAL=y. > > > OK, I looked into this a little bit, and it turns out that the problematic > > > address here is from cleanup_trusted() in > > > security/keys/trusted-keys/trusted_core.c. > > > (and it's builtin due to CONFIG_TRUSTED_KEYS=y) > > > > > > The function is marked as __exit, so it does not fall within the > > > 'core kernel text address range,' which is between _stext and _etext > > > (or between _sinittext and _einittext). and thus __text_poke() thinks that > > > it's vmalloc/module area. > > > > > > I think __text_poke() should be taught that functions marked as __exit > > > also belong to kernel code just like __init. > > I think your patch is fine (well, whitespace-damaged, but conceptually good). > > > > But I also wonder about that > > > > static_call_cond(trusted_key_exit)(); > > > > in cleanup_trusted(). It seems all kinds of pointless to use static > > calls for something that is done *once*. That's not an optimization, > > that's honestly just _stupid_. It costs more to do the rewriting that > > it does to just do the one dynamic indirect call. > > That's true, there isn't any real performance benefit here. It is something > which I mentioned when I was asked to incorporate it here [1]. However, on > the flip side I think there are security benefits here. We wouldn't like any > indirect branch speculation attack to leak the trusted key material contents > here.
1) retpolines; 2) if you can unload modules, you've got bigger problems.
| |