[lkml]   [2019]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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

> 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.

 \ /
  Last update: 2019-04-08 20:41    [W:0.115 / U:1.596 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site