Call Depth Tracking Mitigation Updated For Linux In Better Mitigating Retbleed

[phoronix]

Phoronix: Call Depth Tracking Mitigation Updated For Linux In Better Mitigating Retbleed

Back in July Intel's Peter Zijlstra proposed "Call Depth Tracking" as a mitigation approach for handling Retbleed and avoiding the "performance horror show" of Indirect Branch Restricted Speculation (IBRS) usage. Out today is the newest version of the Call Depth Tracking code and the performance benchmark results are looking very promising for lessening the pain of the Retbleed CPU mitigation performance impact...

https://www.phoronix.com/news/Call-Depth-Tracking-Retbleed-v2

[birdie]

Good, I've still disabled retbleed mitigations on my dual core skylake laptop (the first time I'm doing that but retbleed is so obscure I just don't care) - it's already too slow due to meltdown and a ton of other mitigations.

[MastaG]

When you are the only one accessing your device, you can just set mitigations=off on your kernel cmdline.

Also even if you have somebody with shell access, I doubt it's easy to use these kind of attacks to actually get hold of your private keys or something.

I'd even downgrade the bios to get an older microcode that has no mitigations in place.

[Vorpal]

When you are the only one accessing your device, you can just set mitigations=off on your kernel cmdline.

Also even if you have somebody with shell access, I doubt it's easy to use these kind of attacks to actually get hold of your private keys or something.

I'd even downgrade the bios to get an older microcode that has no mitigations in place.

Except for the issue of web browsers. Some of these (mostly the early ones iirc, like meltdown and spectre, but I have not kept up with recent developments) have working public exploit code for JavaScript in browsers.

Sure NoScript helps, but a lot of legitimate pages breaks with it, so you still need to allow a lot of js.

Were it not for the web, I would agree with you.

[xcom]

If you use your PC locally without internet and single user then mitigations are not really needed

[archkde]

Except for the issue of web browsers. Some of these (mostly the early ones iirc, like meltdown and spectre, but I have not kept up with recent developments) have working public exploit code for JavaScript in browsers.

Sure NoScript helps, but a lot of legitimate pages breaks with it, so you still need to allow a lot of js.

Were it not for the web, I would agree with you.

This can't be stressed enough. When you're browsing the web, you're effectively never the only one using your machine. Every JS author of sites you visit is too.

[blackshard]

When you are the only one accessing your device, you can just set mitigations=off on your kernel cmdline.

Also even if you have somebody with shell access, I doubt it's easy to use these kind of attacks to actually get hold of your private keys or something.

I'd even downgrade the bios to get an older microcode that has no mitigations in place.

No, no and no. Any time any code from untrusted author runs on your machine, you're in danger.
As others have pointed out, any site that use javascript can potentially steal stuff from your machine.

In general, giving the chance to any userland process to access any memory location of your machine is just a violation of the basic rule of process isolation, which is a basic requirement for any non-toy operating system.

[binarybanana]

r

Except for the issue of web browsers. Some of these (mostly the early ones iirc, like meltdown and spectre, but I have not kept up with recent developments) have working public exploit code for JavaScript in browsers.

Sure NoScript helps, but a lot of legitimate pages breaks with it, so you still need to allow a lot of js.

Were it not for the web, I would agree with you.

Are there any working demos for this? I know of Google's http://leaky.page but that never worked for me no matter how hard I tried. And I spent probably a good hour on it between both on my laptop and my phone. Both running Firefox. I guess the fact I use privacy.resistFingerprinting which reduces timer precision helps but even without that it didn't work. I think Firefox has limited timer precision in general at some point.

[Weasel]

When you are the only one accessing your device, you can just set mitigations=off on your kernel cmdline.

Also even if you have somebody with shell access, I doubt it's easy to use these kind of attacks to actually get hold of your private keys or something.

I'd even downgrade the bios to get an older microcode that has no mitigations in place.

Note that what you mentioned is not enough if you want absolute performance. You will have to rebuild the kernel with these config options:

CONFIG_RETPOLINE=n
CONFIG_CALL_THUNKS=n
CONFIG_ZERO_CALL_USED_REGS=n

[boxie]

That is some impressive work - I wonder if there is any perf benefit of the 16 byte function alignment alone?