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 1fAtuH-0001Kf-N7 for speck@linutronix.de; Tue, 24 Apr 2018 11:06:40 +0200 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id E6B46AC7D for ; Tue, 24 Apr 2018 09:06:31 +0000 (UTC) Date: Tue, 24 Apr 2018 11:06:30 +0200 From: Joerg Roedel Subject: [MODERATED] L1D-Fault KVM mitigation Message-ID: <20180424090630.wlghmrpasn7v7wbn@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: Hey, I've been looking into the mitigation for the L1D fault issue in KVM, and since the hardware seems to speculate with the GPA as an HPA, it seems we have to disable SMT to be fully secure here because otherwise two different guests running on HT siblings could spy on each other. I'd like to discuss how we mitigate this, the big hammer would be not initializing the HT siblings at boot on affected machines, but that is probably a bit too eager as it also penalizes people not using KVM. Another option is to just print a fat warning and/or refuse to load the KVM modules on affected machines when HT is enabled. So what are the opinions on how we should best mitigate this issue? Regards, Joerg