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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 17 Mar 2021 13:08:21 +0100 From: Michal Hocko <mhocko@...e.com> To: Kees Cook <keescook@...omium.org> Cc: Andrew Morton <akpm@...ux-foundation.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Alexey Dobriyan <adobriyan@...il.com>, Lee Duncan <lduncan@...e.com>, Chris Leech <cleech@...hat.com>, Adam Nichols <adam@...mm-co.com>, linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org, linux-hardening@...r.kernel.org, Uladzislau Rezki <urezki@...il.com> Subject: Re: [PATCH v2] seq_file: Unconditionally use vmalloc for buffer On Tue 16-03-21 12:08:02, Kees Cook wrote: > On Tue, Mar 16, 2021 at 09:31:23AM +0100, Michal Hocko wrote: [...] > > Also this cannot really be done for configurations with a very limited > > vmalloc space (32b for example). Those systems are more and more rare > > but you shouldn't really allow userspace to deplete the vmalloc space. > > This sounds like two objections: > - 32b has a small vmalloc space > - userspace shouldn't allow depletion of vmalloc space > > I'd be happy to make this 64b only. For the latter, I would imagine > there are other vmalloc-exposed-to-userspace cases, but yes, this would > be much more direct. Is that a problem in practice? vmalloc space shouldn't be a problem for 64b systems but I am not sure how does vmalloc scale with many small allocations. There were some changes by Uladzislau who might give us more insight (CCed). > > I would be also curious to see how vmalloc scales with huge number of > > single page allocations which would be easy to trigger with this patch. > > Right -- what the best way to measure this (and what would be "too > much")? Proc is used quite heavily for all sorts of monitoring so I would be worried about a noticeable slow down. Btw. I still have problems with the approach. seq_file is intended to provide safe way to dump values to the userspace. Sacrificing performance just because of some abuser seems like a wrong way to go as Al pointed out earlier. Can we simply stop the abuse and disallow to manipulate the buffer directly? I do realize this might be more tricky for reasons mentioned in other emails but this is definitely worth doing. -- Michal Hocko SUSE Labs
Powered by blists - more mailing lists