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 22E11C433FE for ; Mon, 7 Mar 2022 22:22:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242761AbiCGWW6 convert rfc822-to-8bit (ORCPT ); Mon, 7 Mar 2022 17:22:58 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43292 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245596AbiCGWWv (ORCPT ); Mon, 7 Mar 2022 17:22:51 -0500 Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.86.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 039D58CDBE for ; Mon, 7 Mar 2022 14:21:55 -0800 (PST) Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id uk-mta-165-8y9FGRZFPriMZfq4Jpk07A-1; Mon, 07 Mar 2022 22:21:53 +0000 X-MC-Unique: 8y9FGRZFPriMZfq4Jpk07A-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) by AcuMS.aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) with Microsoft SMTP Server (TLS) id 15.0.1497.28; Mon, 7 Mar 2022 22:21:49 +0000 Received: from AcuMS.Aculab.com ([fe80::994c:f5c2:35d6:9b65]) by AcuMS.aculab.com ([fe80::994c:f5c2:35d6:9b65%12]) with mapi id 15.00.1497.028; Mon, 7 Mar 2022 22:21:49 +0000 From: David Laight To: 'Mike Rapoport' , Andy Lutomirski CC: "Edgecombe, Rick P" , "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" , "hjl.tools@gmail.com" , "bp@alien8.de" , "linux-doc@vger.kernel.org" , "arnd@arndb.de" , "Moreira, Joao" , "tglx@linutronix.de" , "mike.kravetz@oracle.com" , "x86@kernel.org" , "Yang, Weijiang" , "dave.martin@arm.com" , "john.allen@amd.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 Thread-Topic: [PATCH 00/35] Shadow stacks for userspace Thread-Index: AQHYMlUnLgOMkkzJIkGC5fp7CqAYeKy0fYyg Date: Mon, 7 Mar 2022 22:21:49 +0000 Message-ID: <776fb081217145f4a488f7bca3e16eab@AcuMS.aculab.com> References: <8e36f20723ca175db49ed3cc73e42e8aa28d2615.camel@intel.com> <9d664c91-2116-42cc-ef8d-e6d236de43d0@kernel.org> <5a792e77-0072-4ded-9f89-e7fcc7f7a1d6@www.fastmail.com> <05df964f-552e-402e-981c-a8bea11c555c@www.fastmail.com> <40a3500c-835a-60b0-15bf-40c6622ad013@kernel.org> In-Reply-To: Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C51A453 smtp.mailfrom=david.laight@aculab.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Mike Rapoport > Sent: 07 March 2022 18:57 ... > > The sigframe thing, OTOH, seems genuinely useful if CRIU would actually use > > it to save the full register state. Generating a signal frame from scratch > > is a pain. That being said, if CRIU isn't excited, then don't bother. > > CRIU is excited :) > > I just was looking for the minimal possible interface that will allow us to > call sigreturn. Rick is right and CRIU does try to expose as little as > possible and handle the pain in the userspace. > > The SIGFRAME approach is indeed very helpful, especially if we can make it > work on other architectures eventually. I thought the full sigframe layout depends very much on what the kernel decides it needs to save? Some parts are exposed to the signal handler, but there are large blocks of data that XSAVE (etc) save that have to be put onto the signal stack. Is it even vaguely feasible to replicate what a specific kernel generates on specific hardware in a userspace library? The size of this data is getting bigger and bigger - causing issues with the SIGALTSTACK (and even thread stack) minimum sizes. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)