From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 04871C2D0F4 for ; Thu, 2 Apr 2020 01:36:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CFFD920721 for ; Thu, 2 Apr 2020 01:36:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Iy/+QP+K" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733094AbgDBBgO (ORCPT ); Wed, 1 Apr 2020 21:36:14 -0400 Received: from mail-lf1-f65.google.com ([209.85.167.65]:36269 "EHLO mail-lf1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726319AbgDBBgN (ORCPT ); Wed, 1 Apr 2020 21:36:13 -0400 Received: by mail-lf1-f65.google.com with SMTP id w145so1385174lff.3 for ; Wed, 01 Apr 2020 18:36:12 -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=p4NjOGhfdlS01zHiaiGfeK4n/oNGr20mOQ6J0VtQZkU=; b=Iy/+QP+K5SVCnjZXEYKbe6gJZoALpPVWnCdKolTHVAcRIpAX95p8NjKGPKSonJCPQl f++BgT7PPp9l1iSRQ0/AkB8k2GJ9laThTMzZvs8e1TP/X1f6WX5Cn8xFtFCbwwx3rX8n RnnPYSdakwGWTapISLCz8yL9IB8meP8yGhRhNjjZEBk8dsZU1QIY+BK0XB9LSfeKWt0W o/ZyWF5EEO830dCD5ifrmYe5HtawBOZlRnV6pZmMlt43dZFsqqFubXhVRsFGQQ1NPDqe N9jUDMHkwlob6QtCmqRhRNG5E0keVN4DvKm0VvPZiQO901MdnKX/cFt9MAbYIYKiTjz2 h+Gw== 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=p4NjOGhfdlS01zHiaiGfeK4n/oNGr20mOQ6J0VtQZkU=; b=OlbyFIXT8Hjr0XGhBzYiaP/zAUh0IBQJZEUAG/YIh13Oi/MDYh9XFW8+vMcmJxOUAS qKgw7ihD5xWamudroldgO785bpBdUMLH9NuZbKILcsS4x1n1OqzGDvTfkMQELDMAEFHm pxKswVZg4ATdMF44Hc/CW5Sn+QNttHTPDgLP3sD7kXTvMQws8ljr5czT9NPH/t31PMol UkdUNAMAUf6BWU0/NTjHP5FixFu/hE9blSe5JNQE5yqxPEuFrIWp6/afmJ8pNkBQv/AH 9z8rSF0NKvvhnnuMH+iQ+/7VTxPzbBf4dVN+99DNPN69tptgl8M9ULKdLQtH+VC9qHf1 XT8w== X-Gm-Message-State: AGi0PubVE2XhDHP608fuP+6BAiRxOJUxV25CVvQiEK7+DC0yHpJZC3fw j68OUDE8KQk1qGhaRFKYF6QTxSq2FBnpTzTayoNwGg== X-Google-Smtp-Source: APiQypJ85uH6hjieFIQ+DVaZ/3dHevVDests4L8XYzQdjxgBwQoqkLkbfa12keCBxd4QZw2RSaoFcAay8z6J77nuKhw= X-Received: by 2002:a05:6512:3127:: with SMTP id p7mr583281lfd.108.1585791371001; Wed, 01 Apr 2020 18:36:11 -0700 (PDT) MIME-Version: 1.0 References: <20200324215049.GA3710@pi3.com.pl> <202003291528.730A329@keescook> <87zhbvlyq7.fsf_-_@x220.int.ebiederm.org> In-Reply-To: From: Jann Horn Date: Thu, 2 Apr 2020 03:35:44 +0200 Message-ID: Subject: Re: [PATCH] signal: Extend exec_id to 64bits To: Linus Torvalds Cc: "Eric W. Biederman" , Alan Stern , Andrea Parri , Will Deacon , Peter Zijlstra , Boqun Feng , Nicholas Piggin , David Howells , Jade Alglave , Luc Maranget , "Paul E. McKenney" , Akira Yokosawa , Daniel Lustig , Adam Zabrocki , kernel list , Kernel Hardening , Oleg Nesterov , Andy Lutomirski , Bernd Edlinger , Kees Cook , Andrew Morton , stable , Marco Elver , Dmitry Vyukov , kasan-dev Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 2, 2020 at 1:55 AM Linus Torvalds wrote: > On Wed, Apr 1, 2020 at 4:51 PM Linus Torvalds > wrote: > > > > It's literally testing a sequence counter for equality. If you get > > tearing in the high bits on the write (or the read), you'd still need > > to have the low bits turn around 4G times to get a matching value. > > Put another way: first you'd have to work however many weeks to do 4 > billion execve() calls, and then you need to hit basically a > single-instruction race to take advantage of it. > > Good luck with that. If you have that kind of God-like capability, > whoever you're attacking stands no chance in the first place. I'm not really worried about someone being able to hit this in practice, especially given that the only thing it lets you do is send signals; I just think that the code is wrong in principle, and that we should avoid having "technically wrong, but works in practice" code in the kernel. This kind of intentional race might also trip up testing tools like the upcoming KCSAN instrumentation, unless it is specifically annotated as an intentionally racing instruction. (For now, KCSAN is 64-bit only, so it won't actually be able to detect this though; and the current KCSAN development branch actually incorrectly considers WRITE_ONCE() to always be atomic; but still, in principle it's the kind of issue KCSAN is supposed to detect, I think.) But even without KCSAN, if we have tearing stores racing with loads, I think that we ought to *at least* have a comment noting that we're intentionally doing that so that people don't copy this kind of code to a place where the high bits change more frequently and correctness matters more. Since the read is already protected by the tasklist_lock, an alternative might be to let the execve path also take that lock to protect the sequence number update, given that execve is not a particularly hot path. Or we could hand-code the equality check and increment operations to be properly race-free.