Received: by 10.223.176.46 with SMTP id f43csp1435400wra; Wed, 24 Jan 2018 16:57:58 -0800 (PST) X-Google-Smtp-Source: AH8x226Qdou+DOx/aQyZMebgGmVVJbzJT9FNeER2NMBf+ghNXiuvgvt7Lmxab2HL3Z45tiroAjFx X-Received: by 2002:a17:902:9a41:: with SMTP id x1-v6mr3312463plv.256.1516841878083; Wed, 24 Jan 2018 16:57:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516841878; cv=none; d=google.com; s=arc-20160816; b=GPD+5/2QSyv6K6liwqoILZVlZpANdm02xQh/7ItgSLGzu+yIlXJu5lcvmbDBwOukA3 M2DiENcZ8WA4+aeaVBYkNYdYs76ij9AItTtns0IZYA5mIRVah9BetiWq3Oo7FnY5K/iZ 08RFBB7AAWbnVvFEFnAMQl6y2iXQKyoOcRRnUlhweWgpCFtzFoASd1Vy5LnJ61HKYd8T WCTvHg/jMk8O7aQsvmAvW+gI7ZiwxzlYWYgxocUFArglAR7P5n0xzVtBIBwLeWFADG9w f6CS/XRsL+bCa2lcdpAeiD5yuU09wesojiBU3eSq4RdyM3+NTcwveTQWkCN4WVGrzAl2 lmtg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=wq+LWPWREMPWTha0KuLU0ctpl8oyI66DKfy3rV43WUM=; b=gxOYURER9QfCXQv8m1m0Gsbvg2Qf1s+Yw2S3knkc8hK0IYwGbWh4WOXL3XKoqAWLv2 gZGE8PQ3rXD5WIC9442KK78Wfb+1I36cIkJ6HIA0RR48ep9DPyVux4tOUIq47GJ0dJBN 3xOqTzNzPaeOU32cBQriSl1uBheyv4u9ZtrPcJQYcClWuc94yWqHJayny5E9wo04K5V6 EbnCKRMc2g11nuhmLkGVl6NEd3cs8ZCi0c/eCL8gChDtlIbm4NpfbwiohOwymCdBkjsm xTHPnO617c6os8i+hUV7lVH7zLZf1h9VfheuA4ble5KOcI1nm2fjBJcNCefmuwMFqVJg doiw== ARC-Authentication-Results: i=1; mx.google.com; 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 98-v6si1015407pla.756.2018.01.24.16.57.43; Wed, 24 Jan 2018 16:57:58 -0800 (PST) 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; 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 S933026AbeAYA5S (ORCPT + 99 others); Wed, 24 Jan 2018 19:57:18 -0500 Received: from mga09.intel.com ([134.134.136.24]:55857 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932250AbeAYA5Q (ORCPT ); Wed, 24 Jan 2018 19:57:16 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jan 2018 16:57:15 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,409,1511856000"; d="scan'208";a="22116104" Received: from skl-02.jf.intel.com ([10.54.74.43]) by orsmga003.jf.intel.com with ESMTP; 24 Jan 2018 16:57:15 -0800 From: Tim Chen To: linux-kernel@vger.kernel.org Cc: Tim Chen , KarimAllah Ahmed , Andi Kleen , Andrea Arcangeli , Andy Lutomirski , Arjan van de Ven , Ashok Raj , Asit Mallick , Borislav Petkov , Dan Williams , Dave Hansen , David Woodhouse , 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 Subject: [RFC PATCH 2/2] x86/ibpb: Prevent missed IBPB flush Date: Wed, 24 Jan 2018 16:36:42 -0800 Message-Id: <332d3ac8a7018b98d8182ec86b5fc41239c667c6.1516840211.git.tim.c.chen@linux.intel.com> X-Mailer: git-send-email 2.9.4 In-Reply-To: References: In-Reply-To: References: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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. Suggested-by: Dave Hansen Signed-off-by: Tim Chen --- arch/x86/mm/tlb.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c index 86ed07f..3bdaa10 100644 --- a/arch/x86/mm/tlb.c +++ b/arch/x86/mm/tlb.c @@ -7,6 +7,7 @@ #include #include #include +#include #include #include @@ -291,8 +292,17 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct mm_struct *next, trace_tlb_flush_rcuidle(TLB_FLUSH_ON_TASK_SWITCH, 0); } - if (next != &init_mm && next != last) + if (next != &init_mm && next != last) { + if (last != NULL) + mmdrop(last); + /* + * Keep 'next' allocated until we switch to another mm. + * This keeps us from missing a flush of the branch predictors + * if 'next' gets freed and reallocated. + */ + mmgrab(next); this_cpu_write(cpu_tlbstate.last_usr_mm, next); + } this_cpu_write(cpu_tlbstate.loaded_mm, next); this_cpu_write(cpu_tlbstate.loaded_mm_asid, new_asid); } @@ -370,6 +380,7 @@ void initialize_tlbstate_and_flush(void) write_cr3(build_cr3(mm->pgd, 0)); /* Reinitialize tlbstate. */ + this_cpu_write(cpu_tlbstate.last_usr_mm, NULL); this_cpu_write(cpu_tlbstate.loaded_mm_asid, 0); this_cpu_write(cpu_tlbstate.next_asid, 1); this_cpu_write(cpu_tlbstate.ctxs[0].ctx_id, mm->context.ctx_id); -- 2.9.4