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=-7.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 CCB3BC636C9 for ; Wed, 21 Jul 2021 18:28:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5A0AF61222 for ; Wed, 21 Jul 2021 18:28:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5A0AF61222 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CF6936B005D; Wed, 21 Jul 2021 14:28:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CA6C86B006C; Wed, 21 Jul 2021 14:28:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B95616B0070; Wed, 21 Jul 2021 14:28:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0197.hostedemail.com [216.40.44.197]) by kanga.kvack.org (Postfix) with ESMTP id 9E4846B005D for ; Wed, 21 Jul 2021 14:28:49 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 4C9188248076 for ; Wed, 21 Jul 2021 18:28:49 +0000 (UTC) X-FDA: 78387431178.10.1B1B149 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf09.hostedemail.com (Postfix) with ESMTP id CEE2F3002E44 for ; Wed, 21 Jul 2021 18:28:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1626892128; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TkdTO/UxdGxI+/KgnvL1pZPS4iHaPv/sef/gzkTwrYg=; b=HT+8xbUv57kJvwKY0CsNo1OHm/siAwiwaBZrOaOobV/mp4SMgtbv7B8ZOE2FNBX0UknQxb ZIqpT3sDOyJee94JHW0t+DDplnJd+R4qZPmS1rWDpKfpkwx6Lo6zSKtfook9Gq0J9NgAlK 7h8ZjdHC/xS861dbmdcaCBcW8fCVNoE= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-167-OZJ_IJG8M8idZr9-uoubBQ-1; Wed, 21 Jul 2021 14:28:46 -0400 X-MC-Unique: OZJ_IJG8M8idZr9-uoubBQ-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0404BC7401; Wed, 21 Jul 2021 18:28:42 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-113-201.ams2.redhat.com [10.36.113.201]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D3AE4610AF; Wed, 21 Jul 2021 18:28:25 +0000 (UTC) From: Florian Weimer To: John Allen Cc: Yu-cheng Yu , x86@kernel.org, "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Arnd Bergmann , Andy Lutomirski , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , "H.J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , "Ravi V. Shankar" , Vedvyas Shanbhogue , Dave Martin , Weijiang Yang , Pengfei Xu , Haitao Huang Subject: Re: [PATCH v27 24/31] x86/cet/shstk: Handle thread shadow stack References: <20210521221211.29077-1-yu-cheng.yu@intel.com> <20210521221211.29077-25-yu-cheng.yu@intel.com> Date: Wed, 21 Jul 2021 20:28:23 +0200 In-Reply-To: (John Allen's message of "Wed, 21 Jul 2021 13:14:56 -0500") Message-ID: <87h7gnldx4.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: CEE2F3002E44 X-Stat-Signature: 3hoxsd1q8rfh5sfcwscxh55c4oc6nnqg Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=HT+8xbUv; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf09.hostedemail.com: domain of fweimer@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=fweimer@redhat.com X-HE-Tag: 1626892128-709835 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: * John Allen: > At the very least, it would seem that on some systems, it isn't valid to > rely on the stack_size passed from clone3, though I'm unsure what the > correct behavior should be here. If the passed stack_size =3D=3D 0 and sp= =3D=3D > 0, is this a case where we want to alloc a shadow stack for this thread > with some capped size? Alternatively, is this a case that isn't valid to > alloc a shadow stack and we should simply return 0 instead of -EINVAL? > > I'm running Fedora 34 which satisfies the required versions of gcc, > binutils, and glibc. Fedora 34 doesn't use clone3 yet. You can upgrade to a rawhide build, e.g. glibc-2.33.9000-46.fc35: It's currently not in main rawhide because the Firefox sandbox breaks clone3. The =E2=80=9Cfix=E2=80=9D is that clone3 will fail with ENOSYS und= er the sandbox. I expect that container runtimes turn clone3 into clone in the same way (via ENOSYS), at least for the medium term. So it would make sense to allocate some sort of shadow stack for clone as well, if that's possible to implement in some way. Thanks, Florian