From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f199.google.com (mail-qk0-f199.google.com [209.85.220.199]) by kanga.kvack.org (Postfix) with ESMTP id A57AC6B0003 for ; Mon, 4 Jun 2018 17:00:08 -0400 (EDT) Received: by mail-qk0-f199.google.com with SMTP id 126-v6so57543qkd.20 for ; Mon, 04 Jun 2018 14:00:08 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com. [66.187.233.73]) by mx.google.com with ESMTPS id 11-v6si209301qvj.212.2018.06.04.14.00.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Jun 2018 14:00:07 -0700 (PDT) Subject: Re: pkeys on POWER: Access rights not reset on execve References: <20180519202747.GK5479@ram.oc3035372033.ibm.com> <20180520060425.GL5479@ram.oc3035372033.ibm.com> <20180520191115.GM5479@ram.oc3035372033.ibm.com> <20180603201832.GA10109@ram.oc3035372033.ibm.com> <4e53b91f-80a7-816a-3e9b-56d7be7cd092@redhat.com> <20180604140135.GA10088@ram.oc3035372033.ibm.com> <20180604190229.GB10088@ram.oc3035372033.ibm.com> From: Florian Weimer Message-ID: <30040030-1aa2-623b-beec-dd1ceb3eb9a7@redhat.com> Date: Mon, 4 Jun 2018 23:00:00 +0200 MIME-Version: 1.0 In-Reply-To: <20180604190229.GB10088@ram.oc3035372033.ibm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Ram Pai Cc: Andy Lutomirski , Linux-MM , linuxppc-dev , Dave Hansen On 06/04/2018 09:02 PM, Ram Pai wrote: > On Mon, Jun 04, 2018 at 07:57:46PM +0200, Florian Weimer wrote: >> On 06/04/2018 04:01 PM, Ram Pai wrote: >>> On Mon, Jun 04, 2018 at 12:12:07PM +0200, Florian Weimer wrote: >>>> On 06/03/2018 10:18 PM, Ram Pai wrote: >>>>> On Mon, May 21, 2018 at 01:29:11PM +0200, Florian Weimer wrote: >>>>>> On 05/20/2018 09:11 PM, Ram Pai wrote: >>>>>>> Florian, >>>>>>> >>>>>>> Does the following patch fix the problem for you? Just like x86 >>>>>>> I am enabling all keys in the UAMOR register during >>>>>>> initialization itself. Hence any key created by any thread at >>>>>>> any time, will get activated on all threads. So any thread >>>>>>> can change the permission on that key. Smoke tested it >>>>>>> with your test program. >>>>>> >>>>>> I think this goes in the right direction, but the AMR value after >>>>>> fork is still strange: >>>>>> >>>>>> AMR (PID 34912): 0x0000000000000000 >>>>>> AMR after fork (PID 34913): 0x0000000000000000 >>>>>> AMR (PID 34913): 0x0000000000000000 >>>>>> Allocated key in subprocess (PID 34913): 2 >>>>>> Allocated key (PID 34912): 2 >>>>>> Setting AMR: 0xffffffffffffffff >>>>>> New AMR value (PID 34912): 0x0fffffffffffffff >>>>>> About to call execl (PID 34912) ... >>>>>> AMR (PID 34912): 0x0fffffffffffffff >>>>>> AMR after fork (PID 34914): 0x0000000000000003 >>>>>> AMR (PID 34914): 0x0000000000000003 >>>>>> Allocated key in subprocess (PID 34914): 2 >>>>>> Allocated key (PID 34912): 2 >>>>>> Setting AMR: 0xffffffffffffffff >>>>>> New AMR value (PID 34912): 0x0fffffffffffffff >>>>>> >>>>>> I mean this line: >>>>>> >>>>>> AMR after fork (PID 34914): 0x0000000000000003 >>>>>> >>>>>> Shouldn't it be the same as in the parent process? >>>>> >>>>> Fixed it. Please try this patch. If it all works to your satisfaction, I >>>>> will clean it up further and send to Michael Ellermen(ppc maintainer). >>>>> >>>>> >>>>> commit 51f4208ed5baeab1edb9b0f8b68d7144449b3527 >>>>> Author: Ram Pai >>>>> Date: Sun Jun 3 14:44:32 2018 -0500 >>>>> >>>>> Fix for the fork bug. >>>>> Signed-off-by: Ram Pai >>>> >>>> Is this on top of the previous patch, or a separate fix? >>> >>> top of previous patch. >> >> Thanks. With this patch, I get this on an LPAR: >> >> AMR (PID 1876): 0x0000000000000003 >> AMR after fork (PID 1877): 0x0000000000000003 >> AMR (PID 1877): 0x0000000000000003 >> Allocated key in subprocess (PID 1877): 2 >> Allocated key (PID 1876): 2 >> Setting AMR: 0xffffffffffffffff >> New AMR value (PID 1876): 0x0fffffffffffffff >> About to call execl (PID 1876) ... >> AMR (PID 1876): 0x0000000000000003 >> AMR after fork (PID 1878): 0x0000000000000003 >> AMR (PID 1878): 0x0000000000000003 >> Allocated key in subprocess (PID 1878): 2 >> Allocated key (PID 1876): 2 >> Setting AMR: 0xffffffffffffffff >> New AMR value (PID 1876): 0x0fffffffffffffff >> >> Test program is still this one: >> >> >> >> So the process starts out with a different AMR value for some >> reason. That could be a pre-existing bug that was just hidden by the >> reset-to-zero on fork, or it could be intentional. But the kernel > > yes it is a bug, a patch for which is lined up for submission.. > > The fix is > > > commit eaf5b2ac002ad2f5bca118d7ce075ce28311aa8e > Author: Ram Pai > Date: Mon Jun 4 10:58:44 2018 -0500 > > powerpc/pkeys: fix total pkeys calculation > > Total number of pkeys calculation is off by 1. Fix it. > > Signed-off-by: Ram Pai Looks good to me now. Initial AMR value is zero, as is currently intended. So the remaining question at this point is whether the Intel behavior (default-deny instead of default-allow) is preferable. But if you can get the existing fixes into 4.18 and perhaps the relevant stable kernels, that would already be a great help for my glibc work. Thanks, Florian