Yes, I've used it -- the link I provided to Typed Assembly Language is by the same folks. Cyclone is pretty cool; it's a lot less painful then writing in C (because static type checking helps you find bugs, and because it has neat new language features like regions), and a lot more secure. However, it's just a research compiler at this stage, and it produces pretty slow code.
Unless you're porting legacy C code, in my opinion it's better to start with a mature language that has mature compilers, like SML or O'Caml.
> Besides, high-level languages often do too much for use inside a kernel; like how do > you write a VMM? (Remember, you can't allocate any memory.)
I'm only (half-heartedly) advocating the use of high-level languages for writing components in a microkernel-style architecture. Those components can allocate memory, since they're just userland processes. (In fact, modules in the monolithic linux kernel can allocate memory, too. They just have to do it a different way.) Though I do believe it would be possible to make better programming languages for low-level system hacking, it would be pretty crazy to use high level languages right now for most of it.
> Assembler is still not type-safe. The type-checking is an intermediate language that > evaluates down to "real" x86 assembler, and unless Intel decides to make > some serious changes, the CPU is not going to make sure the value you're > incrementing is an integer.
I don't think you understand what it does. With Cornell TAL, there is a standard x86 binary (.o file) as well as files with typing annotations. A special loader loads the.o, disassembles, and checks it against the typing annotations -- if they match, then it runs the machine code directly on the hardware. You really do get all the benefits of type safety, and it really is actual machine code.
Well, it would be instantly more secure, the question is whether it would be instantly as functional.;)
I don't think it would take too long, though. I was able to rewrite my ftp daemon, getting almost full RFC functionality, in just a weekend by myself. I bet a month's worth of hacking by a team of talented programmers could pretty much polish off the common internet services.
"It's pretty cool, actually, since it makes compiler bugs MUCH more difficult to write because there is a piece of code (type-checker) checking the compiler's output."
By "get rid of C", I mean, get rid of C where it is inappropriate: application development. Yes, in UNIX it's pretty much impossible to get rid of C entirely, and that would be a dumb thing to try because C and UNIX are such good friends.
I don't use the JVM, I compile to native code when I want to use Java. It's a real mistake to think that all type-safe languages run in a virtual machine -- SML and O'Caml compilers for instance produce really fast and lean native code that is guaranteed not to crash. All of these have runtimes written in C, and a bug there could lead to an exploit (of course). However, empirical evidence suggests that exploitable compiler bugs are rare compared to application bugs. C programmers have to live with compiler bugs and application bugs, programmers in type-safe languages only have to live with compiler bugs. That sounds like a clear win to me!
You're probably just teasing me, but I don't think it would be so bad if we had a microkernel (probably written in C) with the option of writing certain OS services, like maybe the file system, in other languages. Some parts of the kernel really don't need hardware access, and might benefit from this method. But the kernel actually works pretty well, so I'm not complaining about that. I'm complaining about the wealth of broken C network servers that keep getting my office computer rooted.
By the way, I welcome you to check out typed assembly language: http://www.cs.cornell.edu/talc/. Of course, this is research software and isn't really appropriate yet for industrial use, but the technology exists. It's pretty cool, actually, since it makes compiler bugs
First, there are many Java compilers that compile to native code (ie, gcc) -- that's what I'd suggest, since virtual machines are pretty complicated (JIT compilation is especially prone to bugs) and don't perform so well.
The fact is that ALL compilers at some level need to produce unsafe code (except certifying compilers; check out http://www.cs.cornell.edu/talc/). C compilers, Java compilers, SML compilers. But the kinds of bugs that cause exploitable buffer overflows are not really easy to make in a compiler. Certainly a Java program is not subject to the "same level of risk in the buffer vulnerabilities", since these are errors in the application, not errors in C itself. (C just makes it easy to make those errors.) Anyway, even if compiler bugs are a threat to security, and I think a case could probably be made for that, we simply have only one trusted piece of code (the compiler), rather than hundreds. That's clearly a win to me.
So it's not so much avoiding anything written in C -- C is a pretty decent language for writing runtime software (garbage collectors, virtual machines), OS Kernels, device drivers, and embedded software. It's just inappropriate for constructing large software--especially security critical software--because it is difficult to keep from making exploitable mistakes. (I think that Bugtraq speaks for itself on this one!)
It seems like they are talking about failure tolerance, not insecurity.
However, if they are really trying to make a hack-proof version of linux, I maintain that a really good way to do this would be to get rid of C in the implementation of security-critical components (network servers, suid programs, etc.). If these components were written in a type-safe language (like O'Caml, SML, or Java), we'd instantly have a more sercure system. The code would also be a lot nicer to write and maintain!
One only needs to subscribe to Bugtraq for a while to realize that buffer-overflow style holes are not going to go away by sheer willpower. Machine-checked safety is an easy way around this, and it stuns me that people who want secure software don't simply use secure languages.
First, make the games. You'll probably find out it's a lot more work than it seems.
Then, try to convince people to play your games. In order to do that, you'll probably have to make them free to play (because you'll be competing with lots of other game sites, like mine that offer games for free).
Once you have a rabid following (!), then you can try to solve the problem that everyone else has on the internet: how to turn a popular site into a cash cow without alienating your audience.
I don't think Open Source or not will enter into it. What you need is users, not intellectual property.
Good luck! Personally, I suggest just doing it for fun.
Uh, Solaris needs just as careful an admin as a windows computer (especially right out of the box). Perhaps you missed the recent slew of rpc vulnerabilities?
It's probably true that a competent admin could lock down a Sun box better than a Windows one, but betting his reputation (job?) on it doesn't seem like a good wager...
Come on -- in order to be able to do the analysis, you need to understand how the algorithms work, and a great way to understand how they work is to implement them.
I'm a real theory weenie myself, but to say that CS courses are "not about learning to write... any code at all", especially INTRO courses, is totally retarded.
No, the no libraries policy is typically simple. If the assignment is about building a data structure (hash table, trie), it is not appropriate to use a library that implements that data structure for you, or allows you to do it without understanding what you're doing. There's no trick here, just common sense.
Nah, bubble sort is O(n^2). There are plenty of less efficient sorts, like:
- randomly permute the array and check if it's sorted; repeat (expected O((n+1)!))
- recursively sort first third, last third, then first third again (worse than n^2)
But, shame on you for falling for a troll. (And shame on me if I am being suckered as well!;))
I have a page with several popular GPL VST Plugins ("Destroy FX"). If someone were to port VSTGUI to linux, we'd definitely compile our stuff for linux users as well.
Yes indeed.
In fact, the "twiddling" that my program does isn't even always "circumvention", since circumvention only occurs when it is done without the authority of the copyright holder. I guess Royster should read the whole DMCA!
They define "effectively controls access" in the DMCA. It is not a judgment call based on the english word "effective". The definition is:
(B) a technological measure ''effectively controls access to a work'' if the measure, in the ordinary course of its operation, requires the application of information, or a process or a treatment, with the authority of the copyright owner, to gain access to the work.
I'd agree that the CD copy protection doesn't fit this definition either (in what sense does it require application of information/process/treatment?), but it has nothing to do with "how effective" the protection is.
Sorry, just sick of hearing this particular argument (I had it suggested to me many times in my own DMCA battle... I think that having the good guys understand the law is an important step.
> No, you should expect to get arrested (if you're a Russian national). The DMCA is a criminal statue, not a civil one.
I believe criminal penalties only apply if you sell the circumvention device, or circumvent for money. Check out 17 USC 1202 and 17 USC 1203.
> OK, I follow you here, but note that musicians usually do not usually own the copyright to "their" works.
What? Typically a musician who is not on a "major" label and who writes his own material owns the copyright to his work. If you don't think there are lots of these musicians, check out the bagillions on mp3.com, just for an example.
(However, I do agree that it is unlikely someone would want to license CD protection and then tell people that they are free to bypass it. Should these copy-protections become "standard" though, well, who knows...)
If it were me, I'd write circuit-simulator software and do it in simulation on the computer. Who wants to deal with burnt-out components and other perils of the real world? Plus, this way allows for lots more interesting experimentation, and you get to code up the ICs rather than using off-the-shelf components.
Uh, I wouldn't call perl the "swiss army knife of computer programming", maybe "swiss army knife of unix scripting" is more appropriate. There are LOTS of computer programming tasks that aren't at all easy in perl.
Actually, to call Mathematica the swiss army knife of Mathematics is also a bit of an overstatement; though it's great at matrices, calculus, and number theory, there are tons of branches of mathematics where it's pretty useless.
But anyway, you're right, Mathematica is a great tool. I wish there was an open source equivalent...
This is a stupid ass review. Guess what else, "The 6th day" was pretty crappy. So was "Jurassic Park 3". There's no use getting worked up about it, especially years after they've come out.
Also, if you want to write a review about how stupid something else is, you should be careful not to make blunders of your own, as (for instance) the editors pointed out in your summary.
Sounds like you are not going far enough... lives are at stake if this is code for a car, and handing a bunch of C hackers some guidelines is not going to cut it. In general, I think that when you require absolute correctness, software systems are just too complex to try to tackle by brute mindpower. I really believe that you need to develop automated systems for checking that code is correct -- or instance, I understand that BMW does model checking on their code to make sure that bad things can't happen (ie, deadlock).
Slashdot Mirror
Yes, I've used it -- the link I provided to Typed Assembly Language is by the same folks. Cyclone is pretty cool; it's a lot less painful then writing in C (because static type checking helps you find bugs, and because it has neat new language features like regions), and a lot more secure. However, it's just a research compiler at this stage, and it produces pretty slow code.
Unless you're porting legacy C code, in my opinion it's better to start with a mature language that has mature compilers, like SML or O'Caml.
> Besides, high-level languages often do too much for use inside a kernel; like how do
.o, disassembles, and checks it against the typing annotations -- if they match, then it runs the machine code directly on the hardware. You really do get all the benefits of type safety, and it really is actual machine code.
> you write a VMM? (Remember, you can't allocate any memory.)
I'm only (half-heartedly) advocating the use of high-level languages for writing components in a microkernel-style architecture. Those components can allocate memory, since they're just userland processes. (In fact, modules in the monolithic linux kernel can allocate memory, too. They just have to do it a different way.) Though I do believe it would be possible to make better programming languages for low-level system hacking, it would be pretty crazy to use high level languages right now for most of it.
> Assembler is still not type-safe. The type-checking is an intermediate language that
> evaluates down to "real" x86 assembler, and unless Intel decides to make
> some serious changes, the CPU is not going to make sure the value you're
> incrementing is an integer.
I don't think you understand what it does. With Cornell TAL, there is a standard x86 binary (.o file) as well as files with typing annotations. A special loader loads the
Well, it would be instantly more secure, the question is whether it would be instantly as functional. ;)
I don't think it would take too long, though. I was able to rewrite my ftp daemon, getting almost full RFC functionality, in just a weekend by myself. I bet a month's worth of hacking by a team of talented programmers could pretty much polish off the common internet services.
(I guess that'll teach me to write non-linearly!)
The post should end,
"It's pretty cool, actually, since it makes compiler bugs MUCH more difficult to write because there is a piece of code (type-checker) checking the compiler's output."
By "get rid of C", I mean, get rid of C where it is inappropriate: application development. Yes, in UNIX it's pretty much impossible to get rid of C entirely, and that would be a dumb thing to try because C and UNIX are such good friends.
I don't use the JVM, I compile to native code when I want to use Java. It's a real mistake to think that all type-safe languages run in a virtual machine -- SML and O'Caml compilers for instance produce really fast and lean native code that is guaranteed not to crash. All of these have runtimes written in C, and a bug there could lead to an exploit (of course). However, empirical evidence suggests that exploitable compiler bugs are rare compared to application bugs. C programmers have to live with compiler bugs and application bugs, programmers in type-safe languages only have to live with compiler bugs. That sounds like a clear win to me!
You're probably just teasing me, but I don't think it would be so bad if we had a microkernel (probably written in C) with the option of writing certain OS services, like maybe the file system, in other languages. Some parts of the kernel really don't need hardware access, and might benefit from this method. But the kernel actually works pretty well, so I'm not complaining about that. I'm complaining about the wealth of broken C network servers that keep getting my office computer rooted.
By the way, I welcome you to check out typed assembly language: http://www.cs.cornell.edu/talc/.
Of course, this is research software and isn't really appropriate yet for industrial use, but the technology exists. It's pretty cool, actually, since it makes compiler bugs
First, there are many Java compilers that compile to native code (ie, gcc) -- that's what I'd suggest, since virtual machines are pretty complicated (JIT compilation is especially prone to bugs) and don't perform so well.
The fact is that ALL compilers at some level need to produce unsafe code (except certifying compilers; check out http://www.cs.cornell.edu/talc/). C compilers, Java compilers, SML compilers. But the kinds of bugs that cause exploitable buffer overflows are not really easy to make in a compiler. Certainly a Java program is not subject to the "same level of risk in the buffer vulnerabilities", since these are errors in the application, not errors in C itself. (C just makes it easy to make those errors.) Anyway, even if compiler bugs are a threat to security, and I think a case could probably be made for that, we simply have only one trusted piece of code (the compiler), rather than hundreds. That's clearly a win to me.
So it's not so much avoiding anything written in C -- C is a pretty decent language for writing runtime software (garbage collectors, virtual machines), OS Kernels, device drivers, and embedded software. It's just inappropriate for constructing large software--especially security critical software--because it is difficult to keep from making exploitable mistakes. (I think that Bugtraq speaks for itself on this one!)
However, if they are really trying to make a hack-proof version of linux, I maintain that a really good way to do this would be to get rid of C in the implementation of security-critical components (network servers, suid programs, etc.). If these components were written in a type-safe language (like O'Caml, SML, or Java), we'd instantly have a more sercure system. The code would also be a lot nicer to write and maintain!
One only needs to subscribe to Bugtraq for a while to realize that buffer-overflow style holes are not going to go away by sheer willpower. Machine-checked safety is an easy way around this, and it stuns me that people who want secure software don't simply use secure languages.
Check out the 'ssh on win32' tutorial at sourceforge. That worked fine for me.
Thank you for Asking Slashdot!
Good luck! Personally, I suggest just doing it for fun.
These MS Paint jobs remind me of "all your base are belong to pyramatrix" or something...
Uh, Solaris needs just as careful an admin as a windows computer (especially right out of the box). Perhaps you missed the recent slew of rpc vulnerabilities?
It's probably true that a competent admin could lock down a Sun box better than a Windows one, but betting his reputation (job?) on it doesn't seem like a good wager...
Pushd and popd made my day when I learned about them. I now never use unix without 'em!
Come on -- in order to be able to do the analysis, you need to understand how the algorithms work, and a great way to understand how they work is to implement them.
... any code at all", especially INTRO courses, is totally retarded.
I'm a real theory weenie myself, but to say that CS courses are "not about learning to write
No, the no libraries policy is typically simple. If the assignment is about building a data structure (hash table, trie), it is not appropriate to use a library that implements that data structure for you, or allows you to do it without understanding what you're doing. There's no trick here, just common sense.
Nah, bubble sort is O(n^2).
;))
There are plenty of less efficient sorts, like:
- randomly permute the array and check if it's sorted; repeat (expected O((n+1)!))
- recursively sort first third, last third, then first third again (worse than n^2)
But, shame on you for falling for a troll. (And shame on me if I am being suckered as well!
VST is cross platform. The only obstacle to porting VST plugins to linux is the lack of a VST GUI lib (and of course the lack of VST hosts there!).
We've got some good, free VST plugins at Destroy FX (win32, os9, osx)...
I have a page with several popular GPL VST Plugins ("Destroy FX"). If someone were to port VSTGUI to linux, we'd definitely compile our stuff for linux users as well.
Yes indeed. In fact, the "twiddling" that my program does isn't even always "circumvention", since circumvention only occurs when it is done without the authority of the copyright holder. I guess Royster should read the whole DMCA!
(B) a technological measure ''effectively controls access to a work'' if the measure, in the ordinary course of its operation, requires the application of information, or a process or a treatment, with the authority of the copyright owner, to gain access to the work.
I'd agree that the CD copy protection doesn't fit this definition either (in what sense does it require application of information/process/treatment?), but it has nothing to do with "how effective" the protection is.
Sorry, just sick of hearing this particular argument (I had it suggested to me many times in my own DMCA battle ... I think that having the good guys understand the law is an important step.
> No, you should expect to get arrested (if you're a Russian national). The DMCA is a criminal statue, not a civil one.
I believe criminal penalties only apply if you sell the circumvention device, or circumvent for money. Check out 17 USC 1202 and 17 USC 1203.
> OK, I follow you here, but note that musicians usually do not usually own the copyright to "their" works.
What? Typically a musician who is not on a "major" label and who writes his own material owns the copyright to his work. If you don't think there are lots of these musicians, check out the bagillions on mp3.com, just for an example.
(However, I do agree that it is unlikely someone would want to license CD protection and then tell people that they are free to bypass it. Should these copy-protections become "standard" though, well, who knows...)
If it were me, I'd write circuit-simulator software and do it in simulation on the computer. Who wants to deal with burnt-out components and other perils of the real world? Plus, this way allows for lots more interesting experimentation, and you get to code up the ICs rather than using off-the-shelf components.
Uh, I wouldn't call perl the "swiss army knife of computer programming", maybe "swiss army knife of unix scripting" is more appropriate. There are LOTS of computer programming tasks that aren't at all easy in perl.
Actually, to call Mathematica the swiss army knife of Mathematics is also a bit of an overstatement; though it's great at matrices, calculus, and number theory, there are tons of branches of mathematics where it's pretty useless.
But anyway, you're right, Mathematica is a great tool. I wish there was an open source equivalent...
This is a stupid ass review. Guess what else, "The 6th day" was pretty crappy. So was "Jurassic Park 3". There's no use getting worked up about it, especially years after they've come out.
Also, if you want to write a review about how stupid something else is, you should be careful not to make blunders of your own, as (for instance) the editors pointed out in your summary.
Sounds like you are not going far enough... lives are at stake if this is code for a car, and handing a bunch of C hackers some guidelines is not going to cut it. In general, I think that when you require absolute correctness, software systems are just too complex to try to tackle by brute mindpower. I really believe that you need to develop automated systems for checking that code is correct -- or instance, I understand that BMW does model checking on their code to make sure that bad things can't happen (ie, deadlock).
Come on, if Blizzard is so bad for this lawsuit (and I agree that they are), then maybe slashdot shouldn't be posting free advertising for them.