Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp57596ybh; Tue, 17 Mar 2020 18:04:45 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsqrEB4Cdjw++aT2KOzdZs//QW7If9NGzINtd8zmAlPFqnJ9eUGigOlt3UEiHF4LfJvqNsF X-Received: by 2002:a05:6830:1f0c:: with SMTP id u12mr1783826otg.59.1584493485207; Tue, 17 Mar 2020 18:04:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584493485; cv=none; d=google.com; s=arc-20160816; b=DxcSAOk47WtRhwU7pzx9d/J+KY1RtU2IuHCpmCV3ZCvSeZwvZxxLGRv6cT2/4Jggxh c38e08jshdZQuFZrAjv0DqwG1FUF0lA/v/PxZGhW3j9gk0KIU02Rz26aCO7z0dwqPwnm XLlHd+P9eWWCRQn8w3PAZWuywKWKXPi0PO/K64oHwezSBoDJeNtPUtaMKnECto+gq2jS tIo06UzyLMnVPbZEktNyk4PDYVzc2WVQle5BnhaOZ9YmPBjQuZp/PWAjdkSe/R408CZO LR60D8mPD90RH8Ye+EvL+aoJZhe2UhMbS9wPlbCwlf1iwfMLoWVjB9zGk686VoMPzxHK 4MBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=z/UM91m3H9SucrrzE6InBosgNbwLVjkfbWviiKx3hOw=; b=WdoQI0R2OxGDJFXAjH7fXQsedsiQ0IdBH9M0pkCkymavfHiwuX4lXHD9zV1yomcNwr NQ2jRUUeqYBmBpGU+WZE/GN7NNu++LHTb/RkcsRFdQ3O2U+EczB+7ZXw1ro+VmNea508 eC3XQeum21rapUFSVa+7LiUeUd5NIigNxV7aL1Ya/NztHQai/WIhBfQWvL3LsQEfRVka Q+TJhc715Q3pcCZfFsl/MAjtvlqptSLMnlDfd+9PFr3EPljfgjiBlI4N6iwS9z4o48sz 26joZeP4fwydB46cbW3mRdE+b8+7SxNd4DLMCbNWjo38zg4bkLOVRzdqZeP9DXvPBZDh DIqg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b="mKYR/Iex"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h3si2368642otm.254.2020.03.17.18.04.31; Tue, 17 Mar 2020 18:04:45 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b="mKYR/Iex"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727461AbgCRBDK (ORCPT + 99 others); Tue, 17 Mar 2020 21:03:10 -0400 Received: from mail-qv1-f65.google.com ([209.85.219.65]:45687 "EHLO mail-qv1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727210AbgCRBDK (ORCPT ); Tue, 17 Mar 2020 21:03:10 -0400 Received: by mail-qv1-f65.google.com with SMTP id h20so8107789qvr.12 for ; Tue, 17 Mar 2020 18:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=z/UM91m3H9SucrrzE6InBosgNbwLVjkfbWviiKx3hOw=; b=mKYR/IexVgIIHRle+DSeYJI0sWzJl1m36ntdDhMhJ1Cu2Wn6OqoIxTGSLNFUl1+QAP Rv5iJhlrVramUD9FEix15VU+i5XA0LsR+bnIh0Q7us3Pq6gp0Jp6iWrUM6pUsB77lq/2 juE/yVK2+agU+VkY6Aopcq1NfwOLCxuMyXU6I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=z/UM91m3H9SucrrzE6InBosgNbwLVjkfbWviiKx3hOw=; b=Ks8jI6vbrlSaSW7ljmxyJ2Zh/EAE3DyZ6ibcl+Xk+byrSf1frl6k0HslW/xAnlj3QY MAz/+lPfeNXz9LEYXHsESJ0x7QnCZcQRf/NoFMylG3jxZmCgi/bNr7vJ/tSFdY43VhDY y9vkaiPq2vr6LxEQWFGMXeMakTIFkGVlxakzhHyAc9wCJyJCxblDYH/qeo6iaQdTGvcB 2a/9bKYDURzH4f81vcx8vw84hTJij9MEfdl4feIjrymEG6gLAMsSvxrp7kaO6Gwy5pxO CnfGUUM6irx6e0SL8U3GzdxZSOnxsIu2hv+kMzjO+OHm4LDW13y83gGCuB4I1ZqgGH1V 7eFQ== X-Gm-Message-State: ANhLgQ3ZdoyClqY+NGg395nBYsYhtqVGKU3MzpDmGLB4ewrdNVedxKA4 ltIteh8KLyftsEJxono3RUFNoA== X-Received: by 2002:ad4:5401:: with SMTP id f1mr1828266qvt.209.1584493389098; Tue, 17 Mar 2020 18:03:09 -0700 (PDT) Received: from localhost ([2620:15c:6:12:9c46:e0da:efbf:69cc]) by smtp.gmail.com with ESMTPSA id t71sm3169655qke.55.2020.03.17.18.03.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Mar 2020 18:03:08 -0700 (PDT) Date: Tue, 17 Mar 2020 21:03:07 -0400 From: Joel Fernandes To: Thomas Gleixner Cc: Tim Chen , Julien Desfossez , Peter Zijlstra , Vineeth Remanan Pillai , Aubrey Li , Nishanth Aravamudan , Ingo Molnar , Paul Turner , Linus Torvalds , Linux List Kernel Mailing , Dario Faggioli , =?iso-8859-1?Q?Fr=E9d=E9ric?= Weisbecker , Kees Cook , Greg Kerr , Phil Auld , Aaron Lu , Valentin Schneider , Mel Gorman , Pawan Gupta , Paolo Bonzini , "Luck, Tony" Subject: Re: [RFC PATCH v4 00/19] Core scheduling v4 Message-ID: <20200318010307.GA111608@google.com> References: <20200212230705.GA25315@sinkpad> <29d43466-1e18-6b42-d4d0-20ccde20ff07@linux.intel.com> <20200221232057.GA19671@sinkpad> <20200317005521.GA8244@google.com> <87imj2bs04.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87imj2bs04.fsf@nanos.tec.linutronix.de> User-Agent: Mutt/1.12.2 (2019-09-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Thomas, Thanks for the detailed email. I am on the same page with all your points, I had a question on one of the points below (which I agree with as well) but just to confirm, On Tue, Mar 17, 2020 at 10:17:47PM +0100, Thomas Gleixner wrote: [..] > >> 4. HT1 is idle, and HT2 is running a victim process. Now HT1 starts running > >> hostile code on guest or host. HT2 is being forced idle. However, there is > >> an overlap between HT1 starting to execute hostile code and HT2's victim > >> process getting scheduled out. > >> Speaking to Vineeth, we discussed an idea to monitor the core_sched_seq > >> counter of the sibling being idled to detect that it is now idle. > >> However we discussed today that looking at this data, it is not really an > >> issue since it is such a small window. > > If the victim HT is kicked out of execution with an IPI then the overlap > depends on the contexts: > > HT1 (attack) HT2 (victim) > > A idle -> user space user space -> idle > > B idle -> user space guest -> idle > > C idle -> guest user space -> idle > > D idle -> guest guest -> idle > > The IPI from HT1 brings HT2 immediately into the kernel when HT2 is in > host user mode or brings it immediately into VMEXIT when HT2 is in guest > mode. > > #A On return from handling the IPI HT2 immediately reschedules to idle. > To have an overlap the return to user space on HT1 must be faster. > > #B Coming back from VEMXIT into schedule/idle might take slightly longer > than #A. > > #C Similar to #A, but reentering guest mode in HT1 after sending the IPI > will probably take longer. > > #D Similar to #C if you make the assumption that VMEXIT on HT2 and > rescheduling into idle is not significantly slower than reaching > VMENTER after sending the IPI. > > In all cases the data exposed by a potential overlap shouldn't be that > interesting (e.g. scheduler state), but that obviously depends on what > the attacker is looking for. About the "shouldn't be that interesting" part, you are saying, the overlap should not be that interesting because the act of one sibling IPI'ing the other implies the sibling HT immediately entering kernel mode, right? Thanks, your email really helped!!! - Joel