Name: Anonymous 2013-09-14 20:42
Languages that run on a VM general.
Why do so many people hate Java and like Erlang?
Erlang is slooooooooow.
Why do so many people hate Java and like Erlang?
Erlang is slooooooooow.
The root of all vulnerabilities is the programmer (or in some cases the designer).Yes, and it's the programmer/designer's fault for using such a dangerous programming language.
one-size-fits-all solutionVM doesn't imply the code is secure, it just makes security vulnerabilities (intentional or not) easier to see.
Yes, and it's the programmer/designer's fault for using such a dangerous programming language.I mean how does one implement RSA in COBOL?
I mean how does one implement RSA in COBOL?I'll assume that by `COBOL' you means ``a high-level language''. The bignum library would be part of the things that get implemented using ``unsafe features'' for extra speed; or maybe not, if the language has some fast (obviously bounds-checked) buffer/array structure. What's your point?
and no hardware isolation required, dipshit. FreeBSD Jails are run as an application, and each jail has its own process.And how is process isolation achieved, dipshit?
If there's hardware bugs, nothing can be run in the machine, not even your stupid VM Design for just that language.Suppose you have a machine that has the f00f bug. Any ``native code'' application you run can trigger it and freeze the entire machine. However, I fucking dare you to trigger it using an interpreted or VMed language (assuming the VM doesn't trigger the bug itself or generate native code that triggers it). My point is that on a secure system, only the superuser should be able to run non-VMed code (and the superuser [i]really[/i] shouldn't use that privilege unless absolutely necessary).
>>5 already mentioned languages suited for nearly all general tasks, including working in a VM, and implementing one, both safe and fault tolerant.None of those languages are really ``dangerous'' from my point of view; to do ``pointer stuff'' in Scala or Scheme or CL you really need to go out of your way, and the languages are perfectly usable without ``escaping to hardware''. Can you say the same about C/C++ (I did that on purpose just because fuck you)?
I fucking dare you to trigger it using an interpreted or VMed language [u][b](assuming the VM doesn't trigger the bug itself or generate native code that triggers it).[/b][/u]Yeah, keep fucking up kid. What kind of fictional hardware bug can make the language specific VM work, but not another VM in the same server running the same processes as domain-specific VM in another language? If the are the same processes, the output will be the same, which includes errors. Circular fallacy 101.Can kids these days even do a little bit Gedankenexperiment? Or are they too brainwashed to conceptualize?
My point is that on a secure system, only the superuser should be able to run non-VMed code (and the superuser really shouldn't use that privilege unless absolutely necessary).Thanks for reteaching me what system administration is all about. Its sad that no *nix system has a wheel group to escalate privileges as superusers, or utilities to ch root directories of programs that run processes, to prevent them from affecting others. Sigh
Can you say the same about C/C++ (I did that on purpose just because fuck you)?Thanks for confirming your buttration. Good thing I brought those languages into the conversation as possible solutions to your requirement, so we can reiterate the point that VM or Jails need to be implemented on the OS, regardless of the language and the program. It's not like it's the fault of the system administrator for implementing non-robost practices, including the language of choice.
What exactly do you think my position is?Wild guess, Web app developer. Never programmed a kernel in his life. Never dealt with faulty hardware.
What kind of fictional hardware bug can make the language specific VM work, but not another VM in the same server running the same processes as domain-specific VM in another language? If the are the same processes, the output will be the same, which includes errors.What the fuck. You can easily trigger the f00f bug using a C compiler (or even just an assembler). You can't trigger it by feeding any kind of code and input to a brainfuck interpreter, though brainfuck is (theoretically) computationally as powerful as C (or assembly).
Thanks for confirming your buttration.Eat a bucket of diarrhoea.
Good thing I brought those languages into the conversation as possible solutions to your requirement, so we can reiterate the point that VM or Jails need to be implemented on the OS, regardless of the language and the program.Oh, so we agree. Do you also agree with the statement that the vast majority of code (including [b]all[/b] unprivileged code) running on a secure system should be interpreted bytecode or the direct compilation/translation (to machine code) of bytecode?
Wild guess, Web app developer. Never programmed a kernel in his life. Never dealt with faulty hardware.Wrong on all three counts. That bucket's getting cold.
You can easily trigger the f00f bug using a C compiler (or even just an assembler).Cool. The Jail prevented from spreading. Only the Jail keeps fucking up. Nothing to see here, than recode the program in the Jail.
Eat a bucket of diarrhoea.Thank you. I already eat my healthy mix of cereals, diarrhea lover. Ezekiel 4:9
should be interpreted bytecode or the direct compilation/translation (to machine code) of bytecode?Nope. My network packets don't need bytecode. My disk writes, don't need interpretation. My scheduling does not need compilation. They need strongly typed determined fault tolerant systems, not leaky execution.
Wrong on all three counts. That bucket's getting cold.Ah, so you do telephony system? That's cool. How have you been able to mitigate the recurrent PSTN issues?
Cool. The Jail prevented from spreading. Only the Jail keeps fucking up. Nothing to see here, than recode the program in the Jail.That particular bug happened to just freeze the machine. A similar hardware bug could also allow arbitrary poking of memory or even ring0 escalation.
Nope. My network packets don't need bytecode. My disk writes, don't need interpretation. My scheduling does not need compilation.And then when someone rapes your security using a buffer overflow in your IP stack or filesystem driver or even scheduler, don't come complai--
They need strongly typed determined fault tolerant systems,Unrelated. If someone writes a correctness proving system for C (despite the fact that the problem in the general case is halting-complete) and it produces a proper correctness certificate in a reasonable amount of time (perhaps prompting the user to add extra checks in the code), then the whole discussion about languages and security is pointless; you can replace ``C'' with any other language and it's just as ``secure'' since the proving system can be ported. At that point, you can run everything in ring0 with no process separation as long as you require programs to have correctness certificates that prove that they don't misbehave and they clean up after themselves. The problem then will be that the verifier is slow as fuck and the user gets tired of inserting seemingly superfluous checks in the code just to speed up verification. Since every language is as ``secure'' (thanks to the verifier) but C gives you the most pain in the ass with the verification process (in addition to being ugly as fuck), people would just opt to use more high level languages such as [b]LISP[/b].
not leaky execution.Are you the anti-GC faggot?
Ah, so you do telephony system? That's cool. How have you been able to mitigate the recurrent PSTN issues?Do you drop acid?
That particular bug happened to just freeze the machine. A similar hardware bug could also allow arbitrary poking of memory or even ring0 escalation.Oh kool, then your domain-specific VM didn't trigger it, because it did the same execution as the other language in Jail. How kool. Too bad the domain-spedific VM is not jailed, so it ran over my other processes's memory. The Jail just eat it allocated memory, and keeps tripping in it. Do your self a favor, and actually read the documentation:
hole discussion about languages and security is pointless; you can replace ``C'' with any other language and it's just as ``secure'' since the proving system can be ported.Ok, then implement for me a fail safe system write to a CD driver, if the driver just tripped on the CD, and does not know where it is writing in COBOL. Hard is in it? Is it because it does not I/O functions adapted for testing maps? Is it because a magic library for that has not been implemented? Or is it because it is near impossible to express it? COBOL was a domain specific language, so it cannot express it. Java is too. Erlang is ok, until they properly optimize the syntax, and the domain-specific VM. You are welcome to use Scala, >>5 did you that favor
The problem then will be that the verifier is slow as fuck and the user gets tired of inserting seemingly superfluous checks in the code just to speed up verification.What, you run your programs with out another output filter program? I assume you also run your system with no firewall too⸮My jail takes care of it not escaping, almost like a guest VM, but without the hardware virtualization.
but C gives you the most pain in the ass with the verification processAnd I brought C into the conversation, right⸮
Are you the anti-GC faggot?See >>5. [spoiler]My fav. GC, are those that I can limit as a please, and optimize as fuck. I hope your JVM can supply just that⸮[/spoiler]
Do you drop acid?Just milk. Sorry. At the least you do not work for a bank, that would be depressing. Mmmm, let me think. What kind of system requires Java, and may use Erlang. Mmm.
Erlang vs JavaIHBT
Erlang (the language) is somewhat decentsyntax is fucked up to the point of preventing of usage of certain language features. in particular anonymous functions.
Erlang is just a no-one-knows programming languageulike with js, a brain-dead php coder could learn erlang in just two weeks (that's not just a meme but also a truth)