On Mon, May 7, 2018 at 1:49 PM, Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > On Mon, May 07, 2018 at 01:27:38PM -0700, Kees Cook wrote: >> On Mon, May 7, 2018 at 1:19 PM, Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: >> > Yes. And today with kvmalloc. However, I proposed to Linus that >> > kvmalloc() shouldn't allow it -- we should have kvmalloc_large() which >> > would, but kvmalloc wouldn't. He liked that idea, so I'm going with it. >> >> How would we handle size calculations for _large? > > I'm not sure we should, at least initially. The very few places which > need a large kvmalloc really are special and can do their own careful > checking. Because, as Linus pointed out, we shouldn't be letting the > user ask us to allocate a terabyte of RAM. We should just fail that. > > let's see how those users pan out, and then see what we can offer in > terms of safety. > >> > There are very, very few places which should need kvmalloc_large. >> > That's one million 8-byte pointers. If you need more than that inside >> > the kernel, you're doing something really damn weird and should do >> > something that looks obviously different. >> >> I'm CCing John since I remember long ago running into problems loading >> the AppArmor DFA with kmalloc and switching it to kvmalloc. John, how >> large can the DFAs for AppArmor get? Would an 8MB limit be a problem? > > Great! Opinions from people who'll use this interface are exceptionally > useful. > >> And do we have any large IO or network buffers >8MB? > > Not that get allocated with kvmalloc ... because you can't DMA map vmalloc > (without doing some unusual contortions). Er, yes, right. I meant for _all_ allocators, though. If 8MB is going to be the new "saturated" value? Maybe I misunderstood? What are you proposing for the code of array_size()? >> > but I thought of another problem with array_size. We already have >> > ARRAY_SIZE and it means "the number of elements in the array". >> > >> > so ... struct_bytes(), array_bytes(), array3_bytes()? >> >> Maybe "calc"? struct_calc(), array_calc(), array3_calc()? This has the >> benefit of actually saying more about what it is doing, rather than >> its return value... In the end, I don't care. :) > > I don't have a strong feeling on this either. I lean ever so slightly towards *_size(). It'll be hard to mix up ARRAY_SIZE() and array_size(), given the parameters. -Kees -- Kees Cook Pixel Security
