From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932354AbcK1JLr (ORCPT ); Mon, 28 Nov 2016 04:11:47 -0500 Received: from erza.lautre.net ([80.67.160.89]:36273 "EHLO erza.lautre.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932094AbcK1JLo (ORCPT ); Mon, 28 Nov 2016 04:11:44 -0500 Message-ID: <1480324296.2089.1.camel@nonadev.net> Subject: Re: [RFC 1/1] LSM ptags: Add tagging of processes From: =?ISO-8859-1?Q?Jos=E9?= Bollo To: Tetsuo Handa Cc: linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org Date: Mon, 28 Nov 2016 10:11:36 +0100 In-Reply-To: <201611261325.FGC60477.HJtOOSQFOFFMVL@I-love.SAKURA.ne.jp> References: <1479893597-5022-1-git-send-email-jobol@nonadev.net> <1479893597-5022-2-git-send-email-jobol@nonadev.net> <201611261325.FGC60477.HJtOOSQFOFFMVL@I-love.SAKURA.ne.jp> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.1 (3.22.1-2.fc25) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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é