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: <Y3NfX0zXDIZztwKL@hirez.programming.kicks-ass.net>
Date:   Tue, 15 Nov 2022 10:43:59 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
Cc:     "Torvalds, Linus" <torvalds@...ux-foundation.org>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "fweimer@...hat.com" <fweimer@...hat.com>,
        "hjl.tools@...il.com" <hjl.tools@...il.com>,
        "x86@...nel.org" <x86@...nel.org>
Subject: Re: CET shadow stack app compatibility


Let me hijack this and go off on a tangent..

On Mon, Nov 14, 2022 at 11:15:44PM +0000, Edgecombe, Rick P wrote:

> The breakage derives from how the decision is made on whether to enable
> shadow stack enforcement. Glibc will do this by checking a bit in the
> elf header of the binary. It then tells the kernel to turn CET on via a
> separate kernel API. But instead of this elf bit being selected by
> application developers, it was mostly applied in various automated ways
> (mostly default on) by distro builds for years. This huge amount of
> untested enablement has not generated any visible issues for users yet,
> because without kernel support the presence of this bit has not
> generated any actual CET enforcement.

CET is two things, ideally we're fully eradicate the term CET, never
again mention CET, ever. Whoever at Intel decided to push that term has
created so much confusion it's not funny :/

The feature at hand here is backward edge control flow -- or shadow
stacks (the means to implement this). Be explicit about this, do *NOT*
use CET ever again.

The other thing CET has is forward edge control flow -- or indirect
branch tracking, this is a completely different and independent feature
and not advertised or implemented here.

These things are obviously related, but since they're two independent
features there's the endless confusion as to which is actually meant.

(go (re)watch the last plumbers conf talks on the subject -- there's
always someone who gets is wrong)

The only things that should have CET in their name are the CR4 bit and
the two MSRs, nothing more.

ELF bits should not, must not, be called CET. API, not CET, Compiler
features, also not CET.

(and I know it's too late to eradicate some of it, but please, at least
make sure the kernel doesn't propagate this nonsense).

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