Have a look at Linux 2.0 implementation. You'lll see an interrupt handler copying registers to the stack, and *then* invoking the call gate. So basically, doubling the work. And no, interrupts are not safer, as they don't provide stack isolation. This is done *manually* in the Linux implementation.

I seriously doubt that. I was working extensively with x86 assembly in 98, and actually implemented call-gate systems in some of my pet projects. Granted, they were pet projects, not a mainstream piece of OSS, but I don't share that experience.

AFAIK, the implementation 2.0/2.2 still uses a call gate. Not directly, but inside the IV.

It is a fundamental problem with the trap gate. The pipeline size and the agressive branch prediction mechanism only made it worse. Shorter pipelines don't suffer as much, as they are faster to clean and less prone to stupid execution stalls. Also, there was a huge amount of optimization done on silicon for this since 32 bit operating systems using interrupts became mainstream, and the same can't be said for the architecturally complex call-gate solution. SYSENTER simplifies a lot, but performs basically the same task as a call gate.

Actually, the fact that many other architectures do not provide any other user-defined global entry point besides the interrupt table has a huge weight in it; I don't see any problem with the metodology, if you're implementing a portable system. I see problems with a specific implementation of it on an operating system designed from the ground up for x86, and one of those problems is that whoever implemented it clearly had no clue about how it worked.

As many other tribes do, including many many muslim settlers. Jews didn't existed as a "nation" trying to form their own country since the beginning of the 30's. Problems between jewish settlements and muslim settlements go back many many centuries, as both shared the same piece of land. To suggest that jews are the ones with the legitimate right to it is to be narrow-minded. During the beginning of the XX century, they were actually a minority in the region. In fact, when jews all over Europe started returning to the "promised land", the influx was so big that the Brits passed laws limiting Jewish emigration.

That is a piss-poor excuse. I bet your neighbour doesn't have nuclear devices and the backing of the most well-equipped army in the World. But if that "us-or-them" attitude is what makes you sleep well at night - by all means. But regardless, both sides are to blame.

Oddly enough, when American citizens are killed by the thousands as a response to direct actions of their freely elected democratic government, its called "terrorism", and it is a legitimate excuse to bomb the shit out of other countries. What you're saying is that anyone that suffered directly from decisions made by the US governments has the legitimate right of shooting down *any* american, just because it exercised its democratic duty. So, lets expand this concept - there has been some heavy international military interventions in the last decade, coordinated by more than a dozen democratic nations. It was their government's decision to take part on it. What you're defending is, that if you were on the other side of any of those interventions, you have the *right* to kill *anyone* from any of those countries, because they elected a government?
I actually hope you're an american.

Its not the hater's portrayal when you have western media covering it, and even have Israel allies asking questions about this. Are you really convinced that Hamas has a super-duper propaganda machine that is bigger and more efficient than Israel's/US machine? Shit happens when you bomb one of the most densely populated areas in the world, and they don't care.

And what do they have left? I'd suggest you try to corner a common house pet like a cat or a dog, and see what happens. It is easy to take the moral high ground when you have food, water, sanitation and electricity. And a job, public transportation, schools, shelter. Parks for kids to play. Do you think everyone in Gaza is a terrorist? Do you think every arab is a terrorist?
Imagine yourself without most of what you take for granted, and that you look across your fence and your neighbour has everything you want and is laughing at you. It is hard not to get emotional on this, specially when you have an active propaganda machine telling you who the enemy is. And this machine exists in both sides.

Keep in mind, what is now the US and Australia was partially colonized by western criminals. Does this mean they are all criminals, and their children need to die? I don't think you believe what you wrote.

So, a guy insults you and says you should die. You shoot him and his family? Is this the appropriate response? Because that's what I've seen Israeli leaders and spokesman defend, and they don't look like batshit crazy terrorists. The other guys do.

Playing devil advocate's here, but most Hamas attacks are almost laughable a military point of view, and they are a pretty good excuse for Israel to retaliate. They may be taking the credit for them, but I'd be quite surprised if at least some of these attacks aren't "sponsored" by Israel itself.

Wrong. Linux didn't use them because every Unix OS out there didn't use them because... You know, they weren't designed specifically for x86. And - contrary to *every* single f***ing int 0x80 implementation out there, x86 Linux uses/used to (before SYSENTER) by-register instead of by-stack parameter passing convention.

Windows NT didn't use them because it was designed as a highly portable micro-kernel. Initially they targeted other architectures besides x86, such as MIPS. There were other reasons, and AFAIK most of the *actual* protection mechanism from the kernel was developed by an outside consultant (read it on a book some years back about Windows 95, cannot vouch for accuracy).

BSD kernels weren't designed for x86. They were ported for x86. The ports were done using the most generic approach. And every x86 BSD kernel uses by stack convention, not by register.

OSX wasn't designed as a x86-only operating system, and also inherits from BSD and XNU. XNU is based on Mach, which is based on 4.2BSD, so again, a port, not a native x86 development.

You're kidding me, right? A single call that triggers a processor mechanism that creates a destination stack frame, SECURELY copies X bytes of stack between levels and invokes a higher - or LOWER level function? Most 32 bit code is 4-byte aligned anyway and binaries built page-bounded, so the actual savings are bare to none. And call gates are *actually* faster than interrupts. And given the way that protected memory works, I'd expect to see way more cache penalties on the interrupt approach than with a call gate. And all this not considering the huge amount of executed code before dispatching the actual syscall, at least on the kernels I mentioned.

No, you're confusing software interrupts (such as int 21h, int 80h, etc) with parameter convention. DOS-style is to pass parameters to interrupts by register, eg. ah=25h, al=00, int 21h. Every other x86 unix implementation passes by stack, not by register. There is the "but its slower" argument that falls when you actually look at the 2.0 kernel implementation specifics.

