From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (146.0.238.70:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 04 Mar 2019 04:08:07 -0000 Received: from mx1.redhat.com ([209.132.183.28]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1h0eta-0007x4-EE for speck@linutronix.de; Mon, 04 Mar 2019 05:08:06 +0100 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 04C3B308AA1E for ; Mon, 4 Mar 2019 04:08:00 +0000 (UTC) Received: from tonnant.bos.jonmasters.org (ovpn-120-248.rdu2.redhat.com [10.10.120.248]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 624A25C207 for ; Mon, 4 Mar 2019 04:07:59 +0000 (UTC) References: <20190304012138.gikabpafseh2swre@treble> <20190304012529.vlwghtse56qvnigx@treble> From: Jon Masters Message-ID: <07faccc1-eee1-979f-9093-3d856e114a5d@redhat.com> Date: Sun, 3 Mar 2019 23:07:54 -0500 MIME-Version: 1.0 In-Reply-To: <20190304012529.vlwghtse56qvnigx@treble> Subject: [MODERATED] Encrypted Message Content-Type: multipart/mixed; boundary="uVDpBQSCcMHiS0KZf2Q3D3fy54u2pviUL"; protected-headers="v1" To: speck@linutronix.de List-ID: This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156) --uVDpBQSCcMHiS0KZf2Q3D3fy54u2pviUL Content-Type: text/rfc822-headers; protected-headers="v1" Content-Disposition: inline From: Jon Masters To: speck for Josh Poimboeuf Subject: Re: [PATCH RFC 4/4] 4 --uVDpBQSCcMHiS0KZf2Q3D3fy54u2pviUL Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 3/3/19 8:25 PM, speck for Josh Poimboeuf wrote: > From: Josh Poimboeuf > Subject: [PATCH RFC 4/4] x86/speculation: Add 'cpu_spec_mitigations=3D'= cmdline > options >=20 > Keeping track of the number of mitigations for all the CPU speculation > bugs has become overwhelming for many users. It's getting more and mor= e > complicated to decide what mitigations are needed for a given > architecture. >=20 > Most users fall into a few basic categories: >=20 > - want all mitigations off; >=20 > - want all reasonable mitigations on, with SMT enabled even if it's > vulnerable; or >=20 > - want all reasonable mitigations on, with SMT disabled if vulnerable. >=20 > Define a set of curated, arch-independent options, each of which is an > aggregation of existing options: >=20 > - cpu_spec_mitigations=3Doff: Disable all mitigations. >=20 > - cpu_spec_mitigations=3Dauto: [default] Enable all the default mitigat= ions, > but leave SMT enabled, even if it's vulnerable. >=20 > - cpu_spec_mitigations=3Dauto,nosmt: Enable all the default mitigations= , > disabling SMT if needed by a mitigation. >=20 > See the documentation for more details. Looks good. There's an effort to upstream mitigation controls for the arm64 but that's not in place yet. They'll want to wire that up later. I actually had missed the s390x etokens work so that was fun to see here. Jon. --=20 Computer Architect | Sent with my Fedora powered laptop --uVDpBQSCcMHiS0KZf2Q3D3fy54u2pviUL--