| |||||||||||||
There are big difference...There are big difference...Posted Nov 17, 2011 23:08 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)In reply to: There are big difference... by khim Parent article: Interview with Andrew Tanenbaum (LinuxFr.org)
>Not really. 80386 included 275,000 transistors and already included all the components needed to handle segmented RAM. Security model was only minimally changed since then.
Come on. We've seen bugs in NX implementation, in cache coherency protocols, etc. A lot of them can be exploited for privilege escalation - remember the infamous F00F bug. I've personally seen a Javascript code that causes hardware errors on certain Intel CPUs.
>Bytecode verifier is not important. It's tiny piece of software and yes, it can be verified. What is important is JIT. Either you use simple JIT (or no JIT at all) - and lose all these nice benefits from fast switching because your system just runs slow - or you use complex, spaghetti-like, unverifiable pile of crap which makes your "security" wishfull thinking.
Nope. Both are possible.
The key to this is to design your VM to actually use instructions that are close to the real hardware instead of abstract stack machines. In this case you can directly verify the code that is going to be executed on the real hardware.
See here for more info: http://en.wikipedia.org/wiki/Typed_assembly_language
That's exactly what Azul guys do - they translate Java bytecode into their own instruction set. Then the _translated_ code is checked for correctness and uses hardware assists for features like memory allocation and bounds checking.
LISP machines were doing similar things long time ago, sure. So what?
(Log in to post comments)
There are big difference... Posted Nov 18, 2011 0:47 UTC (Fri) by khim (subscriber, #9252) [Link] Come on. We've seen bugs in NX implementation, in cache coherency protocols, etc. Sure. But this is question about frequency. Absolute security is not possible so we should expect problems from time to time. But how often the hardware bugs are detected in comparison to JVM or .NET bugs? A lot of them can be exploited for privilege escalation - remember the infamous F00F bug. Sure. I remember it well enough to know that it can not be used for privilege escalation. And it's "infamous" precisely because bugs of such magnitude are rare in CPUs. The key to this is to design your VM to actually use instructions that are close to the real hardware instead of abstract stack machines. In this case you can directly verify the code that is going to be executed on the real hardware. Why do you need that if you can just directly verify the machine code? E2k does this entirely on hardware level (with full ANSI C support), NaCl does it for x86 at machine code level (again with full ANSI C support but with coarser granularity and bigger speed loss). Then the _translated_ code is checked for correctness and uses hardware assists for features like memory allocation and bounds checking. That's certainly cool, but this has to do with all these pointless complications like JVM and managed code with a lot of restrictions? LISP machines were doing similar things long time ago, sure. So what? Well, the history repeats itself. First you create pointless complications (like LISP or Java) to do something on general-purpose hardware, then you find out that you can not achieve good performance without hardware support, at stage three you create said hardware support and the next step is to realize that if you have said hardware support then you don't need the complications which promised to solve the problem on the old hardware. Java is currently at stage three. If Azul guys are doing something similar to what E2K guys did (and I suspect this is what they actually do) then you can easily implement fast microkernel on top of that architecture without any need to have bytecode or "fully-managed system". This can certainly make sense if people worry about security. But this is as far from Microsoft Singularity as you can imagine.
There are big difference... Posted Nov 18, 2011 1:50 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
Well, I certainly agree that JVM or CLI bytecodes are not optimal to serve for system-level code.
But x86 isn't that good either, so a better machine-language code is needed. Then there's an absolute dependency on having a garbage collector. You can't have flat RAM, manual memory management and security at the same time (it's a 'choose any two' situation) because it's trivially easy to exploit dangling references.
Then you have to have mandatory boundary checks and limited pointer arithmetic.
So as a result you get something that looks a bit like Java or CLR from the logical point of view and much less like x86 machine code.
E2k doesn't really solve it (as someone who knows a few folks from MCST - E2k doesn't really solve ANYTHING). It has hardware tagging for pointers, so all pointer arithmetic instructions are privileged operations. That can be used as a hardware assist for low-level secure OS, but in itself it's certainly not enough.
And NaCl still relies on hardware memory protection to contain untrusted code, so it's just a clever way to implement lightweight virtualization on x86. Qemu or VMWare both do similar tricks as well.
So to recap this, I believe that a future OS is going to use software-enforced isolation. Probably aided by a more suitable hardware architecture than x86. It most probably won't use bytecode format of current virtual machines, but it would functionally similar to them.
This is partially true... Posted Nov 18, 2011 7:56 UTC (Fri) by khim (subscriber, #9252) [Link] But x86 isn't that good either, so a better machine-language code is needed. Why? Because you've said so? The only architecture which can realistically challenge x86 is ARM - and it's not all that better security-wise, it's just less power-hungry. Then there's an absolute dependency on having a garbage collector. Sorry, but no. Garbage collector is the very opossite from what's needed. History teaches us that again and again. LISP machines bet big on GC, Intel bet big on GC (remember iAPX 432?), others bet big on GC - all these bets failed. Intel had a fall-back plan in 8086 so Intel survived, but all these GC ideas were rightfully forgotten for 10 years. But then architecture astronauts found another victim to push it. It was "bigger success" because Sun just had more money to burn. Think about yet-another-big-bet-on-GC: Ada. It, too, was designed in times where "first GC push" happened. But Ada developers were not crazy enough to mandate garbage collector: they gave this right to impementers - and that's it. Ada may not be big on desktop today, yet it still used quite heavility where security is important. But guess what: no GC. In most impementations, at least. You can't have flat RAM, manual memory management and security at the same time (it's a 'choose any two' situation) because it's trivially easy to exploit dangling references. Right. But the only solution which works is "non-flat RAM" (it many forms). Because for security you need compartmentalization - and this implies non-flat memory model. GC is just not enough. If you have non-flat memory model then you don't need a GC. In fact it hurts security because it makes your design more complex for no good reason. Then you have to have mandatory boundary checks and limited pointer arithmetic. Not if you compartmentalized well enough. And since this is required anyway... E2k doesn't really solve it (as someone who knows a few folks from MCST - E2k doesn't really solve ANYTHING). It has hardware tagging for pointers, so all pointer arithmetic instructions are privileged operations. Not all. It's pointer includes memory address, size of region and offset in that region. This is enough for compartmentalization. That can be used as a hardware assist for low-level secure OS, but in itself it's certainly not enough. Sure, you still need to design you software carefully - even with hardware support. But to do that you need right principles. GC and managed code will not work because they bring complexity to the very piece which must be superuberrobust. And NaCl still relies on hardware memory protection to contain untrusted code It only relies on NX bit. And while yes, there were cases where NX bit was handled incorrectly in hardware they are much less common then errors in GC and JIT. So to recap this, I believe that a future OS is going to use software-enforced isolation. Probably aided by a more suitable hardware architecture than x86. It most probably won't use bytecode format of current virtual machines, but it would functionally similar to them. I'm pretty sure architecture astronauts will try to push something like this. They will find another suitable victim with billions to burn and we'll have yet another fiasco. Complete with grand promises, industry-wide madness and disappointment at the end. But they will need to wait about 10 years till they'll try that: people are fed up with astoronautics for the moment.
This is partially true... Posted Nov 18, 2011 8:14 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
>Sorry, but no. Garbage collector is the very opossite from what's needed.
You can't have a managed OS without GC (well, you can - but it's going to be pointless).
>History teaches us that again and again. LISP machines bet big on GC, Intel bet big on GC (remember iAPX 432?), others bet big on GC - all these bets failed.
You are using example that is at least 30 years old?!? That's insane. EVERYTHING has changed since then.
>Ada may not be big on desktop today, yet it still used quite heavility where security is important. But guess what: no GC. In most impementations, at least.
But then there's .NET and Java, Python and Perl, Erlang and Haskell and even JavaScript. All of them use GC. All of them are used much more widely than ADA.
>Right. But the only solution which works is "non-flat RAM" (it many forms). Because for security you need compartmentalization - and this implies non-flat memory model. GC is just not enough. If you have non-flat memory model then you don't need a GC. In fact it hurts security because it makes your design more complex for no good reason.
Nope. You clearly don't know what you're talking about. Flat-memory Singularity-like OSes implement (essentially) capability-based security - which is the only proven security model, btw. Each object reference is a capability, processes can exchange them using pipes and so on.
The crucial part is impossibility to forge a capability which can be done easily without a GC. Like this: create an object, get a pointer to it, remove an object (pointer becomes dangling), create an object of another type in its place, use your dangling pointer to manipulate private data of another object.
However, once you have a GC and safe language - you don't need memory protection.
>Not all. It's pointer includes memory address, size of region and offset in that region. This is enough for compartmentalization.
Not enough. See my scenario with a dangling reference.
>I'm pretty sure architecture astronauts will try to push something like this. They will find another suitable victim with billions to burn and we'll have yet another fiasco. Complete with grand promises, industry-wide madness and disappointment at the end. But they will need to wait about 10 years till they'll try that: people are fed up with astoronautics for the moment.
Dude, Azul _already_ sells machines that work like this. And they routinely outperform top-of-the-line POWER (and x86) servers on tasks that require management of LARGE amounts of data. I know a Wall Street company that had rewritten their insanely tuned C++ HFT (High Frequency Trading) code into Java running on Azul system - and got great speedups.
So the future is here, it's only unevenly distributed.
The transition to secure systems won't happen overnight, it'll probably happen in 20-30 years after the Great Permanent Crash event of 2015 when a virus bricks half of Linux-based routers in the world and causes massive outages.
This is partially true... Posted Nov 18, 2011 9:04 UTC (Fri) by khim (subscriber, #9252) [Link] But then there's .NET and Java, Python and Perl, Erlang and Haskell and even JavaScript. All of them use GC. All of them are used much more widely than ADA. Sure. Where you need to ship this beast yesterday - and we can fix bugs later GC-based languages rule. They are good for that. Where military-grade security is required? Not so much. Flat-memory Singularity-like OSes implement (essentially) capability-based security - which is the only proven security model, btw. Sure, but they it at the wrong level. You don't need capabilities on the level of objects. You need capabilities at the level of compartmentalized components. However, once you have a GC and safe language - you don't need memory protection. I'll use you own words against you: memory protection is the only proven security model. GC and safe languages produced only failures so far (security-wise, they are good for some other things). Not enough. See my scenario with a dangling reference. Your scenario assumes flat memory model and the ability to pass pointers from one process to the other. This problem is trivially solveable by simple additional rule: no pointers in shared memory region. Most programs are ready to cope with this limitation anyway so it's not a big problem compatibility-wise. Dude, Azul _already_ sells machines that work like this. Sure. We are at stage 3 (where yoy try to patch the mess you've created in first two stages by introducing specialized hardware). This hardware is highly-specialized so of course it's good for some specialized tasks. java has nothing to do with it - it's just used as buzzword to sell said hardware. And they routinely outperform top-of-the-line POWER (and x86) servers on tasks that require management of LARGE amounts of data. Hmm... How many of them are in Top500 list? I know a Wall Street company that had rewritten their insanely tuned C++ HFT (High Frequency Trading) code into Java running on Azul system - and got great speedups. LISP machines also outperformed general purpose computers back in the day. For some tasks, that is. When HFT will die Azul systems will die with them - it's only matter of time. The transition to secure systems won't happen overnight, it'll probably happen in 20-30 years after the Great Permanent Crash event of 2015 when a virus bricks half of Linux-based routers in the world and causes massive outages. Well, aliens can do something like this, sure - I just don't know why you think aliens will do it in 2015 and not before or after. Human parasites which write viruses... well, they are not interested in killing the host.
This is partially true... Posted Nov 18, 2011 18:13 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
>Sure. Where you need to ship this beast yesterday - and we can fix bugs later GC-based languages rule. They are good for that. Where military-grade security is required? Not so much.
And bugs in unmanaged languages are more of: "Who cares if it explodes? We have deadlines to meet!" And speaking of military-grade security, LISP and Java are used by NASA on satellites.
>Sure, but they it at the wrong level. You don't need capabilities on the level of objects. You need capabilities at the level of compartmentalized components.
Then you instantly have a problem how to keep compartments. We've failed spectacularly at this regard, I don't think one can find half a year when Linux had not been vulnerable to local security exploits.
>I'll use you own words against you: memory protection is the only proven security model. GC and safe languages produced only failures so far (security-wise, they are good for some other things).
"Proven" in the sense of "formally proven". And no, memory protection has failed miserably as witnessed by the current torrent of vulnerabilities.
>Hmm... How many of them are in Top500 list?
Top500 is not representative of all the tasks. Its benchmark basically test the speed of your interconnections for mostly-parallel tasks. Azul hardware is geared towards realtime (trading is fast!) and data-intensive tasks which traditional supercomputers suck at.
>LISP machines also outperformed general purpose computers back in the day. For some tasks, that is. When HFT will die Azul systems will die with them - it's only matter of time.
So? You argument boils down to "we've tried this 30 years before and it hadn't worked then, so it would never work at all!"
There were graphic accelerators back then for performing specialized rendering (like sprite animation) and by 90-s they all but disappeared from most of the hardware since software rendering became fast enough. Does it mean that we don't need GPUs since "they've been tried and failed"?
Nope, the current generation of GPUs are light-years ahead of simple accelerated sprite output. So is the current generation of GCs - Azul has _pauseless_ GC (and it really is) which has never been achieved in practice before.
>Well, aliens can do something like this, sure - I just don't know why you think aliens will do it in 2015 and not before or after. Human parasites which write viruses... well, they are not interested in killing the host.
Hello? Have you heard about SQL Slammer? Or maybe the original Morris worm? Or about those terrorists insisting on bringing down the Western world?
I believe that Linux right now has at least several undiscovered remotely-exploitable vulnerabilities. I don't doubt that they can be used to bring down the Internet and cause massive havoc.
This is partially true... Posted Nov 18, 2011 21:17 UTC (Fri) by khim (subscriber, #9252) [Link] And speaking of military-grade security, LISP and Java are used by NASA on satellites. On LISP and Java machines? Care to share a link? I have nothing against LISP, Haskel, Java and other such languages. If they are used where it makes sense... why not. But this hysteria where LISP (long ago) and Java (in last 10-15 years) was supposed to replace everything down to OS and hardware - this is just crazy. We've failed spectacularly at this regard, I don't think one can find half a year when Linux had not been vulnerable to local security exploits. Sure. But the same can be said about JVM and CLR - and they don't even try to offer full capabilities of full-blown OS! And no, memory protection has failed miserably as witnessed by the current torrent of vulnerabilities. This is, again, is the case where theory and practice are not the same. In theory we have these nice articles which claim that managed code should rule them all. And we have these scary intrusion reports. But we also have facts: the most common vehicle for intrusions is JVM - and CLR are only behind because Silverlight is less pervasive then Java plugin. As the saying goes: memory protection is the worst form of security... except all the others that have been tried. Azul hardware is geared towards realtime (trading is fast!) and data-intensive tasks which traditional supercomputers suck at. Sorry, but no cigar. Traditional supercomputers excels on these tasks. The only problem: these beasts were so expensive most researches dropped them and learned to use much "worse" architecture to do real work. Thus now Top500 is dominated by "commodity hardware with a small twist" systems and traditional supercomputers are displayed in museums. Azul tried to compete with commodity hardware for a time, but... now it, too, offers it's goodies in Linux for x86 version. This is beginning of the end for that saga, I believe. So? You argument boils down to "we've tried this 30 years before and it hadn't worked then, so it would never work at all!" Yes. This rule is not 100% bullet-proof, but it's pretty good rule of thumb. One example where this rule want me astray: I was convinced for a time that people will never manage to write a compiler which can eliminate all that bloat in STL for that reason - but compiler developers managed to do that.. well, almost. It took over 10 years, but they did that. This is great achievement and notable counter-example. Notable exactly because it's so extremely rare. There were graphic accelerators back then for performing specialized rendering (like sprite animation) and by 90-s they all but disappeared from most of the hardware since software rendering became fast enough. Sorry, but you, again, are rewriting history. PC had no graphic acceleration initially. It got it in 1991 (with S3 86C911) and kept it ever since. Sure, today we don't have 2D acceleration in hardware - but that's because 3D units can emulate is quite efficiently. LISP machines, on the other hand, disappeared completely. Azul understands this much better then you - that's why it switches to x86, Linux and commodity hardware. I'm pretty sure it'll sell it's expensive hardware packages till people will be willing to pay for them, but there are no doubt that eventually it'll be pure software company. Does it mean that we don't need GPUs since "they've been tried and failed"? On the contrary: they've been tried and survived when the host platforms (workstation and LISP Machines) folded, they've just migrated to PC when PC killed these hosts - this means they are here to stay. So is the current generation of GCs - Azul has _pauseless_ GC (and it really is) which has never been achieved in practice before. Sure, but what this has to do with OS design? You don't need GC at all so the fact that you create cool GC does not really change anything. It's still complicated piece of software which should not be in (micro?)kernel if want to create secure OS. Hello? Have you heard about SQL Slammer? Or maybe the original Morris worm? Or about those terrorists insisting on bringing down the Western world? Yeah, I've seen and heard tales. Sure, some hiccups happened, but somehow the only country where cyberwar managed to destroy significant value is Iran - which kinda makes it all less scary then you want to imply. I believe that Linux right now has at least several undiscovered remotely-exploitable vulnerabilities. I don't doubt that they can be used to bring down the Internet and cause massive havoc. Probably - but where is the profit in that? Why will anyone pay for such work? That's the question. Actually what you are preaching already happened in a sense - and nobody noticed. The funny thing is that while yes, Linux routers were infected (among other computers), yet attackers had no need for kernel vulnerabilities. Not at all. They just used well-known usernames and password (admin/admin and the like) - and it was enough. With this state of security on the Internet talks about microkernels and Singularity are... well, premature - don't you think?
This is partially true... Posted Nov 18, 2011 23:34 UTC (Fri) by pboddie (subscriber, #50784) [Link] On LISP and Java machines? Care to share a link? Lisp advocates were always talking about NASA making hot-fixes on space probes - it was surely one of Paul Graham's standard dinner party stories - and as everyone else started to use other languages, such tales of past glory appeared to be the only comfort to the community. There were graphic accelerators back then for performing specialized rendering (like sprite animation) and by 90-s they all but disappeared from most of the hardware since software rendering became fast enough.Sorry, but you, again, are rewriting history. PC had no graphic acceleration initially. No, the history goes back a bit more than the PC as you know it. Various microcomputers had dedicated sprite hardware, which is hardly a surprise given that as video circuitry became more sophisticated, it made sense to solve various common problems in hardware instead of having the CPU blit sprites to the display buffer. Eventually, CPUs became powerful enough to be able to dedicate some of their time to blitting and have enough time left over to do other things, and since some of the special video architectures were actively obstructive to other tasks, they were given the push.
This is partially true... Posted Nov 20, 2011 6:30 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
>On LISP and Java machines? Care to share a link?
Paul Graham wrote about usage of LISP in NASA. For Java see http://javapathfinder.sourceforge.net/ - that's a framework for formal verification of Java programs. I don't have a link about its usage on spacecrafts, unfortunately.
Oh, and Spirit and Opportunity rovers use vxWorks without any memory protection (it's available in vxWorks but is rarely used).
>Sure. But the same can be said about JVM and CLR - and they don't even try to offer full capabilities of full-blown OS!
Mostly because they are implemented in unmanaged languages and try to do a lot of work that should be done in hardware. Which as you've said is subject to economy of scale and designed by hordes of Intel engineers.
>As the saying goes: memory protection is the worst form of security... except all the others that have been tried.
So how come memory protection can't protect us from flaws in JVM/CLR/Flash?
>Sorry, but no cigar. Traditional supercomputers excels on these tasks. The only problem: these beasts were so expensive most researches dropped them and learned to use much "worse" architecture to do real work.
Well, OK. But still, traders have a requirement to access A LOT of data with the least possible latency. That requires an architecture that is ill-suited for modern [super]computers.
But we might be moving in that direction even with the general-purpose computers. It's quite possible that in 10 years we're going to have practical phase-change non-volatile RAM which is going to make Linux and other traditional OSes obsolete. That's another reason why I find managed OSes interesting.
>Sorry, but you, again, are rewriting history. PC had no graphic acceleration initially. It got it in 1991 (with S3 86C911) and kept it ever since. Sure, today we don't have 2D acceleration in hardware - but that's because 3D units can emulate is quite efficiently.
Commodore 64 and the original Apple Mac had it, though. As well as tons of other architectures. If you read history, X11 server was first designed for a machine with full graphic acceleration (it had hardware vector drawing primitives, hardware mouse cursor, etc.) and then ported to a machine with a dumb framebuffer.
And yet we've had a resurgence of graphics accelerators once it became clear that CPUs are not up to speed with graphics.
>Yeah, I've seen and heard tales. Sure, some hiccups happened, but somehow the only country where cyberwar managed to destroy significant value is Iran - which kinda makes it all less scary then you want to imply.
SQL Slammer was a walk in the park. It has only infected several tens of thousands of machines and yet it managed to bring down the networks of the whole countries. Several millions of infected routers can kill the whole Internet for a period of time.
Just imagine - a new worm starts infecting routers making them slam the network with continuous scans at full speed. In minutes you can get millions of routers infected. Such a scenario is unlikely, but is certainly possible. Especially since routers' hardware is slowly converging to just several platforms.
Still more nonsense... Posted Nov 20, 2011 9:09 UTC (Sun) by khim (subscriber, #9252) [Link] So how come memory protection can't protect us from flaws in JVM/CLR/Flash? Because they don't use it? They foolishly believed your tales (that managed code can save us all) and thus neglected compartmentalization via MMU. When browser developers stopped believing this tale and started using memory protection.... well, Chrome is left standing for last 3 years in pwn2own and Firefox was unbroken after it did similar switch. Sure, memory protection is not perfect, I'm pretty sure eventually Chrome will be broken (contestants could have used recent Windows UDP vulnerability to break any Windows system, after all), but so far it works much, much better then "formally proved" managed code approach. I will repeat again: >As the saying goes: memory protection is the worst form of security... except all the others that have been tried. Memory protection is not perfect. In fact it's awful in many respects. It's just better then anything else out there - and that's it. And yet we've had a resurgence of graphics accelerators once it became clear that CPUs are not up to speed with graphics. They were never lost. We have systems without graphics accelerator today and we always had systems with graphics accelerator for the last 30 years. It was just matter of choice: Nintendo happily sold systems with sprite acceleration in a time when Apple decided to ditch it. And PC kept it when NEXTStep thrown away it's own acceleration when it was ported to Mac to become MacOS X. Not at all like LISP or Java machines which were produced for a few years in small quantities, never reached mainstream and then were lost and forgotten. Just imagine - a new worm starts infecting routers making them slam the network with continuous scans at full speed. In minutes you can get millions of routers infected. Such a scenario is unlikely, but is certainly possible. Especially since routers' hardware is slowly converging to just several platforms. Cui prodest? You had the ability to do something similar for years using Windows computers (it certainly have similar number of vulnerabilities to what you have in routers - and it's the same image on hundred of millions systems) - yet nothing happened. The same is true for routers (as I've said you don't even need to search for vulnerabilities). Such attacks must be organized by someone - and it's not easy to organize such a "perfect storm" attack. Unless carefully orchestrated it'll clog the pipes from the region where it will be started and people from outside will be able to contain the problem. If you can not explain why this attack is more likely in two years it's just fairy tale. Please don't talk about rise in cyberhostility: it's true that people are inventing more sophisticated things and money involved in this part of the underworld is quite significant, but all these changes are pointing to more stealthy attacks, not more flashy ones. Parasite is not interested in killing the host!
Still more nonsense... Posted Nov 21, 2011 4:30 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
Oh, Chrome has been broken multiple times.
http://www.zdnet.com/blog/hardware/google-chrome-pwned-on... - this is a complete pwnage.
'Page local' exploits are even more numerous.
So your best case shows that MEMORY PROTECTION WITH UNMANAGED LANGUAGES IS NOT SECURE and can not be made so with any rational amount of investment. There are literally no large enough unmanaged systems without buffer exploit vulnerabilities.
Define large enough... Posted Nov 21, 2011 7:34 UTC (Mon) by khim (subscriber, #9252) [Link] There are literally no large enough unmanaged systems without buffer exploit vulnerabilities. And the same is true for managed systems. But security is not binary. Number of successful exploits against JVM and .NET dwarfs the number of successful exploits against memory-managed systems. So your best case shows that MEMORY PROTECTION WITH UNMANAGED LANGUAGES IS NOT SECURE No, my best case shows that you can make it secure enough that break-ins will make the news. JVM and .NET-based break-ins are just accepted as "fact of life", even if they make the news they are reported as "oh, well, yet another vulnerability is found and fixed in XXX product". Often they don't make the news at all. If your idea of improving security is to replace poorly behaving system with utterly broken system then I'm glad you are not working here.
Define large enough... Posted Nov 21, 2011 7:49 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
Yup. Most (note this!) current implementations of VMs are written in unreliable unmanaged languages so they are not secure. And I wouldn't expect them to be.
To have a secure system you need your hardware to enforce safety. That can be done with the help of architectures with TAL (Typed Assembly Languages) which Azul system essentially is.
In this way you can build the system using safe languages from ground up. And small unsafe parts can be audited to hell and back.
Ah, that again... Posted Nov 21, 2011 8:21 UTC (Mon) by khim (subscriber, #9252) [Link] To have a secure system you need your hardware to enforce safety. That can be done with the help of architectures with TAL (Typed Assembly Languages) which Azul system essentially is. Well, Azul hardware systems will be interesting exhibits in Computer History Museum (next to Intel iAPX 432 and LISP machines), I'll grant you that, but I fail to see how these museum pieces are relevant to the discussion.
Still more nonsense... Posted Dec 5, 2011 19:07 UTC (Mon) by cmccabe (guest, #60281) [Link]
It looks like that bug was not a Chrome bug, but an Adobe Flash bug.
See http://www.reddit.com/r/netsec/comments/h9vax/is_the_vupe...
> "As usual, security journalists don't bother to fact check. VUPEN
This is partially true... Posted Nov 19, 2011 7:12 UTC (Sat) by cmccabe (guest, #60281) [Link]
Programming language zealot checklist
* The magic programming language being advocated is more than 15 years old. +1. Java was released in 1995.
* Prophecy of imminent doom for unbelievers
* The poster doesn't understand or is a novice at the programming language being advocated
* The poster advocates garbage collection in kernel space
* The poster makes ad hominem attacks
* The magic programming language is revealed to "faster than C" because of a microbenchmark, apocryphal story, or thought experiment.
Someone should tell IBM to stop making all those mainframes that suck at data-intensive tasks. Make the good ones, instead, please!
Your score is 4 out of a possible 6. Play again?
This is partially true... Posted Nov 19, 2011 7:26 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
>Programming language zealot checklist
Me? Nope.
>The magic programming language being advocated is more than 15 years old.
I'm not advocating Java (or C#), you misunderstand me. I'm advocating the 'safe' languages and software-based isolation in general. The list of safe languages includes but is not limited to: Haskell, Python, Perl, JS, subsets of C++ and C, Cyclone, Ocaml, Java, C# and so on.
>+1. And we even got a specific date, 2015!
For dramatic effect only. But it's not impossible.
>The poster advocates garbage collection in kernel space
Nope, I'm advocating abolishing kernel space altogether.
>For the apocryphal story about the high frequency trading platform and the revelation that Top500 is a meaningless benchmark. Also the fun revelation that the magic language is good at "realtime... and data-intensive tasks which traditional supercomputers suck at."
Yep. And I'm totally correct and you are totally wrong. Supercomputers suck at HFT tasks and IBM mainframes has never been particularly _fast_ (they are usually characterized as 'reliable').
>Your score is 4 out of a possible 6. Play again?
Read the thread again and then come back.
This is partially true... Posted Nov 19, 2011 21:50 UTC (Sat) by cmccabe (guest, #60281) [Link]
You are amazingly naive. People are still hacking COBOL, Fortran and PL/I code that was written 30 or 40 years ago. There are obvious and huge advantages to replacing these legacy systems, but nobody ever does, because why fix what isn't "broken"?
No matter how advanced your technology is, systems can never be 100% secure because of the monkey in front of the keyboard. Think idiots who use "123" as a password, put their password on a sticky note, respond to emails from Nigeria, etc. Or simple black hats abusing their access. Even if systems could be made 100% secure, nobody in the software industry has an economic incentive to do so. A lot of vendors charge for bug fixes and support. Microsoft makes money off antivirus software.
Your current fixation is on Lisp Machines. But really, hardware versus software is irrelevant. Either hardware or software could be constructed to be provably correct. Nobody ever does, except for things like elevator control hardware where it really is necessary.
General-purpose hardware always tends to win in the end, because the hardware business is a volume game. The more you ship, the cheaper it is. Your custom, one-of-a-kind Erlang machine might be beautifully designed, but Intel has armies of physicists working on shrinking transistors, and massive economies of scale. Arguably, microprocessors are one of the most advanced technologies the world has ever seen, but due to economies of scale, you can buy one for cheaper than the price of a fancy haircut. Think about that. You're not going to win this battle writing transistor diagrams on a napkin in your basement. Why don't you read about the original Lisp Machines. Or Intel's CPU that executed Ada directly.
If you have a lot of data, what you need to do is build a Hadoop cluster, not pay through the nose for some proprietary hardware. You can even do it without writing a line of unmanaged code.
In 2015, there will be more application developers using managed languages. There will also be more people writing drivers in C, and creating hardware using Verilog or VHDL. And there will be another crop of idealistic college students ready to believe that the world will convert to Scheme or Prolog in 3 years.
Provably correct hardware not possible Posted Nov 21, 2011 21:21 UTC (Mon) by jhhaller (subscriber, #56103) [Link]
While it is possible to have a provably correct hardware design, it is impossible to build hardware which always matches the provably correct design. The design is likely to be based on digital circuits, while the implementation is based on analog circuits made from imperfect materials subject to environmental conditions ranging from cosmic rays to more mundane things like electromigration, thermal stress, and analog artifacts like reflections on transmission lines. What can be designed is something that works like the design most of the time, with deviations detected most of the time. This makes it impossible to depend on provably correct software, which depends on provably correct hardware, which doesn't exist. Some of the deviations may be common to an entire production run, which can be exploited, while others are more random, and the random ones are more difficult to purposefully exploit.
Provably correct hardware not possible Posted Nov 21, 2011 23:54 UTC (Mon) by cmccabe (guest, #60281) [Link]
"As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality."
- Albert Einstein
Provably correct hardware not possible Posted Nov 22, 2011 4:10 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Digital circuitry is _digital_. It's specifically designed to not care about small deviations in voltage levels. If one circuit behaves differently from another one then it's a defect, which can in theory be diagnosed during manufacture.
Of course, it's possible that a passing OhMyGod particle would knock your CPU off, but that's outside of range of provable hardware and software.
Provably correct hardware not possible Posted Nov 23, 2011 12:52 UTC (Wed) by pjm (subscriber, #2080) [Link]
> Digital circuitry is _digital_. It's specifically designed to not care about small deviations in voltage levels.
In practice, it's quite common for PC hardware not to behave according to spec (bits flipped in transit): common enough that I've noticed it myself on more than one machine, and common enough that I'm quite surprised that you apparently haven't noticed it.
Provably correct hardware not possible Posted Nov 23, 2011 15:28 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
These are defects. Barring really bad design, you can't predict them or use them to reliably exploit something.
GC in common languages Posted Nov 19, 2011 11:20 UTC (Sat) by Yenya (subscriber, #52846) [Link]
: > Ada may not be big on desktop today, yet it still used quite
: > heavility where security is important. But guess what: no GC. : > In most impementations, at least.
> But then there's .NET and Java, Python and Perl, Erlang and Haskell
Just for the sake of correctness, Perl does not use GC at all - Perl uses reference counting, and as soon as the count drops to zero, the object's memory can be recycled (after a destructor finishes). This is much more simple than GC, destructors are called in a deterministic place of the program, but it also has drawbacks, such as not being able to free a circular reference, which is not referenced from the outside world (see Scalar::Util::weaken for the solution).
-Yenya
GC in common languages Posted Nov 19, 2011 20:45 UTC (Sat) by elanthis (guest, #6227) [Link]
Reference counting is a form of automatic garbage collection, and not even the most efficient one at that. "GC" is not limited solely to mark-and-sweep and it's offspring.
GC in common languages Posted Nov 19, 2011 20:57 UTC (Sat) by Yenya (subscriber, #52846) [Link]
OK, sorry for the confusion then.
In the world I live in, I usually hear the phrase "automatic versus manual memory management" for the "high-level languages versus C" thing, and "garbage collection" for scanning for unreferenced data periodically (LISP style).
In my humble opinion it is a bit cleaner to not call the automatic memory management "GC", because e.g. with refcounting there is no "garbage" which could be later "collected".
GC in common languages Posted Nov 20, 2011 0:04 UTC (Sun) by elanthis (guest, #6227) [Link]
Yeah, it's all just terminology.
Since I'm a nerd and have to be pedantic about such things though (I'm easy to need-snipe), "garbage" is still a correct term in reference counting schemes. That the garbage object is almost immediately collected rather than sitting around a while until collection isn't really relevant; it's still for a brief moment a valid memory-consuming object that is known to be unneeded (ref count hit zero) but not yet reclaimed. :)
In fact, even in many ref counting systems, reclaiming is not instantaneous, but rather delayed. Objects with a ref count of zero are just put into a list of dead objects, and that list is "cleaned" at the end of the app's main loop. This is handy when you realize that an object might become dead during a callback from one of the object's methods, for instance, or when you allow "temporary" raw pointers (nothing persisting past a function call's lifetime) to avoid excessive ref count increments/decrements in tight inner loops or in cache-friendly code.
In object pool setups, the object might not even be "reclaimed" until another object is created (replacing the dead object in memory).
Not tricks you find in general purpose setups, but definitely common in things like games (which is one of the reasons why C++ is still king of the hill in that domain, and only little casual games are ever implemented in high level languages with a one-size-better-fit-all-or-you're-screwed approach to object management and low-level data structures.)
There are big difference... Posted Nov 18, 2011 21:54 UTC (Fri) by tpo (subscriber, #25713) [Link]
khim wrote:
> NaCl does it [code verification] for x86 at machine code level (again with full ANSI C support but with coarser granularity and bigger speed loss).
and Cyberax countered:
> And NaCl still relies on hardware memory protection to contain untrusted code, so it's just a clever way to implement lightweight virtualization on x86. Qemu or VMWare both do similar tricks as well.
If any of you two has pointers to how exactly NaCl (or Qemu or VMWare) achieves to prevent "compartementalized" code within a process from accessing the enclosing rest of the code/data, I'd be interested and thankful to see those pointers (I've checked a bit the nativeclient docu but didn't see anything at first glance).
Thanks,
The pointers are there... Posted Nov 18, 2011 22:29 UTC (Fri) by khim (subscriber, #9252) [Link] If any of you two has pointers to how exactly NaCl (or Qemu or VMWare) achieves to prevent "compartementalized" code within a process from accessing the enclosing rest of the code/data, I'd be interested and thankful to see those pointers (I've checked a bit the nativeclient docu but didn't see anything at first glance). Well, Qemu, VMWare and NaCl use six different approaches (four because NaCl uses four different, albeit similar, ones). If you want to read more about NaCl your best bet would be research papers, I think. Original NaCl uses hardware support (segment registers), but later version (x86-64, ARM, MIPS) do everything in software. Note that MIPS version is done by some outside people, not by Google so there are no papers yet, only this bug.
There are big difference... Posted Nov 18, 2011 7:32 UTC (Fri) by deepfire (subscriber, #26138) [Link]
Extra points for Lisp being called a "pointless complication".
You clearly know enough about the history of ideas in computing.
Not sure if it's sarcasm or not... Posted Nov 18, 2011 8:10 UTC (Fri) by khim (subscriber, #9252) [Link] Extra points for Lisp being called a "pointless complication". If you meant it as sarcasm then you missed the point. Sure, there are things which Lisp does better and simpler then other solutions. But when you try to shoehorn the whole world in Lisp - this is pointless complication. You clearly know enough about the history of ideas in computing. I know enough to know that In theory, theory and practice are the same. In practice, they are not. It funny to see intelligent people like Niklaus Wirth, Andrew Tanenbaum and others do a "novice error" again and again. If you want to introduce something new you better have the contingency plan ready which will introduce your creation as piecemeal replacement for something. Time for "flag day revolutions" have come and gone. Even if you introduce something "brand new" you either need to introduce a way to bring legacy code on your platform - as Android did when it introduced NDK, or you can see it eventually rejected (it may survive as niche solution, of course: LISP certainly did).
Not sure if it's sarcasm or not... Posted Nov 18, 2011 8:35 UTC (Fri) by deepfire (subscriber, #26138) [Link]
>> Extra points for Lisp being called a "pointless complication".
> Sure, there are things which Lisp does better and simpler then other
Have you experienced a Lisp machine environment?
You judge things so easily..
Not sure if it's sarcasm or not... Posted Nov 19, 2011 3:18 UTC (Sat) by k8to (subscriber, #15413) [Link]
Mentioning it doesn't really bring anything.. it's already been mentioned.
If you have relevant information as to why lisp machines really were a great approach, offering something that other solutions that won cannot provide, especially in a practical way... by all means do share it.
|
|||||||||||||