summaryrefslogtreecommitdiff
path: root/arch/x86/um/shared/sysdep/stub_64.h
AgeCommit message (Collapse)AuthorFilesLines
2024-01-05um: Always inline stub functionsBenjamin Berg1-8/+9
The stub executable page is remapped to a different location in the userland process. As these functions may be used by the stub, they really need to be always inlined rather than permitting the compiler to emit a function. Signed-off-by: Benjamin Berg <benjamin@sipsolutions.net> Signed-off-by: Richard Weinberger <richard@nod.at>
2023-04-21um: make stub data pages size tweakableJohannes Berg1-4/+4
There's a lot of code here that hard-codes that the data is a single page, and right now that seems to be sufficient, but to make it easier to change this in the future, add a new STUB_DATA_PAGES constant and use it throughout the code. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2022-07-18um: include linux/stddef.h for __always_inlineJason A. Donenfeld1-0/+1
When compiling against musl, their shipped <stddef.h> doesn't have __always_inline. So instead explicitly include the kernel uapi header, <linux/stddef.h>, which does. This prevents the following build error: In file included from arch/x86/um/shared/sysdep/stub.h:11, from arch/um/kernel/skas/clone.c:14: arch/x86/um/shared/sysdep/stub_64.h:111:23: error: expected ‘;’ before ‘void’ 111 | static __always_inline void *get_stub_page(void) | ^~~~~ | ; make[4]: *** [scripts/Makefile.build:249: arch/um/kernel/skas/clone.o] Error 1 Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2021-08-26um: fix stub location calculationJohannes Berg1-0/+12
In commit 9f0b4807a44f ("um: rework userspace stubs to not hard-code stub location") I changed stub_segv_handler() to do a calculation with a pointer to a stack variable to find the data page that we're using for the stack and the rest of the data. This same commit was meant to do it as well for stub_clone_handler(), but the change inadvertently went into commit 84b2789d6115 ("um: separate child and parent errors in clone stub") instead. This was reported to not be compiled correctly by gcc 5, causing the code to crash here. I'm not sure why, perhaps it's UB because the var isn't initialized? In any case, this trick always seemed bad, so just create a new inline function that does the calculation in assembly. Reported-by: subashab@codeaurora.org Fixes: 9f0b4807a44f ("um: rework userspace stubs to not hard-code stub location") Fixes: 84b2789d6115 ("um: separate child and parent errors in clone stub") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2021-02-12um: rework userspace stubs to not hard-code stub locationJohannes Berg1-12/+24
The userspace stacks mostly have a stack (and in the case of the syscall stub we can just set their stack pointer) that points to the location of the stub data page already. Rework the stubs to use the stack pointer to derive the start of the data page, rather than requiring it to be hard-coded. In the clone stub, also integrate the int3 into the stack remap, since we really must not use the stack while we remap it. This prepares for putting the stub at a variable location that's not part of the normal address space of the userspace processes running inside the UML machine. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2021-02-12um: separate child and parent errors in clone stubJohannes Berg1-1/+1
If the two are mixed up, then it looks as though the parent returned an error if the child failed (before) the mmap(), and then the resulting process never gets killed. Fix this by splitting the child and parent errors, reporting and using them appropriately. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2011-11-02um: take arch/um/sys-x86 to arch/x86/umAl Viro1-0/+99
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Richard Weinberger <richard@nod.at>