Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp2523341ybf; Mon, 2 Mar 2020 10:18:40 -0800 (PST) X-Google-Smtp-Source: ADFU+vtG2P/MJektUs3cr+jl08n6qF9Y4ygWHVSZru8cPuXiRZQZeGBc4bE9zaAWFVFLdKIQo0Ca X-Received: by 2002:a05:6830:1385:: with SMTP id d5mr367141otq.61.1583173119858; Mon, 02 Mar 2020 10:18:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583173119; cv=none; d=google.com; s=arc-20160816; b=QtV5H3M8lDDopb6CChfcvHznKYBJ9f4Ppn+fOkZt+mxOAMNOY3QkcfkeaQ6iyRHjux AB3dUCyU/BtvWGYR6Ejy45O3hcN68NupB4/3LinCreu2AVH9IUFwaurS2m3JhYSUV0d3 nI6SBAHP4J9aH3QE9sIhCmy3gekBHU1tDHXi7OK6fgs//CTJ71YZ1sCrja4GkdDarUFd Lq/vi4fEGN2Cp7YeGhayariP5JVfbJmjc8yXG/feddaLpqnDcNz2yfK4czPNXvtbmtn3 MCEV1EPcB+91G6vRzHRg+mxn+lg7ZjIVi3HZJIPKes/pRCLfTj1eaGAOkAXVrZyZmoVJ HQIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=dkIKEunspbm7vvq6Vi7LSmhvIa5CNrgbE4fc3Br8gcw=; b=q15Tr1rmZOVADOhtWUXDsB4FZxISMFvVFCZAc0wLroK1BAcR79EeNodXxTUWkYk7Yf fI1BUe5BrASxbNA1Tcak5TqtjKox10OMfD/voNNfJiVwk/TcXhR9gN6kSH/0f+nXjNoY LvZhw+/CEeSfAcfScV5Sra9AuDWmxABAFEHgUdbe+ug8YnAC/PO4ABY8klXg3kSMHNGK zZxUzMFaQjhNJKdFNElfGdNhmN81vsNJKuouEtxfjZ8oWVzgdJLUnQl01OAl5oU+w1FT ntRm3EJxeIHlbwst+IjFum3YTGQoMbIysFG3YU/dSLDeZEKDggDt2AqbsVZM71DAiDbD vQ9g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="h9/BYT0V"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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. [209.132.180.67]) by mx.google.com with ESMTP id w22si5329471otl.29.2020.03.02.10.18.26; Mon, 02 Mar 2020 10:18:39 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="h9/BYT0V"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 S1727314AbgCBSRR (ORCPT + 99 others); Mon, 2 Mar 2020 13:17:17 -0500 Received: from mail-wm1-f68.google.com ([209.85.128.68]:50508 "EHLO mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726451AbgCBSRR (ORCPT ); Mon, 2 Mar 2020 13:17:17 -0500 Received: by mail-wm1-f68.google.com with SMTP id a5so97497wmb.0 for ; Mon, 02 Mar 2020 10:17:16 -0800 (PST) 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=dkIKEunspbm7vvq6Vi7LSmhvIa5CNrgbE4fc3Br8gcw=; b=h9/BYT0VV2933Zm22oDgQkHPwM72o7HYQz9S7NzgkkgRrea96GrmK83XN6Dos7mqKs z4GsyLPp8KOMpPr6Qp7h0GIQUDd/oE7wFSAu3cZTEY1S/wneOyE1xhZZBGFe0IGKk0Ts qtwVg0tg/yQp8T9kt88RWKiynfu8Fmp9+rAZnaRihMEzD/ult8LcDzHiVjvkYYaTjTC3 ZveMnddiHf7gGU9/jMOSKKManlXqEBYg1zO4ylD2sjOSUYsnkjiL6U79qox495/8jEvB aWAR/SBOK2sWQCLb8/6GdrKTuP7OUdoQUkbh6enUFhDMXtSbaiaVZozLzSlJlqFUFFUr wPAQ== 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=dkIKEunspbm7vvq6Vi7LSmhvIa5CNrgbE4fc3Br8gcw=; b=FLU2yhrY8WIffRhDPFmH5XInUyKyQKv/cPwXGB8RgdPUeFhhWvwjkYt+lt3ZvUHPSD K+MOLxzOmXICRKNOTZ+DHfJ9qJ6aD/VpT8n6weVzsgu9mftBCfr1IRnhigMRJNzHQKfD mdYZ7nvTn5Sio2539tJ/lD8j9aFR6MtgwH2Ry4S6syocLQOWJA0TkmAXt4BTRvenBY0d d2vDzE1MDI0ziP7gnI4XWr1ZcUzWAheaOLiDW+Mcq9sAHbJX7KRNire6EMteNr0cbJly A8KDnNo0DMJbTT5nNIQzRD5aY3/M6ciA7mPirYnGs7RQzberKbhjiKALHgvmFlWTukmM hPhw== X-Gm-Message-State: ANhLgQ1Lvk+pyDHoxEcCPe1TP7WOlVZauwihGwIOpd7xq0mTYxt1L6N6 5YLfw1ojdmPjcmWT/A1Z53rdLTPbOqJeBKCTbdQnJg== X-Received: by 2002:a1c:e0d6:: with SMTP id x205mr122589wmg.29.1583173035221; Mon, 02 Mar 2020 10:17:15 -0800 (PST) MIME-Version: 1.0 References: <20200302130430.201037-1-glider@google.com> <20200302130430.201037-2-glider@google.com> <0eaac427354844a4fcfb0d9843cf3024c6af21df.camel@perches.com> <4cac10d3e2c03e4f21f1104405a0a62a853efb4e.camel@perches.com> In-Reply-To: <4cac10d3e2c03e4f21f1104405a0a62a853efb4e.camel@perches.com> From: Alexander Potapenko Date: Mon, 2 Mar 2020 19:17:02 +0100 Message-ID: Subject: Re: [PATCH v2 2/3] binder: do not initialize locals passed to copy_from_user() To: Joe Perches Cc: Todd Kjos , Kees Cook , Greg Kroah-Hartman , =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= , Ingo Molnar , Dmitriy Vyukov , Jann Horn , "open list:ANDROID DRIVERS" , Peter Zijlstra , LKML 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 Mon, Mar 2, 2020 at 3:00 PM Joe Perches wrote: > > On Mon, 2020-03-02 at 14:25 +0100, Alexander Potapenko wrote: > > On Mon, Mar 2, 2020 at 2:11 PM Joe Perches wrote: > > > On Mon, 2020-03-02 at 14:04 +0100, glider@google.com wrote: > > > > Certain copy_from_user() invocations in binder.c are known to > > > > unconditionally initialize locals before their first use, like e.g. in > > > > the following case: > > > [] > > > > diff --git a/drivers/android/binder.c b/drivers/android/binder.c > > > [] > > > > @@ -3788,7 +3788,7 @@ static int binder_thread_write(struct binder_proc *proc, > > > > > > > > case BC_TRANSACTION_SG: > > > > case BC_REPLY_SG: { > > > > - struct binder_transaction_data_sg tr; > > > > + struct binder_transaction_data_sg tr __no_initialize; > > > > > > > > if (copy_from_user(&tr, ptr, sizeof(tr))) > > > > > > I fail to see any value in marking tr with __no_initialize > > > when it's immediately written to by copy_from_user. > > > > This is being done exactly because it's immediately written to by copy_to_user() > > Clang is currently unable to figure out that copy_to_user() initializes memory. > > So building the kernel with CONFIG_INIT_STACK_ALL=y basically leads to > > the following code: > > > > struct binder_transaction_data_sg tr; > > memset(&tr, 0xAA, sizeof(tr)); > > if (copy_from_user(&tr, ptr, sizeof(tr))) {...} > > > > This unnecessarily slows the code down, so we add __no_initialize to > > prevent the compiler from emitting the redundant initialization. > > So? CONFIG_INIT_STACK_ALL by design slows down code. Correct. > This marking would likely need to be done for nearly all > 3000+ copy_from_user entries. Unfortunately, yes. I was just hoping to do so for a handful of hot cases that we encounter, but in the long-term a compiler solution must supersede them. > Why not try to get something done on the compiler side > to mark the function itself rather than the uses? This is being worked on in the meantime as well (see http://lists.llvm.org/pipermail/cfe-dev/2020-February/064633.html) Do you have any particular requisitions about how this should look on the source level?