Received: by 2002:a05:6359:6284:b0:131:369:b2a3 with SMTP id se4csp5723449rwb; Wed, 9 Aug 2023 08:19:25 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHgPMIBfUmxjaWMhBq7UEO5FmysObg8Qpi7qRwfUzbdXjgrz9IC+I0jHQDQnEj/l5Jfslwa X-Received: by 2002:a05:6a21:35c4:b0:140:3554:3f44 with SMTP id ba4-20020a056a2135c400b0014035543f44mr2883986pzc.22.1691594365540; Wed, 09 Aug 2023 08:19:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691594365; cv=none; d=google.com; s=arc-20160816; b=XhMHvsejbNJbQPYn+nZlM8ErcqyJAlyrcKeWqhWUP0GuT3vqJdIGBGFeMDJi8sa+jI ccoodHs4iD+n8w9LlnKv+PqwFy182Ju4Ojz4tmyb4kXMa1JkdfkxlLl0txZXwGRVxADH uMo6BUHEdWvZHMkm9w6RJErLNz1aUdKNuW4NC8mggidY+dSOqzEmBc5wJOCFjP8awBcT 3Ztz9j7KdhBvzlOsKltulFugt0jg9fzxo35RCpCyAg/waEHVZho9JgUJcG1kjXvHxOMo KBuL9sEOL8PTaPsNT2nkaSLChXED0Tr/PgE1JiefKFpITd8o/+S7708iQQm/oZ9qS1s6 kvbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=S6yA5FU6N7+o51hZuqwt8JKjCm2bWHsithctyFR/cqY=; fh=nIqJPQrB4V45MOdRoOCBABHD990j3QSMCgsf+X0qIaI=; b=lN30Jh3eVZFOr1Q07+sTpfezt5iRv0SnVsPm4hiZU5OQxWNBU28nugVukauyo8UiTi PX0R9mk5jBcGAn1XLYpb3TNzytKuIiQFiOpt/1N9KpLH7Q3xp/lrvPINV3ixq2VuKUwn XQNEEDoKZIfVi9AdfmMwv644iKlld52rhzcoECKRThg+5F5ggxNkMKGbyng7YLEHj6yJ yv+IcguZir7vASYuJ4cIPvMg8JxrX9Uf06iGcz8xd76WFnwQK6cdsplwXD+fdmdPXJXk PCoRTPbmGCj4yqPEWvyAyyAkeA1cS/AsEpcVaZ67RytfI6LDoA8cLg4bwgiExeWtlVce Sh9Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=W750R2F1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b4-20020a6541c4000000b00534780446d9si8989535pgq.640.2023.08.09.08.19.13; Wed, 09 Aug 2023 08:19:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=W750R2F1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S233283AbjHIO2x (ORCPT + 99 others); Wed, 9 Aug 2023 10:28:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44288 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233279AbjHIO2w (ORCPT ); Wed, 9 Aug 2023 10:28:52 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 16A00170B for ; Wed, 9 Aug 2023 07:28:52 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 9624063422 for ; Wed, 9 Aug 2023 14:28:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3A51EC433C7; Wed, 9 Aug 2023 14:28:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1691591331; bh=sTMZ5ww1qIGz1lhvEVOD4pr1bzYqs6NfWACJ2GRhEfQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=W750R2F1rsrsUrhTtXPBO82gX2Mmt3nBZg9Kv/mKmn2y1b1BsmhDBGe+uG8sawudT /IA01sk7ecutdzHSyo6Wmtf392324G/Lr/GWD5JxvfNEyhqT5cQs6pvAto/tGnjHYY PLZ9dZrkG3/TbS3utzpDH7UyRGfVcjXdcHctBCRqc14Yhr59V5yY4eb83P52ZNtaPz KGChIHY7c25n328GRaacVodfHeWbo7tTInGNVkorVrzuv38psxrgRnrK3ZoH3e5kL5 XaBr///W2556fhT/TVily1YM2/D1zUUmGgoWCgtW3Fwmyp/HlmnF9RbhOKrurcAZLJ cVEYzTy4vR9mA== Date: Wed, 9 Aug 2023 10:28:47 -0400 From: Josh Poimboeuf To: Peter Zijlstra Cc: x86@kernel.org, linux-kernel@vger.kernel.org, David.Kaplan@amd.com, Andrew.Cooper3@citrix.com, gregkh@linuxfoundation.org Subject: Re: [RFC][PATCH 06/17] x86/cpu: Add SRSO untrain to retbleed= Message-ID: <20230809142847.3prfwo6cclbydfep@treble> References: <20230809071218.000335006@infradead.org> <20230809072200.850338672@infradead.org> <20230809134233.d7hlutglk2j3f4w3@treble> <20230809140603.GO212435@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20230809140603.GO212435@hirez.programming.kicks-ass.net> X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 09, 2023 at 04:06:03PM +0200, Peter Zijlstra wrote: > On Wed, Aug 09, 2023 at 09:42:33AM -0400, Josh Poimboeuf wrote: > > On Wed, Aug 09, 2023 at 09:12:24AM +0200, Peter Zijlstra wrote: > > > static enum retbleed_mitigation retbleed_mitigation __ro_after_init = > > > @@ -796,6 +802,10 @@ static int __init retbleed_parse_cmdline > > > retbleed_cmd = RETBLEED_CMD_AUTO; > > > } else if (!strcmp(str, "unret")) { > > > retbleed_cmd = RETBLEED_CMD_UNRET; > > > + } else if (!strcmp(str, "srso")) { > > > + retbleed_cmd = RETBLEED_CMD_UNRET_SRSO; > > > + } else if (!strcmp(str, "srso_alias")) { > > > + retbleed_cmd = RETBLEED_CMD_UNRET_SRSO_ALIAS; > > > > It doesn't make sense for "srso_alias" to be a separate cmdline option, > > as that option is a model-dependent variant of the SRSO mitigation. > > so what I did with retbleed, and what should be fixed here too (I > forgot) is run with: > > retbleed=force,unret > > on any random machine (typically Intel, because I have a distinct lack > of AMD machines :-() and look at the life kernel image to see if all the > patching worked. > > I suppose I should add: > > setup_force_cpu_bug(X86_BUG_SRSO); > > to the 'force' option, then: > > retbleed=force,srso_alias > > should function the same, irrespective of the hardware. > > I'm also of the opinion that the kernel should do as told, even if it > doesn't make sense. If you tell it nonsense, you get to keep the pieces. > > So in that light, yes I think we should have separate options. What if I want the SRSO mitigation regardless of CPU model? > > > @@ -870,8 +915,17 @@ static void __init retbleed_select_mitig > > > default: > > > if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD || > > > boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) { > > > - if (IS_ENABLED(CONFIG_CPU_UNRET_ENTRY)) > > > - retbleed_mitigation = RETBLEED_MITIGATION_UNRET; > > > + if (IS_ENABLED(CONFIG_CPU_UNRET_ENTRY)) { > > > + if (boot_cpu_has_bug(X86_BUG_RETBLEED)) > > > + retbleed_mitigation = RETBLEED_MITIGATION_UNRET; > > > + > > > + if (boot_cpu_has_bug(X86_BUG_SRSO) && !boot_cpu_has(X86_FEATURE_SRSO_NO)) { > > > + if (boot_cpu_data.x86 == 0x19) > > > + retbleed_mitigation = RETBLEED_MITIGATION_UNRET_SRSO_ALIAS; > > > + else > > > + retbleed_mitigation = RETBLEED_MITIGATION_UNRET_SRSO; > > > > It would be great to get confirmation from somebody at AMD that the SRSO > > mitigations supersede the Retbleed one, i.e., that the SRSO mitigations > > also fix Retbleed. > > They should, the discussions we had back then explained the Zen1/2 > retbleed case in quite some detail and the srso case matches that > exactly with the movabs. A larger instruction is used because we need a > larger embedded sequence of instructions, but otherwise it is identical. > > The comments provided for srso_alias state the BTB is untrained using > the explicit aliasing. > > That is to say, AFAIU any of this, yes both srso options untrain the BTB > and mitigate the earlier retbleed thing. > > SRSO then goes one step further with the RAP/RSB clobber. Ah, nice. Please add that information somewhere (e.g., one of the commit logs). > > > + } > > > + } > > > else if (IS_ENABLED(CONFIG_CPU_IBPB_ENTRY) && boot_cpu_has(X86_FEATURE_IBPB)) > > > retbleed_mitigation = RETBLEED_MITIGATION_IBPB; > > > > Here should have the microcode check too: > > > > if (boot_cpu_has_bug(X86_BUG_SRSO) && !has_microcode) > > pr_err("IBPB-extending microcode not applied; SRSO NOT mitigated\n"); > > That earlier printk is unconditional of the selected mitigation, you > really want it printed again? Hm, if you don't want it printed twice then remove it from the RETBLEED_CMD_IBPB case too. -- Josh