linux-kernel - Re: objtool clac/stac handling change..

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: <CAHk-=wiY-67yt4kGd2EW-7kChQgnLHZ_2aJ+=ps7i7rCz894PQ@mail.gmail.com>
Date:   Wed, 1 Jul 2020 14:02:42 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     Andy Lutomirski <luto@...capital.net>,
        Andy Lutomirski <luto@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: objtool clac/stac handling change..

On Wed, Jul 1, 2020 at 1:51 PM Josh Poimboeuf <jpoimboe@...hat.com> wrote:
>
> Yeah.  Peter's more of the expert here, but I think we'd at least need
> to annotate the code which expects an implicit CLAC so objtool knows
> what to expect.  It's not trivial, but it might be doable.

In both C and asm code, it's the "_ASM_EXTABLE_UA" cases that would do
this ("UA" being for "User Access").

In fact, it should be quite easy to see: the thing that distinguishes
those things is that the exception handler is "ex_handler_uaccess". So
objtool should be able to see that quite easily as it follows the
exception tables.

It's a special case for entirely unrelated reasons (reasons objtool
doesn't care about): a user access exception can be either due to a
page fault (normal) or due to a misformed non-canonical address, and
we warn about the latter case.

That said, I wouldn't necessarily object to making the rule be that
*any* exception handler invocation will always do the
user_access_end().

It sounds dangerous/wrong to me to do anything that can fault (other
than the user access itself, of course) within a STAC/CLAC region.

So the objtool rule might be:

 - in a STAC region, no exception handlers at all except for that
ex_handler_uaccess case

 - and that case will clear AC if it triggers.

and maybe such an objtool check would show some case where I'm wrong,
and we do some MSR read other other fault thing within a STAC region.
That _sounds_ wrong to me, but maybe we have reason to do so that I
just can't think or right now?

               Linus