On Thu 27-04-17 18:11:28, Kees Cook wrote:
> On Tue, Apr 11, 2017 at 7:19 AM, Michal Hocko wrote:
> > I would do something like...
> > ---
> > diff --git a/mm/slab.c b/mm/slab.c
> > index bd63450a9b16..87c99a5e9e18 100644
> > --- a/mm/slab.c
> > +++ b/mm/slab.c
> > @@ -393,10 +393,15 @@ static inl
On Tue, Apr 11, 2017 at 7:19 AM, Michal Hocko wrote:
> I would do something like...
> ---
> diff --git a/mm/slab.c b/mm/slab.c
> index bd63450a9b16..87c99a5e9e18 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -393,10 +393,15 @@ static inline void set_store_user_dirty(struct
> kmem_cache *cachep)
On Tue 04-04-17 13:30:22, Michal Hocko wrote:
> On Fri 31-03-17 09:40:28, Kees Cook wrote:
> > As found in PaX, this adds a cheap check on heap consistency, just to
> > notice if things have gotten corrupted in the page lookup.
> >
> > Signed-off-by: Kees Cook
>
> NAK without a proper changelog.
On Tue, 18 Apr 2017, Michal Hocko wrote:
> Are you even reading those emails? First of all we are talking about
> slab here. Secondly I've already pointed out that the BUG_ON(!PageSlab)
> in kmem_freepages is already too late because we do operate on a
> potential garbage from invalid page...
Bef
On Tue, 18 Apr 2017, Michal Hocko wrote:
> > The patch does not do that. See my review. Invalid points to kfree are
> > already caught with a bug on. See kfree in mm/slub.c
>
> Are you even reading those emails? First of all we are talking about
> slab here. Secondly I've already pointed out that
On Mon 17-04-17 10:22:29, Cristopher Lameter wrote:
> On Tue, 11 Apr 2017, Michal Hocko wrote:
>
> > On Tue 11-04-17 13:59:44, Cristopher Lameter wrote:
> > > On Tue, 11 Apr 2017, Michal Hocko wrote:
> > >
> > > > I didn't say anything like that. Hence the proposed patch which still
> > > > needs
On Tue, 11 Apr 2017, Michal Hocko wrote:
> On Tue 11-04-17 13:59:44, Cristopher Lameter wrote:
> > On Tue, 11 Apr 2017, Michal Hocko wrote:
> >
> > > I didn't say anything like that. Hence the proposed patch which still
> > > needs some more thinking and evaluation.
> >
> > This patch does not eve
On Tue 11-04-17 13:59:44, Cristopher Lameter wrote:
> On Tue, 11 Apr 2017, Michal Hocko wrote:
>
> > I didn't say anything like that. Hence the proposed patch which still
> > needs some more thinking and evaluation.
>
> This patch does not even affect kfree().
Ehm? Are we even talking about the
On Tue, 11 Apr 2017, Michal Hocko wrote:
> I didn't say anything like that. Hence the proposed patch which still
> needs some more thinking and evaluation.
This patch does not even affect kfree(). Could you start another
discussion thread where you discuss your suggestions for the changes in
the
On Tue 11-04-17 13:44:02, Cristopher Lameter wrote:
> On Tue, 11 Apr 2017, Michal Hocko wrote:
>
> > > So we are already handling that condition. Why change things? Add a BUG_ON
> > > if you want to make SLAB consistent.
> >
> > I hate to repeat myself but let me do it for the last time in this
>
On Tue, 11 Apr 2017, Michal Hocko wrote:
> > So we are already handling that condition. Why change things? Add a BUG_ON
> > if you want to make SLAB consistent.
>
> I hate to repeat myself but let me do it for the last time in this
> thread. BUG_ON for something that is recoverable is completely
>
On Fri, 31 Mar 2017, Kees Cook wrote:
> As found in PaX, this adds a cheap check on heap consistency, just to
> notice if things have gotten corrupted in the page lookup.
Ok this only affects kmem_cache_free() and not kfree(). For
kmem_cache_free() we already have a lot of stuff in the hotpath du
On Tue 11-04-17 13:03:01, Cristopher Lameter wrote:
> On Tue, 11 Apr 2017, Michal Hocko wrote:
>
> > >
> > > There is a flag SLAB_DEBUG_OBJECTS that is available for this check.
> >
> > Which is way too late, at least for the kfree path. page->slab_cache
> > on anything else than PageSlab is just
On Tue, 11 Apr 2017, Michal Hocko wrote:
> >
> > There is a flag SLAB_DEBUG_OBJECTS that is available for this check.
>
> Which is way too late, at least for the kfree path. page->slab_cache
> on anything else than PageSlab is just a garbage. And my understanding
> of the patch objective is to sto
On Tue 11-04-17 11:16:42, Cristopher Lameter wrote:
> On Tue, 11 Apr 2017, Michal Hocko wrote:
>
> > static inline void *index_to_obj(struct kmem_cache *cache, struct page
> > *page,
> > @@ -3813,14 +3818,18 @@ void kfree(const void *objp)
> > {
> > struct kmem_cache *c;
> > unsigned lo
On Tue, Apr 11, 2017 at 9:23 AM, Christoph Lameter wrote:
> On Tue, 11 Apr 2017, Kees Cook wrote:
>
>> It seems that enabling the debug checks comes with a non-trivial
>> performance impact. I'd like to see consistency checks by default so
>> we can handle intentional heap corruption attacks bette
On Tue, 11 Apr 2017, Kees Cook wrote:
> It seems that enabling the debug checks comes with a non-trivial
> performance impact. I'd like to see consistency checks by default so
> we can handle intentional heap corruption attacks better. This check
> isn't expensive...
Note also that these checks c
On Tue, 11 Apr 2017, Kees Cook wrote:
> It seems that enabling the debug checks comes with a non-trivial
> performance impact. I'd like to see consistency checks by default so
> we can handle intentional heap corruption attacks better. This check
> isn't expensive...
Its in a very hot code and fr
On Tue, Apr 11, 2017 at 9:16 AM, Christoph Lameter wrote:
> On Tue, 11 Apr 2017, Michal Hocko wrote:
>
>> static inline void *index_to_obj(struct kmem_cache *cache, struct page
>> *page,
>> @@ -3813,14 +3818,18 @@ void kfree(const void *objp)
>> {
>> struct kmem_cache *c;
>> unsigne
On Tue, 11 Apr 2017, Michal Hocko wrote:
> static inline void *index_to_obj(struct kmem_cache *cache, struct page *page,
> @@ -3813,14 +3818,18 @@ void kfree(const void *objp)
> {
> struct kmem_cache *c;
> unsigned long flags;
> + struct page *page;
>
> trace_kfree(_RET_IP_
On Tue, Apr 11, 2017 at 7:19 AM, Michal Hocko wrote:
> On Tue 11-04-17 07:14:01, Kees Cook wrote:
>> On Tue, Apr 11, 2017 at 6:46 AM, Michal Hocko wrote:
>> > On Mon 10-04-17 21:58:22, Kees Cook wrote:
>> >> On Tue, Apr 4, 2017 at 1:13 PM, Michal Hocko wrote:
>> >> > On Tue 04-04-17 14:58:06, Cr
On Tue 11-04-17 07:14:01, Kees Cook wrote:
> On Tue, Apr 11, 2017 at 6:46 AM, Michal Hocko wrote:
> > On Mon 10-04-17 21:58:22, Kees Cook wrote:
> >> On Tue, Apr 4, 2017 at 1:13 PM, Michal Hocko wrote:
> >> > On Tue 04-04-17 14:58:06, Cristopher Lameter wrote:
> >> >> On Tue, 4 Apr 2017, Michal H
On Tue, Apr 11, 2017 at 6:46 AM, Michal Hocko wrote:
> On Mon 10-04-17 21:58:22, Kees Cook wrote:
>> On Tue, Apr 4, 2017 at 1:13 PM, Michal Hocko wrote:
>> > On Tue 04-04-17 14:58:06, Cristopher Lameter wrote:
>> >> On Tue, 4 Apr 2017, Michal Hocko wrote:
>> >>
>> >> > On Tue 04-04-17 14:13:06, C
On Mon 10-04-17 21:58:22, Kees Cook wrote:
> On Tue, Apr 4, 2017 at 1:13 PM, Michal Hocko wrote:
> > On Tue 04-04-17 14:58:06, Cristopher Lameter wrote:
> >> On Tue, 4 Apr 2017, Michal Hocko wrote:
> >>
> >> > On Tue 04-04-17 14:13:06, Cristopher Lameter wrote:
> >> > > On Tue, 4 Apr 2017, Michal
On Tue, Apr 4, 2017 at 1:13 PM, Michal Hocko wrote:
> On Tue 04-04-17 14:58:06, Cristopher Lameter wrote:
>> On Tue, 4 Apr 2017, Michal Hocko wrote:
>>
>> > On Tue 04-04-17 14:13:06, Cristopher Lameter wrote:
>> > > On Tue, 4 Apr 2017, Michal Hocko wrote:
>> > >
>> > > > Yes, but we do not have to
On Tue 04-04-17 14:58:06, Cristopher Lameter wrote:
> On Tue, 4 Apr 2017, Michal Hocko wrote:
>
> > On Tue 04-04-17 14:13:06, Cristopher Lameter wrote:
> > > On Tue, 4 Apr 2017, Michal Hocko wrote:
> > >
> > > > Yes, but we do not have to blow the kernel, right? Why cannot we simply
> > > > leak t
On Tue, 4 Apr 2017, Michal Hocko wrote:
> On Tue 04-04-17 14:13:06, Cristopher Lameter wrote:
> > On Tue, 4 Apr 2017, Michal Hocko wrote:
> >
> > > Yes, but we do not have to blow the kernel, right? Why cannot we simply
> > > leak that memory?
> >
> > Because it is a serious bug to attempt to free
On Tue 04-04-17 14:13:06, Cristopher Lameter wrote:
> On Tue, 4 Apr 2017, Michal Hocko wrote:
>
> > Yes, but we do not have to blow the kernel, right? Why cannot we simply
> > leak that memory?
>
> Because it is a serious bug to attempt to free a non slab object using
> slab operations. This is o
On Tue, 4 Apr 2017, Michal Hocko wrote:
> Yes, but we do not have to blow the kernel, right? Why cannot we simply
> leak that memory?
Because it is a serious bug to attempt to free a non slab object using
slab operations. This is often the result of memory corruption, coding
errs etc. The system
On Tue, Apr 4, 2017 at 8:58 AM, Michal Hocko wrote:
> On Tue 04-04-17 08:46:02, Kees Cook wrote:
>> On Tue, Apr 4, 2017 at 8:16 AM, Michal Hocko wrote:
>> > On Tue 04-04-17 10:07:23, Cristopher Lameter wrote:
>> >> On Tue, 4 Apr 2017, Michal Hocko wrote:
>> >>
>> >> > NAK without a proper changel
On Tue 04-04-17 08:46:02, Kees Cook wrote:
> On Tue, Apr 4, 2017 at 8:16 AM, Michal Hocko wrote:
> > On Tue 04-04-17 10:07:23, Cristopher Lameter wrote:
> >> On Tue, 4 Apr 2017, Michal Hocko wrote:
> >>
> >> > NAK without a proper changelog. Seriously, we do not blindly apply
> >> > changes from o
On Tue, Apr 4, 2017 at 8:16 AM, Michal Hocko wrote:
> On Tue 04-04-17 10:07:23, Cristopher Lameter wrote:
>> On Tue, 4 Apr 2017, Michal Hocko wrote:
>>
>> > NAK without a proper changelog. Seriously, we do not blindly apply
>> > changes from other projects without a deep understanding of all
>> >
On Tue 04-04-17 10:07:23, Cristopher Lameter wrote:
> On Tue, 4 Apr 2017, Michal Hocko wrote:
>
> > NAK without a proper changelog. Seriously, we do not blindly apply
> > changes from other projects without a deep understanding of all
> > consequences.
>
> Functionalitywise this is trivial. A pag
On Tue, 4 Apr 2017, Michal Hocko wrote:
> NAK without a proper changelog. Seriously, we do not blindly apply
> changes from other projects without a deep understanding of all
> consequences.
Functionalitywise this is trivial. A page must be a slab page in order to
be able to determine the slab ca
On Fri 31-03-17 09:40:28, Kees Cook wrote:
> As found in PaX, this adds a cheap check on heap consistency, just to
> notice if things have gotten corrupted in the page lookup.
>
> Signed-off-by: Kees Cook
NAK without a proper changelog. Seriously, we do not blindly apply
changes from other projec
On Mon, Apr 03, 2017 at 09:03:50AM -0500, Christoph Lameter wrote:
> On Mon, 3 Apr 2017, Michael Ellerman wrote:
>
> > At least in slab.c it seems that would allow you to "free" an object
> > from one kmem_cache onto the array_cache of another kmem_cache, which
> > seems fishy. But maybe there's a
On Mon, 3 Apr 2017, Michael Ellerman wrote:
> At least in slab.c it seems that would allow you to "free" an object
> from one kmem_cache onto the array_cache of another kmem_cache, which
> seems fishy. But maybe there's a check somewhere I'm missing?
kfree can be used to free any object from any
Kees Cook writes:
> On Fri, Mar 31, 2017 at 2:33 PM, Andrew Morton
> wrote:
>> On Fri, 31 Mar 2017 09:40:28 -0700 Kees Cook wrote:
>>
>>> As found in PaX, this adds a cheap check on heap consistency, just to
>>> notice if things have gotten corrupted in the page lookup.
>>
>> "As found in PaX"
On Fri, Mar 31, 2017 at 2:33 PM, Andrew Morton
wrote:
> On Fri, 31 Mar 2017 09:40:28 -0700 Kees Cook wrote:
>
>> As found in PaX, this adds a cheap check on heap consistency, just to
>> notice if things have gotten corrupted in the page lookup.
>
> "As found in PaX" isn't a very illuminating just
On Fri, 31 Mar 2017 09:40:28 -0700 Kees Cook wrote:
> As found in PaX, this adds a cheap check on heap consistency, just to
> notice if things have gotten corrupted in the page lookup.
"As found in PaX" isn't a very illuminating justification for such a
change. Was there a real kernel bug which
As found in PaX, this adds a cheap check on heap consistency, just to
notice if things have gotten corrupted in the page lookup.
Signed-off-by: Kees Cook
---
mm/slab.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/slab.h b/mm/slab.h
index 65e7c3fcac72..64447640b70c 100644
--- a/mm/slab.
41 matches
Mail list logo
