Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp6624376yba; Wed, 1 May 2019 16:34:58 -0700 (PDT) X-Google-Smtp-Source: APXvYqz7M4Amca7uBrkFYr8Q5KnVrmLom4wOCBtfNvpMgUu2ODcg97i6qZS8y0R9V7JSwee25nGq X-Received: by 2002:a63:6103:: with SMTP id v3mr731492pgb.48.1556753698521; Wed, 01 May 2019 16:34:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556753698; cv=none; d=google.com; s=arc-20160816; b=pXKgmpZ5tQZZU7mPIyPAu1tM+LKLuSXdtihgr3eA6qE3O0BoSo/vVkeR6aZ+vfYUuK YR+1V7bGdcJZewoUFz/A9YFcyuQPp8yeh8DqMSr8XZVegyvpIaxn2bUEDu/3ZMnIRiiM x9vSZJd76UnNOv5tHMJhF9uPI4+pk607sGfiLbBXELQx96TJKXuou3lHtJZtWEWrhok7 /Yx0Fqnw7Yt0f9h96/EX99cqE5CzKR/MxOR9yQylnJbEZq77sancADYhtX2fv4y4l1+m MtHllQpTWDmT/i7lqcsUQexHT1nP3U4C+a5vvaoMDFxxpMuPS9HBF/9J+l80qRdP/Ikh 0+JQ== 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=0kFbzviDzeTu2wfqv2lTZzD4MWerHhsL6Uda5mpl1/Q=; b=HGvTdTuXV3g2pJdwqe/NsLQ3EgsBYFaS2TFwktI8S8dRLPNpoNxLVSCkUpEoqPSEoX Z0n6brR5UvaxqBLLkPgXIhP8tWQF+5PXkGzwVneEk0PPvlp2ilDVz4G/a/FRbn/NO+4S 9zarplAqwcgljBxzLXnQsipNTkRlxjzNKe8UHCR+ikQ7e/8RAM3IUhDfg4WaDn+1Hoyc /w+GyXKuEztBIxROij5UE0+FSXzs0XpulouRt35DvT7yTruN5HFuz4VttDRaNe0IFdtN /yChbgPkeZmxNcicyrYF1AZ2lWJsldpreWFn5x0Qkg1b0Kr4m8NhiBw8sy2JpK7N59uN BiHA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="u/0c+KuV"; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u79si43573560pfa.6.2019.05.01.16.34.41; Wed, 01 May 2019 16:34:58 -0700 (PDT) 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=@kernel.org header.s=default header.b="u/0c+KuV"; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726189AbfEAXdu (ORCPT + 99 others); Wed, 1 May 2019 19:33:50 -0400 Received: from mail.kernel.org ([198.145.29.99]:40606 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726126AbfEAXdu (ORCPT ); Wed, 1 May 2019 19:33:50 -0400 Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A2C1121783 for ; Wed, 1 May 2019 23:33:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1556753628; bh=UQ03RoUVgEqrh24m1ibWvm3BQ70ctrej1g8FlyRCbUQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=u/0c+KuVBUG5WeZTCWcOhcZoPGxsnZH1n8O333AVJBL1xvQaxjnzaAT1VFaLZIzmG ldgZ7PChxp8fVfst7G6uIsNSYIshYptv7boi+gwVtzkmo+fHmVb3rfaXbWOtKZqm2V I5BfoVcJt0/2MdXqc2QwtyaI7tOrHyjPUfZnhai8= Received: by mail-wr1-f50.google.com with SMTP id e9so653279wrc.1 for ; Wed, 01 May 2019 16:33:48 -0700 (PDT) X-Gm-Message-State: APjAAAWmZor7vBQoYbLs1OnqV3INj27MB2Hv6d8/IRJePSQBjw0V8Us+ KgYQQXPq+GeA/BSSaZMBhZm53QVIFAwuBHRCwpAUUg== X-Received: by 2002:a5d:4e82:: with SMTP id e2mr381220wru.199.1556753627151; Wed, 01 May 2019 16:33:47 -0700 (PDT) MIME-Version: 1.0 References: <2236FBA76BA1254E88B949DDB74E612BA4C51962@IRSMSX102.ger.corp.intel.com> <20190416120822.GV11158@hirez.programming.kicks-ass.net> <01914abbfc1a4053897d8d87a63e3411@AcuMS.aculab.com> <20190416154348.GB3004@mit.edu> <2236FBA76BA1254E88B949DDB74E612BA4C52338@IRSMSX102.ger.corp.intel.com> <9cf586757eb44f2c8f167abf078da921@AcuMS.aculab.com> <20190417151555.GG4686@mit.edu> <99e045427125403ba2b90c2707d74e02@AcuMS.aculab.com> <2236FBA76BA1254E88B949DDB74E612BA4C5E473@IRSMSX102.ger.corp.intel.com> <2236FBA76BA1254E88B949DDB74E612BA4C63E24@IRSMSX102.ger.corp.intel.com> <20190426140102.GA4922@mit.edu> <57357E35-3D9B-4CA7-BAB9-0BE89E0094D2@amacapital.net> <2236FBA76BA1254E88B949DDB74E612BA4C66A8A@IRSMSX102.ger.corp.intel.com> <6860856C-6A92-4569-9CD8-FF6C5C441F30@amacapital.net> <2236FBA76BA1254E88B949DDB74E612BA4C6A4D7@IRSMSX102.ger.corp.intel.com> <303fc4ee5ac04e4fac104df1188952e8@AcuMS.aculab.com> In-Reply-To: <303fc4ee5ac04e4fac104df1188952e8@AcuMS.aculab.com> From: Andy Lutomirski Date: Wed, 1 May 2019 16:33:35 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] x86/entry/64: randomize kernel stack offset upon syscall To: David Laight Cc: "Reshetova, Elena" , "Theodore Ts'o" , Eric Biggers , "ebiggers@google.com" , "herbert@gondor.apana.org.au" , Ingo Molnar , Peter Zijlstra , "keescook@chromium.org" , Daniel Borkmann , "luto@kernel.org" , "linux-kernel@vger.kernel.org" , "jpoimboe@redhat.com" , "jannh@google.com" , "Perla, Enrico" , "mingo@redhat.com" , "bp@alien8.de" , "tglx@linutronix.de" , "gregkh@linuxfoundation.org" , "Edgecombe, Rick P" 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 Wed, May 1, 2019 at 1:42 AM David Laight wrote: > > From: Reshetova, Elena > > Sent: 30 April 2019 18:51 > ... > > +unsigned char random_get_byte(void) > > +{ > > + struct rnd_buffer *buffer = &get_cpu_var(stack_rand_offset); > > + unsigned char res; > > + > > + if (buffer->byte_counter >= RANDOM_BUFFER_SIZE) { > > + get_random_bytes(&(buffer->buffer), sizeof(buffer->buffer)); > > + buffer->byte_counter = 0; > > + } > > + > > + res = buffer->buffer[buffer->byte_counter]; > > + buffer->buffer[buffer->byte_counter] = 0; > > If is really worth dirtying a cache line to zero data we've used? > The unused bytes following are much more interesting. > For this particular use case, zeroing is probably worthless. But, for the general case of get_random_bytes(), we need to zero, and I would argue that get_random_bytes() should be doing exactly this in general.