Received: by 2002:ac0:8c9a:0:0:0:0:0 with SMTP id r26csp4859251ima; Tue, 5 Feb 2019 02:28:45 -0800 (PST) X-Google-Smtp-Source: AHgI3IZ0G1JYCWZpWeBQ1mHyBvHzLH4PxB0wYE+KJsWk8oRNcebBuO+sDWXJK4dvmSVyQ4tw3VjG X-Received: by 2002:a65:60c5:: with SMTP id r5mr3894256pgv.427.1549362525589; Tue, 05 Feb 2019 02:28:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549362525; cv=none; d=google.com; s=arc-20160816; b=usTB1g7iLTb/RPLRKpr1KFs/Xw+yEdlGxBucqVM+bU++r7ynLlD7OQoKw0pKFPsV19 9sBnVXT23Jg9qVqs2ha8UlDDkmSbgz4Lt06Cw3mo4Fpprw6nkEqgDJTx18BrL8bgf5P8 MpDUYcwJSytUjvgrDMOV1QYC2TgwSAMztW47LQJ4F1UFvB2cNQVHgnXsAklh8xnRxaeT 6MnwAFPnvxSkq08gqOASPdLVHhHJ+pDgweUE8B2gYx7JC2tlrMSVXTa53+UWHfDvH7yk Hcm4vMrpwxXNb2/xGSlIi8ZyitP6G2d5I0yOkxx9b7qkgjZ1ISXJI0cYDdtCcvCIz8s4 G1yQ== 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=4WLWE+J0DRMfgxDveUBu3Q4pEbwtQo3nPkdUwTDOryU=; b=JqQSmE0yl94luuPKj7t21gwf3FDuXZQQ0X48Allx5xkpkkv6iU8yAFVf5skGxOBP6a 6yyn/+Jef5wcAV+TGku0jXeN0kHxs+MgiBDsI+ghW0Y3+D7ds94Ou+6UHuJ70dTwez6h DtkbBDix1LxZiyyTQHR3emLtR8YobUEjpt1NGmLWl7IWo5LX2bqz4Ka205i8QCzqpfkp s+hEe5dllRprvy1J5F22gcwWrK7Sbay7qPsc+XZ+EaXYmN7QE9fFGHV20SIMapaxKCKy eG4R3yF7T0VfFBKiBijT0rXKSf4VYoJt0TsbSKeqR0NnuejfJF60Zrl8xyp6EDp8C8Au UiKw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b="sN+VAMR/"; 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=alien8.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v11si2607702pgr.20.2019.02.05.02.28.29; Tue, 05 Feb 2019 02:28:45 -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; dkim=pass header.i=@alien8.de header.s=dkim header.b="sN+VAMR/"; 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=alien8.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728777AbfBEJ7F (ORCPT + 99 others); Tue, 5 Feb 2019 04:59:05 -0500 Received: from mail.skyhub.de ([5.9.137.197]:55272 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727127AbfBEJ7F (ORCPT ); Tue, 5 Feb 2019 04:59:05 -0500 Received: from zn.tnic (p200300EC2BCB6B0041C3B5D5EB4D55D2.dip0.t-ipconnect.de [IPv6:2003:ec:2bcb:6b00:41c3:b5d5:eb4d:55d2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 617901EC02AE; Tue, 5 Feb 2019 10:59:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1549360743; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=4WLWE+J0DRMfgxDveUBu3Q4pEbwtQo3nPkdUwTDOryU=; b=sN+VAMR/+p82N2cesfhrBJmbYaaoU6yls9h3YT7v4jao9kNIG/tcUSCbuxKb/0uVV9erWV 4hRsw4aqxnrrRj4e8lwlE5VFodJOJK/dg/QuzXN/u4AmU8FxMDHrO8Yi/CrlUmQLYakWNr BlG/qnD7KImItVvOV94cFbrLYko4xMg= Date: Tue, 5 Feb 2019 10:58:53 +0100 From: Borislav Petkov To: Rick Edgecombe Cc: Andy Lutomirski , Ingo Molnar , linux-kernel@vger.kernel.org, x86@kernel.org, hpa@zytor.com, Thomas Gleixner , Nadav Amit , Dave Hansen , Peter Zijlstra , linux_dti@icloud.com, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, akpm@linux-foundation.org, kernel-hardening@lists.openwall.com, linux-mm@kvack.org, will.deacon@arm.com, ard.biesheuvel@linaro.org, kristen@linux.intel.com, deneen.t.dock@intel.com, Nadav Amit , Kees Cook , Dave Hansen , Masami Hiramatsu Subject: Re: [PATCH v2 06/20] x86/alternative: use temporary mm for text poking Message-ID: <20190205095853.GJ21801@zn.tnic> References: <20190129003422.9328-1-rick.p.edgecombe@intel.com> <20190129003422.9328-7-rick.p.edgecombe@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190129003422.9328-7-rick.p.edgecombe@intel.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 28, 2019 at 04:34:08PM -0800, Rick Edgecombe wrote: > From: Nadav Amit > > text_poke() can potentially compromise the security as it sets temporary s/the // > PTEs in the fixmap. These PTEs might be used to rewrite the kernel code > from other cores accidentally or maliciously, if an attacker gains the > ability to write onto kernel memory. Eww, sneaky. That would be a really nasty attack. > Moreover, since remote TLBs are not flushed after the temporary PTEs are > removed, the time-window in which the code is writable is not limited if > the fixmap PTEs - maliciously or accidentally - are cached in the TLB. > To address these potential security hazards, we use a temporary mm for > patching the code. > > Finally, text_poke() is also not conservative enough when mapping pages, > as it always tries to map 2 pages, even when a single one is sufficient. > So try to be more conservative, and do not map more than needed. > > Cc: Andy Lutomirski > Cc: Kees Cook > Cc: Dave Hansen > Cc: Masami Hiramatsu > Acked-by: Peter Zijlstra (Intel) > Signed-off-by: Nadav Amit > Signed-off-by: Rick Edgecombe > --- > arch/x86/include/asm/fixmap.h | 2 - > arch/x86/kernel/alternative.c | 106 +++++++++++++++++++++++++++------- > arch/x86/xen/mmu_pv.c | 2 - > 3 files changed, 84 insertions(+), 26 deletions(-) > > diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h > index 50ba74a34a37..9da8cccdf3fb 100644 > --- a/arch/x86/include/asm/fixmap.h > +++ b/arch/x86/include/asm/fixmap.h > @@ -103,8 +103,6 @@ enum fixed_addresses { > #ifdef CONFIG_PARAVIRT > FIX_PARAVIRT_BOOTMAP, > #endif > - FIX_TEXT_POKE1, /* reserve 2 pages for text_poke() */ > - FIX_TEXT_POKE0, /* first page is last, because allocation is backward */ Two fixmap slots less - good riddance. :) > #ifdef CONFIG_X86_INTEL_MID > FIX_LNW_VRTC, > #endif > diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c > index ae05fbb50171..76d482a2b716 100644 > --- a/arch/x86/kernel/alternative.c > +++ b/arch/x86/kernel/alternative.c > @@ -11,6 +11,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -683,41 +684,102 @@ __ro_after_init unsigned long poking_addr; > > static void *__text_poke(void *addr, const void *opcode, size_t len) > { > + bool cross_page_boundary = offset_in_page(addr) + len > PAGE_SIZE; > + temporary_mm_state_t prev; > + struct page *pages[2] = {NULL}; > unsigned long flags; > - char *vaddr; > - struct page *pages[2]; > - int i; > + pte_t pte, *ptep; > + spinlock_t *ptl; > + pgprot_t prot; > > /* > - * While boot memory allocator is runnig we cannot use struct > - * pages as they are not yet initialized. > + * While boot memory allocator is running we cannot use struct pages as > + * they are not yet initialized. > */ > BUG_ON(!after_bootmem); > > if (!core_kernel_text((unsigned long)addr)) { > pages[0] = vmalloc_to_page(addr); > - pages[1] = vmalloc_to_page(addr + PAGE_SIZE); > + if (cross_page_boundary) > + pages[1] = vmalloc_to_page(addr + PAGE_SIZE); > } else { > pages[0] = virt_to_page(addr); > WARN_ON(!PageReserved(pages[0])); > - pages[1] = virt_to_page(addr + PAGE_SIZE); > + if (cross_page_boundary) > + pages[1] = virt_to_page(addr + PAGE_SIZE); > } > - BUG_ON(!pages[0]); > + BUG_ON(!pages[0] || (cross_page_boundary && !pages[1])); checkpatch fires a lot for this patchset and I think we should tone down the BUG_ON() use. WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() #116: FILE: arch/x86/kernel/alternative.c:711: + BUG_ON(!pages[0] || (cross_page_boundary && !pages[1])); While the below BUG_ON makes sense, this here could be a WARN_ON or so. Which begs the next question: AFAICT, nothing looks at text_poke*()'s retval. So why are we even bothering returning something? > + > local_irq_save(flags); > - set_fixmap(FIX_TEXT_POKE0, page_to_phys(pages[0])); > - if (pages[1]) > - set_fixmap(FIX_TEXT_POKE1, page_to_phys(pages[1])); > - vaddr = (char *)fix_to_virt(FIX_TEXT_POKE0); > - memcpy(&vaddr[(unsigned long)addr & ~PAGE_MASK], opcode, len); > - clear_fixmap(FIX_TEXT_POKE0); > - if (pages[1]) > - clear_fixmap(FIX_TEXT_POKE1); > - local_flush_tlb(); > - sync_core(); > - /* Could also do a CLFLUSH here to speed up CPU recovery; but > - that causes hangs on some VIA CPUs. */ > - for (i = 0; i < len; i++) > - BUG_ON(((char *)addr)[i] != ((char *)opcode)[i]); > + > + /* > + * The lock is not really needed, but this allows to avoid open-coding. > + */ > + ptep = get_locked_pte(poking_mm, poking_addr, &ptl); > + > + /* > + * This must not fail; preallocated in poking_init(). > + */ > + VM_BUG_ON(!ptep); > + > + /* > + * flush_tlb_mm_range() would be called when the poking_mm is not > + * loaded. When PCID is in use, the flush would be deferred to the time > + * the poking_mm is loaded again. Set the PTE as non-global to prevent > + * it from being used when we are done. > + */ > + prot = __pgprot(pgprot_val(PAGE_KERNEL) & ~_PAGE_GLOBAL); So _KERNPG_TABLE | _PAGE_NX as this is pagetable page, AFAICT. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.