Linus Torvalds writes:
> On Wed, Dec 13, 2017 at 7:54 AM, Peter Zijlstra wrote:
>>
>> Which is why get_user_pages() _should_ enforce this.
>>
>> What use are protection keys if you can trivially circumvent them?
>
> No, we will *not* worry about protection keys in get_user_pages().
>
> They are
On Wed, Dec 13, 2017 at 4:10 PM, Matthew Wilcox wrote:
> On Wed, Dec 13, 2017 at 11:12:33PM +0100, Peter Zijlstra wrote:
>> On Wed, Dec 13, 2017 at 01:50:22PM -0800, Matthew Wilcox wrote:
>> > On Tue, Dec 12, 2017 at 06:32:26PM +0100, Thomas Gleixner wrote:
>> > > From: Peter Zijstra
>> > > In or
On Wed, Dec 13, 2017 at 11:12:33PM +0100, Peter Zijlstra wrote:
> On Wed, Dec 13, 2017 at 01:50:22PM -0800, Matthew Wilcox wrote:
> > On Tue, Dec 12, 2017 at 06:32:26PM +0100, Thomas Gleixner wrote:
> > > From: Peter Zijstra
> > > In order to create VMAs that are not accessible to userspace create
On Wed, Dec 13, 2017 at 01:50:22PM -0800, Matthew Wilcox wrote:
> On Tue, Dec 12, 2017 at 06:32:26PM +0100, Thomas Gleixner wrote:
> > From: Peter Zijstra
> >
> > In order to create VMAs that are not accessible to userspace create a new
> > VM_NOUSER flag. This can be used in conjunction with
> >
On Tue, Dec 12, 2017 at 06:32:26PM +0100, Thomas Gleixner wrote:
> From: Peter Zijstra
>
> In order to create VMAs that are not accessible to userspace create a new
> VM_NOUSER flag. This can be used in conjunction with
> install_special_mapping() to inject 'kernel' data into the userspace map.
On Wed, Dec 13, 2017 at 10:32 AM, Peter Zijlstra wrote:
>
> Now, if VM_NOUSER were to live, the above change would ensure write(2)
> cannot read from such VMAs, where the existing test for FOLL_WRITE
> already disallows read(2) from writing to them.
So I don't mind at all the notion of disallowin
On Wed, Dec 13, 2017 at 10:08:30AM -0800, Linus Torvalds wrote:
> On Wed, Dec 13, 2017 at 7:54 AM, Peter Zijlstra wrote:
> >
> > Which is why get_user_pages() _should_ enforce this.
> >
> > What use are protection keys if you can trivially circumvent them?
>
> No, we will *not* worry about protec
On Wed, Dec 13, 2017 at 10:08 AM, Linus Torvalds
wrote:
> On Wed, Dec 13, 2017 at 7:54 AM, Peter Zijlstra wrote:
>>
>> Which is why get_user_pages() _should_ enforce this.
>>
>> What use are protection keys if you can trivially circumvent them?
>
> No, we will *not* worry about protection keys in
On Wed, Dec 13, 2017 at 10:21 AM, Dave Hansen wrote:
> On 12/13/2017 10:08 AM, Linus Torvalds wrote:
>> On Wed, Dec 13, 2017 at 7:54 AM, Peter Zijlstr wrote:
>>> Which is why get_user_pages() _should_ enforce this.
>>>
>>> What use are protection keys if you can trivially circumvent them?
>> No,
On 12/13/2017 10:08 AM, Linus Torvalds wrote:
> On Wed, Dec 13, 2017 at 7:54 AM, Peter Zijlstr wrote:
>> Which is why get_user_pages() _should_ enforce this.
>>
>> What use are protection keys if you can trivially circumvent them?
> No, we will *not* worry about protection keys in get_user_pages(
On Wed, Dec 13, 2017 at 7:54 AM, Peter Zijlstra wrote:
>
> Which is why get_user_pages() _should_ enforce this.
>
> What use are protection keys if you can trivially circumvent them?
No, we will *not* worry about protection keys in get_user_pages().
They are not "security". They are a debug aid
On Wed, Dec 13, 2017 at 07:47:46AM -0800, Dave Hansen wrote:
> On 12/13/2017 07:32 AM, Peter Zijlstra wrote:
> >> This will fault writing a byte to 'addr':
> >>
> >>char *addr = malloc(PAGE_SIZE);
> >>pkey_mprotect(addr, PAGE_SIZE, 13);
> >>pkey_deny_access(13);
> >>*addr[0] = 'f';
On 12/13/2017 07:32 AM, Peter Zijlstra wrote:
>> This will fault writing a byte to 'addr':
>>
>> char *addr = malloc(PAGE_SIZE);
>> pkey_mprotect(addr, PAGE_SIZE, 13);
>> pkey_deny_access(13);
>> *addr[0] = 'f';
>>
>> But this will write one byte to addr successfully (if it uses
On Wed, Dec 13, 2017 at 07:14:41AM -0800, Dave Hansen wrote:
> On 12/13/2017 04:57 AM, Kirill A. Shutemov wrote:
> > Dave, what is effect of this on protection keys?
>
> The goal was to make pkeys-protected userspace memory access
> _consistent_ with normal access. Specifically, we want a kernel
On 12/13/2017 04:57 AM, Kirill A. Shutemov wrote:
> Dave, what is effect of this on protection keys?
The goal was to make pkeys-protected userspace memory access
_consistent_ with normal access. Specifically, we want a kernel to
disallow access (or writes) to memory where userspace mapping has a
On Wed, Dec 13, 2017 at 04:00:07PM +0100, Peter Zijlstra wrote:
> On Wed, Dec 13, 2017 at 05:43:39PM +0300, Kirill A. Shutemov wrote:
> > > am I perchance looking at the wrong tee?
> >
> > I'm looking at Linus' tree.
>
> Clearly I'm not synced up enough... :/
>
> > It was changed recently:
> >
On Wed, Dec 13, 2017 at 05:43:39PM +0300, Kirill A. Shutemov wrote:
> > am I perchance looking at the wrong tee?
>
> I'm looking at Linus' tree.
Clearly I'm not synced up enough... :/
> It was changed recently:
> 5c9d2d5c269c ("mm: replace pte_write with pte_access_permitted in fault
> +
On Wed, Dec 13, 2017 at 03:34:55PM +0100, Peter Zijlstra wrote:
> On Wed, Dec 13, 2017 at 03:57:40PM +0300, Kirill A. Shutemov wrote:
> > On Wed, Dec 13, 2017 at 01:22:11PM +0100, Peter Zijlstra wrote:
>
> > > get_user_pages_fast() will ultimately end up doing
> > > pte_access_permitted() before g
On Wed, Dec 13, 2017 at 03:57:40PM +0300, Kirill A. Shutemov wrote:
> On Wed, Dec 13, 2017 at 01:22:11PM +0100, Peter Zijlstra wrote:
> > get_user_pages_fast() will ultimately end up doing
> > pte_access_permitted() before getting the page, follow_page OTOH does
> > not do this, which makes for a
On Wed, Dec 13, 2017 at 01:22:11PM +0100, Peter Zijlstra wrote:
> On Tue, Dec 12, 2017 at 10:00:08AM -0800, Andy Lutomirski wrote:
> > On Tue, Dec 12, 2017 at 9:32 AM, Thomas Gleixner wrote:
> > > From: Peter Zijstra
> > >
> > > In order to create VMAs that are not accessible to userspace create
On Tue, Dec 12, 2017 at 10:00:08AM -0800, Andy Lutomirski wrote:
> On Tue, Dec 12, 2017 at 9:32 AM, Thomas Gleixner wrote:
> > From: Peter Zijstra
> >
> > In order to create VMAs that are not accessible to userspace create a new
> > VM_NOUSER flag. This can be used in conjunction with
> > install
On Tue, Dec 12, 2017 at 10:06:51AM -0800, Andy Lutomirski wrote:
> On Tue, Dec 12, 2017 at 10:05 AM, Peter Zijlstra wrote:
> > gup would find the page. These patches do in fact rely on that through
> > the populate things.
> >
>
> Blech. So you can write(2) from the LDT to a file and you can ev
On Tue, Dec 12, 2017 at 10:05 AM, Peter Zijlstra wrote:
> On Tue, Dec 12, 2017 at 10:00:08AM -0800, Andy Lutomirski wrote:
>> On Tue, Dec 12, 2017 at 9:32 AM, Thomas Gleixner wrote:
>> > From: Peter Zijstra
>> >
>> > In order to create VMAs that are not accessible to userspace create a new
>> >
On Tue, Dec 12, 2017 at 10:00:08AM -0800, Andy Lutomirski wrote:
> On Tue, Dec 12, 2017 at 9:32 AM, Thomas Gleixner wrote:
> > From: Peter Zijstra
> >
> > In order to create VMAs that are not accessible to userspace create a new
> > VM_NOUSER flag. This can be used in conjunction with
> > install
On Tue, Dec 12, 2017 at 9:32 AM, Thomas Gleixner wrote:
> From: Peter Zijstra
>
> In order to create VMAs that are not accessible to userspace create a new
> VM_NOUSER flag. This can be used in conjunction with
> install_special_mapping() to inject 'kernel' data into the userspace map.
>
> Simila
From: Peter Zijstra
In order to create VMAs that are not accessible to userspace create a new
VM_NOUSER flag. This can be used in conjunction with
install_special_mapping() to inject 'kernel' data into the userspace map.
Similar to how arch_vm_get_page_prot() allows adding _PAGE_flags to
pgprot_
26 matches
Mail list logo
