Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3628826yba; Sat, 11 May 2019 15:46:41 -0700 (PDT) X-Google-Smtp-Source: APXvYqwrHAOCh5bdJfIeNGphXlJfgJkjs5J+FlOWegaMWoR79NSsHHylst00JqdXYUnoU57DPwec X-Received: by 2002:a63:7d09:: with SMTP id y9mr3103978pgc.350.1557614801160; Sat, 11 May 2019 15:46:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557614801; cv=none; d=google.com; s=arc-20160816; b=f/SJrsSmH/Xes1dM9eMhx2YAXMumk0tqnJnXLC3mhgLa7VoHE2yJ/AgURPhMWG0zv4 YusWq/dnFhmsiQ5InvKovlCpNf81CqCZT9BKrpUUJ8VAnBK4XaagqmmETdgcCiBtkTjS Zg9ThbUk1a0DZk3Iswtjaiq1S1+8oyLUs9OlDfjsWrnGna0uGHfylz+ghmslXHOy8XSJ 5HsMXUy4+NLolXcfLfBV8NYWGF1UmiWpYnAODATDDWcroj9lzw/q8jSqg52RabdhRf6z 7aiHPKy7nzKEl1AmSyJzLy3l8GYsSUTaZP1bTCjimgUZniIiWlnnd4ThEqlXkSj/BHK2 oVDg== 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=j5Kq1wmV0e3QZ7WAehUGWtMqpUFvp6XaSKwsh6VOCjg=; b=FWsnJSSzUq2wTvZLfPxSxCp44325TgUV3/DvvPkWLU4+K20WC0yJ8z9ruxX9YXt8AE VYOz0cf932/4k6XaLROk98HtBVqlxBAyVNZsD4u/nsY3G6YYKs46i7aSIK5fGGyF00DV T0ci90d7TPQoYbkmINkC4eTViKsMr7MXv6vGktEDmhAnig365Lcp0ULfeWdSxISPzLiJ oK5Db2wQJqhC8IAgzmc/4qegc1oIDEBoNr3YwD3zB2w+O8rW8+I5xc/fOizh9xsr6tXO nkhuzR5wTIfLZRDcbRUhehZWJkz0sWn+ixQIwtoThyt6KdztxoZn5aEC9JLJBPT6f8R+ EXrQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=SakiPGZt; 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 p13si766024pfq.57.2019.05.11.15.46.25; Sat, 11 May 2019 15:46:41 -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=SakiPGZt; 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 S1726425AbfEKWpf (ORCPT + 99 others); Sat, 11 May 2019 18:45:35 -0400 Received: from mail.kernel.org ([198.145.29.99]:35680 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726033AbfEKWpf (ORCPT ); Sat, 11 May 2019 18:45:35 -0400 Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) (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 E4F5021871 for ; Sat, 11 May 2019 22:45:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1557614734; bh=j5Kq1wmV0e3QZ7WAehUGWtMqpUFvp6XaSKwsh6VOCjg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=SakiPGZtPWXJrGkvIOjG/+dAQZv0SyWGj/x7tPcqMxGlssIjAcpTsj2sJJU0QC+yG s0Bu4kaLFHLR+6dLkQjZl7c3I7tbmfKN1DDplJLW2TtD4FRx+NwqKSDiuYcE/PA3Mp 0uhMjWGct/8pSWTU7eOWf3DT/HziOO/3RbwcwzY8= Received: by mail-wr1-f48.google.com with SMTP id h4so11332044wre.7 for ; Sat, 11 May 2019 15:45:33 -0700 (PDT) X-Gm-Message-State: APjAAAXiwt8pCvYvKWzpJ5mGy5v25q2isswOCsIKDEjhHJEr1wsQQy8N YM46CtisLjduF+R4kmeOoDY+HRifUxROlrvlFyo1Yg== X-Received: by 2002:adf:ef8f:: with SMTP id d15mr12879839wro.330.1557614732557; Sat, 11 May 2019 15:45:32 -0700 (PDT) MIME-Version: 1.0 References: <20190502150853.GA16779@gmail.com> <20190502164524.GB115950@gmail.com> <2236FBA76BA1254E88B949DDB74E612BA4C6F523@IRSMSX102.ger.corp.intel.com> <2236FBA76BA1254E88B949DDB74E612BA4C760A7@IRSMSX102.ger.corp.intel.com> <20190508113239.GA33324@gmail.com> <2236FBA76BA1254E88B949DDB74E612BA4C762F7@IRSMSX102.ger.corp.intel.com> <20190509055915.GA58462@gmail.com> <2236FBA76BA1254E88B949DDB74E612BA4C7741F@IRSMSX102.ger.corp.intel.com> <20190509084352.GA96236@gmail.com> In-Reply-To: <20190509084352.GA96236@gmail.com> From: Andy Lutomirski Date: Sat, 11 May 2019 15:45:19 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] x86/entry/64: randomize kernel stack offset upon syscall To: Ingo Molnar Cc: "Reshetova, Elena" , David Laight , Andy Lutomirski , "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 9, 2019 at 1:43 AM Ingo Molnar wrote: > > > * Reshetova, Elena wrote: > > > > I find it ridiculous that even with 4K blocked get_random_bytes(), > > > which gives us 32k bits, which with 5 bits should amortize the RNG > > > call to something like "once per 6553 calls", we still see 17% > > > overhead? It's either a measurement artifact, or something doesn't > > > compute. > > > > If you check what happens underneath of get_random_bytes(), there is a > > fair amount of stuff that is going on, including reseeding CRNG if > > reseeding interval has passed (see _extract_crng()). It also even > > attempts to stir in more entropy from rdrand if avalaible: > > > > I will look into this whole construction slowly now to investigate. I > > did't optimize anything yet also (I take 8 bits at the time for > > offset), but these small optimization won't make performance impact > > from 17% --> 2%, so pointless for now, need a more radical shift. > > So assuming that the 17% overhead primarily comes from get_random_bytes() > (does it? I don't know), that's incredibly slow for something like the > system call entry path, even if it's batched. > ISTM maybe a better first step would be to make get_random_bytes() be much faster? :) --Andy