The kind of RPC and IPC problems you mention is what systems like.NET have been designed to solve.
You're not paying attention. Lots of "systems like.NET
have been designed to solve" the problems. Those systems
always fail. The next person comes along and finds the
same problems, and says "I'm designing an RPC system...".
That's why we have so many.
The number of different RPC mechanisms extant should be
a clue that
none of them are really satisfactory (else
people wouldn't feel compelled to keep inventing
new ones), and
they don't really work out, in practice
(else people would be satisfied with one of them).
The problem with RPC is that, to be useful at all,
it has to be used where the function-call abstraction
fails. In inter-process communication and (more so) in
network communications, there are too many failure
modes that just don't fit that abstraction, but that
a reliable application needs to handle anyway.
The whole point of RPC is supposed to be that the code
invoking them looks just like regular function calls.
To be reliable, though, they need to be decorated with
so much error handling junk that any such benefit is
usually lost. You're better off with explicit message
passing and a documented wire protocol. You need the
latter anyway to have a debuggable application.
This result bears on the Andrew Bunner trade-secret case
in California. That court found that since the trade secret
was (supposedly) illegally obtained, Andrew Bunner and
several hundred "John Does" had acted improperly in
posting it.
At the trial the question came up whether in
fact the reverse engineering involved was legal under
Norwegian law. They called for opinions from Norwegian
lawyers. The plaintiff trotted out a tame lawyer who
asserted (without any support) that it was not legal.
The defendant's lawyer said nothing in Norwegian law
or case law supported any opinion one way or the other.
The judge took that to mean that in fact it wasn't
legal.
Now that it's established that in fact it was legal,
Bunner et al. should be able to have the decision
vacated. (Shame on that judge.)
The Gnome and KDE toolkits are about equivalent, so the
choice amounts to a coin flip, licensing issues aside.
Of greater moment is the choice of database library.
PostgreSQL is enormously more complete and standard-compliant
than MySQL, and (for years, now) faster, and is committed
to the more liberal license that Bruce has demanded. MySQL
(like KDE) is straight GPL in release 4.x, and lacks many
important enterprise features.
Odd, isn't it, that we don't see flame wars over
the database? Probably they will switch quietly
to PostgreSQL once they get around to the matter,
and nobody will make a fuss.
Of greater moment is the choice of MySQL vs. PostgreSQL.
Similar license issues pertain, and the differences in
fundamental capability are much greater.
This is a good demonstration that the distinction
always made between local privilege-elevation bugs and
remote exploits is academic hair-splitting. It's rarely
difficult to get unprivileged access through a buggy
non-privileged service. (Web-server plug-ins are a
reliable source of entry points.) Once you're in,
privilege elevation takes you the rest of the way.
Certainly the distinction is useful to security students
and analysts, but it's misleading for everybody else.
"Oh, that one's just a local exploit; not so bad."
The OpenBSD advocates promote the fallacy: "only one
remote exploit in this millennium!" (or something like
that), encouraging us to ignore almost equally damaging
exploits in non-core services that provide access to
local accounts and more damaging attacks.
There's a similar fallacy in distinguishing security
holes from other bugs. Without a depth of analysis
that hardly anybody can ever afford, almost any bug
might actually be a security hole, too. The OpenBSD
people get this one right -- to them, any bug is a
security hole until proven otherwise, and they
encourage running latest versions -- but almost
everybody else gets it wrong. When I fixed a
double-free segfault in lib[mumble], nobody posted security
warnings about every program that relies on it.
despite that double-free bugs can often be exploited.
Debian gets this wrong, and very selectively backports
only proven security holes, ignoring the myriad bugfixes
that might just as easily be security holes as well.
To find holes in stable-branch services, just look for
bug fixes in later versions, particularly in libraries
used by those services. Failing that, look at new
features added shortly before the library-version used.
Chances are the last new feature added has
bugs that haven't been noted yet, and that might be
exploitable.
This might be a good place to mention that the CVS codebase
is almost irreparably insecure. The practical implications
are: (1) A remotely-accessible CVS server should never be
run on a host that does anything else that matters, or
that has access to anything else;
(2) An anonymous CVS server should never be the same CVS
server that is used for checkins, or even run on the same
machine. The pserver should be a slave that only gets
read access to a copy of the archive. (3) Checkins on
remotely-accessible servers should result in patches logged
to another archive kept on another, not-remotely-accessible
machine. Patches from that server should be posted
to the mailing list.
Eighteen thousand downloads would be pretty impressive
for a very specialized project. It doesn't seem like
so many for something meant to be useful to all programmers.
How does that number compare to other projects of
similarly general utility that aren't in Java?
Eclipse might yet become the first successful free Java
program used by people not otherwise obliged to use Java.
But I don't think 18K copies saturates the already-using-Java crowd.
Nothing plays OGG. There's no such thing as OGG.
It's Ogg. It's not an acronym, it's just a name.
Ogg is the name. The name is Ogg.
Can somebody explain why this such a difficult concept?
Ogg. Ogg. Ogg. Not so hard.
Incidentally, I'll bet it doesn't play every kind of Ogg.
I'll bet it plays
only Ogg/Vorbis and (probably) Ogg/FLAC, but probably not
Ogg/Speex, yet. In principle it could play Ogg/Theora,
but the display's probably not up to the job -- Theora
is a video compression format.
RML claims, "Sorry, you're wrong, for two reasons:
A char* can be used to point to anything.
You can write to one member of a union and
read from another."
Yes, a char* can point to anything. However, actually
reading from uninitialized storage has undefined
behavior. Writing a different member of a union
doesn't count as initializing. Unions really cannot
safely be used for type punning.
Casting a pointer, as you say:
double d = 1.0; int i = *(int *)&d;
would be the correct way
achieve that end (almost). The compiler would observe that
the address of d had been taken, and not assume it was "dead"
after the assignment. Then, i would get initialized via
the pointer. No optimizer would damage such code.
Note, though, that to be strictly defined (albeit not
specified), i and the cast should be "unsigned int".
With unions, though, all bets are off. If the
Linux kernel has gaffes like that in it, it's no
surprise that it breaks under newer compilers!
The code means c = "the second byte in the machine's representation of 1.0 as a double"
If gcc generated code doesn't produce that, than gcc needs fixing.
Sorry, that's totally false. (I hope you don't get
paid for writing C like this!)
It doesn't just have "unspecified
results", it is "undefined". The compiler is allowed
to give you the second (or seventh!) byte of the double,
but if you say -O3, you're asking it to generate the
fastest code that is consistent with the standard.
The fastest code, in this place, is to leave whatever
is in that register already alone. If your code doesn't
do what you wanted, then, it's because you didn't
really say what you wanted.
This is a Good Thing. Running the Windows driver in a wrapper
on Linux makes it much easier to reverse-engineer. Anything
discovered that way is free of vendors' non-disclosure
agreements. This applies to lots of drivers, and lots of manufacturers, not just Intel and Centrino.
You miss the point. There is no longer any such thing
as "innocent and uninformed". Plugging an insecure host
into the wide-open internet is, now, itself a hostile
act. Your gentle information distribution has already
been demonstrated a near-total failure. (Certainly my
parents would have no idea what to make of your
advice, and would necessarily ignore it.) Insecure hosts
are not just vulnerable to misuse themselves, they are weapons
for the misuse of all hosts, secure and otherwise.
I don't expect anyone to live the kind of life I want.
I do expect the machines they own not to attack mine. If
they do not do what is necessary, then it is not only the
right, but the responsibility of others to make
their machines stop. You like analogies: every vulnerable
host is a rabid dog. Surely you will not argue that shooting
a rabid dog that is attacking you is somehow immoral? How
about a rabid dog that is has not yet begun attacking you
and your children, but certainly will -- but you (or they)
might not be armed when it does?
The only choices available are (1) to have an internet in
which some hosts are able to operate normally (the secure
ones) and (2) one in which none can. If no hosts can
operate normally, because the insecure hosts have made it
impossible, how is failing to take down the insecure hosts
doing their owners any favors? The internet they would
like to be connected to doesn't exist, because it's being
destroyed by them and their like. No one is prevented from
setting up a secure host -- that option is open to all.
The only effective encouragement possible is for that option
to be the only one that actually works for any length of time.
...we'll have no terrorists taking hostages if we kill all of the potential hostages
I don't recall suggesting to kill anybody. Anyhow, every
vulnerable host, sooner or later, will be hijacked
by a spammer, or worse. The owners typically neither know
nor particularly care if their machines have been hijacked
that way, so long as it doesn't interfere too much with their
own surfing, e-mailing, or file-sharing. Their ISPs, if
they are responsible, do care, but can do little.
There's a legal term for operating a vulnerable host
on the 'net: it's an "attractive nuisance". In the
absence of possible legal measures, removing such
nuisances is the obligation of responsible citizens.
Anybody operating a secure host will be unaffected,
other than to welcome each incremental decrease
in spam.
Nobody has an inherent right to keep a loaded cannon
pointed at the town square where anybody might walk
up and fire it. Responsible townsmen will pour
concrete into any such cannon they find before,
not after, the local hooligans come around to fire
it. As it is, the local hooligans are firing them
again and again, and the owners are generally
doing nothing to stop it.
And no, I'm not a sysadmin, but lots of sysadmins
agree with me, although they (as I) doubt they could
participate in such an action themselves.
This isn't proof that they don't have a quantum computer.
It's evidence that they do have, or expect to, or expect
others to have soon. A quantum computer isn't magic. The
best guess about the power of quantum computers, as applied
to decryption, is that they can crack a 2N-bit cipher about
as fast as an ordinary computer cracks an N-bit cipher.
So, when we see the NSA not just adding key bits, but
adding bits and then doubling them, we see evidence
of countermeasures against quantum computers. This doesn't
mean they have quantum computers. Remember that
they are not just guarding secrets they transmit today
against attack now, but against attack ten years from now,
when revelation might still be damaging.
Once we all do have quantum computers, I wonder what
amusing revelations will come from cracking old
ciphertexts. You can bet the NSA will keep busy at it,
and so will the Brits, and the French, and the Germans,
and the Russians, and the Israelis. (No doubt a few of
the biggest corporations go on that list too.)
The only way to deal with these distributed attacks
is pre-emptively: any host that is susceptible
to attack by a spammer must be attacked first by
an anti-spammer. The most effective way would be
via worms, but that does not suffice. Spammers
also enter via booby-trapped web pages and e-mail
viruses, so anti-spammers must use those vectors as
well. Anti-spammers have to attack first, because
otherwise the spammers will plug up the holes behind
them, making it progressively harder to root them
out after they have installed their own malware.
It is tempting to think that simply closing off
the known holes in the target machines should
suffice. That's just wishful thinking. There
will always be other ways for the spammers to
enter, not yet discovered. The only way to keep
the spammers out of those hosts is to wipe them
clean. Eventually the owners will either leave
them disconnected from the internet, or wiped,
or will install something secure. Until then,
they need to be wiped as many times as needed
to get the message across.
This level of conflict was inevitable once the
spammers encountered enough interference in their
old methods. Now there's no going back.
We need to ensure, positively, that any host that
is connected to the net really is secure enough
not to be hijacked by the spammers, and there's
only one way to do that.
The only practical problem with this
method is that the spammers have a vector available
that anti-spammers don't. Spammers can put their
viruses in their own spam, and booby-trap their
own web pages referenced by their spam, but
anti-spammers can't use those vectors without
themselves spamming. Fortunately there are so many
holes in the target systems that it will be some
time before that difference actually protects the
target hosts.
The Free competitors to iTRON are not RTLinux (and RTNetBSD)
as the article (half fails to) point out. The competitors
are eCos and RTEMS. The latter is clearly the more mature,
but the former is arguably more modern in design. ECos
hasn't the penetration that iTRON has achieved, but RTEMS
is everywhere, and is equally invisible.
Suppose I wanted to buy a single-processor Alpha 67 or
7 or 79 motherboard or box. Can anybody post what would
be the lowest price? HP makes it pretty hard to look up.
TIA.
As I understand it, it's just an extension to the existing
instruction set, with the same sort of prefix bytes that
you see in the 8086->80386 16-bit->32-bit extensions,
and convoluted ways to get to the extra registers. In
other words, there's no "mode bit", so it can't be as
clean as it might be, because it still supports all the
old instructions in the same instruction stream.
Answering the original question -- about tools to help
identify and shut down spammers -- nothing helps much.
Now that spammers use viruses to hijack thousands of
helpless newbies' MS boxes, and make them send the
spam through normal channels, nothing much can be done
except, perhaps, wiping out ("securing") all those
hundreds of thousands of infected relays, along with
any other vulnerable hosts yet to be exploited for the
purpose.
Of course that's a job for another virus. While that
might be seen as worse than the problem, I don't run
anything susceptible to viruses. Do you? The trick
is to exploit holes before the spammers do,
but be careful not to harm the ISPs in the process
by overloading their pipes. Once all vulnerable hosts
have been wiped (and, perhaps, reloaded with something
secure, but that's the owners' job -- get it wrong and
get wiped again!) the spammers will have nothing to work
with. Better yet, most of their customers' customers will
be off the net too, solving the other half of the problem.
(By the way, all answers about spam filtering should
be moderated into the toilet, as "off-topic".)
Anything is hackable. Some things just aren't
worth the trouble. The useful distinction is
whether it rewards hacktivity with deep and
abiding satisfaction.
For the majority of readers who are not hackish,
that means that having hacked it, you can make
it do cool stuff that the original designers not
only didn't think of, but never would have in a
million years. It's even better if the next
regular release does that stuff too.
All the tradeoffs will change radically when MRAM hits
the streets. It's potentially denser than disk and DRAM,
as fast as static RAM, nonvolatile, doesn't use power when
it's not used, and can be made on regular silicon process
machinery. Expect it first in cell phones next year, and
then everywhere.
This doesn't just affect file storage and virtual memory.
It also changes the economics of cache and main memory,
and makes deployment of 64-bit CPUs more urgent. It also
makes system crashes much less tolerable, because turning
the computer off and on doesn't involve long shutdown and
boot procedures any more.
Slashdot Mirror
They are treading on thin ice. Take it up with your bank.
Hmm, Java.
Just go buy something.
And it runs NetBSD, too.
You're not paying attention. Lots of "systems like .NET
have been designed to solve" the problems. Those systems
always fail. The next person comes along and finds the
same problems, and says "I'm designing an RPC system...".
That's why we have so many.
Clue.
The problem with RPC is that, to be useful at all, it has to be used where the function-call abstraction fails. In inter-process communication and (more so) in network communications, there are too many failure modes that just don't fit that abstraction, but that a reliable application needs to handle anyway.
The whole point of RPC is supposed to be that the code invoking them looks just like regular function calls. To be reliable, though, they need to be decorated with so much error handling junk that any such benefit is usually lost. You're better off with explicit message passing and a documented wire protocol. You need the latter anyway to have a debuggable application.
At the trial the question came up whether in fact the reverse engineering involved was legal under Norwegian law. They called for opinions from Norwegian lawyers. The plaintiff trotted out a tame lawyer who asserted (without any support) that it was not legal. The defendant's lawyer said nothing in Norwegian law or case law supported any opinion one way or the other. The judge took that to mean that in fact it wasn't legal.
Now that it's established that in fact it was legal, Bunner et al. should be able to have the decision vacated. (Shame on that judge.)
Of greater moment is the choice of database library. PostgreSQL is enormously more complete and standard-compliant than MySQL, and (for years, now) faster, and is committed to the more liberal license that Bruce has demanded. MySQL (like KDE) is straight GPL in release 4.x, and lacks many important enterprise features.
Odd, isn't it, that we don't see flame wars over the database? Probably they will switch quietly to PostgreSQL once they get around to the matter, and nobody will make a fuss.
Of greater moment is the choice of MySQL vs. PostgreSQL. Similar license issues pertain, and the differences in fundamental capability are much greater.
Certainly the distinction is useful to security students and analysts, but it's misleading for everybody else. "Oh, that one's just a local exploit; not so bad." The OpenBSD advocates promote the fallacy: "only one remote exploit in this millennium!" (or something like that), encouraging us to ignore almost equally damaging exploits in non-core services that provide access to local accounts and more damaging attacks.
There's a similar fallacy in distinguishing security holes from other bugs. Without a depth of analysis that hardly anybody can ever afford, almost any bug might actually be a security hole, too. The OpenBSD people get this one right -- to them, any bug is a security hole until proven otherwise, and they encourage running latest versions -- but almost everybody else gets it wrong. When I fixed a double-free segfault in lib[mumble], nobody posted security warnings about every program that relies on it. despite that double-free bugs can often be exploited.
Debian gets this wrong, and very selectively backports only proven security holes, ignoring the myriad bugfixes that might just as easily be security holes as well. To find holes in stable-branch services, just look for bug fixes in later versions, particularly in libraries used by those services. Failing that, look at new features added shortly before the library-version used. Chances are the last new feature added has bugs that haven't been noted yet, and that might be exploitable.
This might be a good place to mention that the CVS codebase is almost irreparably insecure. The practical implications are: (1) A remotely-accessible CVS server should never be run on a host that does anything else that matters, or that has access to anything else; (2) An anonymous CVS server should never be the same CVS server that is used for checkins, or even run on the same machine. The pserver should be a slave that only gets read access to a copy of the archive. (3) Checkins on remotely-accessible servers should result in patches logged to another archive kept on another, not-remotely-accessible machine. Patches from that server should be posted to the mailing list.
Eclipse might yet become the first successful free Java program used by people not otherwise obliged to use Java. But I don't think 18K copies saturates the already-using-Java crowd.
Can somebody explain why this such a difficult concept?
Ogg. Ogg. Ogg. Not so hard.
Incidentally, I'll bet it doesn't play every kind of Ogg. I'll bet it plays only Ogg/Vorbis and (probably) Ogg/FLAC, but probably not Ogg/Speex, yet. In principle it could play Ogg/Theora, but the display's probably not up to the job -- Theora is a video compression format.
- A char* can be used to point to anything.
- You can write to one member of a union and
read from another."
Yes, a char* can point to anything. However, actually reading from uninitialized storage has undefined behavior. Writing a different member of a union doesn't count as initializing. Unions really cannot safely be used for type punning.Casting a pointer, as you say:
would be the correct way achieve that end (almost). The compiler would observe that the address of d had been taken, and not assume it was "dead" after the assignment. Then, i would get initialized via the pointer. No optimizer would damage such code. Note, though, that to be strictly defined (albeit not specified), i and the cast should be "unsigned int".With unions, though, all bets are off. If the Linux kernel has gaffes like that in it, it's no surprise that it breaks under newer compilers!
Sorry, that's totally false. (I hope you don't get paid for writing C like this!)
It doesn't just have "unspecified results", it is "undefined". The compiler is allowed to give you the second (or seventh!) byte of the double, but if you say -O3, you're asking it to generate the fastest code that is consistent with the standard. The fastest code, in this place, is to leave whatever is in that register already alone. If your code doesn't do what you wanted, then, it's because you didn't really say what you wanted.
This is a Good Thing. Running the Windows driver in a wrapper on Linux makes it much easier to reverse-engineer. Anything discovered that way is free of vendors' non-disclosure agreements. This applies to lots of drivers, and lots of manufacturers, not just Intel and Centrino.
I don't expect anyone to live the kind of life I want. I do expect the machines they own not to attack mine. If they do not do what is necessary, then it is not only the right, but the responsibility of others to make their machines stop. You like analogies: every vulnerable host is a rabid dog. Surely you will not argue that shooting a rabid dog that is attacking you is somehow immoral? How about a rabid dog that is has not yet begun attacking you and your children, but certainly will -- but you (or they) might not be armed when it does?
The only choices available are (1) to have an internet in which some hosts are able to operate normally (the secure ones) and (2) one in which none can. If no hosts can operate normally, because the insecure hosts have made it impossible, how is failing to take down the insecure hosts doing their owners any favors? The internet they would like to be connected to doesn't exist, because it's being destroyed by them and their like. No one is prevented from setting up a secure host -- that option is open to all. The only effective encouragement possible is for that option to be the only one that actually works for any length of time.
I don't recall suggesting to kill anybody. Anyhow, every vulnerable host, sooner or later, will be hijacked by a spammer, or worse. The owners typically neither know nor particularly care if their machines have been hijacked that way, so long as it doesn't interfere too much with their own surfing, e-mailing, or file-sharing. Their ISPs, if they are responsible, do care, but can do little.
There's a legal term for operating a vulnerable host on the 'net: it's an "attractive nuisance". In the absence of possible legal measures, removing such nuisances is the obligation of responsible citizens. Anybody operating a secure host will be unaffected, other than to welcome each incremental decrease in spam.
Nobody has an inherent right to keep a loaded cannon pointed at the town square where anybody might walk up and fire it. Responsible townsmen will pour concrete into any such cannon they find before, not after, the local hooligans come around to fire it. As it is, the local hooligans are firing them again and again, and the owners are generally doing nothing to stop it.
And no, I'm not a sysadmin, but lots of sysadmins agree with me, although they (as I) doubt they could participate in such an action themselves.
So, when we see the NSA not just adding key bits, but adding bits and then doubling them, we see evidence of countermeasures against quantum computers. This doesn't mean they have quantum computers. Remember that they are not just guarding secrets they transmit today against attack now, but against attack ten years from now, when revelation might still be damaging.
Once we all do have quantum computers, I wonder what amusing revelations will come from cracking old ciphertexts. You can bet the NSA will keep busy at it, and so will the Brits, and the French, and the Germans, and the Russians, and the Israelis. (No doubt a few of the biggest corporations go on that list too.)
It is tempting to think that simply closing off the known holes in the target machines should suffice. That's just wishful thinking. There will always be other ways for the spammers to enter, not yet discovered. The only way to keep the spammers out of those hosts is to wipe them clean. Eventually the owners will either leave them disconnected from the internet, or wiped, or will install something secure. Until then, they need to be wiped as many times as needed to get the message across.
This level of conflict was inevitable once the spammers encountered enough interference in their old methods. Now there's no going back. We need to ensure, positively, that any host that is connected to the net really is secure enough not to be hijacked by the spammers, and there's only one way to do that.
The only practical problem with this method is that the spammers have a vector available that anti-spammers don't. Spammers can put their viruses in their own spam, and booby-trap their own web pages referenced by their spam, but anti-spammers can't use those vectors without themselves spamming. Fortunately there are so many holes in the target systems that it will be some time before that difference actually protects the target hosts.
The Free competitors to iTRON are not RTLinux (and RTNetBSD) as the article (half fails to) point out. The competitors are eCos and RTEMS. The latter is clearly the more mature, but the former is arguably more modern in design. ECos hasn't the penetration that iTRON has achieved, but RTEMS is everywhere, and is equally invisible.
Suppose I wanted to buy a single-processor Alpha 67 or 7 or 79 motherboard or box. Can anybody post what would be the lowest price? HP makes it pretty hard to look up. TIA.
As I understand it, it's just an extension to the existing instruction set, with the same sort of prefix bytes that you see in the 8086->80386 16-bit->32-bit extensions, and convoluted ways to get to the extra registers. In other words, there's no "mode bit", so it can't be as clean as it might be, because it still supports all the old instructions in the same instruction stream.
Of course that's a job for another virus. While that might be seen as worse than the problem, I don't run anything susceptible to viruses. Do you? The trick is to exploit holes before the spammers do, but be careful not to harm the ISPs in the process by overloading their pipes. Once all vulnerable hosts have been wiped (and, perhaps, reloaded with something secure, but that's the owners' job -- get it wrong and get wiped again!) the spammers will have nothing to work with. Better yet, most of their customers' customers will be off the net too, solving the other half of the problem.
(By the way, all answers about spam filtering should be moderated into the toilet, as "off-topic".)
For the majority of readers who are not hackish, that means that having hacked it, you can make it do cool stuff that the original designers not only didn't think of, but never would have in a million years. It's even better if the next regular release does that stuff too.
This doesn't just affect file storage and virtual memory. It also changes the economics of cache and main memory, and makes deployment of 64-bit CPUs more urgent. It also makes system crashes much less tolerable, because turning the computer off and on doesn't involve long shutdown and boot procedures any more.