Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp209036imm; Wed, 29 Aug 2018 18:41:14 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYWf5IayjuY4te8qyuLPP9Prh/5PvhSBu9vQPUSiDDqha1psJLBPjgbebSKgvWe8j/1oVOo X-Received: by 2002:a17:902:59cf:: with SMTP id d15-v6mr8285267plj.184.1535593274920; Wed, 29 Aug 2018 18:41:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535593274; cv=none; d=google.com; s=arc-20160816; b=M8WqgGu4IaxYhhkBQA2RkXZRmhyJnatm6HCsMnFY7CjGAB1CPhje1hC24OIkVSfzcO 3ww+C+LJ4v+HJZJKeQclCQIKkBaH/57/Ec770ObV8GMec7kIUmLFeUgrqzBL4uqCkVYf fGcQ5ayMFnsyoslEd2PR2Gd7UFao2zO4EJyShLnG1nkXC2kIqWzquhTrwRlDTYzifAgQ LKWO98JnZx+LjugEf666oBuzc2tDG0Ymh4WlVxtoJr47+pct/NnjASwLzP7UkhiVfFxS 8dYVwP/5QMC11HSxEFyACGbD2XXbIltFBjTtpzcVOflCrgIiTCQfyxKsDKuTbEN9Wor4 WIXQ== 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:message-id:subject:cc:to:from:date :dkim-signature:arc-authentication-results; bh=e7hHm74WnU8vmwOerZOqspRXIsBrOuUW+bBY1pDgfk8=; b=Hf7u1fJ2dbri6+6O3LfwdyYkBZODNcXmmym4fTjhGr3nc6BlHn9n+mvLT94uq4quwY Y1ecQ9XnHq8KdSrSP5S+Zh3vqIpCf6JKvoUb6kdFjw0WrbF/ryb2VnHF2oiYg7R1x783 zjDsSvIp1RVS61/kf5AzzSy04AwVsiJQSCGaIJPLxF+tRW6iM0XcyxaDTZIEY9y/hOTU n5I2ZECZbBEK1Vf7EdQDTEPYbHatUTAtxlBJONpp9BhgPM1/hhxVl3V3+9c+/2EnX/Gr 8WdXjrmbEzEGnRX1FX2iX+hZzemit+Sc+9tdU5ZhtsSx9rGesZZapQxhSf/j26p+Jci2 8t1w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Zj3uL4mo; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f186-v6si5618165pfa.336.2018.08.29.18.41.00; Wed, 29 Aug 2018 18:41:14 -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=@kernel.org header.s=default header.b=Zj3uL4mo; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727555AbeH3Fim (ORCPT + 99 others); Thu, 30 Aug 2018 01:38:42 -0400 Received: from mail.kernel.org ([198.145.29.99]:39558 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726169AbeH3Fim (ORCPT ); Thu, 30 Aug 2018 01:38:42 -0400 Received: from devbox (NE2965lan1.rev.em-net.ne.jp [210.141.244.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B65D920647; Thu, 30 Aug 2018 01:39:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1535593143; bh=8VlH8e8j2cWDJs9IABSd5/ciDypp8K7ukiOk3NJaHAE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Zj3uL4mopCYWNyOGbCZxST7/BgQSQ4Ijlk2bHjO0Or977olW+02NjRbrMVcW5mFTN iJmhwJcARnz1n+fCI2z2Pkt9y6n0ACUn5HgkhhPaEq5YMXsz3IYW5i83f7SjWAIxB1 zAy0yHWUVhmh2+zNCXB3t2dS7V8NmH+8peL1UL6c= Date: Thu, 30 Aug 2018 10:38:59 +0900 From: Masami Hiramatsu To: Andy Lutomirski Cc: Nadav Amit , Thomas Gleixner , LKML , Ingo Molnar , X86 ML , Arnd Bergmann , linux-arch , Kees Cook , Peter Zijlstra Subject: Re: [RFC PATCH 2/6] x86/mm: temporary mm struct Message-Id: <20180830103859.ac309b71c53d267da2f6e9f8@kernel.org> In-Reply-To: References: <20180829081147.184610-1-namit@vmware.com> <20180829081147.184610-3-namit@vmware.com> <20180829184925.64caee4dadf705080373f84f@kernel.org> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 29 Aug 2018 08:41:00 -0700 Andy Lutomirski wrote: > On Wed, Aug 29, 2018 at 2:49 AM, Masami Hiramatsu wrote: > > On Wed, 29 Aug 2018 01:11:43 -0700 > > Nadav Amit wrote: > > > >> From: Andy Lutomirski > >> > >> Sometimes we want to set a temporary page-table entries (PTEs) in one of > >> the cores, without allowing other cores to use - even speculatively - > >> these mappings. There are two benefits for doing so: > >> > >> (1) Security: if sensitive PTEs are set, temporary mm prevents their use > >> in other cores. This hardens the security as it prevents exploding a > >> dangling pointer to overwrite sensitive data using the sensitive PTE. > >> > >> (2) Avoiding TLB shootdowns: the PTEs do not need to be flushed in > >> remote page-tables. > >> > >> To do so a temporary mm_struct can be used. Mappings which are private > >> for this mm can be set in the userspace part of the address-space. > >> During the whole time in which the temporary mm is loaded, interrupts > >> must be disabled. > >> > >> The first use-case for temporary PTEs, which will follow, is for poking > >> the kernel text. > >> > >> [ Commit message was written by Nadav ] > >> > >> Cc: Andy Lutomirski > >> Cc: Masami Hiramatsu > >> Cc: Kees Cook > >> Cc: Peter Zijlstra > >> Signed-off-by: Nadav Amit > >> --- > >> arch/x86/include/asm/mmu_context.h | 20 ++++++++++++++++++++ > >> 1 file changed, 20 insertions(+) > >> > >> diff --git a/arch/x86/include/asm/mmu_context.h b/arch/x86/include/asm/mmu_context.h > >> index eeeb9289c764..96afc8c0cf15 100644 > >> --- a/arch/x86/include/asm/mmu_context.h > >> +++ b/arch/x86/include/asm/mmu_context.h > >> @@ -338,4 +338,24 @@ static inline unsigned long __get_current_cr3_fast(void) > >> return cr3; > >> } > >> > >> +typedef struct { > >> + struct mm_struct *prev; > >> +} temporary_mm_state_t; > >> + > >> +static inline temporary_mm_state_t use_temporary_mm(struct mm_struct *mm) > >> +{ > >> + temporary_mm_state_t state; > >> + > >> + lockdep_assert_irqs_disabled(); > >> + state.prev = this_cpu_read(cpu_tlbstate.loaded_mm); > >> + switch_mm_irqs_off(NULL, mm, current); > >> + return state; > >> +} > > > > Hmm, why don't we return mm_struct *prev directly? > > I did it this way to make it easier to add future debugging stuff > later. Also, when I first wrote this, I stashed the old CR3 instead > of the old mm_struct, and it seemed like callers should be insulated > from details like this. Hmm, I see. But in that case, we should call it "struct temporary_mm" and explicitly allocate (and pass) it, since we can not return the data structure from stack. If we can combine it with new mm, it will be more encapsulated e.g. struct temporary_mm { struct mm_struct *mm; struct mm_struct *prev; }; static struct temporary_mm poking_tmp_mm; poking_init() { if (init_temporary_mm(&tmp_mm, &init_mm)) goto error; ... } text_poke_safe() { ... use_temporary_mm(&tmp_mm); ... unuse_temporary_mm(&tmp_mm); } Any thought? Thanks, -- Masami Hiramatsu