From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 74F91C433DF for ; Mon, 22 Jun 2020 21:30:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 37C4D20732 for ; Mon, 22 Jun 2020 21:30:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="PbXo+AAU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 37C4D20732 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id AB6336B0002; Mon, 22 Jun 2020 17:30:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A66376B0005; Mon, 22 Jun 2020 17:30:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 955C16B0006; Mon, 22 Jun 2020 17:30:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0210.hostedemail.com [216.40.44.210]) by kanga.kvack.org (Postfix) with ESMTP id 7E77C6B0002 for ; Mon, 22 Jun 2020 17:30:21 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id DD563824805A for ; Mon, 22 Jun 2020 21:30:20 +0000 (UTC) X-FDA: 76958141400.09.food39_3f0ad3e26e36 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin09.hostedemail.com (Postfix) with ESMTP id B1843180AD80F for ; Mon, 22 Jun 2020 21:30:20 +0000 (UTC) X-HE-Tag: food39_3f0ad3e26e36 X-Filterd-Recvd-Size: 7003 Received: from mail-pj1-f66.google.com (mail-pj1-f66.google.com [209.85.216.66]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Mon, 22 Jun 2020 21:30:20 +0000 (UTC) Received: by mail-pj1-f66.google.com with SMTP id d6so510782pjs.3 for ; Mon, 22 Jun 2020 14:30:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=pLN2RaPddxRloDpN+pRwQoiNiSyh25YEOfza1Wb+VHE=; b=PbXo+AAUJ5jVd5yBXYTaqNpkqWjS+viBecyCQ4cn0lZ7K1T7oe9cXDqosUKpFoYZZu FtVG00wDnjPQEg/jKU5F5eqvyPGU1ZgCNOYpKqeywY4h2JUzArVp7p4RLYBb0oVl4kmj 3ANK8t3QGcMtwG+m1ybJ7nlXfeTZQpbBr6POo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=pLN2RaPddxRloDpN+pRwQoiNiSyh25YEOfza1Wb+VHE=; b=dqUdozMf00cYBSCgcXOkVc+vp/b9GOQ3/EN2mMVYbpaA6aOvKdslKW4Om5aoyt9ckF 8rU3weu5LTei35nmcotntAiGeZSCBXZr/Q7JsWnz1GKK+rikRLHNsQlKtrGe5t0rivvs L33ZTEvlnzO9U2JHHK40MYqI5wqaLAnQuCJ2tbQgRu/+wCHVfJN/I+OSosr2dIT3W7aA w1PsbN/S93bvuW7m0FF9M/7CrfLQjc7KngOEGjFNgaO+2dg+j7Viw/AGRcu+HN7O3hva 027Lhg4Kdj3btqLcHUqO9AhtdOOOOwvpt2Ul3fkTwIObdh18Wp86l1X3mx3Q4fKPDiGm /vUg== X-Gm-Message-State: AOAM5336pztRcQW86swCEZZbOu0zyLc8o5vsW8yN2A63wfkcoI1UAdg+ jpTrkcguE9d8DMM6c2DI8bgIAg== X-Google-Smtp-Source: ABdhPJw7w1NVvAhJYf89+YhAFuDDc20voExouq/QieTMXvtk2w4TSXX7wfv4gqLDVHJ1o0sg4pMirg== X-Received: by 2002:a17:902:6908:: with SMTP id j8mr18923742plk.124.1592861419296; Mon, 22 Jun 2020 14:30:19 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id p11sm15103897pfq.10.2020.06.22.14.30.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Jun 2020 14:30:18 -0700 (PDT) Date: Mon, 22 Jun 2020 14:30:17 -0700 From: Kees Cook To: Jann Horn Cc: Thomas Gleixner , Elena Reshetova , the arch/x86 maintainers , Andy Lutomirski , Peter Zijlstra , Catalin Marinas , Will Deacon , Mark Rutland , Alexander Potapenko , Alexander Popov , Ard Biesheuvel , Kernel Hardening , Linux ARM , Linux-MM , kernel list Subject: Re: [PATCH v4 3/5] stack: Optionally randomize kernel stack offset each syscall Message-ID: <202006221426.CEEE0B8@keescook> References: <20200622193146.2985288-1-keescook@chromium.org> <20200622193146.2985288-4-keescook@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: B1843180AD80F X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 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: On Mon, Jun 22, 2020 at 10:07:37PM +0200, Jann Horn wrote: > On Mon, Jun 22, 2020 at 9:31 PM Kees Cook wrote: > > This provides the ability for architectures to enable kernel stack base > > address offset randomization. This feature is controlled by the boot > > param "randomize_kstack_offset=on/off", with its default value set by > > CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT. > [...] > > +#define add_random_kstack_offset() do { \ > > + if (static_branch_maybe(CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT, \ > > + &randomize_kstack_offset)) { \ > > + u32 offset = this_cpu_read(kstack_offset); \ > > + u8 *ptr = __builtin_alloca(offset & 0x3FF); \ > > + asm volatile("" : "=m"(*ptr)); \ > > + } \ > > +} while (0) > > clang generates better code here if the mask is stack-aligned - > otherwise it needs to round the stack pointer / the offset: Interesting. I was hoping to avoid needing to know the architecture stack alignment (leaving it up to the compiler). > > $ cat alloca_align.c > #include > void callee(void); > > void alloca_blah(unsigned long rand) { > asm volatile(""::"r"(alloca(rand & MASK))); > callee(); > } > $ clang -O3 -c -o alloca_align.o alloca_align.c -DMASK=0x3ff > $ objdump -d alloca_align.o > [...] > 0: 55 push %rbp > 1: 48 89 e5 mov %rsp,%rbp > 4: 81 e7 ff 03 00 00 and $0x3ff,%edi > a: 83 c7 0f add $0xf,%edi > d: 83 e7 f0 and $0xfffffff0,%edi > 10: 48 89 e0 mov %rsp,%rax > 13: 48 29 f8 sub %rdi,%rax > 16: 48 89 c4 mov %rax,%rsp > 19: e8 00 00 00 00 callq 1e > 1e: 48 89 ec mov %rbp,%rsp > 21: 5d pop %rbp > 22: c3 retq > $ clang -O3 -c -o alloca_align.o alloca_align.c -DMASK=0x3f0 > $ objdump -d alloca_align.o > [...] > 0: 55 push %rbp > 1: 48 89 e5 mov %rsp,%rbp > 4: 48 89 e0 mov %rsp,%rax > 7: 81 e7 f0 03 00 00 and $0x3f0,%edi > d: 48 29 f8 sub %rdi,%rax > 10: 48 89 c4 mov %rax,%rsp > 13: e8 00 00 00 00 callq 18 > 18: 48 89 ec mov %rbp,%rsp > 1b: 5d pop %rbp > 1c: c3 retq > $ > > (From a glance at the assembly, gcc seems to always assume that the > length may be misaligned.) Right -- this is why I didn't bother with it, since it didn't seem to notice what I'd already done to the alloca() argument. (But from what I could measure on cycle counts, the additional ALU didn't seem to really make much difference ... it _would_ be nice to avoid it, of course.) > Maybe this should be something along the lines of > __builtin_alloca(offset & (0x3ff & ARCH_STACK_ALIGN_MASK)) (with > appropriate definitions of the stack alignment mask depending on the > architecture's choice of stack alignment for kernel code). Is that explicitly selected anywhere in the kernel? I thought the alignment was left up to the compiler (as in I've seen bugs fixed where the kernel had to deal with the alignment choices the compiler was making...) -- Kees Cook