linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Kernel Hardening <kernel-hardening@lists.openwall.com>,
	Laura Abbott <labbott@redhat.com>,
	"the arch/x86 maintainers" <x86@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 04/20] gcc-plugins: Add the randstruct plugin
Date: Thu, 29 Jun 2017 15:53:02 -0700	[thread overview]
Message-ID: <CAGXu5jJHRC83YSDKVfm4_41k0wgqfG=wpqPQss-ce77SRNkwRA@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a0beV+ZUUKxzufXtZRszbXvgC3eQO4Rc1+ZYo_nAmcaaA@mail.gmail.com>

On Thu, Jun 29, 2017 at 3:08 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Fri, May 26, 2017 at 10:17 PM, Kees Cook <keescook@chromium.org> wrote:
> I noticed new build errors that bisected back to this patch, which has
> now showed up
> in linux-next again:

(FWIW this is randstruct not initify, and has been in -next for a
couple weeks now.)

> /git/arm-soc/arch/arm/kernel/entry-armv.S: Assembler messages:
> /git/arm-soc/arch/arm/kernel/entry-armv.S:800: Error: bad immediate
> value for offset (4644)
> /git/arm-soc/scripts/Makefile.build:403: recipe for target
> 'arch/arm/kernel/entry-armv.o' failed
> make[3]: *** [arch/arm/kernel/entry-armv.o] Error 1
> /git/arm-soc/arch/arm/kernel/entry-armv.S: Assembler messages:
> /git/arm-soc/arch/arm/kernel/entry-armv.S:800: Error: bad immediate
> value for offset (5584)

