On Sat, Nov 18, 2023 at 11:58 AM Matthew Maurer <mmaurer@xxxxxxxxxx> wrote: > > The goal of this patch series is to allow MODVERSIONS and RUST to be > enabled simultaneously. The primary issue with doing this at the moment > is that Rust uses some extremely long symbol names - for those > unfamiliar with Rust, it may be helpful to think of some of the mangled > C++ names you may have seen in binaries in the past. > > Previously, Gary Guo attempted to accomplish this by modifying the > existing modversion format [1] to support variable-length symbol names. > This was unfortunately considered to be a potential userspace break > because kmod tools inspect this kernel module metadata. Masahiro Yamada > suggested [2] that this could instead be done with a section per-field. > This gives us the ability to be more flexible with this format in the > future, as a new field or additional information will be in a new > section which userspace tools will not yet attempt to read. > > In the previous version of this patchset, Luis Chamberlain suggested [3] > I move validation out of the version checking and into the elf validity > checker, and also add kernel-docs over there. I found > elf_validity_cached_copy to be fairly dense and difficult to directly > describe, so I refactored it into easier to explain pieces. In the > process, I found a few missing checks and added those as well. See > [PATCH 2/5] for more details. If this is too much, I'm more than happy > to drop this patch from the series in favor of just adding the > kernel-doc to the original code, but figured I'd offer it up in case the > added clarity and checks were valuable. > > [1] https://lore.kernel.org/lkml/20230111161155.1349375-1-gary@xxxxxxxxxxx/ > [2] https://lore.kernel.org/lkml/CAK7LNATsuszFR7JB5ZkqVS1W=hWr9=E7bTf+MvgJ+NXT3aZNwg@xxxxxxxxxxxxxx/ > [3] https://lore.kernel.org/lkml/ZVZNh%2FPA5HiVRkeb@xxxxxxxxxxxxxxxxxxxxxx/ I want to know why this is useful. To clarify my question, let me first explain what the modversion is. In C, a function callee and callers must agree with the interface of the function. This is usually done by having a function prototype in a header file. Say, we have a function declaration int foo(int x, int y); in include/linux/foo.h Then, the C file that defines foo() and all C files that call it must include <linux/foo.h> so that argument mismatch can be detected. Same for EXPORT_SYMBOL; the symbol provider and consumers must agree with the interface of exported symbols. In the kernel, however, there is no promise for in-kernel ABI compatibility across different kernel versions. The kernel only promises the compatibility of the userspace interface. To load modules, by principle, vmlinux and modules must have the same version. To slightly loosen the limitation, CONFIG_MODVERSIONS was introduced; when it is enabled, you can load a module as long as all the prototypes of exported symbols match. To do this, we need to encode information about prototypes. This is done by a tool called genksyms (scripts/genksyms/genksyms). Say, we have this code: int foo(int x, int y) { // genksyms does not care about // the function body. } EXPORT_SYMBOL(foo); Genksyms parses the code and computes a CRC value for 'foo'. Genksyms is only interested in the function name and its prototype. It sees int foo(int, int) and it transforms it into a CRC. Any change to the prototype results in a different CRC, so the module subsystem can check the interface compatibility before loading a module. It is obvious that this is impossible for Rust source because scripts/genksyms/genksyms is only able to parse C code. Then, what is happening here? See rust/exports.c #define EXPORT_SYMBOL_RUST_GPL(sym) extern int sym; EXPORT_SYMBOL_GPL(sym) The global scope symbols in Rust (i.e. 'pub) are automatically exported, and all of them are visible as 'int' variables from C world. Genksyms will see this code: extern int foo; EXPORT_SYMBOL_GPL(foo); Of course, this is not a true prototype. The real signature on the Rust side might be: fn foo(x: i32, y: i32) -> i32 So, even if you enable CONFIG_MODVERSIONS, nothing is checked for Rust. Genksyms computes a CRC from "int foo", and the module subsystem confirms it is a "int" variable. We know this check always succeeds. Why is this useful? > Matthew Maurer (5): > export_report: Rehabilitate script > modules: Refactor + kdoc elf_validity_cached_copy > modpost: Extended modversion support > rust: Allow MODVERSIONS > export_report: Use new version info format > > arch/powerpc/kernel/module_64.c | 25 +- > init/Kconfig | 1 - > kernel/module/internal.h | 18 +- > kernel/module/main.c | 663 +++++++++++++++++++++++++------- > kernel/module/version.c | 43 +++ > scripts/export_report.pl | 17 +- > scripts/mod/modpost.c | 37 +- > 7 files changed, 642 insertions(+), 162 deletions(-) > > -- > 2.43.0.rc0.421.g78406f8d94-goog > -- Best Regards Masahiro Yamada
