Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3678419yba; Sat, 11 May 2019 17:13:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqx7MCCkyc0I5Pt4SwPuzjP46QKZ1H7eOZHKmaIiJdl6b+y9WtxjtWKbkIRCohTEGkXqMuw5 X-Received: by 2002:a17:902:8ec8:: with SMTP id x8mr22440851plo.21.1557620033456; Sat, 11 May 2019 17:13:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557620033; cv=none; d=google.com; s=arc-20160816; b=w0ZZwjoYT5nDq/qYNthfMl3AgOu6z7T1idhQzFXX0vUGnf+lbfBaTlcDDvVxunBDI1 Zy78Ms9CQ3cvEVQGv3yu9YyG5DYdS14WwdjwcldpdvuOiOW87WIs7ehxL1gRyM5EasAa X2skLe6X/cQTCLMYUmsXYV+XIE8SQvKkpTwd0bCpE1uopu0v5r7FgwqI+VH0VX1QIvBc DKh6BzGrkevBsJZ0zh87uG8WUYZfGz7cqEz7OA0UftKpCUSaMOqbG1TjXVGOjNmhz89r /JTLeRGtDaK+mt++C4epgansIGptGxSJkGWofyPC2AVcukFrdMalPSLCeA7R2BltbWo3 B5mw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=Y8+fw8I1ApGmaw/OLwHaGigKZmnm+yTygMk8BjKay9A=; b=Fn1cRBas+Er/8C7MFwuUgsiiti9T8f73eesCnyiyMWB0tABqTKSCk31V4tLO0j9nJ5 B2+cXxcAydKwJs9l24BQx3yi8lbm91dLclgJGIlE2WKmYVQcjH95erlg9kKxMXqQapKT LxzVf3x/f8ZI7GGmoXIlz7jL14LDr/+5EVRElElbNmZ1GkQQupdVoGRI81f/4aDIBTp0 dDYo2UCX2yDJIPAg4i0JLoYzm6WgXW4rrN6hMsY5SbuEukhkfo/2hFNkjI4nHbxSmKZC UOc3Be8HNSRfLzM2jNS/2cm0nDbt0vqKljV9iZjxE7cfDWoJfP0GKrZ3Mr5aOyUuy2sy ZgWQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=haKSxF+A; 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=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z6si12711578pgp.35.2019.05.11.17.13.35; Sat, 11 May 2019 17:13:53 -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=@chromium.org header.s=google header.b=haKSxF+A; 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=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726348AbfELAMo (ORCPT + 99 others); Sat, 11 May 2019 20:12:44 -0400 Received: from mail-pf1-f193.google.com ([209.85.210.193]:35745 "EHLO mail-pf1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726121AbfELAMo (ORCPT ); Sat, 11 May 2019 20:12:44 -0400 Received: by mail-pf1-f193.google.com with SMTP id t87so5184485pfa.2 for ; Sat, 11 May 2019 17:12:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Y8+fw8I1ApGmaw/OLwHaGigKZmnm+yTygMk8BjKay9A=; b=haKSxF+A4OyWeeLByqdc0zPwZjI5znt+/ESISP8jr4aTkGwht+7Ppn9o26cZfioEFM ymmW0tJAxRCxtOALa86uVByBbkFtGRjOfHDptqEKgo0D6F4mU0+YA71cVU4tiwJIEq6z KHLXvfZaT3M1wOZrjxyuuT19hl1i745NYKDTI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Y8+fw8I1ApGmaw/OLwHaGigKZmnm+yTygMk8BjKay9A=; b=BzvLT4ddH84fGFJzq35sbKWcPuoNQSWgb1IJRqrLaE7XxoMjx3bpQbYrmnx9cbdbpC QookGyUj8b5FJ++JYwAiRGSBx6D1OzuZ/o1ouSTzGXmkvjMDSoyW+FVM3QT0wsCz/pwk 435nX9EQJB83o63uwUfr/A30kWLI1jHN4AKAKLyciuU9+n5HzTK6VBlAMRR3jWWq5ZGt Qe2A44l/nXQtJcxQJqzdW2VcNYRjqDchJFKmRZLYIZAbKtIM7grKyP535eRCK4X7Fsbg swy9MxI3mk/FZyhZO3rAJQhv9ssYjnXHwaPen2rGgiUPS1EJXT06gUUCUNCHo+55fqSZ 5o+Q== X-Gm-Message-State: APjAAAVdT42qBaqHguN8R2mgfeixReNL1w7rvGDpBrN3tawDLff8A3O8 Stpd4EJfrvRQ5Ao7i4xIqfjtyQ== X-Received: by 2002:a62:e101:: with SMTP id q1mr24929478pfh.160.1557619963312; Sat, 11 May 2019 17:12:43 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id y10sm9439481pff.4.2019.05.11.17.12.41 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 11 May 2019 17:12:42 -0700 (PDT) Date: Sat, 11 May 2019 17:12:41 -0700 From: Kees Cook To: Andy Lutomirski Cc: Ingo Molnar , "Reshetova, Elena" , David Laight , Theodore Ts'o , Eric Biggers , "ebiggers@google.com" , "herbert@gondor.apana.org.au" , Peter Zijlstra , 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: <201905111703.5998DF5F@keescook> References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, May 11, 2019 at 03:45:19PM -0700, Andy Lutomirski wrote: > ISTM maybe a better first step would be to make get_random_bytes() be > much faster? :) I'm not opposed to that, but I want to make sure we don't break it for "real" crypto uses... I still think just using something very simply like rdtsc would be good enough. This isn't meant to be a perfect defense: it's meant to disrupt the ability to trivially predict (usually another thread's) stack offset. And any sufficiently well-positioned local attacker can defeat this no matter what the entropy source, given how small the number of bits actually ends up being, assuming they can just keep launching whatever they're trying to attack. (They can just hold still and try the same offset until the randomness aligns: but that comes back to us also needing a brute-force exec deterance, which is a separate subject...) The entropy source bikeshedding doesn't seem helpful given how few bits we're dealing with. -- Kees Cook