Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5013BC05027 for ; Fri, 3 Feb 2023 16:26:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232338AbjBCQ0A (ORCPT ); Fri, 3 Feb 2023 11:26:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48888 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232387AbjBCQZs (ORCPT ); Fri, 3 Feb 2023 11:25:48 -0500 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 17D9EA6B9F; Fri, 3 Feb 2023 08:25:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1675441547; x=1706977547; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=vIRC4xnaApbPW8RCCJgEQXnu08a0bMVna8tyTv2MRHQ=; b=Py+NP4thkZbXh0tNJQ//Ow9qleoK0j/YxWbpW8j2xGpVgbopq7rM2rAK +FNSk9Skj6EoxB9McbT+zPr/QFKbZ7gU5Au8ILGM6CWILsyeMOjyo1VYx DCl/A+N70aqmihKHc0x8FRglx23+6nxKGRE2LLUJQtE8ON8nd2e6G3hqy UGRBj1OvITlNz9h9Xn2TCSS0PbM69V8kA3fx5Dudp/paQvCPJBq3MxMO9 qnJwhPF9udfnkhrbvESp532Eze/IDWcgf1JTDa251U+RFMC9hnJW83jdQ a+RbOTsBirFH5kQOaOX1scYrQzCHehyEaWlRb7VGHep3T6lZIi/29Qiyy g==; X-IronPort-AV: E=McAfee;i="6500,9779,10610"; a="316783306" X-IronPort-AV: E=Sophos;i="5.97,270,1669104000"; d="scan'208";a="316783306" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Feb 2023 08:25:46 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10610"; a="911208619" X-IronPort-AV: E=Sophos;i="5.97,270,1669104000"; d="scan'208";a="911208619" Received: from hheck-mobl.amr.corp.intel.com (HELO [10.212.230.180]) ([10.212.230.180]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Feb 2023 08:25:45 -0800 Message-ID: <851920c5-31c9-ddd9-3e2d-57d379aa0671@intel.com> Date: Fri, 3 Feb 2023 08:25:44 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH] x86: enable Data Operand Independent Timing Mode Content-Language: en-US To: Eric Biggers Cc: Jann Horn , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H . Peter Anvin" , x86@kernel.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, Peter Zijlstra , Roxana Bradescu , Adam Langley , Ard Biesheuvel , "Jason A . Donenfeld" References: <20230125012801.362496-1-ebiggers@kernel.org> <14506678-918f-81e1-2c26-2b347ff50701@intel.com> <394c92e2-a9aa-37e1-7a34-d7569ac844fd@intel.com> <8b2771ce-9cfa-54cc-de6b-e80ce7af0a93@intel.com> <16e3217b-1561-51ea-7514-014e27240402@intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/1/23 10:09, Dave Hansen wrote: > Good questions. I want to make sure what I'm saying here is accurate, > and I don't have good answers to those right now. We're working on it, > and should have something useful to say in the next couple of days. This is an attempt to make sure that everyone that is concerned about DOITM behavior has all the same information as Intel folks before we make a decision about a kernel implementation. Here we go... The execution latency of the DOIT instructions[1] does not depend on the value of data operands on all currently-supported Intel processors. This includes all processors that enumerate DOITM support. There are no plans for any processors where this behavior would change, despite the DOITM architecture theoretically allowing it. So, what's the point of DOITM in the first place? Fixed execution latency does not mean that programs as a whole will have constant overall latency. DOITM currently affects features which do not affect execution latency but may, for instance, affect overall program latency due to side-effects of prefetching on the cache. Even with fixed instruction execution latency, these side-effects can matter especially to the paranoid. Today, those affected features are: * Data Dependent Prefetchers (DDP)[2] * Some Fast Store Forwarding Predictors (FSFP)[3]. There are existing controls for those features, including spec_store_bypass_disable=[4]. Some paranoid software may already have mitigations in place that are a superset of DOITM. In addition, both DDP and FSFP were also designed to limit nastiness when crossing privilege boundaries. Please see the linked docs for more details. That's basically the Intel side of things. Everyone else should have all the background that I have. Now back to maintainer mode... So, in short, I don't think everyone's crypto libraries are busted today when DOITM=0. I don't think they're going to _become_ busted any time soon. Where do we go from here? There are a few choices: 1. Apply the patch in this thread, set DOITM=1 always. Today, this reduces exposure to DDP and FSFP, but probably only for userspace. It reduces exposure to any future predictors under the DOITM umbrella and also from Intel changing its mind. 2. Ignore DOITM, leave it to the hardware default of DOITM=0. Today, this probably just steers folks to using relatively heavyweight mitigations (like SSBD) if they want DDP/FSFP disabled. It also leaves Linux exposed to Intel changing its mind on its future plans. 3. Apply the patch in this thread, but leave DOITM=0 as the default. This lets folks enable DOITM on a moment's notice if the need arises. There are some other crazier choices like adding ABI to toggle DOITM for userspace, but I'm not sure they're even worth discussing. #1 is obviously the only way to go if the DOITM architecture remains as-is. There is talk of making changes, like completely removing the idea of variable execution latency. But that's a slow process and would be a non-starter if *anyone* (like other OSes) is depending on the existing DOITM definition. My inclination is to wait a couple of weeks to see which way DOITM is headed and if the definition is likely to get changed. Does anyone feel any greater sense of urgency? 1. https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/resources/data-operand-independent-timing-instructions.html 2. https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/data-dependent-prefetcher.html 3. https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/fast-store-forwarding-predictor.html 4. https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html