Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753687AbdFVVlq (ORCPT ); Thu, 22 Jun 2017 17:41:46 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:60397 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753319AbdFVVlp (ORCPT ); Thu, 22 Jun 2017 17:41:45 -0400 Date: Thu, 22 Jun 2017 14:41:31 -0700 From: Ram Pai To: Benjamin Herrenschmidt Cc: Anshuman Khandual , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, dave.hansen@intel.com, paulus@samba.org, aneesh.kumar@linux.vnet.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> <622d7abf-3d99-8897-5afb-ef8c4f950fc0@linux.vnet.ibm.com> <1497609181.2897.100.camel@kernel.crashing.org> <20170616191537.GB17588@ram.oc3035372033.ibm.com> <1497653684.2897.104.camel@kernel.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1497653684.2897.104.camel@kernel.crashing.org> User-Agent: Mutt/1.5.20 (2009-12-10) X-TM-AS-GCONF: 00 x-cbid: 17062221-0004-0000-0000-0000126E287A X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007274; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000214; SDB=6.00878458; UDB=6.00437715; IPR=6.00658597; BA=6.00005437; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00015927; XFM=3.00000015; UTC=2017-06-22 21:41:42 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17062221-0005-0000-0000-00007FE1FDD8 Message-Id: <20170622214131.GO17588@ram.oc3035372033.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-22_09:,, 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-1706220370 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1419 Lines: 32 On Sat, Jun 17, 2017 at 08:54:44AM +1000, Benjamin Herrenschmidt wrote: > On Fri, 2017-06-16 at 12:15 -0700, Ram Pai wrote: > > gp_regs size is not changed, nor is the layout. A unused field in > > the gp_regs is used to fill in the AMR contents. Old binaries will not > > be knowing about this unused field, and hence should not break. > > > > New binaries can leverage this already existing but newly defined > > field; to read the contents of AMR. > > > > Is it still a concern? > > Calls to sys_swapcontext with a made-up context will end up with a crap > AMR if done by code who didn't know about that register. Turns out x86 does not have this problem, because x86 does not implement sys_swapcontext. However; unlike x86, powerpc lets signal handler program the AMR(x86 PKRU equivalent), which can persist even after the signal handler returns to the kernel through sys_sigreturn. So I am inclined to deviate from the x86 protection-key semantics. On x86 the persistent way for the signal handler to change the key register(PKRU) is through a field in the siginfo structure. And on powerpc the persistent way for the signal handler to change the key register(AMR) will be to directly program the AMR register. This should resolve your concern on powerpc, since there is no way a crap AMR value will change the real AMR register, because the powerpc kernel will not be letting it happen. Acceptable? RP