The patch titled
exec: delay address limit change until point of no return
has been added to the -mm tree. Its filename is
exec-delay-address-limit-change-until-point-of-no-return.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: exec: delay address limit change until point of no return
From: Mathias Krause <[email protected]>
We use kernel_execve() to transfer control of the init procces from
kernel to userland. If the program to start as init process isn't given
on the kernel command line or fails to start we use a few hardcoded
fallbacks. This fallback mechanism does not work when we encounter a
file that is executable but fails to start, e.g. due to a missing
library dependency or by having an unsupported file format.
Unconditionally changing the address limit to USER_DS and not restoring it
to its old value in the error path is wrong because it prevents us using
kernel memory on repeated calls to this function. This, in fact, breaks
the fallback of hard coded paths to the init program from being ever
successful if the first candidate fails to load.
With this patch applied switching to USER_DS is delayed until the point of
no return is reached which makes it possible to have a multi-arch rootfs
with one arch specific init binary for each of the (hard coded) probed
paths.
Since the address limit is already set to USER_DS when start_thread()
will be invoked, this redundancy can be safely removed.
Signed-off-by: Mathias Krause <[email protected]>
Cc: Al Viro <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---
arch/x86/kernel/process_32.c | 1 -
arch/x86/kernel/process_64.c | 1 -
fs/exec.c | 5 +----
3 files changed, 1 insertion(+), 6 deletions(-)
diff -puN
arch/x86/kernel/process_32.c~exec-delay-address-limit-change-until-point-of-no-return
arch/x86/kernel/process_32.c
---
a/arch/x86/kernel/process_32.c~exec-delay-address-limit-change-until-point-of-no-return
+++ a/arch/x86/kernel/process_32.c
@@ -245,7 +245,6 @@ start_thread(struct pt_regs *regs, unsig
{
set_user_gs(regs, 0);
regs->fs = 0;
- set_fs(USER_DS);
regs->ds = __USER_DS;
regs->es = __USER_DS;
regs->ss = __USER_DS;
diff -puN
arch/x86/kernel/process_64.c~exec-delay-address-limit-change-until-point-of-no-return
arch/x86/kernel/process_64.c
---
a/arch/x86/kernel/process_64.c~exec-delay-address-limit-change-until-point-of-no-return
+++ a/arch/x86/kernel/process_64.c
@@ -338,7 +338,6 @@ start_thread_common(struct pt_regs *regs
regs->cs = _cs;
regs->ss = _ss;
regs->flags = X86_EFLAGS_IF;
- set_fs(USER_DS);
/*
* Free the old FP and other extended state
*/
diff -puN fs/exec.c~exec-delay-address-limit-change-until-point-of-no-return
fs/exec.c
--- a/fs/exec.c~exec-delay-address-limit-change-until-point-of-no-return
+++ a/fs/exec.c
@@ -1093,6 +1093,7 @@ int flush_old_exec(struct linux_binprm *
bprm->mm = NULL; /* We're using it now */
+ set_fs(USER_DS);
current->flags &= ~(PF_RANDOMIZE | PF_KTHREAD);
flush_thread();
current->personality &= ~bprm->per_clear;
@@ -1357,10 +1358,6 @@ int search_binary_handler(struct linux_b
if (retval)
return retval;
- /* kernel module loader fixup */
- /* so we don't try to load run modprobe in kernel space. */
- set_fs(USER_DS);
-
retval = audit_bprm(bprm);
if (retval)
return retval;
_
Patches currently in -mm which might be from [email protected] are
exec-delay-address-limit-change-until-point-of-no-return.patch
_______________________________________________
stable mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/stable
