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 X-Spam-Level: X-Spam-Status: No, score=-4.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7ACE6C433B4 for ; Thu, 29 Apr 2021 07:28:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C2A366143E for ; Thu, 29 Apr 2021 07:28:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C2A366143E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D48E06B006C; Thu, 29 Apr 2021 03:28:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CF88C6B006E; Thu, 29 Apr 2021 03:28:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B5D2F6B0070; Thu, 29 Apr 2021 03:28:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0239.hostedemail.com [216.40.44.239]) by kanga.kvack.org (Postfix) with ESMTP id A5B996B006C for ; Thu, 29 Apr 2021 03:28:11 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 58491181AF5C3 for ; Thu, 29 Apr 2021 07:28:11 +0000 (UTC) X-FDA: 78084575982.11.8887881 Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) by imf03.hostedemail.com (Postfix) with ESMTP id 14FAEC0007D7 for ; Thu, 29 Apr 2021 07:28:04 +0000 (UTC) Received: by mail-lf1-f41.google.com with SMTP id 12so103008662lfq.13 for ; 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=es5VzvfemubkB7SBFYIxhNrC4k6thyPqn2Khfeu0IKIi4KM31ZD/WCuvfRPM0rsEjx snVbaA/XgQMuE03kCDPTLzxUhbo7Zj3rgujFEjoJ/oVXU0c6yzYIpHecAyT5JCwXAMF4 r2V1fUsEo7qVEa7sf4VYc0FUkxqdItgN9NTuTsHiMo0r4wzVzbwmKuLa9PXrcQSLeF06 TcgD97MxpXbQxF7SfMwt8SM+sCfzoDGeZzjnc5bFue8uAVE45OTjV7q40eWRw9OslRcS 28Sg2M44PCL5HPkxtGhPIRUX5GT6h2TSWn3fGn0hB1cnNsyISrJsNIn7LxHxxozsoXIt PQHw== X-Gm-Message-State: AOAM53383TMbRMH/RhBQff31zWbinOeIjJPXeKGoTf/UI2eX/w/eQLwx 3Zeq9fAVHxA+dJr9T7KnfoA= X-Google-Smtp-Source: ABdhPJwuzpu7JK/CSqJabsNtmy0swVR3AkMVRzJ7rqYa3XCC6KgbaqN5bCkxJUe0VVIgGQcVOJHNpg== 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) X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 14FAEC0007D7 X-Stat-Signature: dpdn65d3tp34jzna5p4x57gzar6ozj3s Received-SPF: none (gmail.com>: No applicable sender policy available) receiver=imf03; identity=mailfrom; envelope-from=""; helo=mail-lf1-f41.google.com; client-ip=209.85.167.41 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1619681284-946579 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, 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.