lkml.org 
[lkml]   [2016]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC 1/1] LSM ptags: Add tagging of processes
From
Date
Le samedi 26 novembre 2016 à 13:25 +0900, Tetsuo Handa a écrit :
> Jose Bollo wrote:
> > +/**
> > + * is_valid_utf8 - Is buffer a valid utf8 string?
snip
> Do we really need to check UTF-8 inside kernel? What do you do if
> people start using UTF-32 in the future? There was a discussion
> about use of encoding inside kernel started at
> http://lkml.kernel.org/r/20071103164303.GA26707@ubuntu .

Hello Tetsuo-san,

First, thank you for your bright review.

I followed that first thread a lot and conclude to remove that check in
favour of just prohibiting nul bytes that otherwise could create
problems.

snip
> > +
> > + if (size > INT_MAX)
> > + return -E2BIG;
>
> This sanity check is useless. INT_MAX is 2,147,483,647 but kmalloc()
> can't
> allocate larger than 8,388,608 bytes if PAGE_SIZE = 4096 and
> MAX_ORDER = 11.
>
> > + buffer = kmalloc(size, GFP_KERNEL);
> > + if (!buffer)
> > + return -ENOMEM;
>
> Moreover, kmalloc() will not try to allocate larger than 32,768 bytes
> (PAGE_ALLOC_COSTLY_ORDER = 3). Although __GFP_NOFAIL can force
> kmalloc() to
> retry by invoking the OOM killer, such behavior might change in near
> future
> due to http://lkml.kernel.org/r/20161123064925.9716-3-mhocko@kernel.o
> rg .
>
> Given these constants
>
> #define MAXCOUNT 4000
> #define MAXTAGLEN 4000
> #define MAXVALUELEN 32700
>
> and someone tried to use as many and long as possible tags, what is
> possible max value for "size"? I think that that value can easily
> exceed
> 32,768 and kmalloc() won't be reliable. vmalloc() can be used as a
> fallback
> when kmalloc() failed, but is trying to pass possible max value for
> "size"
> to vmalloc() reasonable? Shouldn't this function be rewritten not to
> allocate so much memory?
>
> Also, how much memory will be consumed if everybody tried to use tags
> as many and long as possible?

The fact is that ptags is seat behind the implementation of the special
files in /proc/PID/attr/.. Thus, it has to return an allocated buffer.
I'm not aware of what kind of allocation is possible to use for this
subsystem. Is it possible to use vmalloc? I dont know.

However, the remark is not just about how to implement it technically.
It is also about what amount of memory ptags could consume for threads.

My first naive idea is that consumers of ptags are reasonnables. Am I
fool, crazy or utopian? Guess...

I'm in favour of having a guard. And the gurad of a given memory size
seems good to my eyes. I could rewrite to enforce at most the use of
say 32700 characters. It could be enough for most interesting usage and
conversely it would fit the memory requirement that you pointed out.

Thanks again

Best regards
José

\
 
 \ /
  Last update: 2016-11-28 10:12    [W:0.088 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site