On 06/11/2018 10:08 PM, Ram Pai wrote:
Ok. try this patch. This patch is on top of the 5 patches that I had
sent last week i.e "[PATCH 0/5] powerpc/pkeys: fixes to pkeys"
The following is a draft patch though to check if it meets your
expectations.
commit fe53b5fe2dcb3139ea27ade3ae7cbbe43c4af
On Mon, Jun 11, 2018 at 07:29:33PM +0200, Florian Weimer wrote:
> On 06/11/2018 07:23 PM, Ram Pai wrote:
> >On Fri, Jun 08, 2018 at 07:53:51AM +0200, Florian Weimer wrote:
> >>On 06/08/2018 04:34 AM, Ram Pai wrote:
>
> So the remaining question at this point is whether the Intel
> beha
On 06/11/2018 07:23 PM, Ram Pai wrote:
On Fri, Jun 08, 2018 at 07:53:51AM +0200, Florian Weimer wrote:
On 06/08/2018 04:34 AM, Ram Pai wrote:
So the remaining question at this point is whether the Intel
behavior (default-deny instead of default-allow) is preferable.
Florian, remind me what b
On Fri, Jun 08, 2018 at 07:53:51AM +0200, Florian Weimer wrote:
> On 06/08/2018 04:34 AM, Ram Pai wrote:
> >>
> >>So the remaining question at this point is whether the Intel
> >>behavior (default-deny instead of default-allow) is preferable.
> >
> >Florian, remind me what behavior needs to fixed?
On Fri, 8 Jun 2018 15:51:03 +0200
Florian Weimer wrote:
> On 06/08/2018 03:49 PM, Michal Suchánek wrote:
> > On Fri, 8 Jun 2018 14:57:06 +0200
> > Florian Weimer wrote:
> >
> >> On 06/08/2018 02:54 PM, Michal Suchánek wrote:
> >>> On Fri, 8 Jun 2018 12:44:53 +0200
> >>> Florian Weimer wrot
On 06/08/2018 03:49 PM, Michal Suchánek wrote:
On Fri, 8 Jun 2018 14:57:06 +0200
Florian Weimer wrote:
On 06/08/2018 02:54 PM, Michal Suchánek wrote:
On Fri, 8 Jun 2018 12:44:53 +0200
Florian Weimer wrote:
On 06/08/2018 12:15 PM, Michal Suchánek wrote:
On Fri, 8 Jun 2018 07:53:51 +0200
On Fri, 8 Jun 2018 14:57:06 +0200
Florian Weimer wrote:
> On 06/08/2018 02:54 PM, Michal Suchánek wrote:
> > On Fri, 8 Jun 2018 12:44:53 +0200
> > Florian Weimer wrote:
> >
> >> On 06/08/2018 12:15 PM, Michal Suchánek wrote:
> >>> On Fri, 8 Jun 2018 07:53:51 +0200
> >>> Florian Weimer wrot
On 06/08/2018 02:54 PM, Michal Suchánek wrote:
On Fri, 8 Jun 2018 12:44:53 +0200
Florian Weimer wrote:
On 06/08/2018 12:15 PM, Michal Suchánek wrote:
On Fri, 8 Jun 2018 07:53:51 +0200
Florian Weimer wrote:
On 06/08/2018 04:34 AM, Ram Pai wrote:
So the remaining question at this point
On Fri, 8 Jun 2018 12:44:53 +0200
Florian Weimer wrote:
> On 06/08/2018 12:15 PM, Michal Suchánek wrote:
> > On Fri, 8 Jun 2018 07:53:51 +0200
> > Florian Weimer wrote:
> >
> >> On 06/08/2018 04:34 AM, Ram Pai wrote:
>
> So the remaining question at this point is whether the Intel
On 06/08/2018 12:15 PM, Michal Suchánek wrote:
On Fri, 8 Jun 2018 07:53:51 +0200
Florian Weimer wrote:
On 06/08/2018 04:34 AM, Ram Pai wrote:
So the remaining question at this point is whether the Intel
behavior (default-deny instead of default-allow) is preferable.
Florian, remind me what
On Fri, 8 Jun 2018 07:53:51 +0200
Florian Weimer wrote:
> On 06/08/2018 04:34 AM, Ram Pai wrote:
> >>
> >> So the remaining question at this point is whether the Intel
> >> behavior (default-deny instead of default-allow) is preferable.
> >
> > Florian, remind me what behavior needs to fixed?
On 06/08/2018 04:34 AM, Ram Pai wrote:
So the remaining question at this point is whether the Intel
behavior (default-deny instead of default-allow) is preferable.
Florian, remind me what behavior needs to fixed?
See the other thread. The Intel register equivalent to the AMR by
default dis
>
> So the remaining question at this point is whether the Intel
> behavior (default-deny instead of default-allow) is preferable.
Florian, remind me what behavior needs to fixed?
--
Ram Pai
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, Floria
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/
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 t
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
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
in
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
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 t
On Sat, May 19, 2018 at 11:06:20PM -0700, Andy Lutomirski wrote:
> On Sat, May 19, 2018 at 11:04 PM Ram Pai wrote:
>
> > On Sat, May 19, 2018 at 04:47:23PM -0700, Andy Lutomirski wrote: > On
> Sat, May 19, 2018 at 1:28 PM Ram Pai wrote:
>
> > ...snip...
> > >
> > > So is it possible for two thr
On Sat, May 19, 2018 at 11:04 PM Ram Pai wrote:
> On Sat, May 19, 2018 at 04:47:23PM -0700, Andy Lutomirski wrote: > On
Sat, May 19, 2018 at 1:28 PM Ram Pai wrote:
> ...snip...
> >
> > So is it possible for two threads to each call pkey_alloc() and end up
with
> > the same key? If so, it seems
On Sat, May 19, 2018 at 04:47:23PM -0700, Andy Lutomirski wrote: > On Sat, May
19, 2018 at 1:28 PM Ram Pai wrote:
...snip...
>
> So is it possible for two threads to each call pkey_alloc() and end up with
> the same key? If so, it seems entirely broken.
No. Two threads cannot allocate the sa
On Sat, May 19, 2018 at 1:28 PM Ram Pai wrote:
> You got it mostly right. Filling in some more details below for
> completeness.
> [...]
Okay, so I guess I was correct as to what the functionality was but not as
to the encoding or the name of UAMOR.
Can you also confirm that mprotect_key() aff
On Fri, May 18, 2018 at 06:50:39PM -0700, Andy Lutomirski wrote:
> On Fri, May 18, 2018 at 6:19 PM Ram Pai wrote:
>
> > However the fundamental issue is still the same, as mentioned in the
> > other thread.
>
> > "Should the permissions on a key be allowed to be changed, if the key
> > is not al
On 05/19/2018 03:19 AM, Ram Pai wrote:
The issue you may be talking about here is that --
"when you set the AMR register to 0x, it
just sets it to 0x0c00."
To me it looks like, exec/fork are not related to the issue.
Or are they also somehow connected to the issue?
On 05/19/2018 03:50 AM, Andy Lutomirski wrote:
Now another thread calls pkey_alloc(), so UAMR is asynchronously changed,
and the thread will write zero to the relevant AMR bits. If I understand
correctly, this means that the decision to mask off unallocated keys via
UAMR effectively forces the i
On 05/19/2018 03:19 AM, Ram Pai wrote:
New AMR value (PID 112291, before execl): 0x0c00
AMR (PID 112291): 0x0c00
The issue is here. The second line is after the execl (printed from the
start of main), and the AMR value is not reset to zero.
Allocated key (PID 11229
On Fri, May 18, 2018 at 6:19 PM Ram Pai wrote:
> However the fundamental issue is still the same, as mentioned in the
> other thread.
> "Should the permissions on a key be allowed to be changed, if the key
> is not allocated in the first place?".
> my answer is NO. Lets debate :)
As a preface,
On Fri, May 18, 2018 at 04:27:14PM +0200, Florian Weimer wrote:
> This test program:
>
> #include
> #include
> #include
> #include
> #include
> #include
>
> /* Return the value of the AMR register. */
> static inline unsigned long int
> pkey_read (void)
> {
> unsigned long int result;
>
This test program:
#include
#include
#include
#include
#include
#include
/* Return the value of the AMR register. */
static inline unsigned long int
pkey_read (void)
{
unsigned long int result;
__asm__ volatile ("mfspr %0, 13" : "=r" (result));
return result;
}
/* Overwrite the AMR
31 matches
Mail list logo