From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752684AbdFPTg4 (ORCPT ); Fri, 16 Jun 2017 15:36:56 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:51975 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752516AbdFPTgF (ORCPT ); Fri, 16 Jun 2017 15:36:05 -0400 Date: Fri, 16 Jun 2017 12:35:52 -0700 From: Ram Pai To: Michael Ellerman Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, benh@kernel.crashing.org, paulus@samba.org, khandual@linux.vnet.ibm.com, aneesh.kumar@linux.vnet.ibm.com, bsingharora@gmail.com, dave.hansen@intel.com, hbabu@us.ibm.com Subject: Re: [RFC PATCH 7/7 v1]powerpc: Deliver SEGV signal on protection key violation. Reply-To: Ram Pai References: <1496711109-4968-1-git-send-email-linuxram@us.ibm.com> <1496711109-4968-8-git-send-email-linuxram@us.ibm.com> <87zid8uqnu.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zid8uqnu.fsf@concordia.ellerman.id.au> User-Agent: Mutt/1.5.20 (2009-12-10) X-TM-AS-GCONF: 00 x-cbid: 17061619-0056-0000-0000-0000038B99CF X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007244; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000214; SDB=6.00875744; UDB=6.00436055; IPR=6.00655832; BA=6.00005425; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00015856; XFM=3.00000015; UTC=2017-06-16 19:35:58 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17061619-0057-0000-0000-000007C1AC8D Message-Id: <20170616193552.GC17588@ram.oc3035372033.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-16_11:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706160328 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 16, 2017 at 09:18:29PM +1000, Michael Ellerman wrote: > Ram Pai writes: > > diff --git a/arch/powerpc/include/uapi/asm/ptrace.h b/arch/powerpc/include/uapi/asm/ptrace.h > > index 8036b38..109d0c2 100644 > > --- a/arch/powerpc/include/uapi/asm/ptrace.h > > +++ b/arch/powerpc/include/uapi/asm/ptrace.h > > @@ -49,6 +49,8 @@ struct pt_regs { > > unsigned long dar; /* Fault registers */ > > unsigned long dsisr; /* on 4xx/Book-E used for ESR */ > > unsigned long result; /* Result of a system call */ > > + unsigned long dscr; /* contents of the DSCR register */ > > + unsigned long amr; /* contents of AMR register */ > > }; > > You can't change pt_regs, it's ABI. > > > @@ -109,7 +111,8 @@ struct pt_regs { > > #define PT_DSISR 42 > > #define PT_RESULT 43 > > #define PT_DSCR 44 > > -#define PT_REGS_COUNT 44 > > +#define PT_AMR 45 > > +#define PT_REGS_COUNT 45 > > You can add PT_AMR, but it has to be synthetic like DSCR, ie. not > actually in pt_regs but available via ptrace. ok. > > But do we want to do that? How does the x86 code export the key(s) of a > process? Or doesn't it? The semantics defined on x86 is, signal handler has to have a way of knowing the contents of the PKRU; (the x86 equivalent of AMR). Also the signal handler has to have the ability to modify the PKRU before it returns from the signal handler. This modified information will be used by the kernel to program the CPU's PKRU register. if the signal handler does not have the ability to do so, than when the signal handler returns and the user code restarts executing where it had left, it will continue to access the same protected address and fault again, which will again invoke the signal handler and this will continue infinitely. We have to provide the same semantics on powerpc. The way I intend to do it is to use one of the unused field in the gp_regs and fill that with the contents of the AMR register. PT_AMR, at offset 45 in gp_regs is not used currently. offset 45, 46, and 47 are available AFIACT. Dave: Why is it not ok to reprogram the PKRU from the signal handler, instead of telling the kernel to do so on its behalf? Or have I got my understanding of the semantics wrong? > > cheers -- Ram Pai