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=-8.6 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 15AE9C433DF for ; Mon, 22 Jun 2020 20:08:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E6B0E2075A for ; Mon, 22 Jun 2020 20:08:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="jxiFrV3w" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730500AbgFVUII (ORCPT ); Mon, 22 Jun 2020 16:08:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53460 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728973AbgFVUIF (ORCPT ); Mon, 22 Jun 2020 16:08:05 -0400 Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9ACCCC061573 for ; Mon, 22 Jun 2020 13:08:05 -0700 (PDT) Received: by mail-lj1-x241.google.com with SMTP id n24so20757271lji.10 for ; Mon, 22 Jun 2020 13:08:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O1iewzZxKxZsHCFE1IpIKZAcHdEXX0k0VhJhMjCxJRk=; b=jxiFrV3w0j5aLn+vYERXrsFANe18BmkW8WhpfbwrqvZCR3QlASLHN+s0dvUKCC7S0Z HHlQLoUjWeB77nDpLPWTX2cD+NqKKStkAUVgrU+ZbFo1WfJUCp3PbvnavLvRJJfywm9B PS8KIdxPs6dMefugAy/F3KfgHucAWcr7w9gXuUdcHllmvBB4qZe8A4Bp1EsirM9H8PWJ v3uvp+OkmO1pC5tsQ4XX81pf9YCj8Gokg9OWfBfubRYEyWUdvxonrCWsPW+wes77jqgR h6ape1nNvKoIrkpKbq7TDwpAj4bHv9zDGppyQfT3YxAm8q0kqdPmVMD48RqJ0ih/c0dw +hLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=O1iewzZxKxZsHCFE1IpIKZAcHdEXX0k0VhJhMjCxJRk=; b=j+5WmGtb8NeCDZ3tITGZUZJePnjShqIB+uvhyGov4CM4mk3OT2kUw10dJXH9lnKF0e 9QxTGbnlocJ7+1xSNBYflNI/9Dtw5zzcCLGY1/5IluUpoincro2QB6Pe5SeFRzpysg6H aY1XmVr8P6kWGJg+W3zUFIXrZ6cSvTGj9qrrJxYQqduyWxCdXkA9vaeI+oCFMCdhEc9h kFUCRZnnPMbBDwjz10yL8bp1jTqhq7glF0UL2PG5+mBgQS5U03a96A5WWY4Xnli6BjTK mlv7ITQfL6zh095dp1rKOcsOED/s5tDct7hd26hCOXz44ec/qwNzJa4hSpMN5jnmtw+S lbUA== X-Gm-Message-State: AOAM532lMOUkOPOZXJij5IUmOF0TD9DojIEl1n/PCiLo0dsyXfeIwe2Z n2ri7Zy7HnmO6whOKZZEy2bdig5hBg5Oi0xSmS+3KA== X-Google-Smtp-Source: ABdhPJy5dWzQBSNi9Zt/usqkY9agJUTDidKHpdWxCl7nmtqE+I17wPTUgLZYCHA4VjDO1Von9AZ6ddnuU6GBJyOUNKU= X-Received: by 2002:a2e:9a44:: with SMTP id k4mr9089871ljj.139.1592856483831; Mon, 22 Jun 2020 13:08:03 -0700 (PDT) MIME-Version: 1.0 References: <20200622193146.2985288-1-keescook@chromium.org> <20200622193146.2985288-4-keescook@chromium.org> In-Reply-To: <20200622193146.2985288-4-keescook@chromium.org> From: Jann Horn Date: Mon, 22 Jun 2020 22:07:37 +0200 Message-ID: Subject: Re: [PATCH v4 3/5] stack: Optionally randomize kernel stack offset each syscall To: Kees Cook 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 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, 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: $ 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.) 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). 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=-8.6 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 E578CC433E0 for ; Mon, 22 Jun 2020 20:08:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 897392075A for ; Mon, 22 Jun 2020 20:08:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="jxiFrV3w" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 897392075A Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CF6EC8D0006; Mon, 22 Jun 2020 16:08:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CA8B88D0005; Mon, 22 Jun 2020 16:08:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B97558D0006; Mon, 22 Jun 2020 16:08:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0083.hostedemail.com [216.40.44.83]) by kanga.kvack.org (Postfix) with ESMTP id 9B08E8D0005 for ; Mon, 22 Jun 2020 16:08:06 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 5132F9D0D9 for ; Mon, 22 Jun 2020 20:08:06 +0000 (UTC) X-FDA: 76957934172.25.chess04_1911bf026e35 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin25.hostedemail.com (Postfix) with ESMTP id 002A71804E926 for ; Mon, 22 Jun 2020 20:08:05 +0000 (UTC) X-HE-Tag: chess04_1911bf026e35 X-Filterd-Recvd-Size: 5958 Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com [209.85.208.193]) by imf49.hostedemail.com (Postfix) with ESMTP for ; Mon, 22 Jun 2020 20:08:05 +0000 (UTC) Received: by mail-lj1-f193.google.com with SMTP id e4so20809558ljn.4 for ; Mon, 22 Jun 2020 13:08:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O1iewzZxKxZsHCFE1IpIKZAcHdEXX0k0VhJhMjCxJRk=; b=jxiFrV3w0j5aLn+vYERXrsFANe18BmkW8WhpfbwrqvZCR3QlASLHN+s0dvUKCC7S0Z HHlQLoUjWeB77nDpLPWTX2cD+NqKKStkAUVgrU+ZbFo1WfJUCp3PbvnavLvRJJfywm9B PS8KIdxPs6dMefugAy/F3KfgHucAWcr7w9gXuUdcHllmvBB4qZe8A4Bp1EsirM9H8PWJ v3uvp+OkmO1pC5tsQ4XX81pf9YCj8Gokg9OWfBfubRYEyWUdvxonrCWsPW+wes77jqgR h6ape1nNvKoIrkpKbq7TDwpAj4bHv9zDGppyQfT3YxAm8q0kqdPmVMD48RqJ0ih/c0dw +hLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=O1iewzZxKxZsHCFE1IpIKZAcHdEXX0k0VhJhMjCxJRk=; b=Ms+0PFX6RcnM8iU7KjUrsQbONJtC2qOvTjrFOS9tZvDdyTXAb0BypLMsEPPxU/oZHl hskpm3IXvwiT9cgKURy/tpCM6M751hRX/lgjDP0KTI2yQIdY9JtzLmOPOH2hUTDRObBz zxE2HwCluaY8+A0d19VPGRm4K/uuhsv69hlEa2ScHrWacQHgkao665n5dLLv6lMkiaGF pgOmtT0L3cmlWCSZDOBteN/9WcJCFUy/yuEHVUvEGRd/byAmls/gWVmQKPVXu9ErAmjN s8L6/8lzSwjRQTreWLm9ka9P1gSDS8sNPKuy9yGJOHrViDAwv9oSqaYDClenFS+FWL8F kWFw== X-Gm-Message-State: AOAM5309N/whq5VTPtPoFBNL60PvppShZ82tdjF2uRjmxN5WaOdVmr1S EhcsnB0Uh8sVA/Sn6xgzz/IpVBEcG0y3j0UkM0ZJ4Q== X-Google-Smtp-Source: ABdhPJy5dWzQBSNi9Zt/usqkY9agJUTDidKHpdWxCl7nmtqE+I17wPTUgLZYCHA4VjDO1Von9AZ6ddnuU6GBJyOUNKU= X-Received: by 2002:a2e:9a44:: with SMTP id k4mr9089871ljj.139.1592856483831; Mon, 22 Jun 2020 13:08:03 -0700 (PDT) MIME-Version: 1.0 References: <20200622193146.2985288-1-keescook@chromium.org> <20200622193146.2985288-4-keescook@chromium.org> In-Reply-To: <20200622193146.2985288-4-keescook@chromium.org> From: Jann Horn Date: Mon, 22 Jun 2020 22:07:37 +0200 Message-ID: Subject: Re: [PATCH v4 3/5] stack: Optionally randomize kernel stack offset each syscall To: Kees Cook 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 Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 002A71804E926 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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 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: $ 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.) 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).