6:50 if you're dumb like me and didn't immediately realize why this doesn't work: text.size() is unsigned. Anyway, that means the result of the subtraction is also unsigned, which will never be smaller than 0 and that check will always return false. Instead of going below 0, an unsigned subtraction like that wraps around to the largest possible positive unsigned value.
Very appreciative of the question clarifying that the CPU does not protect other processes from each other, rather, the operating system does. The thing that genuinely freaked me out when Spectre was published was that the branch predictors are virtually addressed and globally shared. I do not understand how that passed review. Also, it is safe to run untrusted code in the same process if its behaviour can be verified deterministic, which is not prohibitive if you don't need to support legacy features (that is, you aren't a browser) and can think carefully about your concurrency story. Very entertaining stuff! Will look for more of this speaker's work.
Does anybody know where the rest of the videos of cppcon are? Or are they being uploaded slowly in the coming weeks? There's barely been anything so far?
I write non security code and do not deal with private info. So I understood only title :( Anyway great talk! Now I need to learn programming few more years.
Wait, I thought branch prediction just loaded the instructions and still waited for the result of test condition before executing them? Otherwise this sounds really dangerous.
Not sure what you'd get from leaking data out of clang, if you're running clang you already have the code. The only untrusted input you have is code and that's the only thing you could steal.
I'm not a security guy at all. This talk filled up one of empty and shallow buckets in my C++ knowledge base. Can you please update more? By more, I mean at least episode per day. pleaaaase
And he gave talk "going nowhere faster" (and the question was asked) in September 2017. Ofc vuln was reported in Jan/Feb 2017, but it all means he probably knew about it when the question was asked
Not planning on posting the specific code I show, but it's not special. If you search for Spectre POCs, can find several that are public and use the same techniques.
OMG the standard does the wrong thing and resolves math between signed and unsigned as unsigned!!!??? Whyyyyyy?!?! Luckily, I never use unsigned values, so I never run into stuff like this, but I had no idea the standard was that wrong when it comes to this. It does the right thing when doing math between floating point and integral types, so why doesn't it correctly resolve between signed and unsigned. That really needs to be addressed.
@@Dziaji The standard is actually technically correct here. With the way 2's compliment arithmetic works, it is impossible to take an unsigned number and a signed number of the same bit width and guarantee a useful signed result with reasonable overflow expectations. For example, working with 8-bit numbers, 255u8 - 1s8 = -2s8, and 254u8 - (-1s8) = -1s8. On the other hand, it *is* possible to get a useful unsigned result with reasonable overflow expectations. 255u8 - 1s8 = 254u8. Additionally, 3u8 - 5s8 becomes 3u8 - 5u8, which underflows to 254u8. The only way around the issue is to cast up to a signed integer of a larger bit width before performing the arithmetic, such as 255u8 - 1s8 becomes 255s16 - 1s16 = 254s16. However, this can result in severe performance degradation depending on your CPU architecture and the size of your integers (think u32 - s32 on a 16-bit proc), so C and C++ do not perform the conversion automatically. Note that this isn't an issue with int vs float because it's always safe to cast from integer to floating point. The exception is when you don't have a hardware FPU, but you already signed up to use floating point arithmetic when you made one of your operands a float.
the fuck? the device I bought, with an INTEL cpu, is vulnerable to shit intel itself knew for 10+ years and I'M NOT ALLOWED TO KNOW about it? THE FUCK?
Only took me 7 years, but finally makes sense. Thanks Chandler.
Chandler is one of my top-ten speakers. such a pleasure listening him. and i am not even a pro C++ programmer
The same here.
I wish I was as intelligent as him .. absolutely love his talks .. so clear and detailed.
6:50 if you're dumb like me and didn't immediately realize why this doesn't work: text.size() is unsigned.
Anyway, that means the result of the subtraction is also unsigned, which will never be smaller than 0 and that check will always return false. Instead of going below 0, an unsigned subtraction like that wraps around to the largest possible positive unsigned value.
I'm really happy that my MOS 6502 isn't impacted ;)
Smile, Sweet, Sister, Sadistic, Surprise, Spectre, Side-channels, Sandboxes, Security.
Big shaq
Spoiler
www.theinquirer.net/inquirer/news/3072107/spoiler-flaw-affects-all-intel-cpus
You missed Specular
This is a big one, waited months for this! Cheers for the upload! =D
Amazing talk! Trully impressive precision and clarity of mind/words
very informative Chandler, thanks for this nice overview of Spectre and co.
Finally I understand Spectre a little more, thank you
Fascinating talk.
55:41 - Using a stack smash to mitigate Stack smash... Why am I finding this so funny?
That's what software fixes are -- skirting around the real source of the problem in the hardware. :)
Very appreciative of the question clarifying that the CPU does not protect other processes from each other, rather, the operating system does. The thing that genuinely freaked me out when Spectre was published was that the branch predictors are virtually addressed and globally shared. I do not understand how that passed review.
Also, it is safe to run untrusted code in the same process if its behaviour can be verified deterministic, which is not prohibitive if you don't need to support legacy features (that is, you aren't a browser) and can think carefully about your concurrency story.
Very entertaining stuff! Will look for more of this speaker's work.
I'm really interested in the talk "What do you mean thread-safe?" by Geoffrey Romer, is it possible to have it uploaded? Thanks :)
Wow! Great work! Thanks. Here ----> skip the disclaimer: 4:44
Great talk! bonus question: why dvorak? :)
Hey! We'd love to have access to at least one full song.
Does anybody know where the rest of the videos of cppcon are? Or are they being uploaded slowly in the coming weeks? There's barely been anything so far?
I write non security code and do not deal with private info. So I understood only title :(
Anyway great talk! Now I need to learn programming few more years.
Is this talk worth watching if I've already seen Godbolt's video on Spectre/Meltdown?
This is so cool, especially the side_channel.cpp. Will Chandler open the full source in this video?
In a reply elsewhere in this comment section, he said no, but also that it's not novel in any way and that similar examples are publicly available.
I see Chandler, I press like.
Wait, I thought branch prediction just loaded the instructions and still waited for the result of test condition before executing them? Otherwise this sounds really dangerous.
Anyone know where I can get the source for the code he presented in the talk? I can't seem to find it in the github folders
Sorry, no source published at this point. You can search for 'SpectrePOC' though and find several good examples.
Very informative talk and thank you for the quick reply. I found something on github that looks promising.
Have a look for my Spectre + Meltdown PoC in just 99 lines of code: github.com/berestovskyy/spectre-meltdown
Is LLVM IR and its runtime safe from Spectre (and if yes which versions)?
Not inherently?
Not sure what you'd get from leaking data out of clang, if you're running clang you already have the code. The only untrusted input you have is code and that's the only thing you could steal.
@@meneldal Perhaps they're writing a code execution engine backend where people submit their code which is untrusted.
You probably should spawn separate process for executing that IR.
What terminal is he using?
I think it's fish shell, but maybe with a plugin?...
Looks like oh my zsh with agnoster theme, customized with some color scheme.
gist.githubusercontent.com/agnoster/3712874/raw/screenshot.png
Looks like fish shell with a bobthefish theme. github.com/oh-my-fish/theme-bobthefish
@@vtyulb Thanks for the tip! Installed these yesterday and really like fish so far.
I see FISH I like 👍
I'm not a security guy at all. This talk filled up one of empty and shallow buckets in my C++ knowledge base. Can you please update more? By more, I mean at least episode per day. pleaaaase
Spectre leaked out before 2018. 2017 October due to patch to Kernel
And he gave talk "going nowhere faster" (and the question was asked) in September 2017. Ofc vuln was reported in Jan/Feb 2017, but it all means he probably knew about it when the question was asked
Can you please post the code for the speculative execution bug?
Not planning on posting the specific code I show, but it's not special. If you search for Spectre POCs, can find several that are public and use the same techniques.
Here is my Spectre + Meltdown PoC in just 99 lines of code: github.com/berestovskyy/spectre-meltdown
I'm not optimistic about this.
1:11:42 I'm looking at you, Intel
> . >
10 - 15 = -5
-5 < 0
The error should have been triggered. Why wasn't it?
OMG the standard does the wrong thing and resolves math between signed and unsigned as unsigned!!!??? Whyyyyyy?!?! Luckily, I never use unsigned values, so I never run into stuff like this, but I had no idea the standard was that wrong when it comes to this. It does the right thing when doing math between floating point and integral types, so why doesn't it correctly resolve between signed and unsigned. That really needs to be addressed.
@@Dziaji The standard is actually technically correct here. With the way 2's compliment arithmetic works, it is impossible to take an unsigned number and a signed number of the same bit width and guarantee a useful signed result with reasonable overflow expectations. For example, working with 8-bit numbers, 255u8 - 1s8 = -2s8, and 254u8 - (-1s8) = -1s8. On the other hand, it *is* possible to get a useful unsigned result with reasonable overflow expectations. 255u8 - 1s8 = 254u8. Additionally, 3u8 - 5s8 becomes 3u8 - 5u8, which underflows to 254u8.
The only way around the issue is to cast up to a signed integer of a larger bit width before performing the arithmetic, such as 255u8 - 1s8 becomes 255s16 - 1s16 = 254s16. However, this can result in severe performance degradation depending on your CPU architecture and the size of your integers (think u32 - s32 on a 16-bit proc), so C and C++ do not perform the conversion automatically.
Note that this isn't an issue with int vs float because it's always safe to cast from integer to floating point. The exception is when you don't have a hardware FPU, but you already signed up to use floating point arithmetic when you made one of your operands a float.
I consider myself to be pretty good at C++, but other than a general idea.. I really don't have a good understanding of all this. Complicated stuff
Because it is more about CPUs than C++.
Made my first comment ever on youtube last week. It was removed. TH-cam, do you care to send me an E-mail and explain why? Thank you.
the fuck? the device I bought, with an INTEL cpu, is vulnerable to shit intel itself knew for 10+ years and I'M NOT ALLOWED TO KNOW about it? THE FUCK?
Please, stop uploading the band at the start
How else are we supposed to know how fun the CppCon was?
@@DPGrupa I didn't come to these CppCon vids to hear the last 10 seconds of a band I don't care about! I'm just here for the talk and nothing else. :P
Please, upload the video with the whole song at the start