Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp3606023ybl; Tue, 21 Jan 2020 04:00:22 -0800 (PST) X-Google-Smtp-Source: APXvYqwF62Im89BnBhRXHouJvGvX6aQP9WkwlTnPoiorIK9NMg6rWHjF50iX8iuQMQ7RR9NhRPWd X-Received: by 2002:a05:6830:138b:: with SMTP id d11mr3201538otq.38.1579608022424; Tue, 21 Jan 2020 04:00:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579608022; cv=none; d=google.com; s=arc-20160816; b=nh5uA2RtWhL+Wc6P7SKjzXt2iFvcv+whEvMUmCJfKf0pGp3OHcZcJlwqv4njmB35H4 jb1OFxIh1Ak6mwbgwZlRBrOR6iSSAcQCIcgT5TH8aOJ2Ov5VobJvPdCKuvZfyD7edNAb 3uLC8v7wCrZuFTy652RKRsCsRIX6jbuR2qz9qR4zKMCbmUaF5NBYqNwSq966+DPRVSsx M2znIzgP2JiTGEqt+/CXZzoDB1D9GegTZAEiVeSZzYzSDwWu6j3GVT8QjdBmf7hYnFXF bVKMWLHT8H8+/0DRI+doTSxB/b28MYRH1fuaG/X9+7S6z/Idgbg5bzgkia5HtP45+Gb/ Yr/A== 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=AK6Wv16544idpmucsyNkFh0MEnk+AES/sRmYGtwTMac=; b=WOO4YkJdzXse+MSGQ2V2V7o2WjRCXX4gQjfDewiaQ8cwGFAyHUvyGoLSsv7RCxTQa8 cZI2Dt/orTtOMiZ0rsHY42bXq1Ix76YdcTjidR3xkSeLg+u/2HvzFLPd9CZezT0LHYdG vLmDlKZQ6I4rxQnoDnQTzZIpa5LuzG3RqE02gJJ4lPsAaSK4Ulp8J2KCKX5YLSxT9tv9 ZS617OynAHC332NnlqJZp76VJtVpoR39QSxgpXKRe4CDu8rVy0bOHHl0hOBr8j9rlXha Lbknt5X4QeOJO/oCm9XtClcMZlDqO/uViZ1+7B+9OrYgcWPy59vqJ89TvjCn8d1+DOmU zwfg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=HtjKVeNB; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q8si21852441otk.283.2020.01.21.04.00.08; Tue, 21 Jan 2020 04:00:22 -0800 (PST) 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=@google.com header.s=20161025 header.b=HtjKVeNB; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729144AbgAUL6E (ORCPT + 99 others); Tue, 21 Jan 2020 06:58:04 -0500 Received: from mail-lj1-f193.google.com ([209.85.208.193]:33500 "EHLO mail-lj1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726052AbgAUL6D (ORCPT ); Tue, 21 Jan 2020 06:58:03 -0500 Received: by mail-lj1-f193.google.com with SMTP id y6so2497287lji.0 for ; Tue, 21 Jan 2020 03:58:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AK6Wv16544idpmucsyNkFh0MEnk+AES/sRmYGtwTMac=; b=HtjKVeNBHMzntMzRTKTW5zX9VZ5Jysv0yL5TQV/ecnddcDIMP+DeViKx2a4zyoE6q+ R1V4gFHLvwAg582p1yD34/b+HoYZEcoB0WOLo2GUL8ybsXA9djDpXAYj64cLLQ6JPkX9 rJRNaBl5KIndnONLgF5ZSYTtKOv4HzZBoN9RGrE7RGWaekAraUtnlYmAwcsROvQtAnLt xGEO5CdfWaCAmTsC9rL/I4Fa+ez/EmKP/+eqTcy2b+2kf7BqgxZEBEC1d0R7w40fcr4Z 9Q2JkNyoqBq8INb9aqtSsExMeiDaENKN7ihlNUhUaV9ocVjYPqRsZ0wXmh9UPOO/c9qT dyEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AK6Wv16544idpmucsyNkFh0MEnk+AES/sRmYGtwTMac=; b=R2SgPmcOC6Q+wuVZ5OsQ7B3MvpsT+51W2RJdSgRMwGxPhep/kqS6CZgvfwjEVH1Lwv 3DeyR5Vpks/cvNUDboeDc3y7CTHSVbq4wN3URvDTb2qlalDy0yXNusDCZU4DB3oLZE/j ra7jbZg8tcHdAPys3uC7csJNObx+0odbe6yo2mCqv8HhkAJv7aL+V8QiRamps0eQiNLa kqTVAN9jmCCs6JfasndZcGCT4OVUQArYeH+0tAYWj/kEde2F4fCIfQ+YS0gw5m/OdNYq xdYNOJt0oFvb+5HuwT+0YCtltygGcZGHmH5golmf+NiOJwk3lxAnIbZh77GbrJzxHZB5 s/eQ== X-Gm-Message-State: APjAAAVps55Iw8YF2SAsf0iGv2Cf57SKfONKlzoMUvvD/6g4NRyDMsg3 qAQ1p/yTaYL7rv9+bc5XfKtutiR978GmTIcIgtz5 X-Received: by 2002:a2e:809a:: with SMTP id i26mr16460465ljg.108.1579607881701; Tue, 21 Jan 2020 03:58:01 -0800 (PST) MIME-Version: 1.0 References: <20191229164830.62144-1-asteinhauser@google.com> <20200121113317.GH7808@zn.tnic> In-Reply-To: <20200121113317.GH7808@zn.tnic> From: Anthony Steinhauser Date: Tue, 21 Jan 2020 03:57:50 -0800 Message-ID: Subject: Re: [PATCH] Return ENXIO instead of EPERM when speculation control is unimplemented To: Borislav Petkov Cc: Thomas Gleixner , linux-kernel@vger.kernel.org, mingo@redhat.com 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 Your change seems to remove exactly the distinction which Thomas pointed out because SPECTRE_V2_USER_UNAVAILABLE would not differentiate between STIBP mitigation not available and STIBP not used because SMT is not possible. Otherwise your modification looks fine to me. On Tue, Jan 21, 2020 at 3:33 AM Borislav Petkov wrote: > > On Sun, Dec 29, 2019 at 08:48:30AM -0800, Anthony Steinhauser wrote: > > @@ -602,7 +603,7 @@ spectre_v2_parse_user_cmdline(enum spectre_v2_mitigation_cmd v2_cmd) > > static void __init > > spectre_v2_user_select_mitigation(enum spectre_v2_mitigation_cmd v2_cmd) > > { > > - enum spectre_v2_user_mitigation mode = SPECTRE_V2_USER_NONE; > > + enum spectre_v2_user_mitigation mode = SPECTRE_V2_USER_UNAVAILABLE; > > bool smt_possible = IS_ENABLED(CONFIG_SMP); > > enum spectre_v2_user_cmd cmd; > > So here in the code, right under this line we check IBPB and STIBP and > whether SMT is force_disabled/possible and set smt_possible if not. We > parse cmdline, pick apart selection, etc... > > > @@ -616,6 +617,7 @@ spectre_v2_user_select_mitigation(enum spectre_v2_mitigation_cmd v2_cmd) > > cmd = spectre_v2_parse_user_cmdline(v2_cmd); > > switch (cmd) { > > case SPECTRE_V2_USER_CMD_NONE: > > + mode = SPECTRE_V2_USER_DISABLED; > > goto set_mode; > > case SPECTRE_V2_USER_CMD_FORCE: > > mode = SPECTRE_V2_USER_STRICT; > > @@ -676,7 +678,7 @@ spectre_v2_user_select_mitigation(enum spectre_v2_mitigation_cmd v2_cmd) > > * mode. > > */ > > if (!smt_possible || !boot_cpu_has(X86_FEATURE_STIBP)) > > - mode = SPECTRE_V2_USER_NONE; > > + mode = SPECTRE_V2_USER_UNAVAILABLE; > > ... but here we do that evaluation again. But I think that *if* the > required hw support is not there - either SMT is not possible or STIBP > not present - then there's no real need to parse the cmdline and do all > that. > > IOW, the filtering out of the cases where the user can't do any changes > due to not present hw should be concentrated at the function entry and > mode left at SPECTRE_V2_USER_UNAVAILABLE. > > IOW 2, unless I'm not missing some of the gazillion use cases with this > ;-\ I think that check needs to be moved up and integrated into the > entry checks. I.e., this ontop or a separate patch...: > > --- > diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c > index 2e9299816530..ffe5e4fa4611 100644 > --- a/arch/x86/kernel/cpu/bugs.c > +++ b/arch/x86/kernel/cpu/bugs.c > @@ -618,8 +618,10 @@ spectre_v2_user_select_mitigation(enum spectre_v2_mitigation_cmd v2_cmd) > return; > > if (cpu_smt_control == CPU_SMT_FORCE_DISABLED || > - cpu_smt_control == CPU_SMT_NOT_SUPPORTED) > + cpu_smt_control == CPU_SMT_NOT_SUPPORTED) { > smt_possible = false; > + return; > + } > > cmd = spectre_v2_parse_user_cmdline(v2_cmd); > switch (cmd) { > @@ -679,13 +681,6 @@ spectre_v2_user_select_mitigation(enum spectre_v2_mitigation_cmd v2_cmd) > /* If enhanced IBRS is enabled no STIBP required */ > if (spectre_v2_enabled == SPECTRE_V2_IBRS_ENHANCED) > return; > - > - /* > - * If SMT is not possible or STIBP is not available clear the STIBP > - * mode. > - */ > - if (!smt_possible || !boot_cpu_has(X86_FEATURE_STIBP)) > - mode = SPECTRE_V2_USER_UNAVAILABLE; > set_mode: > spectre_v2_user = mode; > /* Only print the STIBP mode when SMT possible */ > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette