releases/4.4.170/fork-record-start_time-late.patch

   1 From 7b55851367136b1efd84d98fea81ba57a98304cf Mon Sep 17 00:00:00 2001
   2 From: David Herrmann <dh.herrmann@gmail.com>
   3 Date: Tue, 8 Jan 2019 13:58:52 +0100
   4 Subject: fork: record start_time late
   5
   6 From: David Herrmann <dh.herrmann@gmail.com>
   7
   8 commit 7b55851367136b1efd84d98fea81ba57a98304cf upstream.
   9
  10 This changes the fork(2) syscall to record the process start_time after
  11 initializing the basic task structure but still before making the new
  12 process visible to user-space.
  13
  14 Technically, we could record the start_time anytime during fork(2).  But
  15 this might lead to scenarios where a start_time is recorded long before
  16 a process becomes visible to user-space.  For instance, with
  17 userfaultfd(2) and TLS, user-space can delay the execution of fork(2)
  18 for an indefinite amount of time (and will, if this causes network
  19 access, or similar).
  20
  21 By recording the start_time late, it much closer reflects the point in
  22 time where the process becomes live and can be observed by other
  23 processes.
  24
  25 Lastly, this makes it much harder for user-space to predict and control
  26 the start_time they get assigned.  Previously, user-space could fork a
  27 process and stall it in copy_thread_tls() before its pid is allocated,
  28 but after its start_time is recorded.  This can be misused to later-on
  29 cycle through PIDs and resume the stalled fork(2) yielding a process
  30 that has the same pid and start_time as a process that existed before.
  31 This can be used to circumvent security systems that identify processes
  32 by their pid+start_time combination.
  33
  34 Even though user-space was always aware that start_time recording is
  35 flaky (but several projects are known to still rely on start_time-based
  36 identification), changing the start_time to be recorded late will help
  37 mitigate existing attacks and make it much harder for user-space to
  38 control the start_time a process gets assigned.
  39
  40 Reported-by: Jann Horn <jannh@google.com>
  41 Signed-off-by: Tom Gundersen <teg@jklm.no>
  42 Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
  43 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
  44 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  45
  46 ---
  47  kernel/fork.c |   13 +++++++++++--
  48  1 file changed, 11 insertions(+), 2 deletions(-)
  49
  50 --- a/kernel/fork.c
  51 +++ b/kernel/fork.c
  52 @@ -1411,8 +1411,6 @@ static struct task_struct *copy_process(
  53
  54         posix_cpu_timers_init(p);
  55
  56 -       p->start_time = ktime_get_ns();
  57 -       p->real_start_time = ktime_get_boot_ns();
  58         p->io_context = NULL;
  59         p->audit_context = NULL;
  60         cgroup_fork(p);
  61 @@ -1573,6 +1571,17 @@ static struct task_struct *copy_process(
  62                 goto bad_fork_free_pid;
  63
  64         /*
  65 +        * From this point on we must avoid any synchronous user-space
  66 +        * communication until we take the tasklist-lock. In particular, we do
  67 +        * not want user-space to be able to predict the process start-time by
  68 +        * stalling fork(2) after we recorded the start_time but before it is
  69 +        * visible to the system.
  70 +        */
  71 +
  72 +       p->start_time = ktime_get_ns();
  73 +       p->real_start_time = ktime_get_boot_ns();
  74 +
  75 +       /*
  76          * Make it visible to the rest of the system, but dont wake it up yet.
  77          * Need tasklist lock for parent etc handling!
  78          */