* Do this with "<0" and ">=0" to only test the sign of the result. A
* good compiler would generate better code (and a really good compiler
* wouldn't care). Gcc is currently neither.
It's funny the love-hate relationship the Linux kernel has with GCC. It's the only supported compiler[1], and yet...
[1] can Clang fully compile Linux yet? I haven't followed the updates in a while.
To be fair this comment predates git history (before 2005) when GCC wasn't a very good compiler. The kernel developers at one point were sticking with a specific version of GCC because later versions would miscompile the kernel. Clang didn't exist then.
Do I understand it correctly that the logic is that if timestamp B is above timestamp A, but the difference is more than half of the unsigned range, B is considered to happen before A?
Yes. When the timestamps wrap it's fundamentally ambiguous, but this will be correct unless the timestamps are very far apart (and the failure mode is more benign: a really long time difference being considered shorter is better than all time differences being considered zero after the timestamp wraps).
The first generation was complete garbage. Itanium 2 came too late and it did not get widespread due to wrong business decisions and marketing. By the time it could have been successful, AMD64 was out. And even then Intel targeted only the same high-end enterprise market segment, when they have implemented 64-bit on Xeon: https://www.cnet.com/tech/tech-industry/intel-expanding-64-b...
Both mentioned CVEs seem to be about local privilege escalation. So basically yes, if you don't install crap apps, there's a high chance that you are protected. Problem is that it might not seem to be a crap app, but a nice-looking game, etc. Also an attack can come in with an update of any app you have already installed on your phone.
Threat model is probably third party ad and tracking libraries that pay to get into apps. If I caught it, I'd expect it to be from an app to use a parking deck, a colorful desk lamp, an otoscope etc where the developers sold out years ago
The point was surely more that apps being exploited via the Play Store can be mitigated there without client OS updates. The only hole here requiring the update needs a sideloaded attack.
Except the Play Store is a hot mess, and Google does little to no review of apps. Trusted repositories work best when the repository maintainers build and read the code themselves, like on f-droid or Debian. What Google and Apple are doing with their respective stores is security theater. I would not be surprised if they don't even run the app.
Again though, that's mixing things up. The question is whether or not mitigating the exploit requires an OS patch be applied promptly.
And it seems like it doesn't. If there is a live exploit in the wild (as seems to be contended), then clearly the solution is to blacklist the app (if it exists on the store, which is not attested) and pull it off the store. And that will work regardless of whether or not Samsung got an update out. Nor does it require an "audit" process in the store, the security people get to short circuit that stuff.
https://elixir.bootlin.com/linux/v6.15.7/source/include/linu...