Slashdot Mirror
Bill Joy's Takes on C#
f00zbll writes: "Cnet is running an article by Bill Joy on security and how it relates to C# and Microsoft at large. BJ quotes verbatim: 'C# provides the ability to write unsafe code. In unsafe code it is possible to declare and operate on pointers, to perform conversions between pointers and integral types, to take the address of variables, and so forth.'"
Sure, it'd be great (for Sun) for everybody to rewrite the world in Java, but in reality nobody can justify requiring 50% higher CPU usage in exchange for the ability to let programmers be careless.
I'm not saying Java is a bad thing at all, merely that C# isn't any worse than C, C++, perl or python. It's a shame when a press release manages to get linked from slashdot's main page, but that's all this is. Sorry Joy, but I'm not buying it.
You can use C# to write "Unsafe" code, but it's the runtime that ultimately decides whether or not to let it run. For example, if the VM that the browser creates tries to launch a C# app downloaded from the Internet, and it's "Unsafe", the CLR will refuse to run it.
Difference between C# and ActiveX in this case is that in ActiveX, everything is "Unsafe" and you either take it or leave it. In Java, of course, everything is "safe". C# can go either way.
I really hope that Microsoft simply makes it impossible to run "Unsafe" CLR code in the browser. Not even an option.
- Steve
This sounds like FUD. He didn't really post any examples about what kind of problems C# has for security, that would have been helpful.
.NET common language runtime?
I think a lot of people are upset because MS has actually come out with something that can compare with Java finally.. The ability to write unsafe (unmanaged is what that really means, meaning the garbage collector and built in memory management features of the CLR won't touch it) is an added bonus to Java.
I think the real question is- how secure is the
I still don't understand what's so evil about C#. If you don't want to use it, you don't have to. But personally, I find that not using C# leaves a sizable gap in several different keys, meaning a lot of stuff comes out just sounding wrong.
"What's so random about flipping a coin? Ever heard of the I Ching?"
There is no C-Flat. Occasionally it is written on a piece of music, but it refers to a B. Lowering a C half a step gives you a B-Natural. Someone suggested C-Double-Falt. That would be a B-Flat.
The reason for this is on the piano, the player needs to be able to look down and determine where their hands are based on the missing black keys between the notes B,C and F,E.
Although, calling C# "B" might be interesting. But then again, there was a language B by K&R that preceded C.
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
Pointers are pretty ubiquitous in C, and a large percentage of existing code is in C, but not 99%. Now, you can write good pointer code and bad pointer code just like anything else. To declare all code that uses pointers to be unsafe is bizarre. The danger with pointers is that you can get them pointing at weird places and get weird results. :)
Java (unless things have changed recently) does not use pointers. That, IMHO, is one of it's benefits, not because pointers make things unsafe, but because the code is easier to follow and understand.
Ben
C# does allow pointers and pointer manipulation. This is mostly for programmers seeking extra performance. Like a cast in Java, declaring code as "unsafe" is equivalent to saying to the VM, "Hey, I know what I'm doing." C# pointers are definitely not as liberal as C ones (just like casts in Java are not as liberal as casts in C).
For those sincerely seeking an intelligent discussion of pointers in the CLR, see Gough, J. "Compiling for the .NET Common Language Runtime (CLR)" Prentice Hall, NJ 2002.
Uhh, and the problem with this is ???????
.NET Visual Studio is written in C# itself , it should be pretty thouroughly debugged before its released.
All lll allow this, C3 may not be a lll but theyre trying to appeal to the uper end of that segment.
C# allows you to write managed, OR unmanaged code as well, This is an option. As well as the coders ability to write "unsafe" code. YOU MUST INTENTIONALLY flag the code to be written as UNSAFE !
If you dont know what you are doing and choose to do this so frigging what ???
C# has the fundementals of a good language, forget its from MS, if it where from GNU, you;d be eating it up saying look how much better it is. I am looking forward to working with it, the
Play with it for a week , if youre a beggining C programmer youll love it, if youre experienced, youll love it for the same reasons, My bet is most of the people bitching havent read or written a single line of C#, if have and dont like it Id like to know explicity WHY ?, Ms bashing aside.......
Sig went tro...aahemmm.....fishing........
A language can be both 'safe' and 'unsafe'. Take a look at Perl. You can do a lot of insecure things with it. But as soon as you launch with the -T switch, your script will run in a special mode. Values coming from an insecure source will be refused by potentially dangerous functions, unless you explicitely mangle them before the call. This is extremely powerful and prevents a lot of classical security flaws.
I don't know much about C#. But a taint mode for it would make the language pretty safe, despite the presence of pointers.
{{.sig}}
Guess that's why the sound was so obnoxious. C# kinda makes sense now, eh!
"History doesn't repeat itself, but it does rhyme." Mark Twain
There's been alot of controversy lately over security holes in programming languages. There is one language that has stood the test of time and proven to be the most secure language of all, with a record zero (0) reported security holes.
Here is the link if you want to learn more.
I Heart Sorting Networks
Yep, I think the guy's getting quite jealous of MS. Love or hate these people, the .net programming specification look very powerful, and coupled with the hard-as-nails win2k/xp combination, they will be quite hard to compete against.
.net services are basically going to be the same as before - just with a .net after them, and maybe re-written in C# now.
What Sun should really do is get off there behinds and match C# for features. From what I understand (not much admittedly), the Java VM just has to be extended to give it the breadth of additional languages that the CLI has (in terms of being able to use unsafe methods if the programmer wishes, so allowing C to work through it). The problem with Java has MS has the dominant desktop (and a good one it is now - really this is fact if you have to use them all day long), and they have the "standard" tools for programming. This will generate massive mindshare, and might get everyone from VB to C# (at least being "safe" might be good for programs knocked up at home).
On an unrelated topic, I think cloning the fundamentals of C# to a open-source basis is a very good idea. I might not agree how ximian are going about it, but at least the FSF has a parallel project that can bring the new language to the world - it could persuade casual safe programming, while allowing the breadth of accessing the OS directly.
When it comes to web services, I honestly can't see the difference between Java and C# (apart from the fact everyone will use C# as the MS-sponsored dominant language). It's all down to FUD: the
Java is great, but Bill Joy think he should go get it optimised - working faster, able to compete effectively with C#.
I stopped reading after this line:
-
"So Microsoft built ActiveX, a technique within Windows for automatically downloading and executing arbitrary programs"
Maybe Mr. Joy should read up some more:Anonymous posts are filtered.
The problem occurs when the programmer writes their code to work through that array using pointer / address arithmetic. Perhaps the programmer is one byte off in their math, but only on the 100th integer. That is, they read the 101st number.
Maybe the 100th number is 99% of the time 0, and 1% of the time is 1 (I know, I'm mixing my bits and bytes, but, bear with me, please). The 101st number is just some random value in RAM. It might be 0, or it might be 1. It might be used by some other structure, it might not be used. YOU DON'T KNOW. However, the bug will only show up in the event that you use the number, and that the number is different than you expected. Those two don't happen so often. Ergo -> Jane programmer spends two weeks of her life tracking down a random crash triggered by a function that relies on that last value being 0 based on certain preconditions.
This isn't about computers crashing, it's about memory error bugs. I once wrote a ray tracer which got the colors terribly wrong once the light sources got too bright. After some checking, it turns out my light values weren't being capped at 8 bits. They were overwriting into the adjacent byte, and screwing up color values for pixels near them. Oops. Things like that don't _ever_ happen in Java, say.
Obviously Bill Joy knows a lot more about this stuff than I do; but I think he, and many of Microsoft's critics as well as supporters, are missing a crucial piece of the puzzle.
/. posters have make comments to the effect that MS isn't capable of delivering technically. It used to be the conventional wisdom here, for example, that any MS OS was destined to crash repeatedly.
.NET and C# are technologies that predate this new ordering of MS's priorities, and that they probably won't be very secure. Passport, the most important .NET application yet written, coded by people who ought to know the technology best, has been hacked (and patched, it's only fair to point out). If MS's people don't write secure apps with .NET, are the low end VB coders the platform is designed for going to do a better job?
/., work for one of those companies.
Many of the features that have contributed to MS's insecurity were there not because MS's engineers were too dumb to think clearly about security, but because other people decided that there was an overriding business interest that the features would serve.
Specifically, these features usually tend to be part of the MS strategy of leveraging success in one sector into another. If you use office, it makes sense to choose VB as your scripting language. If you know VB, it makes sense to run IIS. That's why there's a VB interpreter inside every office app.
I think that what we've seen from MS is an official change in policy -- they're saying that business considerations now suggest that security should be the #1 priority. They're admitting that the market will punish them for security holes, and that they can't sacrifice security to establish leverage from one sector to another.
MS has always put business concerns over technical ones. For that reason, a lot of
It turned out that when MS saw Unix and Linux as a threat, and when they decided that reliability was one of the biggest advantages that Unix/Linux offered, they took reliability seriously and made enormous progress in a relatively short period of time. This suggest that Windows crashed not because MS *couldn't* make it reliable, but because it wasn't a *priority* for them to do so. As soon as they saw a change in the business climate on the edge of their radar screen, they changed their behavior.
Windows and its applications haven't been secure because MS hasn't felt it was worth making security a priority until now. There is no evidence that they couldn't cover a lot of ground very quickly in security if that's what they decided to do. And it seems as if they've decided to do just that.
I do agree that
But the problem that Sun faces is that MS has proven time and time again that they're willing to spend lots of money and go through lots of iterations to take a market. They're relentless. They usually don't get it right the first time, but they usually do get it right after four attempts or so.
I'll say something else that will probably get me modded down. After the recent flirtation between AOL and RedHat, I'm not sure that the moralistic arguments against MS hold up so well. Linux has been at the center of some pretty slimey stock swindles -- our gracious hosts, here at
Meanwhile, the Bill and Melinda Gates foundation is giving extraordinary sums of money to real nuts and bolts making the world a better place kinds of causes. Gates could literally turn out to be the most significant philanthropist in the history of the world. They're giving so much money that you can almost see a chunk of what you spend on MS going to a good cause.
All of which suggests to me that politics and the morality play that have always clouded the linux vs. windows debate should probably be put to rest.
Windows is horribly insecure -- viruses do incredible damage in the real world, especially among the least sophisticated users. That's not political, that's a fact.
But they're saying they're trying to clean up the mess. Sure, it's a big mess, and sure it's going to be a big job to clean it up. I give them credit for admitting it, and to taking on the task.
The key point here is memory safety, which C (and C#'s with the unsafe keyword) lack. In a language with memory safety, buffer overrun vulnerabilities and the like can't happen.
Typically, memory safety is tied to type safety. (But, memory safety really has nothing to do with pointers. For instance, SML/NJ allows pointers, but is memory safe, since the type system won't let you treat an integer as a pointer. In SML/NJ, the type system essentially provides you with a proof that your code is memory safe). So, if your code type checks, it *is* memory safe.
The two concepts are distinct, though. Java is memory safe, but you can break the type system with casting. So their is no *static* guarantee that your code is memory safe, but the VM includes runtime checks to make this a dynamic guarantee.
Really??? What gives you this idea? Java + VM is relatively equivalent to C# + CLR (as mentioned in my article that appeared on Slashdot a while ago). Code can be downloaded from the Internet and run just like with Java applets or RMI applications but this is far from the primary design of the platform .
Of all the people in the world I'd expect to criticize a technology without adequately reading up on it first, Bill Joy would have beemn one of the last I'd expect to do such a thing.
Bill Joy (and your post) go on and on about the vulnerability of network programming then ends with the reference to unsafe code which aims at giving the impression that downloaded
Since he's the only one who got the point, despite being an AC.
;)
:)
The whole point of a safe language is to prevent a program from accessing memory it shouldn't. This means not only buffer overruns, but the ability to fabricate a pointer itself. Which means that trusted code won't compromise security with a buffer overrun, and untrusted code can't get a pointer to anything it might want (like, say, a capability descriptor it doesn't own).
And the dynamic aspect is critical. Static guarantees are useless, because in the untrusted code case you weren't there to see it compile. But if you can run code from someone else, and be assured that the VM is going to prevent the program from doing anything it shouldn't, then running untrusted code becomes feasible.
Assuming you believe the VM itself can be trusted.
This is all from memory of a lecture I had in Adv. Op Sys almost 2 years ago, so take that as you will.
The enemies of Democracy are
...before unveiling its secret weapon in the language wars:
COBOL#!
Yes, with the power of COBOL# Sun will be able to monopolize the huge untapped market of legacy COBOL code that could be easily modified and brought up to cross-platform, bytecode standards.
Since there is so much more legacy COBOL code than C/C++ (75-80% of all existing code in businesses is still COBOL), Sun will one-up Microsoft, and along with Java will be able to win over developers with its advanced security features like a rigid sandbox and no direct memory manipulation.
Next up for Sun, Java++... it's rumored that Sun's pulling out all the stops with this one, and even including a full-fledged graphical developing environment with the J++DK, complete with an intelligent "Programming Assistant" that will warn you when you're writing unsafe code! Dancing Bill Joy or paper clip graphics optional.
Light a fire for a man and he'll be warm for a day. Light a man on fire and he'll be warm for the rest of his life.
So why couldn't executable code, like ActiveX or CORBA code, be sandboxed also? This should just require that the component be put into a restricted execution context, that perhaps has lower priveleges than the user's context. The component would operate like a GUEST user, and would not have access to the invoking user's priveleges and resources, like files, etc. This guest user could have it's own scheduling priorities and quotas for a subdirectory, and so on.
All the system calls, e.g. to DLL's or DSO's would be intercepted or remapped, or something like that, so that priveleges are checked and enforced, just like java does. Since modern CPU's can trap anything from illegal memory access to code or data, to illegal port access, it should be possible to fully isolate the code. Right?
Of course, the performance would be inferior because of the context switching between different privelege levels. But in a "safe" mode, this would be a fantastic way to run plugins for PDFs, Flash, a whole game, or some downloadable application.
I'm not a kernel expert, but I thought that mainframes could do this forever. What about Linux? e.g. with Wine?
BTW, this would also make peer-to-peer style distributed computation (like the SETI project) safe and still fast.
First off, I'm primarily a hardware engineer, who writes small programs in C or assembly that deal directly with hardware. So I use pointers and other "unsafe" code a lot; they are both extremely useful and extremely frustrating when it comes to debug time.
.exe or dozens of script-containing formats, it would let it run. Surely virus writers wouldn't be _dishonest_ and change the HTML tag so their .exe's would slip through...
Pointers let you use just about any arbitrary number as an address and poke data in there. The virtual memory system might block this on the grounds that you don't have a page at that address -- but not all computers have the hardware to do that, you can still do horrible things by writing to the wrong place in the pages you do own, and if the protection does block the misplaced write, the resulting invalid page error is not pretty from the user's point of view.
Pointers can be used safely -- if you program very well, like checking every address before you use it (which takes a hell of a lot of extra code), or checking the data going into the pointer calculations to ensure that no way could a wrong value come out (which assumes you didn't make any programming mistakes). And if it is a case of running downloaded code where there is a finite chance that the programmer is _maliciously_ misusing pointers, there is no way for the computer to analyze the code and detect this before you run it. Hence Microsoft's attempt to make internet and e-mail user friendly by automatically running any included executables spawned a plague of viruses, worms, and trojans...
C++ gives you the choice of traditional pointers or references. A "reference" is a sort of super-pointer that includes data on where valid targets must be, and gets checked for validity every time you use it. I don't do Java, but I am under the impression that it uses references only. That isn't enough in itself to prevent writing Java viruses, but it gives the OS a fighting chance of confining them to the sandbox...
OTOH, no computer is going to run entirely on "safe" code. At some level, the code has to read and write hardware registers. To do that, you take the numeric address of the register, and use that as a pointer. True, a good, secure OS would confine all such activities to drivers, which can only be installed by the administrator, who ought to know the difference between a driver and a trojan. But Microsoft doesn't write OS's like that -- NT/2000/XP is rather improved on DOS where direct writes to the video card were almost mandatory, but the security is still swiss cheese.
Incidentally, the original reason for C allowing all sorts of unsafe activities (pointers everywhere, strcpy with no length check, etc.) was performance. Checking the length of a string every time it was used took CPU cycles and RAM to hold the extra machine code. So the creators of C left it up to the programmer to shove in an if statement to check the length when the string was input, and to do the math and pop in another if statement anywhere it was possible for the string to grow too long. This was efficient, but puts quite a load on the programmer. About that time, I was running an 8 bit computer with 16K of RAM, clock speed under 1M, and all the accounting, class schedules, grade reports, etc. for a small college went through it. Efficiency was important! Now, who's going to notice whether the program runs in 1 millisecond or 2? It's better to be reliable. And it's necessary to get the program up and running pretty fast -- that's a lot easier if you don't have to worry about pointers going wild except when you do go to the hardware.
In C# apparently the programmer has the choice of using references and avoiding all "unsafe" code, or of declaring a module "unsafe" and programming any way that gets the job done. By making "unsafe" a PITA, they've encouraged programmers to avoid it except when absolutely necessary. I have a suspicion that once the coders get used to it, that will increase their productivity overall. In addition, it gives any tool that may run code from outside a quick way of determining whether the code was written to be safe or not. In theory...
I have serious doubts about whether that (being able to run "safe" C-sharp programs) will actually work. First off, won't a virus-writer be able to hack the tags that say "unsafe"? Second, ways to do unsafe things in "safe" code will be discovered. Third, if your OS has security like swiss cheese, no program is going to really be safe. Do e-mail viruses actually have to do anything that isn't allowed?
From what I've heard, Microsoft's idea of securing Outlook was to have it look at the HTML tag, and if it said executable pop up a warning which is incomprehensible to the people who are actually ignorant enough to get e-mail viruses. ('Yeah, it's from a trusted source. See the "From" line...') But if the HTML said "text", then it passed the attachment on to the Windows "open" command, which determines the type of the attachment by looking at the attachment, and if it was
Until that sort of thinking changes, giving people a way of tagging the programs "safe" or "unsafe" is just asking for trouble.
Actually, Fujitsu COBOL is part of the
I'm a 2000 man.
What a wonderful combination!
-- Alastair
Furthermore, C# isn't even going after the same market as Java. Java's security model primarily comes into play for applets and mobile code, but that's only a tiny fraction of all applications. C#'s purpose in life is to allow programmers to create desktop and server applications more easily. For that purpose, an easy and robust interface to native code (regular expression libraries, XML parsers, etc.) is much more important than security.
The major problem with C# isn't technical, the major problem is that there aren't any good implementations available yet (no, Microsoft's implementation isn't all that great yet) and that C# comes from Microsoft. But once there are C# implementations that are competitive with Java implementations and once C# has a life outside Microsoft, C# will be a serious threat to Java. And we may see a truly open source, efficient implementation of C# before we see one for Java.
For the time being, I still think Java is the more logical choice for open source applications. It may yet be a few years before competitive C# implementations and libraries come along. Sun still can keep their lead by innovating and extending the Java platform, cooperating with the open source community, and being honest about the strengths and limitations of the Java platform. But if Sun continues along their current course, they will lose sooner or later.
Java is safe because it is interpreted. Sure, it is compiled, but the compiled code doesn't run on hardware.
.NET code is interpreted, then they can make it safe. If they have a silly marker saying "This code is safe because it doesn't operate on memory directly", then that is just silly because some hacker can easily remove this marker.
If
Running code downloaded from the network, directly on your hardware, will always be somewhat dangerous. Of course that is what operating systems are for. However, there is always some way to figure out how to run malicious code in a privileged fashion.
"C++ gives you the choice of traditional pointers or references. A "reference" is a sort of super-pointer that includes data on where valid targets must be, and gets checked for validity every time you use it."
This is not true. C++ references are exactly like pointers, except that you cannot rebind them. With a pointer you can point it one place, then point it another. With a reference you have to define the place it points when you create it and you cannot move it later. So:
Foo& f = *(Foo*)0;
cout << f.someValue;
will still shoot you in the foot just as effectively as:
Foo* f = 0;
printf("%d", f.someValue);
OTOH, in Java, they call everything a reference, but it's really more like a C pointer except that there is no pointer arithmetic. Oh, and it *is* always checked. Try to use a null reference? Exception. Try to typecast a reference in an invalid way? Exception.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
.Net uses security exceptions, too. It's finer grained than Java (or ActiveX) and is managed by a security admin system local to the client. You maintain the security rules yourself, or your office "helpdesk" guys do it for you, but it's done locally.
.Net runtime, as something akin to a super-cookie. In this region, max file size, amount of allowed disk thrashing, etc. are all moderated by the .Net runtime.
It would be a very common thing for code to ask the runtime for permission to save a file automatically, and if permission is denied to then drop back and ask for a "safe file save" dialog box, which lets the user decide where to put the file and what to call it. The safe file save dialog doesn't even tell the app the name or location of the file that was saved. It just gives it a certificate for it, like having a valet park your car. The app doesn't know where it went, but if it wants it back, it can request it and have the contents only (not name or location) delivered back to it.
If even this is denied, then the app can save files in a walled-off section of the hard drive managed by the
Java has nothing like this, and Bill Joy is hardly likely to bring that to your attention.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
It's funny that everyone here is saying Sun is spewing FUD and joking about Slashdot being rigidly anti-MS. As far as I can see, almost everyone here is rigidly pro-Microsoft and eager to heap abuse on Java and praise on Brave Microsoft for making the "Genius" C# and .NET.
.NET is going to be asking your permission all the time. Let me tell you, I just spent the day with a secretary in a law office who was just wrapping her head around loading and saving documents. If her web browser asks her whether or not she "trusts" someone's code, she's going to just click a button at random no matter how many times I try to explain what to do.
.NET, without having ironclad and unequivocal guarantees - as Java can give you - you're setting yourself up to have another MS security disaster.
There's a tremendous amount of well-rated lies here about the article itself. It's really astounding in its volume - ranting on for pages about how Bill Joy is jealous, and C#'s pointers are totally safe, and Sun is making up lies about C#... "Insightful"! It's like some kind of geek guilt or something - we have to be hard on ourselves, and have a backlash against our backlash now?
I prefer to actually look at the objective truth on a given day. What's the article about? Joy is saying that C# doesn't force you to be safe. It lets you choose. And the problem is that if you let people choose to be unsafe, then they sometimes will be unsafe, because it's easier, or faster, or because they don't know any better.
Despite rampant misquoting here to the contrary, Joy wrote explicitly that he knows pointer-massaging code is marked "unsafe" in C#, and is recognized and treated differently by the CLR. It's right there in the article.
The point is that it just brings us back to square one security-wise - to ActiveX. Break out your digital signatures. Do you trust this code? Yes or no. If you want to run it, you better. Some of it might be "unsafe." Once you start flinging pointer arithmetic around, you can stand up and piss right over the sandbox wall.
So many choices. So much freedom.
Joy's point is that in the context of network computing, certain kinds of flexibility are dangerous and ultimately destructive.
I can just see all these rah-rah-C# people making the same kind of arguments I'm hearing about pointers for being able to do powerful word macros and having IE rendering emails. It's so powerful! "Just don't open any word documents from people you don't trust!" they say. Heh.
What we've learned is that we can't dump this security dillemma on the world under the guise of "choice." We've made that mistake (MS certainly has) over and over again, and the result is the same every time. For something like
We're on the road to Tycho.