lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 15 Sep 2014 11:11:34 +0900
From:	Joonsoo Kim <>
To:	Mikulas Patocka <>
Cc:	Christoph Lameter <>,
	Pekka Enberg <>,
	David Rientjes <>,
	Andrew Morton <>,,,
	"Alasdair G. Kergon" <>,
	Mike Snitzer <>,
	Milan Broz <>,,
Subject: Re: [PATCH] slab: implement kmalloc guard

On Thu, Sep 11, 2014 at 10:32:52PM -0400, Mikulas Patocka wrote:
> On Mon, 8 Sep 2014, Christoph Lameter wrote:
> > On Mon, 8 Sep 2014, Mikulas Patocka wrote:
> > 
> > > I don't know what you mean. If someone allocates 10000 objects with sizes
> > > from 1 to 10000, you can't have 10000 slab caches - you can't have a slab
> > > cache for each used size. Also - you can't create a slab cache in
> > > interrupt context.
> > 
> > Oh you can create them up front on bootup. And I think only the small
> > sizes matter. Allocations >=8K are pushed to the page allocator anyways.
> Only for SLUB. For SLAB, large allocations are still use SLAB caches up to 
> 4M. But anyway - having 8K preallocated slab caches is too much.
> If you want to integrate this patch into the slab/slub subsystem, a better 
> solution would be to store the exact size requested with kmalloc along the 
> slab/slub object itself (before the preceding redzone). But it would 
> result in duplicating the work - you'd have to repeat the logic in this 
> patch three times - once for slab, once for slub and once for 
> kmalloc_large/kmalloc_large_node.
> I don't know if it would be better than this patch.


Out of bound write could be detected by kernel address asanitizer(KASan).
See following link.

Although this patch also looks good to me, I think that KASan is
better than this, because it could detect out of bound write and
has more features for debugging.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists