Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp5495677imm; Tue, 26 Jun 2018 12:16:41 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLhlsgcPnPmffaHzW2J+jlLD9sES2JdVWywHJwgX4qsLgtCbCh5EbER7Zwrv8L8Fvj3se0n X-Received: by 2002:a17:902:6f02:: with SMTP id w2-v6mr2844573plk.216.1530040601146; Tue, 26 Jun 2018 12:16:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530040601; cv=none; d=google.com; s=arc-20160816; b=hFl7DQtJx0pvY4ilBUMUlnl3jRt2B9GQyB3yTjPlqRfWpkGKWkLFwVk58rfSqRWzGm omxRo7Ms4SAEPY6Volmh5u/fypq6l/Xd+tBPatBpXAo0qxKAP5oTkMLj1gYBEMkjGdlv 1r7M1rg75m2p/blEvQnXQkhebUHiz96XjyB9SnoKHaGWorZo+ry7nc/Me/3esVcb3F9H a+yEPRurM4DEqyIZlIWvwJXrxERhW7rBXKzZm+lnbi5Moq45+lVSM+pRqmKTA/OGoyGt oH1kSMj3LScDkurKn+NByMRrsqRi4zfeF54P5+YjmowTCc31v/uIQ129yhK9q3iktPP5 OM/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:thread-index:thread-topic :content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:dkim-signature:dkim-filter :arc-authentication-results; bh=v8nSl5O6JQotaKpRZ2s3rbOoTbh14uB3IPy5ozjdjYY=; b=Vx/7O5eIIXK+Q01j5woh0oRRaPLGflSrcwBOrO0kugw1JGkOmFSz1KC7McLLisxoPj hlNUMiZ6ps/L6ZKeDupIU6zw+r3IzMsWrEWZ1YUXtYTifs53LLybZZzuvlVmUG3LY47H ACMNtStLc5elt7DVEtn4wkw2LIjNxu4LVLot21wq55OmGlaIo8N3D7O81tTSACNrvdal qNupH8SD/6qhgiq0mHZM5uNOJJsenUm+ir69ZFxBNbNM2tmpBt9P5YEng0bRQhR4BiBq NXCIDA2DGu2Hu9JmGLgpC4IvdLGTSBM2EH9w5XMDLnG8LXVufnzHplgQ7p/2CGOmyMwt hMrw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@efficios.com header.s=default header.b=EXyD080P; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=efficios.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v187-v6si1900220pgv.678.2018.06.26.12.16.26; Tue, 26 Jun 2018 12:16:41 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@efficios.com header.s=default header.b=EXyD080P; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=efficios.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933664AbeFZSpO (ORCPT + 99 others); Tue, 26 Jun 2018 14:45:14 -0400 Received: from mail.efficios.com ([167.114.142.138]:59318 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933615AbeFZSpN (ORCPT ); Tue, 26 Jun 2018 14:45:13 -0400 Received: from localhost (ip6-localhost [IPv6:::1]) by mail.efficios.com (Postfix) with ESMTP id 4F67522B8F1; Tue, 26 Jun 2018 14:45:12 -0400 (EDT) Received: from mail.efficios.com ([IPv6:::1]) by localhost (mail02.efficios.com [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id OwxrCMlfO9Xq; Tue, 26 Jun 2018 14:45:11 -0400 (EDT) Received: from localhost (ip6-localhost [IPv6:::1]) by mail.efficios.com (Postfix) with ESMTP id BF4B022B8EE; Tue, 26 Jun 2018 14:45:11 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com BF4B022B8EE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1530038711; bh=v8nSl5O6JQotaKpRZ2s3rbOoTbh14uB3IPy5ozjdjYY=; h=Date:From:To:Message-ID:MIME-Version; b=EXyD080PS1Cij6dp/BWoIthYJ5ZdRYYHrrhzTwJtYJSXizuUhBzGIOD2VbhhJGP1A 5tV8BnLowaOb3NGS5vWaO6g0d7at981xfJkkDGFWL2dNfsRls0KYxA7JgcmG0tTkrw 2IMK9eW+jT+HDDOxUYXLRAwJVTJOnmTBRFOUHgSrweOvUj1crWhkL9xkR6EAqcG80O Y6Ad7lLKAuklMGSnol+WmLBB8bwlK2K2KROlb45WeLkQVQK9mDbCMtHWM3C+STiC+b WVfc9xIpEXyWzxWAj+aIkG/4cctGNafkvrajVNZTTvxONdWAcraRfho/xCXwl3DCT7 HTXoWX1NmMrbg== X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([IPv6:::1]) by localhost (mail02.efficios.com [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id NtQIekr6jv7F; Tue, 26 Jun 2018 14:45:11 -0400 (EDT) Received: from mail02.efficios.com (mail02.efficios.com [167.114.142.138]) by mail.efficios.com (Postfix) with ESMTP id AB41F22B8E5; Tue, 26 Jun 2018 14:45:11 -0400 (EDT) Date: Tue, 26 Jun 2018 14:45:11 -0400 (EDT) From: Mathieu Desnoyers To: Andy Lutomirski Cc: Peter Zijlstra , Boqun Feng , linux-kernel , "Paul E. McKenney" , Thomas Gleixner Message-ID: <170076903.5015.1530038711536.JavaMail.zimbra@efficios.com> In-Reply-To: <1514459655.4190.1530034687884.JavaMail.zimbra@efficios.com> References: <1514459655.4190.1530034687884.JavaMail.zimbra@efficios.com> Subject: Re: rseq: How to test for compat task at signal delivery MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [167.114.142.138] X-Mailer: Zimbra 8.8.8_GA_2096 (ZimbraWebClient - FF52 (Linux)/8.8.8_GA_1703) Thread-Topic: rseq: How to test for compat task at signal delivery Thread-Index: F0bW3mNX5qaSbdCuC2GA2EC17JUeiAc/l39L Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- On Jun 26, 2018, at 1:38 PM, Mathieu Desnoyers mathieu.desnoyers@efficios.com wrote: > Hi Andy, > > I would like to make the behavior rseq on compat tasks more robust > by ensuring that kernel/rseq.c:rseq_get_rseq_cs() clears the high > bits of rseq_cs->abort_ip, rseq_cs->start_ip and > rseq_cs->post_commit_offset when a 32-bit binary is run on a 64-bit > kernel. > > The intent here is that if user-space has garbage rather than zeroes > in its struct rseq_cs fields padding, the behavior will be the same > whether the binary is run on 32-bit or 64 kernels. > > I know that internally, the kernel is making a transition from > is_compat_task() to in_compat_syscall(). > > I'm fine with using in_compat_syscall() when rseq_get_rseq_cs() is > invoked from a system call, but is it OK to call it when it is > invoked from signal delivery ? AFAIU, signals can be delivered > upon return from interrupt as well. > > If not, what strategy do you recommend for arch-agnostic code ? I think what we're missing here is a new "is_compat_frame(struct ksignal *ksig)" which I could use in the rseq code. I'll prepare a patch and we can discuss from there. Thanks, Mathieu > > Thanks, > > Mathieu > > -- > Mathieu Desnoyers > EfficiOS Inc. > http://www.efficios.com -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com