Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp1474325pxv; Fri, 2 Jul 2021 04:53:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzcXD9DOxELadawCSABAx3VxqSWTWhWUbYNIEAZfQ4YhPnUrM9TxLZT9SsMp5F8vMepPsgw X-Received: by 2002:a50:ec16:: with SMTP id g22mr6506321edr.188.1625226786581; Fri, 02 Jul 2021 04:53:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625226786; cv=none; d=google.com; s=arc-20160816; b=N5Iktt/sSBonu9QhuM6jneBEuuW9T776PMgcATIauj7xjzL+xvPR5z458hzcqqCEAv P4dV9grcI9j6cpaLse08ejNnmfJ3Dc5liHEXihCkrtH/b9I4Lb7kzJYsK1odj01Cld9C JBuuHmeI76k3seJfXwlWq2W6PxMUHBUiEj4/sD5LLpQ3qEd752ZC89R7zKLVgYGq+Hlk nzkh6c979/V1hX6BbA4augy840e6H/nT9Dgap2wyw3mFi+8DyA642RqlQ7gtxPj5Kj3y kAfY8YwY5L1fyxsmJ9JWYMLqC76cMWFkFIulrUVQwWJVqu9jrTl1WDDyJw5YuNt4RjuT DWHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=itw4ZSFZPbB5jMtAcW94A5cIi28Zbh7A4MY1L25gGO0=; b=kbN6pmMOiIbX54tpCRE7k9uWhPXMYNmH7WEseRAyUM88DIti99WsVC099Zry6J6QZk MR/N794cFfZnyHYOi4UxeViiyAfy4H/zPh3hT7JvMTAM5nJbapJ9zdSpBBITp0bXolO9 7qOR0zENmD1rCl22ytjpaw+71bcHyMIwgiLM+Rir3KC5uYEW9zM9P84S8Tt1Vh/6HksP 4mNa0byBX3zFQ8llMnrhoLATdHmZXl/WhKP0CPtZ01zztsu2s7zR5ffeYQovik11crXz Ahv0mNXujyE7LGyxWKRaG0watJPykyZkxgmMKTLkXCvpCNTIQYSF+dasIYkes1Is5V1a fx0Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=skWOQ+tj; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a6si2990151ejc.745.2021.07.02.04.52.42; Fri, 02 Jul 2021 04:53:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=skWOQ+tj; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231992AbhGBLyJ (ORCPT + 99 others); Fri, 2 Jul 2021 07:54:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34654 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231936AbhGBLyJ (ORCPT ); Fri, 2 Jul 2021 07:54:09 -0400 Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7C4EFC061764 for ; Fri, 2 Jul 2021 04:51:36 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id a15so17569392lfr.6 for ; Fri, 02 Jul 2021 04:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=itw4ZSFZPbB5jMtAcW94A5cIi28Zbh7A4MY1L25gGO0=; b=skWOQ+tjB/RGXCRgCh/oX+pSqn801BpaewaioJ94g7BDJUoKJyzmNIJxfF6R7k4OVV FkwksQciuoAEGOrZtrGFPyYLCXxLZXMJQsbTDphZ25i2JhWuw1YkS/xEcgUdDDbf9BEz j7+1ZY18y7jKX0p1sfgvxy86H6YhI4LvjICQmgerkbW0Z3rzuCrlxHcOSbVsgrfKEMkm twF/uAlLn/bNXF+depqyu2UMF8dk7nIYWit4IrjecjAjTjt4ERd3UudzQ1TbM8bnmPv4 qcu2ePgioE8YFrrKk17qWsiRJ2RNd9GS4629An1dwAydO/asFBTQAYsYJLt0DMpXfTAL jsNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=itw4ZSFZPbB5jMtAcW94A5cIi28Zbh7A4MY1L25gGO0=; b=fWhk2AHGG9wJrsGZ2LyieSj/HAuYlVShtynLVLWvR/Dr+PkpHWtoSfDx9zLcMt6Y0B x4aK0zGURPv9x3PQdVbuDtTX9wAIoWib0n+qIco+m3klEIpsnGHVTmXYu76vwjF6UsSL EGYTqKnutw5YDZyoLwk08Jy5am5puvRXZ/vo0LwXYBLcr8LXkKatopiFx5Mh1jVeD2P+ UNUrchChiXfeIY5v+H9Af+2k1XkuIiw5Rtx8AipXLtSxPx0FXGLHHFjURGuUxFvsW/yS YF+ZDvvQwlvtwvJIRV4qKzc5GxCHSL9kbHTF9fzQxoLApx0K2zkCbNMPJVJX1pWmjnj/ 5l4w== X-Gm-Message-State: AOAM531BI9DpxdfaQDPdKdgZPkmrXyyuR5mCXxLvEgj/Gpyy6pPW2suC tiNtqsKF6JntBRbcWcWNwRuqaUIU1N6xkJrCC+TBOg== X-Received: by 2002:a19:f51a:: with SMTP id j26mr3666613lfb.390.1625226694605; Fri, 02 Jul 2021 04:51:34 -0700 (PDT) MIME-Version: 1.0 References: <20210414055217.543246-1-avagin@gmail.com> <20210414055217.543246-3-avagin@gmail.com> In-Reply-To: From: Jann Horn Date: Fri, 2 Jul 2021 13:51:08 +0200 Message-ID: Subject: Re: [PATCH 2/4] arch/x86: implement the process_vm_exec syscall To: Andrei Vagin Cc: linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, linux-um@lists.infradead.org, criu@openvz.org, avagin@google.com, Andrew Morton , Andy Lutomirski , Anton Ivanov , Christian Brauner , Dmitry Safonov <0x7f454c46@gmail.com>, Ingo Molnar , Jeff Dike , Mike Rapoport , Michael Kerrisk , Oleg Nesterov , Peter Zijlstra , Richard Weinberger , Thomas Gleixner , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 2, 2021 at 8:25 AM Andrei Vagin wrote: > On Mon, Jun 28, 2021 at 06:13:29PM +0200, Jann Horn wrote: > > On Wed, Apr 14, 2021 at 7:59 AM Andrei Vagin wrote: > > > +static void swap_mm(struct mm_struct *prev_mm, struct mm_struct *target_mm) > > > +{ > > > + struct task_struct *tsk = current; > > > + struct mm_struct *active_mm; > > > + > > > + task_lock(tsk); > > > + /* Hold off tlb flush IPIs while switching mm's */ > > > + local_irq_disable(); > > > + > > > + sync_mm_rss(prev_mm); > > > + > > > + vmacache_flush(tsk); > > > + > > > + active_mm = tsk->active_mm; > > > + if (active_mm != target_mm) { > > > + mmgrab(target_mm); > > > + tsk->active_mm = target_mm; > > > + } > > > + tsk->mm = target_mm; > > > > I'm pretty sure you're not currently allowed to overwrite the ->mm > > pointer of a userspace thread. For example, zap_threads() assumes that > > all threads running under a process have the same ->mm. (And if you're > > fiddling with ->mm stuff, you should probably CC linux-mm@.) > > > > As far as I understand, only kthreads are allowed to do this (as > > implemented in kthread_use_mm()). > > kthread_use_mm() was renamed from use_mm in the v5.8 kernel. Before > that, it wasn't used for user processes in the kernel, but it was > exported for modules, and we used it without any visible problems. We > understood that there could be some issues like zap_threads and it was > one of reasons why we decided to introduce this system call. > > I understand that there are no places in the kernel where we change mm > of user threads back and forth, but are there any real concerns why we > should not do that? I agree that zap_threads should be fixed, but it > will the easy one. My point is that if you break a preexisting assumption like this, you'll have to go through the kernel and search for places that rely on this assumption, and fix them up, which may potentially require thinking about what kinds of semantics would actually be appropriate there. Like the MCE killing logic (collect_procs_anon() and such). And current_is_single_threaded(), in which the current patch probably leads to logic security bugs. And __uprobe_perf_filter(). Before my refactoring of the ELF coredump logic in kernel 5.10 (commit b2767d97f5ff75 and the ones before it), you'd have also probably created memory corruption bugs in races between elf_core_dump() and syscalls like mmap()/munmap(). (Note that this is not necessarily an exhaustive list.)