Re: [RFC PATCH v19 0/8] mm: security: ro protection for dynamic data

2018-03-19 Thread Igor Stoppa
On 14/03/18 19:33, Matthew Wilcox wrote: > I think an implementation of > pmalloc which used a page_frag-style allocator would be larger than > 100 lines, but I don't think it would have to be significantly larger > than that. I have some doubt about what is the best way to implement it using vmal

Re: [RFC PATCH v19 0/8] mm: security: ro protection for dynamic data

2018-03-15 Thread Igor Stoppa
On 14/03/2018 19:33, Matthew Wilcox wrote: > On Wed, Mar 14, 2018 at 06:11:22PM +0200, Igor Stoppa wrote: [...] >> Probably page_frag does well with relatively large allocations, while >> genalloc seems to be better for small (few allocation units) allocations. > > I don't understand why you w

Re: [RFC PATCH v19 0/8] mm: security: ro protection for dynamic data

2018-03-14 Thread Matthew Wilcox
On Wed, Mar 14, 2018 at 06:11:22PM +0200, Igor Stoppa wrote: > On 14/03/18 15:04, Matthew Wilcox wrote: > > but the principle it uses > > seems like a better match to me than the rather complex genalloc. > > It uses meta data in a different way than genalloc. > There is probably a tipping point wh

Re: [RFC PATCH v19 0/8] mm: security: ro protection for dynamic data

2018-03-14 Thread Igor Stoppa
On 14/03/18 15:04, Matthew Wilcox wrote: > I don't necessarily think you should use it as-is, I think I simply cannot use it as-is, because it seems to use linear memory, while I need virtual. This reason alone would require a rewrite of several parts. > but the principle it uses > seems like

Re: [RFC PATCH v19 0/8] mm: security: ro protection for dynamic data

2018-03-14 Thread Matthew Wilcox
On Wed, Mar 14, 2018 at 02:55:10PM +0200, Igor Stoppa wrote: > > The page_frag allocator seems like a much better place to > > start than genalloc. It has a significantly lower overhead and is > > much more suited to the kind of probably-identical-lifespan that the > > pmalloc API is going to per

Re: [RFC PATCH v19 0/8] mm: security: ro protection for dynamic data

2018-03-14 Thread Igor Stoppa
On 14/03/18 13:56, Matthew Wilcox wrote: > On Wed, Mar 14, 2018 at 01:21:54PM +0200, Igor Stoppa wrote: [...] > You misread my proposal. I did not suggest storing the 'start', but the > 'end'. Ok, but doesn't that only change the race scenario? Attempting to free one allocation, while it is

Re: [RFC PATCH v19 0/8] mm: security: ro protection for dynamic data

2018-03-14 Thread Matthew Wilcox
On Wed, Mar 14, 2018 at 01:21:54PM +0200, Igor Stoppa wrote: > > * @Kees Cook proposed to turn the self testing into modules. > > My answer was that the functionality is intentionally tested very early > > in the boot phase, to prevent unexplainable errors, should the feature > > really fail.

Re: [RFC PATCH v19 0/8] mm: security: ro protection for dynamic data

2018-03-14 Thread Igor Stoppa
On 13/03/18 23:45, Igor Stoppa wrote: [...] Some more thoughts about the open topics: > Discussion topics that are unclear if they are closed and would need > comment from those who initiated them, if my answers are accepted or not: > > * @Kees Cook proposed to have first self testing for genal