arch/arm/kernel/entry-armv.S:   ldr     r7, [r7, #TSK_STACK_CANARY]
arch/arm/kernel/asm-offsets.c:  DEFINE(TSK_STACK_CANARY,
offsetof(struct task_struct, stack_canary));

This would imply that stack_canary got randomized to an offset within
struct task_struct beyond the "ldr" immediate range (4096). Yay for
giant structs.

I'm surprised this didn't bisect to "task_struct: Allow randomized layout".

> /git/arm-soc/scripts/Makefile.build:403: recipe for target
> 'arch/arm/kernel/entry-armv.o' failed
> make[3]: *** [arch/arm/kernel/entry-armv.o] Error 1
> /git/arm-soc/arch/arm/mm/tlb-v4.S: Assembler messages:
> /git/arm-soc/arch/arm/mm/tlb-v4.S:35: Error: bad immediate value for
> offset (4928)

Similar:

        act_mm  r3                              @ get current->active_mm
...
        .macro  act_mm, rd
        ldr     \rd, [\rd, #TSK_ACTIVE_MM]
...
kernel/asm-offsets.c:  DEFINE(TSK_ACTIVE_MM,
offsetof(struct task_struct, active_mm));

> /git/arm-soc/scripts/Makefile.build:403: recipe for target
> 'arch/arm/mm/tlb-v4.o' failed
> make[3]: *** [arch/arm/mm/tlb-v4.o] Error 1
> /git/arm-soc/arch/arm/mm/tlb-v4wbi.S: Assembler messages:
> /git/arm-soc/arch/arm/mm/tlb-v4wbi.S:34: Error: bad immediate value
> for offset (4928)
> /git/arm-soc/scripts/Makefile.build:403: recipe for target
> 'arch/arm/mm/tlb-v4wbi.o' failed

Same as above.

> So far, that's the only thing that goes wrong for me though, and this
> is probably
> easy to fix.

Thanks for letting me know! These haven't shown up in my tests since I
haven't gotten "unlucky" in randomizing the task_struct, it seems.

I see a few possible solutions:

- ignore it and try your build again with a fresh tree and a new
randomization seed ;)
- remove "depends on !COMPILE_TEST" from
GCC_PLUGIN_RANDSTRUCT_PERFORMANCE, which will leave most stuff near
their original locations
- add a new annotation __randomize_cacheline which performs the same
logic as above, but only for the marked structure
- build new logic to keep certain fields (with some special marking)
within a given range of their original position
- rewrite the ARM code to handle larger immediates

The first obviously won't fly. The second just bypasses the problem
forcing it to be exposed by other people later. The third is likely
easiest to do now, but reduces the effectiveness of randomization for
architectures that don't have sensitive immediate values. The fourth
sounds not generally useful. The fifth may be unacceptable to arm
maintainers due to performance impacts.

Can you verify that reverting "task_struct: Allow randomized layout"
fixes a bugged build for you?

-Kees

-- 
Kees Cook
Pixel Security

  reply	other threads:[~2017-06-29 22:53 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-26 20:17 [PATCH v2 00/20] Introduce struct layout randomization plugin Kees Cook
2017-05-26 20:17 ` [PATCH v2 01/20] NFS: Avoid cross-structure casting Kees Cook
2017-05-28  7:53   ` Christoph Hellwig
2017-05-28 16:55     ` Kees Cook
2017-05-26 20:17 ` [PATCH v2 02/20] gcc-plugins: Detail c-common.h location for GCC 4.6 Kees Cook
2017-05-26 20:17 ` [PATCH v2 03/20] compiler: Add __designated_init annotation Kees Cook
2017-05-26 20:17 ` [PATCH v2 04/20] gcc-plugins: Add the randstruct plugin Kees Cook
2017-06-29 22:08   ` Arnd Bergmann
2017-06-29 22:53     ` Kees Cook [this message]
2017-06-30  0:04       ` Kees Cook
2017-06-30  7:35       ` Arnd Bergmann
2017-06-30  7:55         ` Ard Biesheuvel
2017-06-30  8:27           ` Arnd Bergmann
2017-06-30 14:41             ` Kees Cook
2017-06-30 15:22               ` Arnd Bergmann
2017-05-26 20:17 ` [PATCH v2 05/20] randstruct: Whitelist struct security_hook_heads cast Kees Cook
2017-05-27  8:41   ` Christoph Hellwig
2017-05-27 20:09     ` Kees Cook
2017-05-27 22:04       ` Tetsuo Handa
2017-05-28  0:43         ` [kernel-hardening] " Kees Cook
2017-05-30 10:34       ` James Morris
2017-05-26 20:17 ` [PATCH v2 06/20] randstruct: Whitelist UNIXCB cast Kees Cook
2017-05-26 20:20   ` Kees Cook
2017-05-28  7:56   ` Christoph Hellwig
2017-05-26 20:17 ` [PATCH v2 07/20] randstruct: Whitelist big_key path struct overloading Kees Cook
2017-05-28  8:12   ` Christoph Hellwig
2017-05-28 16:59     ` Kees Cook
2017-06-19 19:24       ` Kees Cook
2017-09-07  7:20         ` Christoph Hellwig
2017-09-07 22:55           ` Kees Cook
2017-05-26 20:17 ` [PATCH v2 08/20] randstruct: Whitelist NIU struct page overloading Kees Cook
2017-05-28  8:15   ` Christoph Hellwig
2017-05-28 17:35     ` Kees Cook
2017-05-28 17:37     ` Kees Cook
2017-05-26 20:17 ` [PATCH v2 09/20] randstruct: Mark various structs for randomization Kees Cook
2017-05-26 20:17 ` [PATCH v2 10/20] randstruct: opt-out externally exposed function pointer structs Kees Cook
2017-05-26 20:17 ` [PATCH v2 11/20] randstruct: Disable randomization of ACPICA structs Kees Cook
2017-05-27  8:42   ` Christoph Hellwig
2017-05-27 20:03     ` Kees Cook
2017-05-28  4:55       ` Christoph Hellwig
2017-05-26 20:17 ` [PATCH v2 12/20] sgi-xp: Use designated initializers Kees Cook
2017-05-27  8:44   ` Christoph Hellwig
2017-05-26 20:17 ` [PATCH v2 13/20] drm/amdgpu: " Kees Cook
2017-05-26 20:17 ` [PATCH v2 14/20] drm/amd/powerplay: " Kees Cook
2017-05-27  8:47   ` Christoph Hellwig
2017-05-27 20:10     ` Kees Cook
2017-05-26 20:17 ` [PATCH v2 15/20] mtk-vcodec: " Kees Cook
2017-05-26 20:17 ` [PATCH v2 16/20] ntfs: Use ERR_CAST() to avoid cross-structure cast Kees Cook
2017-05-26 20:17 ` [PATCH v2 17/20] ocfs2: " Kees Cook
2017-05-26 20:17 ` [PATCH v2 18/20] randstruct: Enable function pointer struct detection Kees Cook
2017-05-26 20:17 ` [PATCH v2 19/20] [RFC] task_struct: Allow randomized layout Kees Cook
2017-05-26 20:23   ` Linus Torvalds
2017-05-26 20:32     ` Kees Cook
2017-05-26 20:17 ` [PATCH v2 20/20] ACPICA: Use designated initializers Kees Cook
2017-05-28  7:45   ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGXu5jJHRC83YSDKVfm4_41k0wgqfG=wpqPQss-ce77SRNkwRA@mail.gmail.com' \
    --to=keescook@chromium.org \
    --cc=arnd@arndb.de \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=labbott@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).