RIP ROP, COP, JOP? Intel to bring anti-exploit tech to market in this year's Tiger Lake chip family

After years in development, Intel is set to debut security mechanisms in its microprocessors that it hopes will block, at the silicon level, exploitation of a class of software vulnerabilities. Known as Control Flow Enforcement Technology, or CET, the protections are designed to prevent miscreants from exploiting certain …

[Anonymous Coward]

Surely an extra NOOP that uses a fetch/execute cycle to retrieve and verify it's a valid destination target to branch to in tight loops that get executed billions of times per second will reduce IPC?

[Richard 12]

Not really, the main cost is a little bit of space in an instruction cache line.

The fetch was happening anyway. Is basically "jump to X", then X performs an "am I a valid jump target?" trap. With hardware support the cost of that can be zero time (but does cost transistors!) Though on CPUs without support there's a decode & NOP.

Will add more state to context switches, as this will obviously need to be explicitly enabled by processes, but context switch is already expensive.

[Dave Pickles]

COMEFROM?

It seems Intel have rediscovered the mythical COMEFROM instruction.

[IGotOut]

Exploit in

3...2....1

SGX anyone?

[iron]

Intel... hardware... security... No, please STOP!

I'm laughing so hard my sides are splitting.

[Anonymous Coward]

I see the Intel employees are out downvoting you!

[Anonymous Coward]

Why not? They bought McAfee!

[Anonymous Coward]

nearly impossible to address with software-based mitigation

So not impossible? Which then makes me wonder why go to all the trouble of changing the hardware when it should be the software that does it anyway, is it not an extra risk to put something else in?

[Richard 12]

Re: nearly impossible to address with software-based mitigation

You'd need to add a lot of extra guard instructions to do it in software.

That really would be quite expensive.

[Anonymous Coward]

Re: nearly impossible to address with software-based mitigation

Fair point, a trade off between speed and security but won't the guard instruction take speed off the processor if it's working on mitigating a threat.

[Richard 12]

Re: nearly impossible to address with software-based mitigation

The difference is that the CPU knows it just returned, so can immediately check whether the jumped-to instruction is one of the "ok" targets.

An application wanting to do the same has to add code to function prologues to mark as "entered function properly" and also add "did we enter this function properly?" checks at various places.

Can probably get most of it by adding checks to the prologue and epilogue to trap if the function was entered without leaving the previous one, or left without entering it, but of course this is several times more code.

[Anonymous Coward]

So what exactly will stop the bad people from putting ENDBRANCH in their exploit code too?

[Richard 12]

This is about preventing exploits where they smash up the stack to make it call a lot of pieces of code that are already in the process - in an evil order.

[Anonymous Coward]

This is where the old 6809 got things right. You had one stack for program control and another for local data storage. If the data stack ended up with malicious garbage, the instruction pointer would still be restored to the right value after returning from the subroutine.

[Anonymous Coward]

So what stopped the control stack from getting mangled? It's just memory, after all.

[IgorS]

ARM equivalent?

> Other architectures, such as Arm, have something similar

Anyone knows what the equivalent ARM mechanism is?

[John Savard]

Re: ARM equivalent?

Apparently it's called Pointer Authentication, and it was introduced in version 8.3 of the ARM architecture.

[John Savard]

Re: ARM equivalent?

And it turns out that IBM has done something in this area for its z/Architecture...

https://patents.google.com/patent/US9891919B2/en

[Anonymous Coward]

Scotty said it best

The more they overthink the plumbing, the easier it is to stop up the drain.

[Duncan Macdonald]

Older programs ?

Most systems have a lot of older code running as well as the latest most up to date stuff. An application obtained as a binary which the supplier has not updated will have a lot of branches that do not have ENDBRANCH as targets. The CET will have to be something that is turned on at a per application level with the default being off or many applications will break. (Given the extreme speed that some suppliers work, there will still be non conforming applications in 2040 !!)

Icon for systems that enable CET without checking for non-compatible programs.

========================>

[Anonymous Coward]

Re: Older programs ?

True, but if you protect all of the system and user libraries that get pulled into a process space, it should reduce some exposure.

[A random security guy]

I can see a lazy programmer disabling it if he can

Just finished some audit of code and the programmer ranting about DEP. Seems like it got in his way of inserting unsigned and un-tested code.