linux-kernel - Re: Re: [PATCH v12 00/18] Enable FSGSBASE instructions

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: <CAFLxGvxeg6+DY1LMTzvJe3=iW=zLyUj4xTRda99DurKdS6TDWw@mail.gmail.com>
Date:   Mon, 25 May 2020 09:54:49 +0200
From:   Richard Weinberger <richard.weinberger@...il.com>
To:     Sasha Levin <sashal@...nel.org>
Cc:     "H. Peter Anvin" <hpa@...or.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Don Porter <porter@...unc.edu>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        Andi Kleen <ak@...ux.intel.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Borislav Petkov <bp@...en8.de>,
        Andy Lutomirski <luto@...nel.org>,
        Dave Hansen <dave.hansen@...el.com>,
        Tony Luck <tony.luck@...el.com>,
        Ravi V Shankar <ravi.v.shankar@...el.com>,
        chang.seok.bae@...el.com
Subject: Re: Re: [PATCH v12 00/18] Enable FSGSBASE instructions

On Sun, May 24, 2020 at 11:20 PM Sasha Levin <sashal@...nel.org> wrote:
>
> On Sun, May 24, 2020 at 12:45:18PM -0700, hpa@...or.com wrote:
> >There are legitimate reasons to write a root-hole module, the main one being able to test security features like SMAP. I have requested before a TAINT flag specifically for this purpose, because TAINT_CRAP is nowhere near explicit enough, and is also used for staging drivers. Call it TAINT_TOXIC or TAINT_ROOTHOLE; it should always be accompanied with a CRIT level alert.
>
> What I don't like about our current system of TAINT_* flags is that
> while we can improve it as much as we want, no one outside of the kernel
> tree seems to be using it. While Thomas may have been commenting on
> Graphene's behaviour, look at any other code that did the same thing:

Even if these modules would set TAINT_ROOTHOLE/TOXIC, the vast majority of users
have no clue what these flags really mean nor bother to take them seriously.

Almost every customer system I get my hands on has the following flags set:
C: Some driver from staging was "needed", mostly media or wifi stuff.
O: Customer did a custom module.
W: Random warning from vendor kernel at bootup because of a slightly
configured device-tree, etc.
P: Sadly too. Mostly because customer has custom module and forgot to set it GPL

All this trained users to believe that a few taint flags don't hurt
and only in a perfect world
none are set.

What works and raises attention is Steve's trace_printk() warning:

        pr_warn("**********************************************************\n");
        pr_warn("**   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE   **\n");
        pr_warn("**                                                      **\n");
        pr_warn("** trace_printk() being used. Allocating extra memory.  **\n");
        pr_warn("**                                                      **\n");
        pr_warn("** This means that this is a DEBUG kernel and it is     **\n");
        pr_warn("** unsafe for production use.                           **\n");
        pr_warn("**                                                      **\n");
        pr_warn("** If you see this message and you are not debugging    **\n");
        pr_warn("** the kernel, report this immediately to your vendor!  **\n");
        pr_warn("**                                                      **\n");
        pr_warn("**   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE   **\n");
        pr_warn("**********************************************************\n");

Maybe we can add something like this for taints too? :-)

-- 
Thanks,
//richard