linux-kernel - Re: [PATCH] x86/mm/mem_encrypt: Disable all instrumentation for SME early boot code

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:   Mon, 8 Apr 2019 18:41:30 +0000
From:   Gary R Hook <ghook@....com>
To:     Borislav Petkov <bp@...en8.de>
CC:     Thomas Gleixner <tglx@...utronix.de>,
        "Hook, Gary" <Gary.Hook@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "luto@...nel.org" <luto@...nel.org>,
        Alexander Potapenko <glider@...gle.com>
Subject: Re: [PATCH] x86/mm/mem_encrypt: Disable all instrumentation for SME
 early boot code

On 4/8/19 11:58 AM, Borislav Petkov wrote:
> On Mon, Apr 08, 2019 at 04:46:31PM +0000, Gary R Hook wrote:
>> My reasoning (not arguing): the file has been touched exactly one time
>> in 4 years, by Thomas. Doesn't appear to be a candidate for constant
>> modification, so this approach doesn't seem risky to me. I could be wrong.
> 
> The problem, like we discussed it with Tom offlist, is that you simply
> cannot turn off instrumentation for those generic files just because SME
> has trouble with them, and that last thing can be any vendor-specific
> feature.

Again, not arguing. I completely understand. However, to be fair, this 
isn't about SME having trouble with those facilities, this is about 
using certain features (e.g. command line option processing) early in 
the boot. Any complex feature could have had that requirement, don't you 
think?

> Even if the functions there are "trivial" now (doesn't mean new stuff
> won't be added there in the future and we forget about the disabled
> instrumentation here.)

Absolutely agree. Recognizing that things can be forgotten has weighed 
heavily on me in light of this. I don't like that possibility at all.

> We simply cannot constrain generic compilation units like that. So the
> functions there either need to be copied or ifdeffed. At the time SME
> was going in, the intention was to reuse code so that there is less
> duplication. But if there's trouble doing that sharing, then we need to
> "unshare" it again. Or come up with something else slick and clean.

Right. My goal was to get a conversation started, because folks are 
running into this problem when KASAN is enabled.

N.B. Here's another facet of this problem: cmdline.c doesn't (today) 
contain anything that would trigger the stack protector. However, it's 
possible to enable the stack protector globally when building, right? In 
which case, a boot would fail, so we have the same issue: early boot 
code has special requirements / restrictions.

I'm not sure what the "right" solution is, but I appreciate your time 
and expertise to discuss. And now I have another idea I'm going to go 
try out.

grh