Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp1151900ybg; Tue, 2 Jun 2020 02:40:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwHz0DEmC9js2LFb8XEKptuPELctNleaV5eyWNj5jEUhSPcnsLKH7mEeClm5ndOh4Mr3XHd X-Received: by 2002:aa7:d388:: with SMTP id x8mr10521955edq.380.1591090850420; Tue, 02 Jun 2020 02:40:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591090850; cv=none; d=google.com; s=arc-20160816; b=TbVGNRU3uGtenrlZQcYpgexuWQGJKGO/Xr0EaNB2Q/0hLFxxJgrCOjgxF6K80y80XF nqnuIRgwNJ5iiPV286FIlQ38z1IWtXEL2X1h7aM52S0jOuHuuf9tYZ/CoDC68h10YmHe HyhuA9OpdLgDOLiS+vVJQrUC8wzafKvlZnW4NJdhNxvU3z8Enku7rnAhhxXghDLmoDU6 FDbCkLw6XN10Z5OitxZ2EX4VcZ77TKk5VOTMPsk6MRcX/pncm0irBi6tYFMnWxyweaih YjtImgTi/qb4T7KpJBR1fFYlEURz/dr3XVZSFfi8wG6FiVIawdzSJaFsXhTEPq4e5olx r7VQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id; bh=zr5dZryDUIwYYkcoPi43YJQI4UsrYcj1cS6zTn60BIs=; b=C5zk/6eP7JKK1X0uVlxP6k/SL5pedIiSx0yoHLrZOY4Ls+9Y2q2xjNGJBw51Mf9dxQ tJhE2tY4eqD2McbUFdZpddnTv8i5t+r12pgeb0lx3aq4dbUjehSYxC6hqeKgz6WkLrWH CajcNQ89NsdgNWOejU3/KoP4nYg4MpWxAF4K6cudLu7cgHbq1hoDcPqUp/k4eaMbO4k8 FvXkVQE7OiiawLvJnhKrOsRarKALrXwBqQYK1Q2XrEf6cGU9zhCCxPS97p8LxGKsg7e1 4bKCOHwLSlvVADEGaFEcU0l61VXvdHgB3wKWBQakdTAjMhLthOaeGxkJ6mMjC6yVeR8Y fUeg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z14si1083127ejr.261.2020.06.02.02.40.26; Tue, 02 Jun 2020 02:40:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726648AbgFBJiM (ORCPT + 99 others); Tue, 2 Jun 2020 05:38:12 -0400 Received: from kernel.crashing.org ([76.164.61.194]:55208 "EHLO kernel.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726580AbgFBJiM (ORCPT ); Tue, 2 Jun 2020 05:38:12 -0400 Received: from localhost (gate.crashing.org [63.228.1.57]) (authenticated bits=0) by kernel.crashing.org (8.14.7/8.14.7) with ESMTP id 0529bUKa025589 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 2 Jun 2020 04:37:34 -0500 Message-ID: Subject: Re: [GIT PULL] x86/mm changes for v5.8 From: Benjamin Herrenschmidt To: Ingo Molnar , Balbir Singh Cc: torvalds@linux-foundation.org, a.p.zijlstra@chello.nl, akpm@linux-foundation.org, bp@alien8.de, linux-kernel@vger.kernel.org, luto@kernel.org, tglx@linutronix.de Date: Tue, 02 Jun 2020 19:37:29 +1000 In-Reply-To: <20200602073350.GA481221@gmail.com> References: <20200601170102.GA1346815@gmail.com> <20200602073350.GA481221@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2020-06-02 at 09:33 +0200, Ingo Molnar wrote: > Or rather, we should ask a higher level question as well, maybe we > should not do this feature at all? Well, it does solve a real issue in some circumstances and there was a reasonable discussion about this on the list that lead to it being merged with Kees and Thomas (and others) agreeing :) But yes, it is pointless with SMT and yes maybe we should make it explicitly do nothing on SMT, but let's not throw the baby out with the bath water shall we ? > Typically cloud computing systems such as AWS will have SMT enabled, > because cloud computing pricing is essentially per vCPU, and they want > to sell the hyperthreads as vCPUs. Not necessarily and not in every circumstances. Yes, VMs will typically have SMT enabled. This isn't targeted at them though. One example that was given during the discussions was containers pertaining to different users. Now maybe we could discuss making the flush on changes of cgroups or other similar things rather than individual process, but so far that hasn't come up during the disucssion on the mailing list. Another example would be a process that handles more critical data such as payment information, than the rest of the system and wants to protect itself (or the admin wants that process protected) against possible data leaks to less trusted processes. > So the safest solution, disabling > SMT on affected systems, is not actually done, because it's an > economic non-starter. (I'd like to note the security double standard > there: the most secure option, to disable SMT, is not actually used ...) This has nothing to do about SMT, though yes maybe we should make the patch do nothing on SMT but this isn't what this feature is about. > BTW., I wonder how Amazon is solving the single-vCPU customer workload > problem on AWS: if the vast majority of AWS computing capacity is > running on a single vCPU, because it's the cheapest tier and because > it's more than enough capacity to run a website. Even core-scheduling > doesn't solve this fundamental SMT security problem: separate customer > workloads *cannot* share the same core - but this means that the > single-vCPU workloads will only be able to utilize 50% of all > available vCPUs if they are properly isolated. > > Or if the majority of AWS EC2 etc. customer systems are using 2,4 or > more vCPUs, then both this feature and 'core-scheduling' is > effectively pointless from a security POV, because the cloud computing > systems are de-facto partitioned into cores already, with each core > accounted as 2 vCPUs. AWS has more than just VMs for rent :-) There are a whole pile of higher level "services" that our users can use and not all of them necessarily run on VMs charged per vCPU. > The hour-up-rounded way AWS (and many other cloud providers) account > system runtime costs suggests that they are doing relatively static > partitioning of customer workloads already, i.e. customer workloads > are mapped to actual physical hardware in an exclusive fashion, with > no overcommitting of physical resources and no sharing of cores > between customers. > > If I look at the pricing and capabilities table of AWS: > > https://aws.amazon.com/ec2/pricing/on-demand/ > > Only the 't2' and 't3' On-Demand instances have 'Variable' pricing, > which is only 9% of the offered 228 configurations. > > I.e. I strongly suspect that neither L1D flushing nor core-scheduling > is actually required on affected vulnerable CPUs to keep customer > workloads isolated from each other, on the majority of cloud computing > systems, because they are already isolated via semi-static > partitioning, using pricing that reflects static partitioning. This isn't about that. These patches aren't trying to solve problems happening inside of a customer VM running SMT not are they about protecting VMs against other VMs on the same system. Cheers, Ben.