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
| ||
|
Message-ID: <6e6a5f86-3080-54ed-82ea-80e57e184fd0@suse.cz> Date: Fri, 23 Sep 2022 11:07:59 +0200 From: Vlastimil Babka <vbabka@...e.cz> To: Kees Cook <keescook@...omium.org> Cc: Christian König <christian.koenig@....com>, Pekka Enberg <penberg@...nel.org>, Feng Tang <feng.tang@...el.com>, David Rientjes <rientjes@...gle.com>, Joonsoo Kim <iamjoonsoo.kim@....com>, Andrew Morton <akpm@...ux-foundation.org>, "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Nick Desaulniers <ndesaulniers@...gle.com>, Alex Elder <elder@...nel.org>, Josef Bacik <josef@...icpanda.com>, David Sterba <dsterba@...e.com>, Sumit Semwal <sumit.semwal@...aro.org>, Jesse Brandeburg <jesse.brandeburg@...el.com>, Daniel Micay <danielmicay@...il.com>, Yonghong Song <yhs@...com>, Marco Elver <elver@...gle.com>, Miguel Ojeda <ojeda@...nel.org>, linux-kernel@...r.kernel.org, linux-mm@...ck.org, netdev@...r.kernel.org, linux-btrfs@...r.kernel.org, linux-media@...r.kernel.org, dri-devel@...ts.freedesktop.org, linaro-mm-sig@...ts.linaro.org, linux-fsdevel@...r.kernel.org, intel-wired-lan@...ts.osuosl.org, dev@...nvswitch.org, x86@...nel.org, linux-wireless@...r.kernel.org, llvm@...ts.linux.dev, linux-hardening@...r.kernel.org, Hyeonggon Yoo <42.hyeyoo@...il.com> Subject: Re: [PATCH 00/12] slab: Introduce kmalloc_size_roundup() On 9/22/22 23:49, Kees Cook wrote: > On Thu, Sep 22, 2022 at 11:05:47PM +0200, Vlastimil Babka wrote: >> On 9/22/22 17:55, Kees Cook wrote: >> > On Thu, Sep 22, 2022 at 09:10:56AM +0200, Christian König wrote: >> > [...] >> > > So when this patch set is about to clean up this use case it should probably >> > > also take care to remove ksize() or at least limit it so that it won't be >> > > used for this use case in the future. >> > >> > Yeah, my goal would be to eliminate ksize(), and it seems possible if >> > other cases are satisfied with tracking their allocation sizes directly. >> >> I think we could leave ksize() to determine the size without a need for >> external tracking, but from now on forbid callers from using that hint to >> overflow the allocation size they actually requested? Once we remove the >> kasan/kfence hooks in ksize() that make the current kinds of usage possible, >> we should be able to catch any offenders of the new semantics that would appear? > > That's correct. I spent the morning working my way through the rest of > the ksize() users I didn't clean up yesterday, and in several places I > just swapped in __ksize(). But that wouldn't even be needed if we just > removed the kasan unpoisoning from ksize(), etc. > > I am tempted to leave it __ksize(), though, just to reinforce that it's > not supposed to be used "normally". What do you think? Sounds good. Note in linux-next there's now a series in slab.git planned for 6.1 that moves __ksize() declaration to mm/slab.h to make it more private. But we don't want random users outside mm and related kasan/kfence subsystems to include mm/slab.h, so we'll have to expose it again instead of ksize().
Powered by blists - more mailing lists