On Tue, 2018-01-09 at 00:02 +0100, Michael Matz wrote: > Hi, > > On Mon, 8 Jan 2018, Woodhouse, David wrote: > > > > > > > > > > > > > > That can be done via asm aliases or direct assembler use; the kernel > > > > doesn't absolutely have to access them via C compatible symbol names. > > > > > > > Hi David, > > > > > > Can you comment on this? > > > > It ends up being a real pain for the CONFIG_TRIM_UNUSED_SYMBOLS > > mechanism in the kernel, which really doesn't cope well with the dots. > > It *does* assume that exported symbols have C-compatible names. > > MODVERSIONS too, although we had a simpler "just shut up the warnings" > > solution for that. It was CONFIG_TRIM_UNUSED_SYMBOLS which was the > > really horrid one. > > > > I went a little way down the rabbit-hole of trying to make it cope, but > > it was far from pretty: > > > > https://patchwork.kernel.org/patch/10148081/ > > > > If there's a way to make it work sanely, I'm up for that. But if the > > counter-argument is "But someone might genuinely want to make their own > > C function called __x86_indirect_thunk_rax"... I'm not so receptive to > > that argument :) > > Well, the naming of the extern thunk isn't so important that the above > might not be a reason to just go with underscores. I'll certainly not > object to the patch on that basis. But do keep in mind that GCC already > uses '.' for other compiler generated symbols, and we're likely to > continue doing this. So eventually you'll want to fix your trim_unused > infrastructure to cope with that. (Perhaps by just ignoring those > symbols? It's not that they must be trimmed if unused, as the user didn't > write them on his own to start with, right?)
This is only for the symbols which are exported to loadable kernel modules. When the compiler-generated symbols are emitted inline in a COMDAT section, we basically never even notice them. The module probably has its own copy, and that's fine. These indirect thunks are special because we really care about modifying them at run time according to which CPU we happen to be running on and which other mitigations for the Spectre problem are in use. That's why we asked for the -mindirect-branch=thunk-extern option and provided our own copy of the thunks — and why we're exporting *our* version to loadable modules. I don't think it's hugely likely that we'll need to cope with other compiler-generated symbols in quite the same way, in the near future. The CONFIG_TRIM_UNUSED_SYMBOLS option is an optimisation to avoid exporting functions which aren't actually used by any of the loadable modules that were built in the currently-active kernel configuration. Lots of in-kernel text can thus be dropped from the image once it's known that it will never be used. And that's the code that has difficulty with the dots. And yes, it's perfectly OK to drop, for example, the %rsp-based thunk completely if nobody happens to use it today (actually, why am I creating that one in the first place? :) There are various ways to address the problem, none of them very pretty. The nicest was to just *not* have dots in the symbols.
smime.p7s
Description: S/MIME cryptographic signature
