From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx3-rdu2.redhat.com ([66.187.233.73] helo=mx1.redhat.com) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fLuQv-0004VH-C3 for speck@linutronix.de; Thu, 24 May 2018 19:53:49 +0200 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A135640201A8 for ; Thu, 24 May 2018 17:53:41 +0000 (UTC) Received: from treble (ovpn-120-163.rdu2.redhat.com [10.10.120.163]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7CD8135446 for ; Thu, 24 May 2018 17:53:41 +0000 (UTC) Date: Thu, 24 May 2018 12:53:40 -0500 From: Josh Poimboeuf Subject: [MODERATED] Re: [PATCH v5 6/8] L1TFv4 4 Message-ID: <20180524175340.7a57cmv3w2fakmas@treble> References: <20180523215651.BFF82610ED@crypto-ml.lab.linutronix.de> <20180524040438.3u66mkm2skcpg24w@treble> <20180524133545.GN4486@tassilo.jf.intel.com> <20180524154511.z4rlf6lplnfq2ewo@treble> <20180524165305.GQ4486@tassilo.jf.intel.com> MIME-Version: 1.0 In-Reply-To: <20180524165305.GQ4486@tassilo.jf.intel.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Thu, May 24, 2018 at 09:53:05AM -0700, speck for Andi Kleen wrote: > > BTW, X86_FEATURE_L1TF_WA is never actually used anywhere, shouldn't > > It is used by the sysfs code. This is only used for reporting. > > > max_swapfile_size() and pfn_modify_allowed() be checking it instead of > > X86_BUG_L1TF? > > No, we should try our best to protect even in this case. In that case the "Disabled L1TF workaround" printk and the L1TF_WA feature are misleading. Even with X86_FEATURE_L1TF_WA cleared, the workaround is still in place, it just might not be 100% effective. -- Josh