Fix externalization on Userpsace Livepatching #124
Conversation
The value of the externalized vars are filled by the livepatch system,
not the compiler. Hence if there are no writes into the variable
the compiler won't generate the instructions to read it. As an
example:
```
static int aa;
int f(void) { return aa; }
```
generates:
```
xor eax, eax
ret
```
Notice how there is no memory read. Adding the `__attribute__((used))`
to it changes the asm code to:
```
movl aa(%rip), %eax
ret
```
Fixing the issue.
Signed-off-by: Giuliano Belinassi <[email protected]>
In the case the symbol is only available on SYMTAB we can't weakly externalize it, as the linker will resolve it as not found. Signed-off-by: Giuliano Belinassi <[email protected]>
SUSE packages contain the stripped .so file with .dynsym and the debuginfo (.debug) provided in -debuginfo packages. We need both of them in Userspace Livepatching since 15.5 for proper analysis. This commit patches the ElfCache and InlineAnalysis so it can use both of them. For kernel we expect it to only use one ELF file for now (the first one). Signed-off-by: Giuliano Belinassi <[email protected]>
|
(I mean to comment on the first commit only...) |
There was a problem hiding this comment.
TBH I don't like much the word "debuginfo" when we just pass plain ELF files, having it debug symbols or not (talking about kernel ELF files). Maybe we could use "elf files" or another name in the future? For now I don't dislike it that much, but using "debuginfo"
everywhere is misleading.
|
I tested here, and it does generate code as before, just adding the new attributes when IBT is not set. LGTM: Reviewed-by: Marcos Paulo de Souza [email protected] |
No, it happens on default as well. |
I kept it as compatibility measure, so we can keep passing -DCE_DEBUGINGO_PATH |
This PR contains multiple fixes with regard to symbol externalization for what concerns Userspace Livepathing. As follows:
usedto avoid gcc to remove the variable read on assembly (i.e. inlining the pointer to always beNULL). This most likely also affects kernel livepatching and possibly it went unnoticed so far because of the gcc version they are currently using. Here is an example of this happening for functionf, whilegis correct..symtabsection.dlsymwon't be able to find such symbols, hence they should be strongly externalized rather than weakly.*.debugfile which is found in-debugpackages in SUSE Linux, the other is the*.sofile. This should not affect kernel livepatching, as they use another mechanism to decide symbol visibility.