> a) there is a very good reason why everyone sets segments to maximal size and it's exactly the fact that this crap is *not* free. It's turned off as an optimisation when processor sees that limit is set to maximum.
Have any references? All I can find when searching for performance of segmented memory in protected mode are a few papers on using it for efficient array bounds checking. :/ Not saying you're wrong, I'd just like to read more about it and I can't find anything useful.
> b) on amd64 segment limits are not verified in 64bit mode. End of story.
NaCl is 32-bit only, even on OSes/machines that support 64-bit mode, in no small part because the tricks employed on x86 depend on such details. The ARM port uses a different set of tricks, naturally.
> And x86 instruction set is not well-suited for analysis, to put it mildly; it's not RISC. Prohibiting jumps into the middle of instruction is nice, but how do you prohibit return into the same?
Since even kernel developers are apparently too lazy to even try to look this stuff up, let me answer your particular attack scenario: the RET instruction is also banned by the NaCl verifier (you are more than free to read the paper on how returns from functions are implemented, if you're wondering how it works). This is one of the reasons why a modified compiler is needed to produce binaries that work inside the NaCl sandbox.
Here is their original paper on their x86 sandboxing; there is more information available to anyone who can bother to spend 30 seconds looking for it:
NaCl isn't for regular desktop apps. It's for smaller, more contained apps. It's for the kinds of things you can already do on the Web or in Flash, except that it allows native speed (or very very close to native, depending on whether you consider hardware-executed but notably non-optimal instructions to be "native", I suppose) and allows for the use of C/C++ code and libraries (I can have a 3D math library that doesn't suck donkey nuts like every last single vector library in every single language other than C, C++, and D does due to the overwhelming limitations of the academia-designed high-level languages; yay!). NaCl isn't intended to be used outside of a browser or for complex applications that couldn't reasonably be implemented and deployed on top of something like Flash (save for the speed).