linux-kernel - Re: [PATCH v2 18/39] x86/ibt: Add IBT feature, MSR and #CP handling

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:   Wed, 2 Mar 2022 10:38:14 -0800
From:   Kees Cook <keescook@...omium.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
        "Poimboe, Josh" <jpoimboe@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Cooper, Andrew" <andrew.cooper3@...rix.com>,
        "hjl.tools@...il.com" <hjl.tools@...il.com>,
        "rostedt@...dmis.org" <rostedt@...dmis.org>,
        "joao@...rdrivepizza.com" <joao@...rdrivepizza.com>,
        "samitolvanen@...gle.com" <samitolvanen@...gle.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "alexei.starovoitov@...il.com" <alexei.starovoitov@...il.com>,
        "Milburn, Alyssa" <alyssa.milburn@...el.com>,
        "mhiramat@...nel.org" <mhiramat@...nel.org>,
        "mbenes@...e.cz" <mbenes@...e.cz>,
        "ndesaulniers@...gle.com" <ndesaulniers@...gle.com>
Subject: Re: [PATCH v2 18/39] x86/ibt: Add IBT feature, MSR and #CP handling

On Wed, Mar 02, 2022 at 02:49:08PM +0100, Peter Zijlstra wrote:
> On Wed, Mar 02, 2022 at 01:59:46AM +0000, Edgecombe, Rick P wrote:
> > As for pinning strength, I'm not understanding this kexec asm enough to
> > say for sure how much better it is than just removing the bit from the
> > pinning mask. I think some future hardening around preventing turning
> > off IBT might still be worthwhile.
> > 
> > Kees, I think you brought up the pinning, what do you think of this?
> 
> IIRC the whole purpose of that was to ensure that the
> cr4_update_irqsoff() function itself isn't a useful gadget to manipulate
> CR4 with.

Right -- as long as the paths that touch cr4 are either respecting
pinning or are inlined at a point of no return (i.e. performing kexec),
they shouldn't end up being very helpful gadgets.

e.g. imagine the scenario of a controlled write to a function pointer
than just aims at a valid endbr function that manipulates cr: an
attacker will just call into that first to disable IBT, and then carry
on doing things as normal.

There is an argument to be made that if an attacker has that kind of
control, they could call any set of functions to do what they want,
but the point is to create an unfriendly environment to attackers so
that future defenses compose well together -- e.g. FGKASLR.

-- 
Kees Cook