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=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 BD5E1C433DF for ; Mon, 22 Jun 2020 22:56:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7CA1D20738 for ; Mon, 22 Jun 2020 22:56:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="TlW8G6Xn" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7CA1D20738 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=alum.mit.edu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D07866B0006; Mon, 22 Jun 2020 18:56:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CB7B16B0007; Mon, 22 Jun 2020 18:56:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BA4A16B000C; Mon, 22 Jun 2020 18:56:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0212.hostedemail.com [216.40.44.212]) by kanga.kvack.org (Postfix) with ESMTP id A4C7B6B0006 for ; Mon, 22 Jun 2020 18:56:19 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 44958180AD815 for ; Mon, 22 Jun 2020 22:56:19 +0000 (UTC) X-FDA: 76958358078.30.play81_420b3eb26e36 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin30.hostedemail.com (Postfix) with ESMTP id 1C1E618174320 for ; Mon, 22 Jun 2020 22:56:19 +0000 (UTC) X-HE-Tag: play81_420b3eb26e36 X-Filterd-Recvd-Size: 4806 Received: from mail-qt1-f195.google.com (mail-qt1-f195.google.com [209.85.160.195]) by imf39.hostedemail.com (Postfix) with ESMTP for ; Mon, 22 Jun 2020 22:56:18 +0000 (UTC) Received: by mail-qt1-f195.google.com with SMTP id u12so3604724qth.12 for ; Mon, 22 Jun 2020 15:56:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=J4t/1UJvzfHD1sfeMp1vjjaj+f6i6rz7qh/A+MZJ/fk=; b=TlW8G6XnBweeMXO77mxR2aTGOdh/2ICx7gObCjvLq2UNfL3/HDbW+smIfJOMVG2gcL lsY37DUopQMvf8Aca+IyTniz/bSKymGHBgUBT8nPFFE5LfOKsAb6xRKdQ7saIovM7jrz Gcc7IZlLGgRdweoPdYugiSt13kCP7q8v92Q1ZSA7kXWZCK09UI3aXlgORpVu1BOgkZDq KDwTv2gMH5q3ZqUHxF0USrzHhMhxWfDoPXI6D1xlqh2UyyT5+bslyfezaLU9LBmlRGsx GS3T0H++0asrVBHeSwjH4ZsuIs3LUcr8V5bHV9uV19oqodtzFYLrhzNFidLkn9FNGOCd RV5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:date:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=J4t/1UJvzfHD1sfeMp1vjjaj+f6i6rz7qh/A+MZJ/fk=; b=QLYZXTi7212YmylzmMAvGLXQKlKwQ7cvwiSz2XkR8/+OdxSGEDIaGcGQDy/LC4oO8t SSZOhMzTG6shSjFN975yABMtjxEcx2NLKbjbnArQ2/UcenOkPLJDI00fGKYe+q/NjJGu 6k3GPRHL6Y3o6MjF9xZQyttFON/mbxm+1Enw5+bzYHiwKwh9UNMSFthBDdSYfyOffU4Z KhdlZcXh3rZYzQDjsll5gQPfrnCYjVgBmgiSM8/eoxV4zXfxLz2ajbhXf9Bm+XTsGICz yLZB+jMXLFEbp8RHZktDsAs7tNoIlzMQCx8b35YcYW/zDHJfLG++chFdCb2pkPh19otU VJfA== X-Gm-Message-State: AOAM531Dw0v5M0SGCMYHmIn/55DT6ERFHeUUZbAM6jE6p+zITtLeVfqE ROP85hUDgDtdzs17tH82fuE= X-Google-Smtp-Source: ABdhPJx6ViX3VUi9U5rO1UC8eBAxyutLutchUmhepd+t1xhXYQPr9V9FJEHmR0NJcQTmGq+2dhFMVQ== X-Received: by 2002:ac8:72d2:: with SMTP id o18mr6306890qtp.208.1592866577875; Mon, 22 Jun 2020 15:56:17 -0700 (PDT) Received: from rani.riverdale.lan ([2001:470:1f07:5f3::b55f]) by smtp.gmail.com with ESMTPSA id o8sm3348262qkh.100.2020.06.22.15.56.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Jun 2020 15:56:17 -0700 (PDT) From: Arvind Sankar X-Google-Original-From: Arvind Sankar Date: Mon, 22 Jun 2020 18:56:15 -0400 To: Kees Cook Cc: Thomas Gleixner , Elena Reshetova , x86@kernel.org, Andy Lutomirski , Peter Zijlstra , Catalin Marinas , Will Deacon , Mark Rutland , Alexander Potapenko , Alexander Popov , Ard Biesheuvel , Jann Horn , kernel-hardening@lists.openwall.com, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 3/5] stack: Optionally randomize kernel stack offset each syscall Message-ID: <20200622225615.GA3511702@rani.riverdale.lan> References: <20200622193146.2985288-1-keescook@chromium.org> <20200622193146.2985288-4-keescook@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200622193146.2985288-4-keescook@chromium.org> X-Rspamd-Queue-Id: 1C1E618174320 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 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 12:31:44PM -0700, Kees Cook wrote: > + > +#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) This feels a little fragile. ptr doesn't escape the block, so the compiler is free to restore the stack immediately after this block. In fact, given that all you've said is that the asm modifies *ptr, but nothing uses that output, the compiler could eliminate the whole thing, no? https://godbolt.org/z/HT43F5 gcc restores the stack immediately, if no function calls come after it. clang completely eliminates the code if no function calls come after. I'm not sure why function calls should affect it, though, given that those functions can't possibly access ptr or the memory it points to. A full memory barrier (like barrier_data) should be better -- it gives the compiler a reason to believe that ptr might escape and be accessed by any code following the block?