From patchwork Wed Aug 15 20:30:16 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rick Edgecombe X-Patchwork-Id: 10566807 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 3484214E1 for ; Wed, 15 Aug 2018 20:34:48 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id EA7592ACA9 for ; Wed, 15 Aug 2018 20:34:47 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id DE4D82AD66; Wed, 15 Aug 2018 20:34:47 +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=-5.2 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.wl.linuxfoundation.org (Postfix) with SMTP id 506832ACA9 for ; Wed, 15 Aug 2018 20:34:45 +0000 (UTC) Received: (qmail 15562 invoked by uid 550); 15 Aug 2018 20:34:33 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Delivered-To: mailing list kernel-hardening@lists.openwall.com Received: (qmail 15539 invoked from network); 15 Aug 2018 20:34:32 -0000 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,244,1531810800"; d="scan'208";a="224930391" From: Rick Edgecombe To: tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel-hardening@lists.openwall.com, daniel@iogearbox.net, jannh@google.com, keescook@chromium.org Cc: kristen@linux.intel.com, dave.hansen@intel.com, arjan@linux.intel.com, Rick Edgecombe Subject: [PATCH v3 0/3] KASLR feature to randomize each loadable module Date: Wed, 15 Aug 2018 13:30:16 -0700 Message-Id: <1534365020-18943-1-git-send-email-rick.p.edgecombe@intel.com> X-Mailer: git-send-email 2.7.4 X-Virus-Scanned: ClamAV using ClamSMTP Hi, This is V3 of the "KASLR feature to randomize each loadable module" patchset. The purpose is to increase the randomization and also to make the modules randomized in relation to each other instead of just the base, so that if one module leaks the location of the others can't be inferred. V3 is a code cleanup from the V2 I had sent out RFC. The performance and memory usage is the same as V2, in summary: - Average allocation 2-4 times better than existing algorithm - Max allocation time usually faster than the existing algorithm - TLB flushes close to existing algorithm, within 1% for <1000 modules, - Memory usage (for PTEs) usually ~1MB higher than existing algorithm - Average module capacity slightly reduced, in the range of 17000 for both For runtime performance, a synthetic benchmark was run that does 5000000 BPF JIT invocations each, from varying numbers of parallel processes, while the kernel compiles sharing the same CPU to stand in for the cache impact of a real workload. The seccomp filter invocations were just Jann Horn's seccomp filtering test from this thread http://openwall.com/lists/kernel-hardening/2018/07/18/2, except non-real time priority. The kernel was configured with KPTI and retpoline, and pcid was disabled. There wasn't any significant difference between the new and the old. Changes for V3: - Code cleanup based on internal feedback. (thanks to Dave Hansen and Andriy Shevchenko) - Slight refactor of existing algorithm to more cleanly live along side new one. - BPF synthetic benchmark Changes for V2: - New implementation of __vmalloc_node_try_addr based on the __vmalloc_node_range implementation, that only flushes TLB when needed. - Modified module loading algorithm to try to reduce the TLB flushes further. - Increase "random area" tries in order to increase the number of modules that can get high randomness. - Increase "random area" size to 2/3 of module area in order to increase the number of modules that can get high randomness. - Fix for 0day failures on other architectures. - Fix for wrong debugfs permissions. (thanks to Jann Horn) - Spelling fix. (thanks to Jann Horn) - Data on module_alloc performance and TLB flushes. (brought up by Kees Cook and Jann Horn) - Data on memory usage. (suggested by Jann) Rick Edgecombe (3): vmalloc: Add __vmalloc_node_try_addr function x86/modules: Increase randomization for modules vmalloc: Add debugfs modfraginfo arch/x86/include/asm/pgtable_64_types.h | 7 + arch/x86/kernel/module.c | 163 ++++++++++++++++--- include/linux/vmalloc.h | 3 + mm/vmalloc.c | 266 +++++++++++++++++++++++++++++++- 4 files changed, 415 insertions(+), 24 deletions(-)