From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x226YwV32LdBjH5LqI4xS3N1HQwSMVnzq/9KF0BM0S6QFduAuuznUQSHJmnFgq4ECliAdI+Ne ARC-Seal: i=1; a=rsa-sha256; t=1516899418; cv=none; d=google.com; s=arc-20160816; b=o/vtc3EM917eQDPYTasXOSLGA1rD8oQff+Eg/owOORktW86rVdlTaa9bz89yI7R/vb w07OOPUDziy8umjJ2wmhBtYmePbVnVgCpFaGRf63UD/xcIIcRZllLObxx9UclN1KZyYZ uR/ihd+yOSLa5qR0Un8advx2fQ2WwdXffFkmZLyBY0i5tap96uEfSn45NGP5o1KrMH9o m5HGIDCIbyqwjB/jMBFYG92JEExr58Ex6njywnL/WS58rWtSNlSdK8jPLuLoVoPlrfi2 fQ3jT0DPRYzAFONeiWHZkTCI3vSMVl8Y10I9w/MiqdGFVCOVBP66Kc3PD0mldisTYPiE XVHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject :arc-authentication-results; bh=ImNCRcLNE3OZ5EgZFCMcaGoLZxu+KJJMQ16a1HBLmQE=; b=HUn1E0iIjYCN9pC1JXpjMsWavPw9YAkKbE04XV3XW7pmRU1Kx+yIo2LoTql24VAzyx UtUil7qbl6Imv2Wz7xMLkdbkvP2FVI9etNpzddxxuvp1/yh0jnCel6/hGM4UjkLMnpwI 8aowoRf/UyJjmhOiqQA1706BMsTcES+5oBnSjHnQq8oF/S6JWE/oyKM7R4k7Wq44lz7L ERJSWltd0f0l3msVweJMdp9rZbtxXYIBUUdGKKHbntQn1JPMIK7mVr76dstsdD2zbjVh tR4MEx4F3KP7uc0Bj8jHqdC5IXeh0X2rSz1R4JPNP+sN+/yuLCpH9vGE6dpxUpB+mRYE 4d/A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of tim.c.chen@linux.intel.com designates 192.55.52.43 as permitted sender) smtp.mailfrom=tim.c.chen@linux.intel.com Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of tim.c.chen@linux.intel.com designates 192.55.52.43 as permitted sender) smtp.mailfrom=tim.c.chen@linux.intel.com X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,412,1511856000"; d="scan'208";a="13454984" Subject: Re: [RFC PATCH 2/2] x86/ibpb: Prevent missed IBPB flush To: David Woodhouse , linux-kernel@vger.kernel.org Cc: KarimAllah Ahmed , Andi Kleen , Andrea Arcangeli , Andy Lutomirski , Arjan van de Ven , Ashok Raj , Asit Mallick , Borislav Petkov , Dan Williams , Dave Hansen , Greg Kroah-Hartman , "H . Peter Anvin" , Ingo Molnar , Janakarajan Natarajan , Joerg Roedel , Jun Nakajima , Laura Abbott , Linus Torvalds , Masami Hiramatsu , Paolo Bonzini , Peter Zijlstra , rkrcmar@redhat.com, Thomas Gleixner , Tom Lendacky , x86@kernel.org References: <332d3ac8a7018b98d8182ec86b5fc41239c667c6.1516840211.git.tim.c.chen@linux.intel.com> <1516868406.30244.16.camel@infradead.org> From: Tim Chen Message-ID: Date: Thu, 25 Jan 2018 08:56:57 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <1516868406.30244.16.camel@infradead.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590523945343890139?= X-GMAIL-MSGID: =?utf-8?q?1590584325074875787?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On 01/25/2018 12:20 AM, David Woodhouse wrote: > On Wed, 2018-01-24 at 16:36 -0800, Tim Chen wrote: >> It is possible that the last uesr mm that we recorded for a cpu was >> released, and a new mm with identical address was allocated when we >> check it again. We could skip IBPB flush here for the process with >> the new mm. >> >> It is a difficult to exploit case as we have to exit() a process on a >> cpu, free the mm, and fork() the victim to use the mm pointer on that >> cpu. The exploiter needs the old mm to get recycled to the >> newly forked process and no other processes run on the target cpu. > > That's what it takes to have the victim process leak information into > the cache. In order to *harvest* that information, the attacker must > then get run on the same CPU again? And since her first process had to > exits, as described above, she needs a new process for that? > > I confess, with all the other wildly theoretical loopholes that exist, > I wasn't losing much sleep over this one. > >> Nevertheless, the patch below is one way to close this hole by >> adding a ref count to prevent the last user mm from being released. >> It does add ref counting overhead, and extra memory cost of keeping an mm >> (though not the VMAs and most of page tables) around longer than we will >> otherwise need to. Any better solutions are welcomed. > > This has no upper bound on the amount of time the user mm gets held, > right? If a given CPU remains idle for ever (and what happens if it's > taken offline?) we'll never do that mmdrop() ? > The downside with this approach is we do hold on to the mm longer than we needs to. Yes, the offline path does need to be fixed up. Tim