Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp7433775yba; Thu, 2 May 2019 09:44:42 -0700 (PDT) X-Google-Smtp-Source: APXvYqyc9EqG0tSaJ3Ou2KN4GI0zLlIS9eWG54Gvi8S6zaG0PgWq5/QT+okw2k3icNTSZHw97vnC X-Received: by 2002:a65:408b:: with SMTP id t11mr4985920pgp.372.1556815482803; Thu, 02 May 2019 09:44:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556815482; cv=none; d=google.com; s=arc-20160816; b=q9CKtT+p5gPF2GBSYqx9huQRhwx7wHEibk+6PylsWhB3zSMkPRFDzM/mssiVb4/rc8 YBWR0aXwIO2PLbPAe6g+xI8xPUMTdO8OogSHViSf7x4WWt35jYn3NJSoooaMDfV3HQDC WmzDGBvWty+kSfeFutbMLdIPnGd2GrUOIungwLQVN1eMM3q/ZdOzporfIW4SOxgu+9xo tJArBqXML9dBh2fifBkRUnrY8bIcX9FLmbMWoCNLGPi0lqGwitz4kvXlBT1qMKTZD47q 8T1RZfV2NSPQVbq6fsHWVN3nDXifKX63AYAGnTpb0cNh1fbXFb0tMo5+pis2jwfujoKz 5RGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=SgRxXaRaZ7SS6NKygq+lIA0qjuJOX/iaVYfC9TFkYh4=; b=OSTdTyIDyl0ESe6RUBRi37JYt1eWX9/R3gyNDT/4ndJCpS5yMKQ0ovosY3SRTX0Wk0 +y8Ydzv5QA28zLNuD8UQfQLLrMqUfFHXbAY01Ryp7IYzGCwbQ4YCBEz7sKAFcrF8LWH6 AHRv9eTuPBeI2u8lJASYQE8u6+q0HCM82OHKiUkU8OGkTdoUrrIfCQEkfpFgU9crEdND sEnAtNJnz91Ebcw/CbJtUAFPJhplpY+taNW3wVgXkLVQRShiq1xwB/fvOqsDjRezKMGP /0dnLfkHTYGC5zI52sSmkU4YNf0PNY5f84sYsu9hkjav/uC3uR7fY4MYCN92H44160nA Dh3w== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=iRI9fosK; 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=fail (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 k13si16699655pfa.289.2019.05.02.09.44.27; Thu, 02 May 2019 09:44:42 -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=fail header.i=@gmail.com header.s=20161025 header.b=iRI9fosK; 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=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726514AbfEBQnb (ORCPT + 99 others); Thu, 2 May 2019 12:43:31 -0400 Received: from mail-wr1-f65.google.com ([209.85.221.65]:38655 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726203AbfEBQnb (ORCPT ); Thu, 2 May 2019 12:43:31 -0400 Received: by mail-wr1-f65.google.com with SMTP id k16so4305694wrn.5 for ; Thu, 02 May 2019 09:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=SgRxXaRaZ7SS6NKygq+lIA0qjuJOX/iaVYfC9TFkYh4=; b=iRI9fosK7/vQzOX2YILGZPZbqFlSYGLXN3m3zv10cxaT47ebsjCOg6Sbb2SLSNyeJV Thntxx6lkLkECavJfhkQYJE9sSDk7Mv5qge8l+xKquEolbu1CPLaBx6TA5WLCad+4iTF ARNXgEsXn273nOa5XnYl6wxc/mJKGhAdj/YG3Q6qunwMQsZm+Ud161MYLjwIlHCf+DAM rYww7QiWbT31NSBK3IvGACptfEtYPz4L6cJZ+dirCa8TiQCL1+140DwGb43oQ4axnIcI c46N7T9EJf6s/oFTh0NWHHnJvLlMeIYvWuLmnjc0odr6YMn9E3QpHw/B4FF41YVjG+fB A7/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=SgRxXaRaZ7SS6NKygq+lIA0qjuJOX/iaVYfC9TFkYh4=; b=KrAYowX/c6gnMxdNPV9VJZGJG/gT14zQnMmg7hX/EVBG0g2tSC1w14nfo6QkQ54Vo2 C/NOW+SSBd3uhDKybpmb9EZ1/48ipGpC22gF7okaTe0Lf3EouRvz9vOXp3wI+2HRDDMP pA0AJCp9KhPdQtx9r+Y1RX2gZhKySk/vFQl4kWOWLQIKd/tTKr5Bnj6cGx9DL97BysWy k0tO6U3Wlx73EqzqIkPQhh/Qd2sBprH//TSzIoJoRsUtSttOUN60cA/RJ2hKRpfnEQQj cdfHwdvpbWkcfrHUyBT1fjzx+XYSGFq7DxooT9wE41f16I+RH4xq1Kt2RlGmWBNcpe0/ /Juw== X-Gm-Message-State: APjAAAUvodQXlF3aFHyglpMzGvrR+S9bInGTSCri9UMP0E6nBhg02t0j rAZj8Tga3n/kM1oYp9COLJY= X-Received: by 2002:adf:f88f:: with SMTP id u15mr3471762wrp.155.1556815409231; Thu, 02 May 2019 09:43:29 -0700 (PDT) Received: from gmail.com (2E8B0CD5.catv.pool.telekom.hu. [46.139.12.213]) by smtp.gmail.com with ESMTPSA id c18sm25658390wrb.16.2019.05.02.09.43.27 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 02 May 2019 09:43:28 -0700 (PDT) Date: Thu, 2 May 2019 18:43:25 +0200 From: Ingo Molnar To: Andy Lutomirski Cc: 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 Subject: Re: [PATCH] x86/entry/64: randomize kernel stack offset upon syscall Message-ID: <20190502164325.GA115950@gmail.com> References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Andy Lutomirski wrote: > > 8 gigabits/sec sounds good throughput in principle, if there's no > > scalability pathologies with that. > > The latency is horrible. Latency would be amortized via batching anyway, so 8 gigabits/sec suggests something on the order of magnitude of 4 bits per cycle, right? With 64 bits extraction at a time that would be 16 cycles per 64-bit word, which isn't too bad, is it? But you are right that get_random_bytes() is probably faster, and also more generic. > > It would also be nice to know whether RDRAND does buffering > > *internally*, > > Not in a useful way :( Too bad ... > > 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. Making it "optional" is not really a technical argument in any way though, either distros enable it in which case it's a de-facto default setting, or they don't, in which case it de-facto almost doesn't exist. Thanks, Ingo