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]

Date:	Wed, 5 Mar 2014 22:03:08 +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 10:00 PM, Daniel Vetter <daniel.vetter@...ll.ch> wrote:
> 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?

s/temporary/created by the macro/ ... past beer time here already ;-)
-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/