From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (193.142.43.55:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 16 Oct 2019 07:26:21 -0000 Received: from mx2.suse.de ([195.135.220.15] helo=mx1.suse.de) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iKdhM-0007E3-Lj for speck@linutronix.de; Wed, 16 Oct 2019 09:26:21 +0200 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 695F1B230 for ; Wed, 16 Oct 2019 07:26:15 +0000 (UTC) Date: Wed, 16 Oct 2019 09:26:14 +0200 (CEST) From: Jiri Kosina Subject: [MODERATED] Re: ***UNCHECKED*** Re: [PATCH v5 08/11] TAAv5 8 In-Reply-To: <20191015103454.GW317@dhcp22.suse.cz> Message-ID: References: <20191009131251.GD6616@dhcp22.suse.cz> <20191014210458.GF4957@zn.tnic> <20191015103454.GW317@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Tue, 15 Oct 2019, speck for Michal Hocko wrote: > From 9666e91b63cd6213d362d04289e1bcbbe2050bc3 Mon Sep 17 00:00:00 2001 > From: Michal Hocko > Date: Tue, 15 Oct 2019 11:21:01 +0200 > Subject: [PATCH] x86, tsx: allow to set tsx=auto by a config option > > There is a general consensus that TSX usage is not largely spread while > the history shows there is a non trivial space for side channel attacks > possible. Therefore the tsx is disabled by default even on platforms > that might have a safe implementation of TSX according to the current > knowledge. This is a fair trade off to make. > > There are, however, workloads that really do benefit from using TSX and > updating to a newer kernel with TSX disabled might introduce a > noticeable regressions. This would be especially a problem for Linux > distributions which will provide TAA mitigations. > > Introduce X86_INTEL_ENABLE_SAFE_TSX config option to override the > default tsx=off semantic and make tsx=auto a default which is more > update friendly. So given the recent clarifications, especially around older MDS_NO=0 CPUs, I think it'd actually make more sense to turn this into a config option that would simply allow to chose what the default behavior should be, chosing from tristate off/on/auto. Thanks, -- Jiri Kosina SUSE Labs