Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp1154771pxy; Thu, 29 Apr 2021 00:30:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyiED1c4mh7hNF0aM21IUsaZzzg4euE8okVAUIwDp+gQWO67aTq0qQtS2UBxAe1Fl8zC0/k X-Received: by 2002:a63:e007:: with SMTP id e7mr32364824pgh.260.1619681446228; Thu, 29 Apr 2021 00:30:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619681446; cv=none; d=google.com; s=arc-20160816; b=ja4tgDxCj7M28bVIZ2mSgerWkXfVb/BvCv9rEMkm1KitulJxc3lUqKOm451T/Jf56Q ++NJraNe73AHdJb2jF1n8VPJAOX4EfVZNWZ8ei+bdSq4ASJbZuUBXycBxJlyciXD4P08 0DWRaJkP+akNXyXrTJ46HSTsfMkck/CdcEEOk6htgw0jFIc4TWwKgQycE3+EN+bX7Owz d0HN+Be7Y20CV1I3/sjS/7sHgPzB8WkFXmCRz1UYR5tO0hY5FNfb9ZIHaXPK1qX0hWYC B8KMJ5nSTgPyA6mSB3of29fCtL0lMPyjjHm1eGeISx1kP4pflTTdLamEA2C+GsjKhgwp kdAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=jdGoIRWBioljnz1nn4BBzNDaqsoqN9PPsguAeYrjWLg=; b=uQH7Jsls0MzhmokIuqoWRsTHrWbqGdRlFspvaOz6act5Zb9ikAaBn8HuywbiZvYp2O OsmclptOj3Kw+baDHQJBoT06xw9jEJ/6jwlb7Ci/c1l0ry2qF2ckbO5l2r8i89+PGHsq QInphhAnROtneh7skE2db8cWc4iAYOd3PXpBn8ghUc5hm61YnyL+wj+cUq6vz3BqDZQF 4DM+x24A1raFhzaxil54OCvHV73V/uQwFUgNM47wNacLsZh1kczUm6JSW7PBy22WbqLN C4KXa9gldsXMlUcRvNE5/SC3fP7E6KM8k+AzL0A0PKASUPK2iGNOgtNV5bxmvssMOi08 SJIw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=HJX7+45y; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n10si928458plc.81.2021.04.29.00.30.33; Thu, 29 Apr 2021 00:30:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=HJX7+45y; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239579AbhD2H3D (ORCPT + 99 others); Thu, 29 Apr 2021 03:29:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60038 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239542AbhD2H25 (ORCPT ); Thu, 29 Apr 2021 03:28:57 -0400 Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 08E48C06138F; Thu, 29 Apr 2021 00:28:11 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id h36so49163112lfv.7; Thu, 29 Apr 2021 00:28:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=jdGoIRWBioljnz1nn4BBzNDaqsoqN9PPsguAeYrjWLg=; b=HJX7+45yNzfNOqoK21ORJnfSS4SqA73WGkbuaPh5kcOvNYBW3pgUgci+P8nrnGhQNi QZWfIOMDuLxP7E+IQpYLX9lQKKuah9ZA8zd1fRzmg+us00a0DmfVFSJnoglvDlrR5JPu wZT0M0/aUfULpMBV9n6oztU1UyISEfYE99jx+Q8TP6g+4uRAG8uA8+yTJauJnN5AbBUY qNoqboxDl+xzzGI7bhFrM+aicJFNWgbT7KP6ymuX4ynpdc3n//T15fOaV6b78MEdGhpM FgBTL7grc3s+XEViMjWFpN6JTZThcff9VQa1IWXouixVnItPd6v/EBVeRr1oW/H3lGiu /UIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=jdGoIRWBioljnz1nn4BBzNDaqsoqN9PPsguAeYrjWLg=; b=F7+IaO8wzRH5HaDZ7T77Gov35YfycrgsjdDmc/5Uz+pJbUnQSZzrU5lrgE64EQhJSP 32Lk8yfAiYARvKp8shBrftuGmLcoo0qws35hlHZkKmaMgohLu7GvpPRhbBsZ32ZOSgWi oMOroKpoqpAKsqedrDZsnY9U12THMT0UMEIFYriBshw4xmcaFWca8fXO4ITnqb9iX6RR osr1sxE1LfcqW6m17zK5polb/jxBA9GGCTBP2iXmptwNrb8WAfllNfT1ntJVIz1VIq40 Oa5gI4UTsU6qavlS3g4NLC5zoJ4RO2GeoNH7aZjxwb7W3mPYw1VDTMLzT7qJ1JoL1Jt+ jb9A== X-Gm-Message-State: AOAM531FUzHww6X9No679KWry/KHEaRq6pENdedH23LqD53HVRitJCdj H0n7s7Bmx7zpKM0RozizhrY= X-Received: by 2002:a05:6512:12d2:: with SMTP id p18mr4572032lfg.239.1619681289241; Thu, 29 Apr 2021 00:28:09 -0700 (PDT) Received: from grain.localdomain ([5.18.199.94]) by smtp.gmail.com with ESMTPSA id f17sm260073lfu.215.2021.04.29.00.28.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Apr 2021 00:28:08 -0700 (PDT) Received: by grain.localdomain (Postfix, from userid 1000) id 72CF5560116; Thu, 29 Apr 2021 10:28:07 +0300 (MSK) Date: Thu, 29 Apr 2021 10:28:07 +0300 From: Cyrill Gorcunov To: Andy Lutomirski Cc: Yu-cheng Yu , linux-arch , X86 ML , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , LKML , "open list:DOCUMENTATION" , Linux-MM , Linux API , Arnd Bergmann , Balbir Singh , Borislav Petkov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , "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: extending ucontext (Re: [PATCH v26 25/30] x86/cet/shstk: Handle signals for shadow stack) Message-ID: References: <20210427204315.24153-1-yu-cheng.yu@intel.com> <20210427204315.24153-26-yu-cheng.yu@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.0.5 (2021-01-21) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 28, 2021 at 04:03:55PM -0700, Andy Lutomirski wrote: > On Tue, Apr 27, 2021 at 1:44 PM Yu-cheng Yu wrote: > > > > When shadow stack is enabled, a task's shadow stack states must be saved > > along with the signal context and later restored in sigreturn. However, > > currently there is no systematic facility for extending a signal context. > > There is some space left in the ucontext, but changing ucontext is likely > > to create compatibility issues and there is not enough space for further > > extensions. > > > > Introduce a signal context extension struct 'sc_ext', which is used to save > > shadow stack restore token address. The extension is located above the fpu > > states, plus alignment. The struct can be extended (such as the ibt's > > wait_endbr status to be introduced later), and sc_ext.total_size field > > keeps track of total size. > > I still don't like this. > > Here's how the signal layout works, for better or for worse: > > The kernel has: > > struct rt_sigframe { > char __user *pretcode; > struct ucontext uc; > struct siginfo info; > /* fp state follows here */ > }; > > This is roughly the actual signal frame. But userspace does not have > this struct declared, and user code does not know the sizes of the > fields. So it's accessed in a nonsensical way. The signal handler Well, not really. While indeed this is not declared as a part of API the structure is widely used for rt_sigreturn syscall (and we're using it inside criu thus any change here will simply break the restore procedure). Sorry out of time right now, I'll read your mail more carefully once time permit.