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 2B6EAC433EF for ; Mon, 7 Mar 2022 22:21:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 97D5C8D0002; Mon, 7 Mar 2022 17:21:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 903198D0001; Mon, 7 Mar 2022 17:21:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7CB048D0002; Mon, 7 Mar 2022 17:21:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id 6990D8D0001 for ; Mon, 7 Mar 2022 17:21:56 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 2E4BB23BDC for ; Mon, 7 Mar 2022 22:21:56 +0000 (UTC) X-FDA: 79219013832.12.1A537CD Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.86.151]) by imf03.hostedemail.com (Postfix) with ESMTP id 6CE002000A for ; Mon, 7 Mar 2022 22:21:55 +0000 (UTC) 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 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 6CE002000A X-Stat-Signature: zpmqaeyj74tcsbpgnwfprtuo7bb6c4xq Authentication-Results: imf03.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=aculab.com; spf=pass (imf03.hostedemail.com: domain of david.laight@aculab.com designates 185.58.86.151 as permitted sender) smtp.mailfrom=david.laight@aculab.com X-HE-Tag: 1646691715-106888 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: 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 scr= atch > > is a pain. That being said, if CRIU isn't excited, then don't bother. >=20 > CRIU is excited :) >=20 > 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. >=20 > The SIGFRAME approach is indeed very helpful, especially if we can make i= t > 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. =09David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1= PT, UK Registration No: 1397386 (Wales)