Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp288477imm; Mon, 2 Jul 2018 11:31:16 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdSWcPvP8YVTEvp3GlQ0WzlPp+NZNYY25010lBoBnFsbe2/gdz6gmq2O9wUjxhcxm/uEuTv X-Received: by 2002:a63:440a:: with SMTP id r10-v6mr2047922pga.27.1530556276898; Mon, 02 Jul 2018 11:31:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530556276; cv=none; d=google.com; s=arc-20160816; b=gZ6C2ZiuVnP3rFwMG+KyC/T4kC7Dx333qiFflIPCqkQsQkYbGmmxbPoDAamtC50qx5 YQgU3TM08PQL21xlnLvRIv74id25CJ0qimAnJSb2OOQxp8iomHTveHcCaNREpNX0Xd/Y Q6LZAUebC9nCA6C6zO5Y7+8tZGzbIMZml1uYSqmn5b4Q1EmUY847U+ZJ74qeh8aa0MTN K3/MgbmpdLo+63YaTMEziBsCj8zAAeShiaqlS6v9T78hABmssvNGRLsQ5UnfgThGoDx/ qnHlRSq2P81aM5Q1QQQSYjluHN86l6J2NJwITTJ0P79YEcAF8PRYZkjP/lLqc86F1YfK byrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=qx4WHmIBRsW6WEfFM7RA8/FczRIZE7LVfDizuJGrzbU=; b=YpolWnivvtYVJDO10Ae0VhWPmYwCylkZEpS8HrhoKLvwIVdl7aZFvGBoRH/nDLh+ln rOuZ3Hk1UVw8hIfgEuFNhrjWt1gy0d3+jDf2QFSeMCDXcuHZgxTrE/ecbPd7tWkZeu6c NMIeu+D35cdWPXHcmPERq5wTnN9CE+wMdevxaqZyPRrwYD6sMS8QTfiksCfIJr0Qv4II Dt44D4cJKLWrevabLcKx9t5qZPP4VXJvh/B6bwapD1g06D3TDtY/mbHX/0YOtLukttaa 17p3ASxKO5YpD/jJnkwxxJSzWfxzuhftNvJvqZCeu8tamwQ3JPXlsz+UUxxwRPeKW3Fa 4/6g== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@google.com header.s=20161025 header.b=hlgjSJxa; dkim=fail header.i=@chromium.org header.s=google header.b=i80AfjIh; 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=fail (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x185-v6si13986482pfx.16.2018.07.02.11.31.02; Mon, 02 Jul 2018 11:31:16 -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=fail header.i=@google.com header.s=20161025 header.b=hlgjSJxa; dkim=fail header.i=@chromium.org header.s=google header.b=i80AfjIh; 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=fail (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932105AbeGBSaC (ORCPT + 99 others); Mon, 2 Jul 2018 14:30:02 -0400 Received: from mail-yw0-f195.google.com ([209.85.161.195]:41046 "EHLO mail-yw0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753391AbeGBS35 (ORCPT ); Mon, 2 Jul 2018 14:29:57 -0400 Received: by mail-yw0-f195.google.com with SMTP id j5-v6so6995329ywe.8 for ; Mon, 02 Jul 2018 11:29:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=qx4WHmIBRsW6WEfFM7RA8/FczRIZE7LVfDizuJGrzbU=; b=hlgjSJxa70aSpblPHYG1oApC3B5i8l0056wBh+Kj1K+/0aH2jeaxQUPLb4JWGjoSwt /DBkiNaXEG+FsJk0ZRED4r8gIoHZmX3s6iR12Je/oANJ+9ACco4Pxtdb5V1GS3ycOJIU 36S5V+N9q571heiJ2KN7Mb6df1X1eYxS6PaA6t1dl/jPrfP9hYpqd97qu7HihALkfypq Fhe4466DDY/ZbzvfuLkw3JUnK7rR869os4vsz+vQo5KgEgJ/H1phgxZtxYAjEODE8waC /gnTAdI0gnsX7afdm/5LT8c6r6ucgC8dKZf+HWZ5EKpHoTKghmK/z6/4bYXJ6E7AymyD R0Tg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=qx4WHmIBRsW6WEfFM7RA8/FczRIZE7LVfDizuJGrzbU=; b=i80AfjIhhNa6WmwMWHEGBWADQX87uoJGkuutIZk8aGsUsPyGGuQdTf3OZGk6heLDS3 zUUAyfAclElRBaMuN07oDCawrKsKphXiPDxdfdIZRZSnN2mNyIMjq/A6SQXkxR8lkfSn r34gXmxuQx/EpRbmoW8lvx7MJllDtKKUTqr0Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=qx4WHmIBRsW6WEfFM7RA8/FczRIZE7LVfDizuJGrzbU=; b=LmSuyuqsFiNaHNUNofpJI3D61/qNoDZVjgXiQ/4Dla2N108HxWWfL6OyEtOjwlbafE i4kUmlcaYZSVqDbpp0vKBvsKVktcPKntzKrzonu6hPharhoZXvugvyu1UJHVZmw6k5+D PFkM2zIGHLsu9a4+wIbX4yRmFgGfW9ZDUuRE6y/WPEMiYSTIj6HOrMhLxHW9dZWzmLqy 7054kO7fCAIErx2NERa09MTzdu+zLWTnDyOw+GYIXknDg5oUPTe0IdmsPxvLY1g56TKw V3IW/52uni+ROF410D5sEe5nM+xfrdw9CEQty6GmvcVh86y4mF/oQwfSNmMqXvpxYgQo E/nA== X-Gm-Message-State: APt69E2syRvsK9mcVAmfjR2qWD/ehzA7GmgER0jLhvPWEwEFLfWxjRRd xVkHj0750F152BMTFZptd6ntkkvntjq/ao5xlYW5FUn9 X-Received: by 2002:a81:2706:: with SMTP id n6-v6mr12712842ywn.88.1530556196406; Mon, 02 Jul 2018 11:29:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:5f51:0:0:0:0:0 with HTTP; Mon, 2 Jul 2018 11:29:55 -0700 (PDT) In-Reply-To: <20180702181145.4799-9-ard.biesheuvel@linaro.org> References: <20180702181145.4799-1-ard.biesheuvel@linaro.org> <20180702181145.4799-9-ard.biesheuvel@linaro.org> From: Kees Cook Date: Mon, 2 Jul 2018 11:29:55 -0700 X-Google-Sender-Auth: 0a3oy8fe3iFvbt1dMcv-ThcPeHA Message-ID: Subject: Re: [PATCH v2 8/8] jump_table: move entries into ro_after_init region To: Ard Biesheuvel Cc: linux-arm-kernel , LKML , linux-s390 , linux-arch , Arnd Bergmann , Heiko Carstens , Will Deacon , Thomas Gleixner , Catalin Marinas , Ingo Molnar , Steven Rostedt , Martin Schwidefsky , Jessica Yu , Peter Zijlstra Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 2, 2018 at 11:11 AM, Ard Biesheuvel wrote: > The __jump_table sections emitted into the core kernel and into > each module consist of statically initialized references into > other parts of the code, and with the exception of entries that > point into init code, which are defused at post-init time, these > data structures are never modified. > > So let's move them into the ro_after_init section, to prevent them > from being corrupted inadvertently by buggy code, or deliberately > by an attacker. > > Signed-off-by: Ard Biesheuvel Yay more things read-only! :) Reviewed-by: Kees Cook > --- > arch/arm/kernel/vmlinux-xip.lds.S | 1 + > arch/s390/kernel/vmlinux.lds.S | 1 + > include/asm-generic/vmlinux.lds.h | 11 +++++++---- > kernel/module.c | 9 +++++++++ > 4 files changed, 18 insertions(+), 4 deletions(-) > > diff --git a/arch/arm/kernel/vmlinux-xip.lds.S b/arch/arm/kernel/vmlinux-xip.lds.S > index 3593d5c1acd2..763c41068ecc 100644 > --- a/arch/arm/kernel/vmlinux-xip.lds.S > +++ b/arch/arm/kernel/vmlinux-xip.lds.S > @@ -118,6 +118,7 @@ SECTIONS > RW_DATA_SECTION(L1_CACHE_BYTES, PAGE_SIZE, THREAD_SIZE) > .data.ro_after_init : AT(ADDR(.data.ro_after_init) - LOAD_OFFSET) { > *(.data..ro_after_init) > + JUMP_TABLE_DATA > } > _edata = .; > > diff --git a/arch/s390/kernel/vmlinux.lds.S b/arch/s390/kernel/vmlinux.lds.S > index f0414f52817b..a7cf61e46f88 100644 > --- a/arch/s390/kernel/vmlinux.lds.S > +++ b/arch/s390/kernel/vmlinux.lds.S > @@ -67,6 +67,7 @@ SECTIONS > __start_ro_after_init = .; > .data..ro_after_init : { > *(.data..ro_after_init) > + JUMP_TABLE_DATA > } > EXCEPTION_TABLE(16) > . = ALIGN(PAGE_SIZE); > diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h > index e373e2e10f6a..ed6befa4c47b 100644 > --- a/include/asm-generic/vmlinux.lds.h > +++ b/include/asm-generic/vmlinux.lds.h > @@ -256,10 +256,6 @@ > STRUCT_ALIGN(); \ > *(__tracepoints) \ > /* implement dynamic printk debug */ \ > - . = ALIGN(8); \ > - __start___jump_table = .; \ > - KEEP(*(__jump_table)) \ > - __stop___jump_table = .; \ > . = ALIGN(8); \ > __start___verbose = .; \ > KEEP(*(__verbose)) \ > @@ -303,6 +299,12 @@ > . = __start_init_task + THREAD_SIZE; \ > __end_init_task = .; > > +#define JUMP_TABLE_DATA \ > + . = ALIGN(8); \ > + __start___jump_table = .; \ > + KEEP(*(__jump_table)) \ > + __stop___jump_table = .; > + > /* > * Allow architectures to handle ro_after_init data on their > * own by defining an empty RO_AFTER_INIT_DATA. > @@ -311,6 +313,7 @@ > #define RO_AFTER_INIT_DATA \ > __start_ro_after_init = .; \ > *(.data..ro_after_init) \ > + JUMP_TABLE_DATA \ > __end_ro_after_init = .; > #endif > > diff --git a/kernel/module.c b/kernel/module.c > index 7cb82e0fcac0..0d4e320e41cd 100644 > --- a/kernel/module.c > +++ b/kernel/module.c > @@ -3349,6 +3349,15 @@ static struct module *layout_and_allocate(struct load_info *info, int flags) > * Note: ro_after_init sections also have SHF_{WRITE,ALLOC} set. > */ > ndx = find_sec(info, ".data..ro_after_init"); > + if (ndx) > + info->sechdrs[ndx].sh_flags |= SHF_RO_AFTER_INIT; > + /* > + * Mark the __jump_table section as ro_after_init as well: these data > + * structures are never modified, with the exception of entries that > + * refer to code in the __init section, which are annotated as such > + * at module load time. > + */ > + ndx = find_sec(info, "__jump_table"); > if (ndx) > info->sechdrs[ndx].sh_flags |= SHF_RO_AFTER_INIT; > > -- > 2.17.1 > -- Kees Cook Pixel Security