linux-kernel - Re: [PATCH v2 1/2] mm: vmalloc: implement vrealloc()

lists.openwall.net		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] [day] [month] [year] [list]

Message-ID: <Ztqww1HBGpopK5kW@feng-clx.sh.intel.com>
Date: Fri, 6 Sep 2024 15:35:31 +0800
From: Feng Tang <feng.tang@...el.com>
To: Vlastimil Babka <vbabka@...e.cz>
CC: Danilo Krummrich <dakr@...nel.org>, "cl@...ux.com" <cl@...ux.com>,
	"penberg@...nel.org" <penberg@...nel.org>, "rientjes@...gle.com"
	<rientjes@...gle.com>, "iamjoonsoo.kim@....com" <iamjoonsoo.kim@....com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"roman.gushchin@...ux.dev" <roman.gushchin@...ux.dev>, "42.hyeyoo@...il.com"
	<42.hyeyoo@...il.com>, "urezki@...il.com" <urezki@...il.com>,
	"hch@...radead.org" <hch@...radead.org>, "kees@...nel.org" <kees@...nel.org>,
	"ojeda@...nel.org" <ojeda@...nel.org>, "wedsonaf@...il.com"
	<wedsonaf@...il.com>, "mhocko@...nel.org" <mhocko@...nel.org>,
	"mpe@...erman.id.au" <mpe@...erman.id.au>, "chandan.babu@...cle.com"
	<chandan.babu@...cle.com>, "christian.koenig@....com"
	<christian.koenig@....com>, "maz@...nel.org" <maz@...nel.org>,
	"oliver.upton@...ux.dev" <oliver.upton@...ux.dev>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>, "rust-for-linux@...r.kernel.org"
	<rust-for-linux@...r.kernel.org>, kasan-dev <kasan-dev@...glegroups.com>
Subject: Re: [PATCH v2 1/2] mm: vmalloc: implement vrealloc()

On Tue, Sep 03, 2024 at 11:18:48AM +0800, Tang, Feng wrote:
> On Mon, Sep 02, 2024 at 10:56:57AM +0200, Vlastimil Babka wrote:
[...]
> > > If we really want to make [37, 48] to be zeroed too, we can lift the
> > > get_orig_size() from slub.c to slab_common.c and use it as the start
> > > of zeroing in krealloc().
> > 
> > Or maybe just move krealloc() to mm/slub.c so there are no unnecessary calls
> > between the files.
> > 
> > We should also set a new orig_size in cases we are shrinking or enlarging
> > within same object (i.e. 48->40 or 48->64). In case of shrinking, we also
> > might need to redzone the shrinked area (i.e. [40, 48]) or later checks will
> > fail.  But if the current object is from kfence, then probably not do any of
> > this... sigh this gets complicated. And really we need kunit tests for all
> > the scenarios :/
> 
> Good point! will think about and try to implement it to ensure the
> orig_size and kmalloc-redzone check setting is kept. 

I checked this, and as you mentioned, there is some kfence and kasan stuff
which needs to be handled to manage the 'orig_size'. As this work depends
on patches in both -slab tree and -mm tree, will base it againt linux-next
tree and send out the patches for review soon.

Thanks,
Feng