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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 911CBC433EF for ; Tue, 31 May 2022 16:36:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346168AbiEaQgv (ORCPT ); Tue, 31 May 2022 12:36:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37872 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241712AbiEaQgr (ORCPT ); Tue, 31 May 2022 12:36:47 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 93CFF10D9; Tue, 31 May 2022 09:36:45 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 2C26160C92; Tue, 31 May 2022 16:36:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 359F6C385A9; Tue, 31 May 2022 16:36:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1654015004; bh=Jcf1LuIwLWTXb1UhNVq0s7bFhNLHcRBB6iSYLTBW6r8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KSUdPURNff9EOMnCrpAuHsisbAE06T/UFYIm/LLXzE73yoHFoGUuI+4Y9Xpz0LvOa 73bUC8f7imE8c/IhdCz+utlUwRSSUyLEwTJDNfHucgV+0464kkpZX1oMroDJBj5Lu8 Ni8j70RezIuXkkG0ZJEtyNSfHNVSj32aH0iQ0DDSBw9JNhN9jqeyR9/oP6K3sCHzzC 1trtk5oB0X9wu7YqVnVLhOlFyhDk/B/pU9zZgJ1VdaP8pARhYDIetGw/Lyk8FZ6JHh FX6VwivaYatuK+qD9yykDNLFmyyVpm0VjNGNUnbJG8otTNbJRO1XX1Ze7v/IhsQALd am/5S2QNwmIWw== Date: Tue, 31 May 2022 19:36:30 +0300 From: Mike Rapoport To: "Edgecombe, Rick P" Cc: "hjl.tools@gmail.com" , "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" , "Yang, Weijiang" , "Lutomirski, Andy" , "bp@alien8.de" , "arnd@arndb.de" , "Moreira, Joao" , "linux-doc@vger.kernel.org" , "tglx@linutronix.de" , "x86@kernel.org" , "mike.kravetz@oracle.com" , "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" Subject: Re: [PATCH 00/35] Shadow stacks for userspace Message-ID: References: <05df964f-552e-402e-981c-a8bea11c555c@www.fastmail.com> <40a3500c-835a-60b0-15bf-40c6622ad013@kernel.org> 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 Tue, May 31, 2022 at 04:25:13PM +0000, Edgecombe, Rick P wrote: > Mike, > > Thanks for doing this. Glad to hear this is solvable with the current > paradigm. > > On Tue, 2022-05-31 at 14:59 +0300, Mike Rapoport wrote: > > * add ability to unlock shadow stack features using ptrace. This is > > required because the current glibc (or at least in the version I used > > for > > tests) locks shadow stack state when it loads a program. This locking > > means > > that a process will either have shadow stack disabled without an > > ability to > > enable it or it will have shadow stack enabled with WRSS disabled and > > again, there is no way to re-enable WRSS. With that, ptrace looked > > like the > > most sensible interface to interfere with the shadow stack locking. > > So whatever glibc you have lock's features even if it doesn't enable > shadow stack? Hmm, I've not encountered this. Which glibc is it? I use glibc from here: https://gitlab.com/x86-glibc/glibc/, commit b6f9a22a00c1f8ae8c0991886f0a714f2f5da002 AFAIU, it's H.J cet work. > WRSS is a feature where you would usually want to lock it as disabled, > but WRSS cannot be enabled if shadow stack is not enabled. Locking > shadow stack and WRSS off together doesn't have any security benefits > in theory. so I'm thinking glibc doesn't need to do this. The kernel > could even refuse to lock WRSS without shadow stack being enabled. > Could we avoid the extra ptrace functionality then? What I see for is that a program can support shadow stack, glibc enables shadow stack, does not enable WRSS and than calls arch_prctl(ARCH_X86_FEATURE_LOCK, LINUX_X86_FEATURE_SHSTK | LINUX_X86_FEATURE_WRSS); so that WRSS cannot be re-enabled. For the programs that do not support shadow stack, both SHSTK and WRSS are disabled, but still there is the same call to arch_prctl(ARCH_X86_FEATURE_LOCK, ...) and then neither shadow stack nor WRSS can be enabled. My original plan was to run CRIU with no shadow stack, enable shadow stack and WRSS in the restored tasks using arch_prct() and after the shadow stack contents is restored disable WRSS. Obviously, this didn't work with glibc I have :) On the bright side, having a ptrace call to unlock shadow stack and wrss allows running CRIU itself with shadow stack. > Rick -- Sincerely yours, Mike.