On Sun, Jul 10, 2016 at 8:38 AM, Andy Lutomirski wrote:
> On Sun, Jul 10, 2016 at 5:03 AM, PaX Team wrote:
>> On 10 Jul 2016 at 11:16, Ingo Molnar wrote:
>>
>>> * PaX Team wrote:
>>>
>>> > On 9 Jul 2016 at 14:27, Andy Lutomirski wrote:
>>> >
>>> > > I like the series, but I have one minor nit to
On Sun, Jul 10, 2016 at 8:03 AM, PaX Team wrote:
> i note that this analysis is also missing from this USERCOPY submission except
> for stating what Kees assumed about USERCOPY (and apparently noone could be
> bothered to read the original Kconfig help of it which clearly states that the
> purpose
On Sun, Jul 10, 2016 at 5:03 AM, PaX Team wrote:
> On 10 Jul 2016 at 11:16, Ingo Molnar wrote:
>
>> * PaX Team wrote:
>>
>> > On 9 Jul 2016 at 14:27, Andy Lutomirski wrote:
>> >
>> > > I like the series, but I have one minor nit to pick. The effect of this
>> > > series is to harden usercopy, bu
On 10 Jul 2016 at 11:16, Ingo Molnar wrote:
> * PaX Team wrote:
>
> > On 9 Jul 2016 at 14:27, Andy Lutomirski wrote:
> >
> > > I like the series, but I have one minor nit to pick. The effect of this
> > > series is to harden usercopy, but most of the code is really about
> > > infrastructure
* PaX Team wrote:
> On 9 Jul 2016 at 14:27, Andy Lutomirski wrote:
>
> > I like the series, but I have one minor nit to pick. The effect of this
> > series is to harden usercopy, but most of the code is really about
> > infrastructure to validate that a pointed-to object is valid.
>
> actua
On 9 Jul 2016 at 14:27, Andy Lutomirski wrote:
> On Jul 6, 2016 6:25 PM, "Kees Cook" wrote:
> >
> > Hi,
> >
> > This is a start of the mainline port of PAX_USERCOPY[1]. After I started
> > writing tests (now in lkdtm in -next) for Casey's earlier port[2], I
> > kept tweaking things further and fu
On Jul 6, 2016 6:25 PM, "Kees Cook" wrote:
>
> Hi,
>
> This is a start of the mainline port of PAX_USERCOPY[1]. After I started
> writing tests (now in lkdtm in -next) for Casey's earlier port[2], I
> kept tweaking things further and further until I ended up with a whole
> new patch series. To tha
On Sat, Jul 9, 2016 at 1:25 AM, Ard Biesheuvel
wrote:
> On 9 July 2016 at 04:22, Laura Abbott wrote:
>> On 07/06/2016 03:25 PM, Kees Cook wrote:
>>>
>>> Hi,
>>>
>>> This is a start of the mainline port of PAX_USERCOPY[1]. After I started
>>> writing tests (now in lkdtm in -next) for Casey's earli
On Fri, Jul 8, 2016 at 7:22 PM, Laura Abbott wrote:
> On 07/06/2016 03:25 PM, Kees Cook wrote:
>>
>> Hi,
>>
>> This is a start of the mainline port of PAX_USERCOPY[1]. After I started
>> writing tests (now in lkdtm in -next) for Casey's earlier port[2], I
>> kept tweaking things further and furthe
On 9 July 2016 at 04:22, Laura Abbott wrote:
> On 07/06/2016 03:25 PM, Kees Cook wrote:
>>
>> Hi,
>>
>> This is a start of the mainline port of PAX_USERCOPY[1]. After I started
>> writing tests (now in lkdtm in -next) for Casey's earlier port[2], I
>> kept tweaking things further and further until
* Rik van Riel wrote:
> On Fri, 2016-07-08 at 19:22 -0700, Laura Abbott wrote:
> >
> > Even with the SLUB fixup I'm still seeing this blow up on my arm64
> > system. This is a
> > Fedora rawhide kernel + the patches
> >
> > [0.666700] usercopy: kernel memory exposure attempt detected from
On Fri, 2016-07-08 at 19:22 -0700, Laura Abbott wrote:
>
> Even with the SLUB fixup I'm still seeing this blow up on my arm64
> system. This is a
> Fedora rawhide kernel + the patches
>
> [0.666700] usercopy: kernel memory exposure attempt detected from
> fc0008b4dd58 () (8 bytes)
> [
* Linus Torvalds wrote:
> On Fri, Jul 8, 2016 at 1:46 AM, Ingo Molnar wrote:
> >
> > Could you please try to find some syscall workload that does many small user
> > copies and thus excercises this code path aggressively?
>
> Any stat()-heavy path will hit cp_new_stat() very heavily. Think the
On Fri, Jul 8, 2016 at 1:46 AM, Ingo Molnar wrote:
>
> Could you please try to find some syscall workload that does many small user
> copies and thus excercises this code path aggressively?
Any stat()-heavy path will hit cp_new_stat() very heavily. Think the
usual kind of "traverse the whole tree
* Kees Cook wrote:
> - I couldn't detect a measurable performance change with these features
> enabled. Kernel build times were unchanged, hackbench was unchanged,
> etc. I think we could flip this to "on by default" at some point.
Could you please try to find some syscall workload that doe
On Thu, Jul 7, 2016 at 3:30 AM, Christian Borntraeger
wrote:
> On 07/07/2016 12:25 AM, Kees Cook wrote:
>> Hi,
>>
>> This is a start of the mainline port of PAX_USERCOPY[1]. After I started
>> writing tests (now in lkdtm in -next) for Casey's earlier port[2], I
>> kept tweaking things further and
On 07/07/2016 12:25 AM, Kees Cook wrote:
> Hi,
>
> This is a start of the mainline port of PAX_USERCOPY[1]. After I started
> writing tests (now in lkdtm in -next) for Casey's earlier port[2], I
> kept tweaking things further and further until I ended up with a whole
> new patch series. To that en
Hi,
This is a start of the mainline port of PAX_USERCOPY[1]. After I started
writing tests (now in lkdtm in -next) for Casey's earlier port[2], I
kept tweaking things further and further until I ended up with a whole
new patch series. To that end, I took Rik's feedback and made a number
of other c
18 matches
Mail list logo
