From mboxrd@z Thu Jan 1 00:00:00 1970 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 5EE9FEB64D8 for ; Wed, 21 Jun 2023 18:37:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230334AbjFUShD (ORCPT ); Wed, 21 Jun 2023 14:37:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59940 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229852AbjFUSg7 (ORCPT ); Wed, 21 Jun 2023 14:36:59 -0400 Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B406410A for ; Wed, 21 Jun 2023 11:36:57 -0700 (PDT) Received: by mail-lf1-f42.google.com with SMTP id 2adb3069b0e04-4f87592ecaeso4942963e87.0 for ; Wed, 21 Jun 2023 11:36:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687372616; x=1689964616; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=a74KK9B3kOJ1bdQv09F1RuG2I+RUQYHb83xPvRjEsmI=; b=i+Zkrk4T1FXFP00P7dc5bUrBO9YvPIwMk8JYGA7F87ZxraaARTB0H8SykBGzY58zVQ p1cl7UhhGM9nlEYkQIqfEvf15aUQOmCJdURn+K2ZdaXVPll5b+F93f/6QjOCJuoFo/BQ zWMctqNaGRhxomy5yk5RzbKJJE9derc/kiTwBfymdLXsxyV46tFMfKHzHOmSQoo4aa3Z Xf/iFiAjM2KkPY3mQ5mbc8jJC1lZ2vDlqi646p7hGpI1JWp5x3/bFP9pOchaRRERnfAe dOZETs6AOEducKtTgX/LCvwOmHE4US4rwx/xW/fKFVOIAFSTIL+hop1owzsVYeciKaHP 0Jfw== X-Gm-Message-State: AC+VfDw77IL2HAw7My4oXb+kU1JyXF7dA6bVYDpq2Wgujb1pURToC+0l AtvavJEGYVrvxHIg/LR412Y= X-Google-Smtp-Source: ACHHUZ5DDD0SzUrhoGXAR4gTtOCW/ZxlMtZE1wbMTz82ecYfHsPsLwBBPjiVs3jtJIo3LsB1zP7zwg== X-Received: by 2002:a05:6512:54a:b0:4f4:cacb:4b4b with SMTP id h10-20020a056512054a00b004f4cacb4b4bmr10070190lfl.18.1687372615691; Wed, 21 Jun 2023 11:36:55 -0700 (PDT) Received: from gmail.com (fwdproxy-cln-022.fbsv.net. [2a03:2880:31ff:16::face:b00c]) by smtp.gmail.com with ESMTPSA id i8-20020a05600011c800b00311339f5b06sm5068900wrx.57.2023.06.21.11.36.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Jun 2023 11:36:55 -0700 (PDT) Date: Wed, 21 Jun 2023 11:36:53 -0700 From: Breno Leitao To: Pawan Gupta Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Peter Zijlstra , Josh Poimboeuf , leit@fb.com, "open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" Subject: Re: [PATCH v2] x86/bugs: Break down mitigations configurations Message-ID: References: <20230616164851.2559415-1-leitao@debian.org> <20230621001327.qdyebewnx7r5aiy3@desk> <20230621173135.wiprtgzslhw5z5or@desk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230621173135.wiprtgzslhw5z5or@desk> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 21, 2023 at 10:31:35AM -0700, Pawan Gupta wrote: > On Wed, Jun 21, 2023 at 08:54:17AM -0700, Breno Leitao wrote: > > On Tue, Jun 20, 2023 at 05:13:27PM -0700, Pawan Gupta wrote: > > > On Fri, Jun 16, 2023 at 09:48:50AM -0700, Breno Leitao wrote: > > > > There is no way to disable MDS, TAA, MMIO Stale data mitigation today at > > > > compilation time. These mitigations are enabled even if > > > > CONFIG_SPECULATION_MITIGATIONS is unset. > > > > > > > > Create a new KCONFIG option for each mitigation under > > > > CONFIG_SPECULATION_MITIGATIONS that allows these > > > > mitigations to be disabled by default at compilation time. > > > > > > I don't think all mitigations are still controllable at build-time e.g. > > > spectre_v2 eIBRS mitigation will still be deployed irrespective of the > > > config. > > > > Right. This patchset only cares about MDS, TAA and MMIO. I am more than > > happy to send a new patch to also disable spectre_v2 eIBRS. > > What about Retbleed, L1TF, SRBDS etc? I thought the goal is to control > all speculation mitigations? > > To be consistent CONFIG_SPECULATION_MITIGATIONS should control all > speculation mitigations. If I understand where you want to go, you think we should create a single patchset that creates a CONFIG_ for each mitigation, and move get it under CONFIG_SPECULATION_MITIGATIONS. Is this what you think we should do? Thanks!