linux-kernel - Re: [PATCH] [RFC] Taint the kernel for unsafe module options

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKMK7uHyQ04-bAjYw9Fjud_2bDwXkgq5iOQU+7N7aZGVYPT5WA@mail.gmail.com>
Date:	Wed, 5 Mar 2014 22:00:56 +0100
From:	Daniel Vetter <daniel.vetter@...ll.ch>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Intel Graphics Development <intel-gfx@...ts.freedesktop.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Jean Delvare <khali@...ux-fr.org>,
	Li Zhong <zhong@...ux.vnet.ibm.com>,
	Jon Mason <jon.mason@...el.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] [RFC] Taint the kernel for unsafe module options

On Wed, Mar 5, 2014 at 9:32 PM, Andrew Morton <akpm@...ux-foundation.org> wrote:
> On Wed,  5 Mar 2014 10:33:14 +0100 Daniel Vetter <daniel.vetter@...ll.ch> wrote:
>
>> Users just love to set random piles of options since surely enabling
>> all the experimental stuff helps. Later on we get bug reports because
>> it all fell apart.
>>
>> Even more fun when it's labelled a regression when some change only
>> just made the feature possible (e.g. stolen memory fixes suddenly
>> making fbc possible).
>>
>> Make it clear that users are playing with fire here. In drm/i915 all
>> these options follow the same pattern of using -1 as the per-machine
>> default, and any other value being used for force the parameter.
>>
>> Adding a pile of cc's to solicit input and figure out whether this
>> would be generally useful - this quick rfc is just for drm/i915.
>
> Seems harmless and potentially useful to others so yes, I'd vote for
> putting it in core kernel.
>
> However this only handles integers.  Will we end up needed great gobs
> of new code to detect unsafe setting of u8's, strings, etc?

Well I've just done integers because hardcoding the -1 default was so
easy ... But thinking about it some more (and looking at some more mod
params in i915) passing the default to the macro and storing it in
some struct, together with the pointer for the variable sounds useful.
With that this could be easily extended to all kinds of types.

Now would such a temporary structure to store the default be
acceptable or is there some neater trick to pull this off?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/