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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8D929E81DEE for ; Fri, 6 Oct 2023 12:30:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0B8B28E0019; Fri, 6 Oct 2023 08:30:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 068608E000B; Fri, 6 Oct 2023 08:30:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E4B638E0019; Fri, 6 Oct 2023 08:30:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id D001E8E000B for ; Fri, 6 Oct 2023 08:30:16 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 9EDA0404CC for ; Fri, 6 Oct 2023 12:30:16 +0000 (UTC) X-FDA: 81314969232.05.0071D4B Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) by imf18.hostedemail.com (Postfix) with ESMTP id 294FA1C0032 for ; Fri, 6 Oct 2023 12:30:13 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=none; spf=pass (imf18.hostedemail.com: domain of ebiederm@xmission.com designates 166.70.13.233 as permitted sender) smtp.mailfrom=ebiederm@xmission.com; dmarc=pass (policy=none) header.from=xmission.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696595414; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6L78lpuFXJ+09lDq4yGUk9Hit0W7HBXeXG+QBVZUx4w=; b=czvmRCFHe8PQ5hPURs1yzi/67VWh1iRw57k0XQJxb922jbTeP6y6tAvJ68KTtKbBCZOLqM gxMILve0f7WksWeoSL5s+6pMIZnIndBk4zjWCUEl4C0B+Tq42jrwvSK0XV8tsTY88Mxqke HaKPOxJuPd49wpDDmgap3utg8y4GQ8k= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696595414; a=rsa-sha256; cv=none; b=qrxGGMZHV4kgP1ZqYSDkAKbysk2NAbx9xl7HlY9rhcR0heC12rffnH/3w9Sc0Mjv22z2IC yGEUe73EZtnwhAZUpQ7G0C7xpiIKh5kNMIdvqcMp9DWfB7l4xul8IjbFVIrTC7rXQ60CWT 1rf+Wi90rudW0DvC4i4Rl1eN0V4kago= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=none; spf=pass (imf18.hostedemail.com: domain of ebiederm@xmission.com designates 166.70.13.233 as permitted sender) smtp.mailfrom=ebiederm@xmission.com; dmarc=pass (policy=none) header.from=xmission.com Received: from in02.mta.xmission.com ([166.70.13.52]:37482) by out03.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1qojy7-00AOeg-9W; Fri, 06 Oct 2023 06:30:11 -0600 Received: from ip68-227-168-167.om.om.cox.net ([68.227.168.167]:49692 helo=email.froward.int.ebiederm.org.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1qojy5-001oHA-T0; Fri, 06 Oct 2023 06:30:10 -0600 From: "Eric W. Biederman" To: Mark Brown Cc: Catalin Marinas , Szabolcs Nagy , Will Deacon , Jonathan Corbet , Andrew Morton , Marc Zyngier , Oliver Upton , James Morse , Suzuki K Poulose , Arnd Bergmann , Oleg Nesterov , Kees Cook , Shuah Khan , "Rick P. Edgecombe" , Deepak Gupta , Ard Biesheuvel , "H.J. Lu" , Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, kvmarm@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org References: <43ec219d-bf20-47b8-a5f8-32bc3b64d487@sirena.org.uk> <38edb5c3-367e-4ab7-8cb7-aa1a5c0e330c@sirena.org.uk> <638a7be5-6662-471d-a3ce-0de0ac768e99@sirena.org.uk> Date: Fri, 06 Oct 2023 07:29:45 -0500 In-Reply-To: <638a7be5-6662-471d-a3ce-0de0ac768e99@sirena.org.uk> (Mark Brown's message of "Fri, 6 Oct 2023 13:17:01 +0100") Message-ID: <87y1ggylvq.fsf@email.froward.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1qojy5-001oHA-T0;;;mid=<87y1ggylvq.fsf@email.froward.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=68.227.168.167;;;frm=ebiederm@xmission.com;;;spf=pass X-XM-AID: U2FsdGVkX1+LvOjycHAoB6LT49HjM3IrRBVDb8ivK8I= X-SA-Exim-Connect-IP: 68.227.168.167 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH v4 03/36] arm64/gcs: Document the ABI for Guarded Control Stacks X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) X-Stat-Signature: jqgw16eoksw6w4cfozu9zhh97o8sm6mh X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 294FA1C0032 X-Rspam-User: X-HE-Tag: 1696595413-155658 X-HE-Meta: U2FsdGVkX19CXWsSrBiluyMq3NuN0zofU614qa8X6P9BJuLubCmpI+hyhOwTMeWsbYNnd4Qqba7k/pZRpS/3Io9wsYP2ETvCt5vkLHGdpUpCQyk/A8aldTWGUsj7ZVSwh3pJhYlOnqnxGpqqOu9YSUAdoHoaM6veCQ590uZctiOWXqMmst/4VJT64ZooLPBKiqbI1Rva5Lzo0Zvd3bBPNyKA9axdL08p7SUNvfIp82/pyEUfgm+lLr9lin1Ci79IF81nbEzklhp4FYucPMT6Sjwp7nW7Mg+H2uLA19nn8FQlOnodyzKE4Q36fj+m34ZXBpIZWt5Q9A75PM1T1xlgwDhwFt+FRT0pMs9KQ5C0i0Fr/UJR+om21mM8Bbrcx8zTu/CbY0+L/n+DcdWG3uiQ20+kWwtRmFVmjP+844WabL8k0YuZjtlmb5B3MvX9YQA/qiy2eDCW6q3UpeRuFtCn8qVqcmxW8+uHysHO41/qRnQg0p7eSGE8SYSdKNxzr0cI+nczrNpJOwDYR4pFi1g6Qa83CD7BBb8yCivrJ26UOrVueEYqyo6zNjDLPaRZq0BmQX2lEmWtB9sa4GKD5dO9y+DpiECRrFhDmA4pe88rkCJHL+VnqbL3XMlt8APn+4JMUdsYiy7NchS5oNLLlLeLpDhXF/5sxH7lX6FZnRG/AxeO4D8l3ZEvgY4jc/lTPnQrQCAFV3ANfMqODqjvo0hh+6MfK/Dcq3MqhmS/YF6EcAZFqYeBFB7hsTGfWH8yx5ZQGtwc9lsdlvBFTyXILS+Lu9pBfRt5g8irPHObt/SMP3omJuQj0ye5ofF8cnBnBmqSkJzLNUzhvF+WJ85q/+nkLAi2/Z3nFp3CbLnHF+mftnzXuiYld6f1LujUpa7ymPp2G/NOUYpQ5iACceGtAeehF7+snkd/b/AH16JHyfSfL8ANvSbZNEs7EZfl0oiSGJAk/9pTY5usgSZ+o03AeB7 xlx+Nqk0 ANnXdsds9BMu7i2m90bygavPrcnhms+ggh4EJu/SFCUCEzHkYbd67/HS1Wp/8gN/jzySj/j0Kr7Nxj93IMU20piR0WLmbfCulpPnOzIhz9BXk72SmVr7BhS4eQ4XJr5bJa4OlQjh+2EEM8l4FwXTQipjv4w== 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: Mark Brown writes: > On Thu, Oct 05, 2023 at 06:23:10PM +0100, Catalin Marinas wrote: > >> It's not just the default size that I dislike (I think the x86 >> RLIMIT_STACK or clone3() stack_size is probably good enough) but the >> kernel allocating the shadow stack and inserting it into the user >> address space. The actual thread stack is managed by the user but the >> shadow stack is not (and we don't do this very often). Anyway, I don't >> have a better solution for direct uses of clone() or clone3(), other >> than running those threads with the shadow stack disabled. Not sure >> that's desirable. > > Running threads with the shadow stack disabled if they don't explicitly > request it feels like it's asking for trouble - as well as the escape > route from the protection it'd provide I'd expect there to be trouble > for things that do stack pivots, potentially random issues if there's a > mix of ways threads are started. It's going to be a tradeoff whatever > we do. Something I haven't seen in the discussion is that one of the ways I have seen a non-libc clone used is to implement a fork with flags. That is a new mm is created, and effectively a new process. Which makes the characterization different. In general creating a thread with clone and bypassing libc is incompatible with pthreads, and the caller gets to keep both pieces. As long as there is enough information code can detect that shadow stacks are in use, and the code is able to create their own I don't see why it shouldn't be the callers responsibility. On the other hand I don't see the maintainer of clone Christian Brauner or the libc folks especially Florian cc'd on this thread. So I really don't think you have the right folks in on this conversation. Eric k