From patchwork Wed Nov 28 00:07:52 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Edgecombe, Rick P" X-Patchwork-Id: 10701655 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 711EA13BB for ; Wed, 28 Nov 2018 00:34:10 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5CFE92C8D3 for ; Wed, 28 Nov 2018 00:34:10 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 4D7342C8D9; Wed, 28 Nov 2018 00:34:10 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D9F7D2C8D3 for ; Wed, 28 Nov 2018 00:34:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E6B446B467B; Tue, 27 Nov 2018 19:34:08 -0500 (EST) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id E1A186B467D; Tue, 27 Nov 2018 19:34:08 -0500 (EST) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D314F6B467E; Tue, 27 Nov 2018 19:34:08 -0500 (EST) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-pg1-f198.google.com (mail-pg1-f198.google.com [209.85.215.198]) by kanga.kvack.org (Postfix) with ESMTP id 91B7D6B467B for ; Tue, 27 Nov 2018 19:34:08 -0500 (EST) Received: by mail-pg1-f198.google.com with SMTP id s27so11092687pgm.4 for ; Tue, 27 Nov 2018 16:34:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-original-authentication-results:x-gm-message-state:from:to:cc :subject:date:message-id:mime-version:content-transfer-encoding; bh=7xmDeFCVUmzpGfR5xxTGZG4UC8V8CPCf10aBiDhMBOc=; b=kcvSHhCo/zmBnXsH4bz/K1kvrQABGZNbN2o93q/jssGz3KMvn/QI2/O89KYwpigXjX VF/OxZ81vhi2otO8CuESQ4h81HFok1AcpegF2wXjYS+z6icGzK9JjzbSYXlQl1IaTIRD uyt6W/o1LM9z5gkTBU3/0GiLUaT+YK3is8NwglYu+ukbxRd6SAebi1MMleLjEhW3b+RJ s9xRWQ4KdKlRFhGKXMFgddEf22LYtxOSqcgYswwvprmJMCwMf75twn0tsBRDjj/Q9lYP YQuCA7cgu0Neo3HBaj7Vnvg7Xpfk343oOt6qLkSE6hzmdYNHoMEbJx0dfTIJUihmMBus 63xQ== X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of rick.p.edgecombe@intel.com designates 192.55.52.151 as permitted sender) smtp.mailfrom=rick.p.edgecombe@intel.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com X-Gm-Message-State: AGRZ1gJK948bc9ir54UqaBQ7ON1GIpLiLPXFLjFGYVbiBSu4xDuwO4dX FNesI/cqKcE4YC3I80NtmXFHPg+o/y7D5Gzp2NYU0yiFyRAThz3tTYqrTsPtUYb7vDf6QG9z/43 65C0xmmEiyRzswo2UTFlvwPq5dSXEBKLVQMlgcJw4cLsDipjHieQYiJ9rRAG02oYjyw== X-Received: by 2002:a62:5003:: with SMTP id e3mr36259146pfb.23.1543365248174; Tue, 27 Nov 2018 16:34:08 -0800 (PST) X-Google-Smtp-Source: AJdET5eqIeyUWlwxk62iwmbrzRU+A9eXpjAV/zaA+qCb45CEBHKH2ARLnPe6k5FEipS3xqmnFK9v X-Received: by 2002:a62:5003:: with SMTP id e3mr36259112pfb.23.1543365247331; Tue, 27 Nov 2018 16:34:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543365247; cv=none; d=google.com; s=arc-20160816; b=bv1DAepsvWbqtZMJHgA8Os3Mx7DOPZS+ec/85QVZ8IxMxtiG8RLoi+VlkwI55prjXb 5KHRPGVxIoJp1wA1rPdj0gFHjPBKc5iGevWQHiV0Gf+HTaQwLbDXy9/iutEB4S51qJy+ jJIgiOJrSsxEarYz/d79h4mZ+PkF3i8ANWEL38bc8CwNBOpGAvHnekBq01gN5OyH1cZG 1y7UDvAN32wK9e1ZfwEKyZL9zq5OzW3mKMvhx3qy0N7RPxb2w14L3AEeOO0MNeZrHaxa LR6H0aWLUggI1pZ4hteZt505U/Ni74jg87S5J3i7zo7Rm6RaMGeZZwYM0Fx3VEh4kbJc BoaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from; bh=7xmDeFCVUmzpGfR5xxTGZG4UC8V8CPCf10aBiDhMBOc=; b=U+wGh5Q3VNAvem0U9qeGloeYlx4ZGkT2MLp2PsHHXUWL+J03kyiyXnDUkx3YZ3isfo v35SeIHN7NxyJmzGAv/KukUHIyNr110YnwFtaJ/puMzepwU3/HTRkyzuZ52JBZ/icM8M qnXhCf6lP4FyNuJM2GFT53yF7E0WcyjFCyXzcfrLb16433ug/qhSHMWbOuA/6j5RRZ9a NK0wKggrIv/BvUy4WcQm+DnQdwNM5f7R+mzoX6Kouei1GVY47xhYwclqsRQshZVQAmmP OCwb/uyW0TI1qHtkKB2nPQE8F06B2jBWy8xRsnR+piBB69e4/v5i4ryTWyc/zH3kEvRs p9mg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of rick.p.edgecombe@intel.com designates 192.55.52.151 as permitted sender) smtp.mailfrom=rick.p.edgecombe@intel.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from mga17.intel.com (mga17.intel.com. [192.55.52.151]) by mx.google.com with ESMTPS id s5si5346864pfi.134.2018.11.27.16.34.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Nov 2018 16:34:07 -0800 (PST) Received-SPF: pass (google.com: domain of rick.p.edgecombe@intel.com designates 192.55.52.151 as permitted sender) client-ip=192.55.52.151; Authentication-Results: mx.google.com; spf=pass (google.com: domain of rick.p.edgecombe@intel.com designates 192.55.52.151 as permitted sender) smtp.mailfrom=rick.p.edgecombe@intel.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Nov 2018 16:34:06 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,288,1539673200"; d="scan'208";a="91641474" Received: from rpedgeco-desk5.jf.intel.com ([10.54.75.128]) by fmsmga007.fm.intel.com with ESMTP; 27 Nov 2018 16:34:06 -0800 From: Rick Edgecombe To: akpm@linux-foundation.org, luto@kernel.org, will.deacon@arm.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com, naveen.n.rao@linux.vnet.ibm.com, anil.s.keshavamurthy@intel.com, davem@davemloft.net, mhiramat@kernel.org, rostedt@goodmis.org, mingo@redhat.com, ast@kernel.org, daniel@iogearbox.net, jeyu@kernel.org, netdev@vger.kernel.org, ard.biesheuvel@linaro.org, jannh@google.com Cc: kristen@linux.intel.com, dave.hansen@intel.com, deneen.t.dock@intel.com, Rick Edgecombe Subject: =?utf-8?q?=5BPATCH_0/2=5D_Don=E2=80=99t_leave_executable_TLB_entrie?= =?utf-8?q?s_to_freed_pages?= Date: Tue, 27 Nov 2018 16:07:52 -0800 Message-Id: <20181128000754.18056-1-rick.p.edgecombe@intel.com> X-Mailer: git-send-email 2.17.1 MIME-Version: 1.0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: X-Virus-Scanned: ClamAV using ClamSMTP Sometimes when memory is freed via the module subsystem, an executable permissioned TLB entry can remain to a freed page. If the page is re-used to back an address that will receive data from userspace, it can result in user data being mapped as executable in the kernel. The root of this behavior is vfree lazily flushing the TLB, but not lazily freeing the underlying pages. There are sort of three categories of this which show up across modules, bpf, kprobes and ftrace: 1. When executable memory is touched and then immediatly freed This shows up in a couple error conditions in the module loader and BPF JIT compiler. 2. When executable memory is set to RW right before being freed In this case (on x86 and probably others) there will be a TLB flush when its set to RW and so since the pages are not touched between setting the flush and the free, it should not be in the TLB in most cases. So this category is not as big of a concern. However, techinically there is still a race where an attacker could try to keep it alive for a short window with a well timed out-of-bound read or speculative read, so ideally this could be blocked as well. 3. When executable memory is freed in an interrupt At least one example of this is the freeing of init sections in the module loader. Since vmalloc reuses the allocation for the work queue linked list node for the deferred frees, the memory actually gets touched as part of the vfree operation and so returns to the TLB even after the flush from resetting the permissions. I have only actually tested category 1, and identified 2 and 3 just from reading the code. To catch all of these, module_alloc for x86 is changed to use a new flag that instructs the unmap operation to flush the TLB before freeing the pages. If this solution seems good I can plug the flag in for other architectures that define PAGE_KERNEL_EXEC. Rick Edgecombe (2): vmalloc: New flag for flush before releasing pages x86/modules: Make x86 allocs to flush when free arch/x86/kernel/module.c | 4 ++-- include/linux/vmalloc.h | 1 + mm/vmalloc.c | 13 +++++++++++-- 3 files changed, 14 insertions(+), 4 deletions(-)