Replying to myself: actually one can easily exploit embedded flash size limitation. Simply make new firmware huge and uncompressable. Attacker will ran out of place to hide (without creating timing side effects e.g. storing stuff on platters)

Actually, writing a verification firmware is possible (assuming, that it was written after attacking code was written and writer was not NSLed)
Simply because attack code doesn't know what output verification code must produce. It either must execute new code (will be busted) or not (will be busted). Putting a full blown interpreter (or some trap mechanism on flash access) will screw timing - again it will be busted.

I think Apple's unwillingness to admit their bugs, dishonest reviewers and apple's fanboys happily squashing all discontent on message boards etc. combined creating a situation when people simply refuse to upgrade/patch their apple gear.

I mean look, when I first upgraded my perfectly nice iPad Air to iOS 8, it's Wi-Fi become practically unusable (had to reconnect every 5 minutes). Rendering iPad useless for several weeks. And it's not like I didn't check online reviews beforehand... None of them (sellouts!) mentioned this shit. Only _after_ I knew what's wrong with the update I was able to find those huge message board threads full of pissed-off users wenting.

Now, with the new update for iOS 8 I'm sitting this one out. Or at least waiting until other people upgraded and google got the message indexed so I can find it...

Interesting. But (I'm not an expert though) it might be that one cannot mothball those things for very long - you pump it or you lose it.

Additionally, even if it does not work for already producing assets, it as sure as hell will clamp down on new investments. And, maybe, that is just good enough of an outcome.

Interesting, how many times Saudis will have to spank new drillers so nobody will risk to make large investments into new wells any more. Unless some government intervenes with some kind of minimal price guarantee or something.

No, you simply didn't get the point. Google can't push the patch to those devices (unless they are from Nexus line). Samsung, LG, etc. must do the pushing. But they wont.

You are wrong. They don't want electric vehicles. And that simply because there is no money (or much, much less) in post sale maintenance.

That was my point - this way you eat only one recursive call, not two. And in general case (or naive qsort implementation) one recursive call is enough to burn (on bad input) through all your allowed stack.

Interesting. But just as a side note: I thought that people generally stopped rolling their own linear algebra code and started to use precanned one from Intel,amd,nVidia etc. I'm sure matlab is that way.

On stack size issue - the point was about a case of malicious/pathological input.

Yes, but they are clever about what and when they put on that stack. In their case it's indeed no more than log base 2 frames (non overlapping intervals with biggest one larger than the rest combined with the "rest" following the same pattern)

Sure, but that would also mean that debug compiled code, optimized code, ported code - all would behave too differently. Which, again, not a sound engineering practice.

I would guess that that "custom stack" lives in the heap, so in that case the limitation on program's stack size does not apply.

Very deterministic. Thus, easy to screw with. Just populate sample points with that worst case pivot value and voilà. Well... it needs to be done for all consecutive rounds so it's not completely trivial but doable.

If the algorithm is made very unlucky with selection of the pivot, then it will need one stack frame per each 2 data elements. So yeah, I think it's doable (if pivot selection is stupid in some predictable way)