True. Most unixes did it because of ABI compatibility (the use of int 0x80 predates any semi-decent protection mechanism from Intel, probably by a decade). Also, most OS developers aren't really tied into building a better mouse trap; If you look at it, most OSs use more-or-less exactly the same design, because most of the guys building them all learned from the same book and the same source references (nothing wrong with that, and it is truely the work of masters), and the guys that didn't usually don't care about x86 at all. Some are little details (such as the call gate stuff), others are a bit more serious (as in the case of not using the cpu's segmentation mechanism in userland applications to provide complete separated read-execute and read-write selectors), but in the end is like having a Ferrari to drive to church :)

I'd say pretty much every protected-mode/mode switching assembly line in 2.0/2.2, and the USB stack issues in 2.4.12 - 2.4.22. And the whole swap mechanism of pre-2.6 (and specially pre-2.4). And the shitty shitty DOS-style syscalls in x86! Wtf was that? Intel/AMD even came up with a shiny new instruction, since apparently linux devs (Linus?) cannot be bothered in reading about level switching with call gates.
Anyway, dreadful bugs? Can't recall any major one. I did have some linux machines locking up randomly, even when they shouldn't, but most of the times, its a driver issue, not the kernel itself.

If you configure any of them to that specific task, there is no technical limitation from their side. But I'm sure you wouldn't consider some scripted operations in Excel to generate and manage certificates a security product, right? That was my point.

And is consistent in every environment? Shall I expect the same quality and behaviour in OpenBSD, Linux and Windows 3.1? Because, you know, this is the actual problem.

Sure, its called ENGINE API. Did LibreSSL removed it? Doesn't seem so. Check https://github.com/libressl/li...

So, you acknowledge they're still not mainstream, as you tried to imply in your previous comment.

Yeah, it didn't. Crypto support in general purpose CPUs is not new, and as you mentioned, the VIA instructions are way older than the incarnation from Intel.

The whole point is, probably some of the critical systems running software implementations in userspace shouldn't. Cryptoprocessors exist for a long time, and cryptocards and SoC are quite common well, everywhere. Bugs will always exist, but the attack surface is way smaller.

That's how all software works. It wasn't a serious/catastrophic bug. The peer review process from the community worked as expected, the bug was spotted and then fixed. The bug was tied to a specific implementation that wasn't very well thought of. Doesn't really matter, it was fixed. The bug itself was quite hard to exploit, specially if used on a secure environment (where process accounting is common; in fact, it baffles me the inane amount of Linux servers without any resource accounting at all, and the huge amount of sysadmins that don't even know how to configure this); I'd guess it is quite easier to gain root access on a given Linux server by using a more "generic" exploit (and then do as much hijacking as you want) than to hijack a crypto channel by using a fork bomb. And if it was Linus doing a similar fuckup, no biggie. But because it's Theo, it is newsworthy.

So, it generates prime numbers and does some math between them. If that is a security product, so is everything else capable of producing that kind of output - it includes both Excel and the C language, as an example.

Define "recently" and "greatly". Because if this bug actually happened in OpenSSL, I suspect that we'd have to wait months for the proper patch from upstream.

It's a shame that you don't realize that *modern* Intel is only a subset of the cpu market, and not even that relevant in network appliances. Have a look at http://en.wikipedia.org/wiki/R..., and you'll quickly see that the instruction you mention is about 2 years old. So, either you have the experience you say you have in other posts, and you're perfectly aware of this and are trolling, or you actually have no clue on the diversity of hardware out there.

OpenSSL/LibreSSL are *not* security products. They are crypto middleware. They can be used to build security products, or to build completely unsecured products. They do nothing by itself. Which is fun, because the LibreSSL Linux port actually required *extra* code so it would work with dumbass admins. And this extra code had the bug. True, Linux PID behaviour is not a security feature, but it is an entropy source. Maybe not a good one, granted. But it was used as fallback. Want to bitch about it, go ahead. It was detected, it was fixed. It is not a big deal. What is the problem?

It isn't. Apparently is an issue related to portability (aka Linux), and lack of permissions to access to proper RNGs in real-world scenarios (no access to /dev/urandom). While this is definitely a bug, it *isn't* a biggie. Its an edge case where the implementation should have been more robust, that's it.

I know. But those are only a subset of the contributors. And eg. for big, important projects, development is done mainly by companies (eg. Linux Kernel, Java, some GCC infrastructure, Mozilla, WebKit, etc), even if the commiters are listed individually. As I explained, the idea of the poor lonely guy in a basement writing code and being sued by the "big corps" is skewed from reality, and it has been for many many years.

That number may be absolute (as you're implying with the SI reference) or relative. Checking yourself into a hospital because of an anxiety attack and getting a prescription and some off time because of the whole situation is easily quantifiable. Many health-related quantifications are done in percent of an expected, well known pattern. And insurance and disability funds are paid based on that.

While I do agree with your point (relying on a 3rd party is usually not a good idea, specially when you can self-host the codebases), this is more common than you think. I myself maintain/contribute to several private (paid) repositories that rely on external dependencies from OSS projects.

Again, if someone publicly acuses you of a crime that is later proved you didn't commit, you are entitled to indemnification by damages caused to your reputation and your business/whatever. As this is not a matter of crime, it is a dispute filed on a civil court. There is no prosecuter on this. It is a dispute between two entities.

Yeah, but again, they are only a subset.

Please tell me one well-known, widespread OSS project that is completely community-driven and mostly built with unpaid volunteer work. And no, stuff like foundations don't count - they're done for tax purposes.