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 4983EC43334 for ; Wed, 1 Jun 2022 19:28:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C84CE8D0031; Wed, 1 Jun 2022 15:28:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C10468D0028; Wed, 1 Jun 2022 15:28:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AD1F28D0031; Wed, 1 Jun 2022 15:28:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 99FEB8D0028 for ; Wed, 1 Jun 2022 15:28:19 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 6257DAEE for ; Wed, 1 Jun 2022 19:28:19 +0000 (UTC) X-FDA: 79530653118.23.0C9C335 Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) by imf19.hostedemail.com (Postfix) with ESMTP id B8FD41A004F for ; Wed, 1 Jun 2022 19:28:03 +0000 (UTC) Received: by mail-pl1-f173.google.com with SMTP id u18so2678178plb.3 for ; Wed, 01 Jun 2022 12:28:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MwFYe8vG1hgF//coAlXZoNBBVbmnrkPi8xOD0rdFVts=; b=KF2QzfcpN134OIsXyk3kBy72OtuSNqbJHaRvlqkAGA0kbj0Phrwf5K3xBxwidYkUPG bJLJl3OjKYDIu8We1CSIRj89bkJWaPAS4LgNgc+eFD3nd7lncagoR28dNSEZsF2gr+qV QtTWORwt+ry+x+RIOznMukILrX1XWqyCPsIdq+3O1AVHRR9hoIAoqHnWn19+CqUU3b6e ht1Yty84Qu0f1N8QPJmld5ipZgWipzdIBsyTXZe8GDxgAEzY1Ic9Sv+lJL6inUqWJ1b4 /IMuJbDxT8M1ogwnWI0/Uw5PL76LSXDEJF/2DnKE2lsiLYAFqovXPYhDRYUR3zXGfr6p FS5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MwFYe8vG1hgF//coAlXZoNBBVbmnrkPi8xOD0rdFVts=; b=aMrkdG2ntLvYn7ApIdiP/BZRulhBwG2rwJiYvz9n642jDkGJapgXsSlhMSguus0T9G lntHzmgoGeD2OnXt2FMsso7RxvjcQua0s5eaCJ8RowtzHv4Ku8UHM/OUrUa/6E3Uu7P7 JOXXNW/VM22O9pJkEngEDkBjB4Q3EjcvUdV4ngUahqIdalg7i65VQtboWyNNcxL5qG3p s4cBSYssuNnznKfhoVhVLLMzOAnaMCuF3tsTHmk9//hR1zyqTJZn4uBlWqrWQB6IjUkC 67RKzzRWE6EVhPhrGGyP8dJTYOLi78jZkst3TZkvUqfIqw0xyQ6hkTXTwBDq3+LsKdNm Yzmg== X-Gm-Message-State: AOAM530lpQnvrhnwtf+pIB8V3t9L008FL1LNtDcyMMCklvd0r0USBjC2 h2JzcvYbZqrmaZcWyWbV5PtqUNiO+Pi4LVZPwIs= X-Google-Smtp-Source: ABdhPJyDA6C5DQXioXg31Wj9TMeGFjgKh185K1zYFg2Gp28lZkR0rLJ5Az2Ahuku4Ke5Wjt3PdFq+l9pcuaeBfBBob8= X-Received: by 2002:a17:90b:23d8:b0:1e2:e3cb:ac08 with SMTP id md24-20020a17090b23d800b001e2e3cbac08mr967331pjb.35.1654111697802; Wed, 01 Jun 2022 12:28:17 -0700 (PDT) MIME-Version: 1.0 References: <05df964f-552e-402e-981c-a8bea11c555c@www.fastmail.com> <40a3500c-835a-60b0-15bf-40c6622ad013@kernel.org> <7c637f729e14f03d0df744568800fc986542e33d.camel@intel.com> <172310e1b8fcc78fca786f9ea7966f58dd93ff93.camel@intel.com> In-Reply-To: <172310e1b8fcc78fca786f9ea7966f58dd93ff93.camel@intel.com> From: "H.J. Lu" Date: Wed, 1 Jun 2022 12:27:41 -0700 Message-ID: Subject: Re: [PATCH 00/35] Shadow stacks for userspace To: "Edgecombe, Rick P" Cc: "bsingharora@gmail.com" , "hpa@zytor.com" , "Syromiatnikov, Eugene" , "peterz@infradead.org" , "rdunlap@infradead.org" , "keescook@chromium.org" , "0x7f454c46@gmail.com" <0x7f454c46@gmail.com>, "Eranian, Stephane" , "kirill.shutemov@linux.intel.com" , "dave.hansen@linux.intel.com" , "linux-mm@kvack.org" , "adrian@lisas.de" , "fweimer@redhat.com" , "nadav.amit@gmail.com" , "jannh@google.com" , "avagin@gmail.com" , "kcc@google.com" , "linux-arch@vger.kernel.org" , "pavel@ucw.cz" , "oleg@redhat.com" , "bp@alien8.de" , "Lutomirski, Andy" , "Yang, Weijiang" , "arnd@arndb.de" , "Moreira, Joao" , "linux-doc@vger.kernel.org" , "tglx@linutronix.de" , "mike.kravetz@oracle.com" , "x86@kernel.org" , "rppt@kernel.org" , "john.allen@amd.com" , "dave.martin@arm.com" , "mingo@redhat.com" , "Hansen, Dave" , "corbet@lwn.net" , "linux-kernel@vger.kernel.org" , "gorcunov@gmail.com" , "Shankar, Ravi V" , "linux-api@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: u69zb519hof1kj1ipzedyddcxganzebm X-Rspam-User: Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=KF2Qzfcp; spf=pass (imf19.hostedemail.com: domain of hjl.tools@gmail.com designates 209.85.214.173 as permitted sender) smtp.mailfrom=hjl.tools@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: B8FD41A004F X-HE-Tag: 1654111683-221320 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 Wed, Jun 1, 2022 at 10:27 AM Edgecombe, Rick P wrote: > > On Tue, 2022-05-31 at 11:00 -0700, H.J. Lu wrote: > > > The glibc logic seems wrong to me also, because shadow stack or IBT > > > could be force-disabled via glibc tunables. I don't see why the elf > > > header bit should exclusively control the feature locking. Or why > > > both > > > should be locked if only one is in the header. > > > > glibc locks SHSTK and IBT only if they are enabled at run-time. > > It's not what I saw in the code. Somehow Mike saw something different > as well. The current glibc cet branch: https://gitlab.com/x86-glibc/glibc/-/commits/users/hjl/cet/master locks only available CET features. Since only SHSTK is available, I saw arch_prctl(0x3003 /* ARCH_??? */, 0x2) = 0 CET features are always enabled early in ld.so to allow function calls in the CET enabled ld.so. ld.so always locks CET features even if they are disabled when the program or a dependency library isn't CET enabled. > > It doesn't > > enable/disable/lock WRSS at the moment. If WRSS can be enabled > > via arch_prctl at any time, we can't lock it. If WRSS should be > > locked early, > > how should it be enabled in application? Also can WRSS be enabled > > from a dlopened object? > > I think in the past we discussed having another elf header bit that > behaved differently (OR vs AND). We should have a complete list of use cases and design a way to support them. -- H.J.