Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp712243pxb; Thu, 2 Sep 2021 13:16:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxFDrPMG5exThokxL/5e5opTq59etgry5cMBlt0i3JyQOWO9XXJ0q8S28ldBmnkwg2E72iO X-Received: by 2002:a05:6402:1d56:: with SMTP id dz22mr125835edb.69.1630613793433; Thu, 02 Sep 2021 13:16:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630613793; cv=none; d=google.com; s=arc-20160816; b=MttpbZLlfyzdEwbpuLhfgC6VVEIlD5OgEgu2vMWtANC8LiX8jnu4zfOzWtW//6p9fg t9hXdEBgf/C1UQRekY++D9G4wotjMeiqtFF9Uxn1IbpxEeU8eZVqmc2hM2NPLFOA04YD IbSi3fqUqmVP3sElpnGA11uUbv9gbwqsWSeXPqzpww15tAdG//dmgK4mfRQunsjfhvLk JNJT3Rzyu9EwEps3SWaU2g1CU2eHHhcz0rs5ZG1trK+KuViA6tNSDzDVTDyFJgorTOmy RF6Ikr/nW1ai2aJLvjQbxfja0ksaU+hl5DxEcQNBApQejVtWj7EycbveTXNl5sGiwckC ooVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=HDAoUcZsfD+c/zEC0G2P+XLrfWfsXMInjiJ2c5tUjik=; b=UfCf5WEm35IoQNq78eXArRfakj8hDB4BB+S10D5zzOWSXbbai+Af7+2pJAmIPCgEvo t/qir8oL/ygEXH4XxxGENYduTir1HGgUKG6s0UJTWuDRxo+DjMS/ynM2Qz4Z8yV92Q7V M//px65yFTP9MfP+Z3cz2HGK7uHFGNXLiEjxIvtx6YlL+DfMjy7x7dOtF0WYi/b1H5K8 ogvStZvOmU0hAawf50N4UAwtNs3RzB+zZXxksy2sZJMnOjDDzCpH6B1EwDq5Cni/bP4o JBG7dxab+RVc0LHVtPkux5eWtKoAltur9z+aIue9gfAXr4UYqy4Vg4Oaq0UhQoYL3HiP dbHg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=gfrGu3Ti; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ds7si3029054ejc.524.2021.09.02.13.16.10; Thu, 02 Sep 2021 13:16:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=gfrGu3Ti; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346638AbhIBRim (ORCPT + 99 others); Thu, 2 Sep 2021 13:38:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36004 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346796AbhIBRi2 (ORCPT ); Thu, 2 Sep 2021 13:38:28 -0400 Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 65D8FC061575 for ; Thu, 2 Sep 2021 10:37:30 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id d17so1650873plr.12 for ; Thu, 02 Sep 2021 10:37:30 -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=HDAoUcZsfD+c/zEC0G2P+XLrfWfsXMInjiJ2c5tUjik=; b=gfrGu3TieN1sG6JBeZ/ppgP2xRHXanv2OoeZyn/J7xB6Xju7XUkcNyEW+87BWZuxCY 43aLdcDr/zLJWDZkXfdY+ntoMc8/lhOH3FZqyo1JG4jjrcOgTzOWwQtPXTSfnuvKeteH BjK/Vc4GPRrjhGM2oxA9TMmVjkLhpgJvElm6Y= 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=HDAoUcZsfD+c/zEC0G2P+XLrfWfsXMInjiJ2c5tUjik=; b=uAirFGnIqwunLC00vtel6/iaOgnwXuL8pRmgSsNabEtIK8SRsE3eZbglKuJpFAAQjp Sh+zTdrI4UmBs1yeb6VvHt3Aa0UUAYKmyey9r01lCIeuTbvVQfe5cAZqKoc0UV8LWPQw SXaz3eUzzoyfhAbSS8qwyGrb7la70sz90uggseNVslpJh8LJX+qZaN5pntXLjOFpWO3L 3U/YsC4fwfRlx6Iup81SuibjFLa817R9VEXCbGZnHy9Bl1oIrhDg8sTSgtdamR3+bK7v liLMgzdhf0gmfsS5I+JfB/Rqnw72JnJy3O63qrQhzAqIQUqxn22UyNqvbO1ibswX+ABE kVig== X-Gm-Message-State: AOAM530EbUjkemIXrUJoMwLzRDB/YdZIhdKuX6M98DOkewS4cpiC3mAV rYBeH+JFkOR7sMUoOjSJ1F4T4A== X-Received: by 2002:a17:90a:6f01:: with SMTP id d1mr5280843pjk.36.1630604249962; Thu, 02 Sep 2021 10:37:29 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id c9sm3455764pgq.58.2021.09.02.10.37.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Sep 2021 10:37:29 -0700 (PDT) Date: Thu, 2 Sep 2021 10:37:27 -0700 From: Kees Cook To: Ard Biesheuvel Cc: Keith Packard , Linux Kernel Mailing List , Abbott Liu , Alexander Sverdlin , Al Viro , Andrew Morton , Anshuman Khandual , Arnd Bergmann , Bjorn Andersson , Florian Fainelli , Geert Uytterhoeven , Hartley Sweeten , Jens Axboe , Jian Cai , Joe Perches , Linus Walleij , Linux ARM , Maninder Singh , Manivannan Sadhasivam , Marc Zyngier , Masahiro Yamada , Mike Rapoport , Nick Desaulniers , Nick Desaulniers , Nicolas Pitre , Peter Zijlstra , Russell King , Thomas Gleixner , Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= , Valentin Schneider , Vaneet Narang , "Wolfram Sang (Renesas)" , YiFei Zhu , Keith Packard , linux-hardening@vger.kernel.org Subject: Re: [PATCH 0/2]: ARM: Enable THREAD_INFO_IN_TASK Message-ID: <202109021036.859812D3DB@keescook> References: <20210902155429.3987201-1-keithp@keithp.com> <202109020904.976207C@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 02, 2021 at 06:18:29PM +0200, Ard Biesheuvel wrote: > On Thu, 2 Sept 2021 at 18:07, Kees Cook wrote: > > > > On Thu, Sep 02, 2021 at 08:54:26AM -0700, Keith Packard wrote: > > > Placing thread_info in the kernel stack leaves it vulnerable to stack > > > overflow attacks. This short series addresses that by using the > > > existing THREAD_INFO_IN_TASK infrastructure. > > > > Very cool! Thanks for working on this. If you want, you can refer to the > > KSPP bug for this too: > > https://github.com/KSPP/linux/issues/1 > > > > (Anyone want to do MIPS?) > > > > I take it this breaks the GCC plugin based per-task stack protector, > given that it emits code to mask the stack pointer and apply an offset > to the resulting value. > > It would be nice if we could replace this with something suitable for > THREAD_INFO_IN_TASK, and if it is suitable enough, try and get the > GCC/Clang folks to adopt it as well (which was never going to happen > for the stack pointer mask/offset approach) I'd love to see the native GCC offset stuff work on arm32, but it's not clear to me how much work that would be. It's implemented for several architectures already. I've tried to capture the matrix here: https://github.com/KSPP/linux/issues/29 -Kees -- Kees Cook