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
