linux-kernel - Re: [PATCH] kernel: Downgrade warning for unsafe parameters

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] [day] [month] [year] [list]

Message-ID: <87tvu322ej.fsf@intel.com>
Date:   Mon, 26 Feb 2018 17:31:32 +0200
From:   Jani Nikula <jani.nikula@...el.com>
To:     Chris Wilson <chris@...is-wilson.co.uk>,
        linux-kernel@...r.kernel.org
Cc:     intel-gfx@...ts.freedesktop.org,
        Chris Wilson <chris@...is-wilson.co.uk>,
        Rusty Russell <rusty@...tcorp.com.au>,
        Jean Delvare <khali@...ux-fr.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Li Zhong <zhong@...ux.vnet.ibm.com>,
        Petri Latvala <petri.latvala@...el.com>,
        Daniel Vetter <daniel.vetter@...ll.ch>
Subject: Re: [PATCH] kernel: Downgrade warning for unsafe parameters

On Mon, 26 Feb 2018, Chris Wilson <chris@...is-wilson.co.uk> wrote:
> As using an unsafe module parameter is, by its very definition, an
> expected user action, emitting a warning is overkill. Nothing has yet
> gone wrong, and we add a taint flag for any future oops should
> something actually go wrong. So instead of having a user controllable
> pr_warn, downgrade it to a pr_notice for "a normal, but significant
> condition".
>
> We make use of unsafe kernel parameters in igt (we have not yet
> succeeded in removing all such debugging options), which generates a
> warning and taints the kernel. The warning is unhelpful as we then need
> to filter it out again as we check that every test themselves do not
> provoke any kernel warnings.

IGT being https://cgit.freedesktop.org/drm/igt-gpu-tools/ for those not
in the DRM/KMS circles.

> References: 91f9d330cc14 ("module: make it possible to have unsafe, tainting module params")
> Signed-off-by: Chris Wilson <chris@...is-wilson.co.uk>
> Cc: Jani Nikula <jani.nikula@...el.com>
> Cc: Rusty Russell <rusty@...tcorp.com.au>
> Cc: Jean Delvare <khali@...ux-fr.org>
> Cc: Andrew Morton <akpm@...ux-foundation.org>
> Cc: Li Zhong <zhong@...ux.vnet.ibm.com>
> Cc: Petri Latvala <petri.latvala@...el.com>
> Cc: Daniel Vetter <daniel.vetter@...ll.ch>

Acked-by: Jani Nikula <jani.nikula@...el.com>

When I added the unsafe module params, I erred on the side of making
more noise about tainting, but there was really no discussion about
it. FWIW, I don't mind the change, as long as it's not debug level.

BR,
Jani.

> ---
>  kernel/params.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/params.c b/kernel/params.c
> index cc9108c2a1fd..ce89f757e6da 100644
> --- a/kernel/params.c
> +++ b/kernel/params.c
> @@ -111,8 +111,8 @@ bool parameq(const char *a, const char *b)
>  static void param_check_unsafe(const struct kernel_param *kp)
>  {
>  	if (kp->flags & KERNEL_PARAM_FL_UNSAFE) {
> -		pr_warn("Setting dangerous option %s - tainting kernel\n",
> -			kp->name);
> +		pr_notice("Setting dangerous option %s - tainting kernel\n",
> +			  kp->name);
>  		add_taint(TAINT_USER, LOCKDEP_STILL_OK);
>  	}
>  }

-- 
Jani Nikula, Intel Open Source Technology Center