Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp7425208yba; Thu, 2 May 2019 09:35:26 -0700 (PDT) X-Google-Smtp-Source: APXvYqzHHtOG3CMWkvasmRexeR69Zwc5VMocKC0jV9rb51Hugj5tfbjRf7+s1hRt9hjanZcmT8X9 X-Received: by 2002:a63:1462:: with SMTP id 34mr4879579pgu.155.1556814926064; Thu, 02 May 2019 09:35:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556814926; cv=none; d=google.com; s=arc-20160816; b=UG7ptIT2mVoZMMWFrECIAKJ/nu+qg3tNPqWT2sEVqrhb9y1hgPwlhYHh3tEsHbPuij 2jO2EpgUffYl0MTLzAT/7JlAIhebHIxhZUiN4mGy0KMaOFqo7oPuD1jCsMy9lEazP2zt GZw/0bpLAILdLgcEfaEb75z5Pab0fZlWOknfgsci3bdO/SIIWoZde9PLdgYrgyBu7q93 c44sY3QIQ5C441SAqBDLTWmfcAqYkUEIAnq4VzXnK95yUybs9Z/dsGnlNK7pwP8IYUJi pG0Pxc9YXwap4mJYF0AEDTCsBYrUr1EDBc1GQGt3ocWEt84r1OFhoc93wiGriXYjQI/O 2gSA== 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=kiwC39FwteXE7me83RT2323KTerqqe1luF+aFbF9+RM=; b=O4OtenZeIiSCF03AFogZDzGIELQjXtXjPb8tXpEo6Liz55DTaji1ssRakY3sJA0aip 13CwiTnzmACwGs3dsoa1cdxkzSCDaSpsvzH3l2iNUhmqfgMG5UzV82h9Hnwk9BHELCzx OcAdXc5Ne3Gl9qq/ArJrKoOcaEjSs76RsgR6DoZ1WqsvebTSYlxiBeT9r9d1UyoBnVbj z9W4Z9K/GUY8UrDGaGVO8/hteyA62zYXShTWQxdmKAlzMykdOGgs9ApkXN1mgPEfkWiu zsb6kUddhoLgL2FPgXb06np03J8NNibeNYmbJ9pvfIb5XLWe5dzlbHc1jP0PdTrkEa5M gGGw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=TWKFY4hG; 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 b63si6181082plb.146.2019.05.02.09.35.10; Thu, 02 May 2019 09:35:26 -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=TWKFY4hG; 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 S1726664AbfEBQcw (ORCPT + 99 others); Thu, 2 May 2019 12:32:52 -0400 Received: from mail.kernel.org ([198.145.29.99]:54292 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726300AbfEBQcv (ORCPT ); Thu, 2 May 2019 12:32:51 -0400 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (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 1EE40217D7 for ; Thu, 2 May 2019 16:32:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1556814770; bh=McrNd6tEs6nZVZHZJyUQ93Q3IzXi+DcF9byW0dFV23Q=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=TWKFY4hGY9y3ZYl2DSaHLJTt/+JyEyAs0Lero670lxqNEbI6IKErvi+lHR7HU9CNz MZ27AOQPjy40S1ebGWgqL2/vxA5Y1SBgSFE+FtP/ofczkC17LnbXC3oEpaO2fZh3hV fRABWvih5quF6vjzL0jRnEsXy2YEYlKuy4/KxYdI= Received: by mail-wm1-f42.google.com with SMTP id y197so3470483wmd.0 for ; Thu, 02 May 2019 09:32:50 -0700 (PDT) X-Gm-Message-State: APjAAAUO4JKynpwRS/vOIQhSyPBkJFSPlIgEFkb7igu1gu3h4YaJrIRl 6Jlksui2qo9nJBEDPwy7k4q2q4FZj+Q+sQTU8oLIdg== X-Received: by 2002:a1c:9689:: with SMTP id y131mr3220276wmd.74.1556814768564; Thu, 02 May 2019 09:32:48 -0700 (PDT) MIME-Version: 1.0 References: <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> <2236FBA76BA1254E88B949DDB74E612BA4C6C2C3@IRSMSX102.ger.corp.intel.com> <2e55aeb3b39440c0bebf47f0f9522dd8@AcuMS.aculab.com> <20190502150853.GA16779@gmail.com> In-Reply-To: <20190502150853.GA16779@gmail.com> From: Andy Lutomirski Date: Thu, 2 May 2019 09:32:35 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] x86/entry/64: randomize kernel stack offset upon syscall To: Ingo Molnar Cc: Andy Lutomirski , David Laight , "Reshetova, Elena" , "Theodore Ts'o" , Eric Biggers , "ebiggers@google.com" , "herbert@gondor.apana.org.au" , Peter Zijlstra , "keescook@chromium.org" , Daniel Borkmann , "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" , Linus Torvalds , Peter Zijlstra 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, May 2, 2019 at 8:09 AM Ingo Molnar wrote: > > > * Andy Lutomirski wrote: > > > Or we decide that calling get_random_bytes() is okay with IRQs off and > > this all gets a bit simpler. > > BTW., before we go down this path any further, is the plan to bind this > feature to a real CPU-RNG capability, i.e. to the RDRAND instruction, > which excludes a significant group of x86 of CPUs? It's kind of the opposite. Elena benchmarked it, and RDRAND's performance was truly awful here. > > Because calling tens of millions of system calls per second will deplete > any non-CPU-RNG sources of entropy and will also starve all other users > of random numbers, which might have a more legitimate need for > randomness, such as the networking stack ... There's no such thing as "starving" other users in this context. The current core RNG code uses a cryptographic RNG that has no limits on the number of bytes extracted. If you want the entropy-accounted stuff, you can use /dev/random, which is separate. > 8 gigabits/sec sounds good throughput in principle, if there's no > scalability pathologies with that. The latency is horrible. > > It would also be nice to know whether RDRAND does buffering *internally*, Not in a useful way :( > Any non-CPU source of randomness for system calls and plans to add > several extra function calls to every x86 system call is crazy talk I > believe... I think that, in practice, the only real downside to enabling this thing will be the jitter in syscall times. Although we could decide that the benefit is a bit dubious and the whole thing isn't worth it. But it will definitely be optional.