On Tue, Nov 20, 2018 at 1:14 PM Kees Cook wrote:
>
> On Fri, Oct 26, 2018 at 12:59 PM, Dave Hansen wrote:
> > On 10/26/18 12:51 PM, Dave Hansen wrote:
> > ...
> >> The result is that, after a fork(), the child's pkey state ends up
> >> looking like it does after an execve(), which is totally wron
On Fri, Oct 26, 2018 at 12:59 PM, Dave Hansen wrote:
> On 10/26/18 12:51 PM, Dave Hansen wrote:
> ...
>> The result is that, after a fork(), the child's pkey state ends up
>> looking like it does after an execve(), which is totally wrong. pkeys
>> that are already allocated can be allocated again
Yeah, a no-op pkey_alloc flag tied to this patch to provide a way to
detect if pkey state is preserved on fork, since kernels without the
patch would report EINVAL. Something like
PKEY_ASSERT_FORK_INHERIT_STATE would make sense. Otherwise, it's
going to be quite painful to adopt this in userspace s
* Daniel Micay wrote:
> > I suppose we could add a new flag for pkey_get() or something.
>
> That would work, since I can apply the workaround (disabling the
> feature in child processes) if I get EINVAL. The flag wouldn't need to
> do anything, just existing and being tied to this patch so I
On Fri, 26 Oct 2018 at 18:12, Andy Lutomirski wrote:
>
>
>
> > On Oct 26, 2018, at 2:39 PM, Daniel Micay wrote:
> >
> > I ended up working around this with a pthread_atfork handler disabling
> > my usage of the feature in the child process for the time being. I
> > don't have an easy way to detec
> On Oct 26, 2018, at 2:39 PM, Daniel Micay wrote:
>
> I ended up working around this with a pthread_atfork handler disabling
> my usage of the feature in the child process for the time being. I
> don't have an easy way to detect if the bug is present within a
> library so
Can you not just ma
I ended up working around this with a pthread_atfork handler disabling
my usage of the feature in the child process for the time being. I
don't have an easy way to detect if the bug is present within a
library so I'm going to need a kernel version check with a table of
kernel releases fixing the pr
On 10/26/18 12:51 PM, Dave Hansen wrote:
...
> The result is that, after a fork(), the child's pkey state ends up
> looking like it does after an execve(), which is totally wrong. pkeys
> that are already allocated can be allocated again, for instance.
One thing I omitted. This was very nicely d
From: Dave Hansen
Our creation of new mm's is a bit convoluted. At fork(), the code
does:
1. memcpy() the parent mm to initialize child
2. mm_init() to initalize some select stuff stuff
3. dup_mmap() to create true copies that memcpy()
did not do right.
For
9 matches
Mail list logo
