| |||||||||||||
This is partially true...This is partially true...Posted Nov 18, 2011 21:17 UTC (Fri) by khim (subscriber, #9252)In reply to: This is partially true... by Cyberax Parent article: Interview with Andrew Tanenbaum (LinuxFr.org)
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?
(Log in to post comments)
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
|
|||||||||||||