From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx2.suse.de ([195.135.220.15]) by Galois.linutronix.de with esmtps (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1f8Y1n-0006iG-2I for speck@linutronix.de; Tue, 17 Apr 2018 23:20:39 +0200 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 7CABEAC25 for ; Tue, 17 Apr 2018 21:20:30 +0000 (UTC) Date: Tue, 17 Apr 2018 23:20:26 +0200 From: Borislav Petkov Subject: [MODERATED] Re: GPZv4 Message-ID: <20180417212026.GG3890@pd.tnic> References: <20180417193105.GD3890@pd.tnic> <476c3e0b-dde6-6e6b-2054-6e71fa2c396b@redhat.com> <20180417203717.GF3890@pd.tnic> <47b619bf-8d07-c465-9017-583cf5ac80ee@redhat.com> MIME-Version: 1.0 In-Reply-To: <47b619bf-8d07-c465-9017-583cf5ac80ee@redhat.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: speck@linutronix.de List-ID: On Tue, Apr 17, 2018 at 05:03:01PM -0400, speck for Jon Masters wrote: > [my one comment in this email on RHEL, feel free to skip next para] > Red Hat's perspective is that we need to be "secure by default". I would > /love/ to be able to leave MD enabled globally on all arches, but in > order for that to happen, everyone across the industry would have to I don't think you can do global decisions like that - it should be per-vendor thing as everything else arch-specific is and we do what the vendor suggests. > So we need to close on the following urgently: >=20 > 1). What are we going to refer to this as? > - MDD > - SSB > - something else? >=20 > In the case of "MDD" it's x86 specific and "enabling" it means you > disable a feature (MD). To me, that seems to be inverted logic. You > would set it to "on", "off", or "kernel" (MD only in userspace). >=20 > In the case of "SSB" it's more industry wide terminology but it's not > the Intel term. You would set it to "on", "off", or "userspace". I for one - and this is just me - see the point of calling it something vendor- and arch-agnostic so sbb I guess. But whatever, as long as it is only one name and the logic is spelled out somewhere. > 2). We need a prctl option for a task to request behavior for SSB. One > option could be a new PR_SET_MITIGATION where we then have minor > parameters for additional mitigations that are required later. I'd look towards other people here for ideas. But prctl() sounds simple enough to me. --=20 Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imend=C3=B6rffer, Jane Smithard, Graham Norton, HR= B 21284 (AG N=C3=BCrnberg) --=20