One, at least, has been developed, and certified multiple times, using x86 commodity PC hardware, with a proprietary security controller (to provide isolated identity secret key and crypto support, like would be provided via TPM chip, today)
What would it do if it ran in a virtual machine with thunks provided so that the virtual machine had direct access to the proprietary security controller? In other words, how easy is it to perform a MITM attack on the OS and security controller?
My wish list for secure hardware would consist of commodity PC hardware with a special CPU that had fast embedded cryptography support so that the contents of RAM and device IO could be automatically decrypted coming off the bus, and encrypted again when going out. Stick the TPM style keys inside the CPU, and it would be much harder to break the system. It would be nice if the L2/L3 cache supported bringing entire pages in and out at once, which would allow the creation of a hash tree over the contents of memory to provide cryptographically strong data integrity outside of the CPU, along with the confidentiality provided by encryption.
Once trusted hardware is available, the only reasonable way of achieving security is with formal verification. There has been lots of neat work in automatic proof generation for subsets of common languages like Java and C, like the proof carrying code stuff done by George Necula and associates. That's really the best way to ensure security; enforce the protection model at the hardware level with computer verification of proofs matched to the actual machine code that's running, avoiding the possibility of compiler errors or backdoors. All that's needed is a small trusted proof verification kernel that can be signed once it has been independently validated, which can then load and verify the rest of the operating system and applications.
The system would still be vulnerable to CPU bugs and hardware errors within the CPU, so it would make sense to beef up the internal data pathways by tagging all the registers and cache values with ECC and verifying them at each step. Paranoid error detection would prevent many kinds of tampering, e.g. temperature or radiation based attacks.
But in today's world, everything, and I do mean everything, from routers to hubs and switches to firewalls, workstations and servers, run on multi-million line monolythic kernel systems, whether Linux, Solaris, BSD or Windows. None of those are evaluable above EAL4 (which is "low assurance" by definition).
I wouldn't blame monolithic kernels per-se. In my secure computing utopia, hardware privilege separation wouldn't even be necessary. Formal verification at the instruction level provides everything (and more) that hardware protection could, while ECC verification prevents the exploitation of bit flips in pointers that was used against the JVM. Formal verification could be attempted on an existing monolithic kernel, and might even succeed, but the work would be in defining a secure operating model and then tracking down all the bugs that violate the model when the proof generator fails, and writing proofs by hand for the hairy parts.
As you point out - on a weak system, anyone with read access to data can probably write it out somewhere, too. Not so with an MLS system supporting data integrity and/or secrecy protections, combined with adequate label integrity mechanisms for exported data (a form of strong DRM, if you like). Of course, protecting against undocumented features (Easter eggs) required another level of assurance, and the ability to verify that there are no hidden trap doors available for (or planted by) determined adversaries.
Good luck implementing a system like that on anything but dedicated proprietary hardware. Virtualization is enough to blow mandatory access controls out of the water without even talking about Van Eck phreaking, physical separation between networks of different privilege levels, etc.
In general, I would also disagree with your claim that a proper mandatory access control system allows users of different clearances to use the same device. Covert channels are too difficult to prevent without severely limiting the usefulness of the system. Basically if two users share the same CPU or hardware they can almost always find a way to use some resource conflict as a covert channel, whether it's just the average response time for a certain operation to complete or something like the key recovery attacks that use cache latency to actually steal keys from a non-cooperating process.
It sounds like the old Common Criteria specifications that enforced need-to-know access and tried to prevent high security documents being accessible at lower privilege levels. The problem for Microsoft and any modern vendor is that they can't really control the hardware like the DoD or military would. With virtualization and the tools available on the Internet (not to mention digital cameras, etc.), the goal of strictly controlled information is pretty much over.
An authorized malicious user will be able to circumvent RMS (at the very least by memorizing the document and recreating it later). In practice, companies find RMS to be valuable, with full knowledge of its limitations and design goals.
Not to mention anyone who happens to have a trojan/rootkit installed on an authorized user's computer.
What's to prevent someone from removing the watermark on a copy and then sending it off? I thought the idea of watermarking was to make it automatic and invisible to the ordinary user.
If a copy is found in the wild without a watermark, the company can claim that it's not responsible for the leak because all internal documents are watermarked. It's not their fault if a spy is smart enough to remove the watermark. At least that's the way they could play it in a lawsuit.
Look up metamath, coq, and mizar. I suppose your definition of "genuine" problems may influence your opinion of these projects. coq was recently used to verify a completely formal proof of the four coloring problem, which I would classify as a genuine mathematical problem considering that no traditional proof has yet been found.
IIRC, Skein is getting about 6 cycles a byte in 512-bit mode on 64 bit platforms, which on a 2.4GHz dual core CPU would yield a theoretical 800 MB/s in a parallel tree hashing mode, 400 MB/s in standard mode. Apparently MD6 has a parallel mode also, and it's striking that both hash functions are trying to be minimalist by employing only three fundamental operations (AND, XOR, SHIFT for MD6; XOR, ADD, ROLL for Skein) and lots of rounds. It's odd that MD6 should be so much slower. Perhaps it hasn't been fully optimized yet?
You're assuming, though, that the cache flush happens really lazily, instead of the I/O board (raid card, or whatever) doing at top priority as soon as the underlying disk hardware is capable of committing the writes.
I'm assuming that the cache is actually used, e.g. if the original poster needed 8 GB of cache, then the workload was a ton of small writes that had to be collected in the 8 GB cache so they could be written in huge chunks and max out the throughput of the disks. Any less of a workload wouldn't necessitate 8 GB of cache. Even for a temporary workload this is true; if the disks sit idle for 23 hours a day but for an hour the cache is full (or almost full) and the disks are totally busy, then during this heavy usage time the data is in quite a bit of danger of being lost/corrupted.
My basic point is; when you need a cache for performance reasons, you are going to be in a situation where the cache has a significant amount of dirty data that would be lost in a crash/power failure. Otherwise you wouldn't need the cache to begin with. Again, some workloads might not suffer a lot of data corruption even under this scenario; storing video or other large contiguous blobs of data will just suffer some loss of a small portion of any given file, which will be relatively obvious. Transactional data is at a much higher risk because the entire database could become unusable because of out-of-order writes (which is the primary method caches use to speed up disk writes) and a crash.
I also think the trend is to more cached writes, not fewer of them, and often in ways you can't control the latency of the cached writes (think SANs or other remote storage where not having cached writes would mean huge latency penalties and unusable storage).
Any SAN worth buying will have battery backed write cache, and may even support in-order writes for transactional loads that require it.
OS crashes and hardware failure do happen. So do random acts of system administration like accidentally pulling a power cord. Additionally, when your UPS battery is running out, does your server have enough time to write 8 GB of cache when it determines that it's time to shut down? UPS's fail, too.
It depends on your workload though. A database or other transactional storage without a write-through cache is basically a disaster waiting to happen, even with archive/replay logs, because the replay logs are probably still sitting in the cache when the database finally commits the transaction. You can utterly break a database that way, with no recourse except to fall back on the last full backup and any replay logs that are still good, while losing your ACID compliance because transactions are not guaranteed to flush to disk until a few seconds/minutes after an application has committed them.
If you just have a bunch of movies or other simple files being stored, the danger is a little lower. You could potentially corrupt a few random files, which is bad, but it's not the same risk as an unrecoverable database. But any sort of processing system that's using the disk to store state information should really have write-through caching for safety.
ASCII and Unicode are going to be around for a long, long time. Same with Bitmaps, PNGs, GIFs, JPEGs, postscript, TeX, HTML, and dozens of other formats.
If you're storing all your documents in Proprietary Paperless Document Imaging System 2000<TM>, then yeah, be very afraid. Otherwise, not so much.
I doubt if you're really getting the benefit from your cache that you think you are; and if you are, it's dangerous. A SAN/NAS should never cache data in memory and tell the client that its data is written to disk until the data has actually been written to some non-volatile storage. Expensive SAN/NAS devices have battery backed caches for exactly that reason. What good is your 8 GB of RAM if all the files you backed up into volatile RAM for the last few minutes are lost when the power goes out?
Things like the interstate highways and the military don't bother you? They are, after all, quite socialist. Who exactly enforces the law without "socialist" taxes to support courts and police? Or is there some narrow definition of "law" and "freedom" that does not imply socialism when the government takes your money to fund it?
XP (and even 2000) supported essentially the same thing. 1) Press -R 2) type N 3) arrow down to the last autocompleted time you ran notepad 4) hit enter
For network, same thing: 1) -R 2) \ 3) \ 4) h 5) arrow down 6) enter
I guess you don't have to write a long essay to get responses like that. Consider that you don't have to compare Vista against vanilla XP, compare it against XP SP2 and XP SP3. Microsoft has continued development on XP and it is not quite a sharp line between XP being totally old and Vista being totally new. I'd look at them as more of two concurrent branches of Windows development, both of which Microsoft is probably trying hard to get rid of in preparation for Windows 7.
Have you compared Vista to XP on the same machine? I find that's where the biggest differences are apparent. Perhaps I have an odd usage model, but I generally want Windows to get out of my way while I use applications, not watch shiny things eat my battery life and slow down background processes.
Anecdotal story: I helped my brother in-law install an XP partition on his laptop, since Vista was crashing (probably hardware/driver issues on a cheap HP laptop).
His comment: "Wow, it's faster and my old games work on it!"
I'd say that unless some magic new feature (which I've yet to see) balances out the slowness and incompatibility, Vista is arguably worse.
Can you name a feature that makes Vista better than XP in a way that can't be tweaked with a registry key or some free add-on? If you say aero then I won't argue, but most sane people use their OS to run other programs, not just a shiny UI...
Most likely it's because Slack comes with a proper development environment, and the nVidia drivers generally compile and install well. I've never tried using a prepackaged kernel driver. ALSA just works. The only issue I have sometimes is the kernel not recognizing the sound card and automatically loading the module, but a line in rc.modules (or a file in/etc/modprobe.d) fixes that.
I've had good luck with slamd64 as well. It runs on a couple of boxes at home and my main box at work, and I haven't had any problems with it. The most annoying thing is that Firefox doesn't release 64 bit packages.
Installing the official Slackware packages for 32-bit compatibility has worked very well for me if slamd64 doesn't have a 32 bit version of a library for some reason, and I can just run the 32-bit version of Firefox until slamd64 puts a new version out.
Sugar is fattening, and of course if you leave yeast in some sugar water you end up with ethanol... Better ban all the foods that contain glucose/sucrose to be safe.
Slashdot Mirror
One, at least, has been developed, and certified multiple times, using x86 commodity PC hardware, with a proprietary security controller (to provide isolated identity secret key and crypto support, like would be provided via TPM chip, today)
What would it do if it ran in a virtual machine with thunks provided so that the virtual machine had direct access to the proprietary security controller? In other words, how easy is it to perform a MITM attack on the OS and security controller?
My wish list for secure hardware would consist of commodity PC hardware with a special CPU that had fast embedded cryptography support so that the contents of RAM and device IO could be automatically decrypted coming off the bus, and encrypted again when going out. Stick the TPM style keys inside the CPU, and it would be much harder to break the system. It would be nice if the L2/L3 cache supported bringing entire pages in and out at once, which would allow the creation of a hash tree over the contents of memory to provide cryptographically strong data integrity outside of the CPU, along with the confidentiality provided by encryption.
Once trusted hardware is available, the only reasonable way of achieving security is with formal verification. There has been lots of neat work in automatic proof generation for subsets of common languages like Java and C, like the proof carrying code stuff done by George Necula and associates. That's really the best way to ensure security; enforce the protection model at the hardware level with computer verification of proofs matched to the actual machine code that's running, avoiding the possibility of compiler errors or backdoors. All that's needed is a small trusted proof verification kernel that can be signed once it has been independently validated, which can then load and verify the rest of the operating system and applications.
The system would still be vulnerable to CPU bugs and hardware errors within the CPU, so it would make sense to beef up the internal data pathways by tagging all the registers and cache values with ECC and verifying them at each step. Paranoid error detection would prevent many kinds of tampering, e.g. temperature or radiation based attacks.
But in today's world, everything, and I do mean everything, from routers to hubs and switches to firewalls, workstations and servers, run on multi-million line monolythic kernel systems, whether Linux, Solaris, BSD or Windows. None of those are evaluable above EAL4 (which is "low assurance" by definition).
I wouldn't blame monolithic kernels per-se. In my secure computing utopia, hardware privilege separation wouldn't even be necessary. Formal verification at the instruction level provides everything (and more) that hardware protection could, while ECC verification prevents the exploitation of bit flips in pointers that was used against the JVM. Formal verification could be attempted on an existing monolithic kernel, and might even succeed, but the work would be in defining a secure operating model and then tracking down all the bugs that violate the model when the proof generator fails, and writing proofs by hand for the hairy parts.
Honestly, it's like fining someone $10,000 for jaywalking or a speeding ticket because they say it isn't wrong, Totally cruel and unusual.
As you point out - on a weak system, anyone with read access to data can probably write it out somewhere, too. Not so with an MLS system supporting data integrity and/or secrecy protections, combined with adequate label integrity mechanisms for exported data (a form of strong DRM, if you like). Of course, protecting against undocumented features (Easter eggs) required another level of assurance, and the ability to verify that there are no hidden trap doors available for (or planted by) determined adversaries.
Good luck implementing a system like that on anything but dedicated proprietary hardware. Virtualization is enough to blow mandatory access controls out of the water without even talking about Van Eck phreaking, physical separation between networks of different privilege levels, etc.
In general, I would also disagree with your claim that a proper mandatory access control system allows users of different clearances to use the same device. Covert channels are too difficult to prevent without severely limiting the usefulness of the system. Basically if two users share the same CPU or hardware they can almost always find a way to use some resource conflict as a covert channel, whether it's just the average response time for a certain operation to complete or something like the key recovery attacks that use cache latency to actually steal keys from a non-cooperating process.
It sounds like the old Common Criteria specifications that enforced need-to-know access and tried to prevent high security documents being accessible at lower privilege levels. The problem for Microsoft and any modern vendor is that they can't really control the hardware like the DoD or military would. With virtualization and the tools available on the Internet (not to mention digital cameras, etc.), the goal of strictly controlled information is pretty much over.
An authorized malicious user will be able to circumvent RMS (at the very least by memorizing the document and recreating it later). In practice, companies find RMS to be valuable, with full knowledge of its limitations and design goals.
Not to mention anyone who happens to have a trojan/rootkit installed on an authorized user's computer.
What's to prevent someone from removing the watermark on a copy and then sending it off? I thought the idea of watermarking was to make it automatic and invisible to the ordinary user.
If a copy is found in the wild without a watermark, the company can claim that it's not responsible for the leak because all internal documents are watermarked. It's not their fault if a spy is smart enough to remove the watermark. At least that's the way they could play it in a lawsuit.
Look up metamath, coq, and mizar. I suppose your definition of "genuine" problems may influence your opinion of these projects. coq was recently used to verify a completely formal proof of the four coloring problem, which I would classify as a genuine mathematical problem considering that no traditional proof has yet been found.
IIRC, Skein is getting about 6 cycles a byte in 512-bit mode on 64 bit platforms, which on a 2.4GHz dual core CPU would yield a theoretical 800 MB/s in a parallel tree hashing mode, 400 MB/s in standard mode. Apparently MD6 has a parallel mode also, and it's striking that both hash functions are trying to be minimalist by employing only three fundamental operations (AND, XOR, SHIFT for MD6; XOR, ADD, ROLL for Skein) and lots of rounds. It's odd that MD6 should be so much slower. Perhaps it hasn't been fully optimized yet?
You're assuming, though, that the cache flush happens really lazily, instead of the I/O board (raid card, or whatever) doing at top priority as soon as the underlying disk hardware is capable of committing the writes.
I'm assuming that the cache is actually used, e.g. if the original poster needed 8 GB of cache, then the workload was a ton of small writes that had to be collected in the 8 GB cache so they could be written in huge chunks and max out the throughput of the disks. Any less of a workload wouldn't necessitate 8 GB of cache. Even for a temporary workload this is true; if the disks sit idle for 23 hours a day but for an hour the cache is full (or almost full) and the disks are totally busy, then during this heavy usage time the data is in quite a bit of danger of being lost/corrupted.
My basic point is; when you need a cache for performance reasons, you are going to be in a situation where the cache has a significant amount of dirty data that would be lost in a crash/power failure. Otherwise you wouldn't need the cache to begin with. Again, some workloads might not suffer a lot of data corruption even under this scenario; storing video or other large contiguous blobs of data will just suffer some loss of a small portion of any given file, which will be relatively obvious. Transactional data is at a much higher risk because the entire database could become unusable because of out-of-order writes (which is the primary method caches use to speed up disk writes) and a crash.
I also think the trend is to more cached writes, not fewer of them, and often in ways you can't control the latency of the cached writes (think SANs or other remote storage where not having cached writes would mean huge latency penalties and unusable storage).
Any SAN worth buying will have battery backed write cache, and may even support in-order writes for transactional loads that require it.
OS crashes and hardware failure do happen. So do random acts of system administration like accidentally pulling a power cord. Additionally, when your UPS battery is running out, does your server have enough time to write 8 GB of cache when it determines that it's time to shut down? UPS's fail, too.
It depends on your workload though. A database or other transactional storage without a write-through cache is basically a disaster waiting to happen, even with archive/replay logs, because the replay logs are probably still sitting in the cache when the database finally commits the transaction. You can utterly break a database that way, with no recourse except to fall back on the last full backup and any replay logs that are still good, while losing your ACID compliance because transactions are not guaranteed to flush to disk until a few seconds/minutes after an application has committed them.
If you just have a bunch of movies or other simple files being stored, the danger is a little lower. You could potentially corrupt a few random files, which is bad, but it's not the same risk as an unrecoverable database. But any sort of processing system that's using the disk to store state information should really have write-through caching for safety.
ASCII and Unicode are going to be around for a long, long time. Same with Bitmaps, PNGs, GIFs, JPEGs, postscript, TeX, HTML, and dozens of other formats.
If you're storing all your documents in Proprietary Paperless Document Imaging System 2000<TM>, then yeah, be very afraid. Otherwise, not so much.
I doubt if you're really getting the benefit from your cache that you think you are; and if you are, it's dangerous. A SAN/NAS should never cache data in memory and tell the client that its data is written to disk until the data has actually been written to some non-volatile storage. Expensive SAN/NAS devices have battery backed caches for exactly that reason. What good is your 8 GB of RAM if all the files you backed up into volatile RAM for the last few minutes are lost when the power goes out?
Things like the interstate highways and the military don't bother you? They are, after all, quite socialist. Who exactly enforces the law without "socialist" taxes to support courts and police? Or is there some narrow definition of "law" and "freedom" that does not imply socialism when the government takes your money to fund it?
slashdot ate <window> because of the tags. The keystroke is Windows-R.
XP (and even 2000) supported essentially the same thing.
1) Press -R
2) type N
3) arrow down to the last autocompleted time you ran notepad
4) hit enter
For network, same thing:
1) -R
2) \
3) \
4) h
5) arrow down
6) enter
it's an upgrade lawlz!!!11!!1one
I guess you don't have to write a long essay to get responses like that. Consider that you don't have to compare Vista against vanilla XP, compare it against XP SP2 and XP SP3. Microsoft has continued development on XP and it is not quite a sharp line between XP being totally old and Vista being totally new. I'd look at them as more of two concurrent branches of Windows development, both of which Microsoft is probably trying hard to get rid of in preparation for Windows 7.
Have you compared Vista to XP on the same machine? I find that's where the biggest differences are apparent. Perhaps I have an odd usage model, but I generally want Windows to get out of my way while I use applications, not watch shiny things eat my battery life and slow down background processes.
Anecdotal story: I helped my brother in-law install an XP partition on his laptop, since Vista was crashing (probably hardware/driver issues on a cheap HP laptop).
His comment: "Wow, it's faster and my old games work on it!"
I'd say that unless some magic new feature (which I've yet to see) balances out the slowness and incompatibility, Vista is arguably worse.
Can you name a feature that makes Vista better than XP in a way that can't be tweaked with a registry key or some free add-on? If you say aero then I won't argue, but most sane people use their OS to run other programs, not just a shiny UI...
They will point out the comments they left for you here, and everything will be pretty peachy from then on.
Most likely it's because Slack comes with a proper development environment, and the nVidia drivers generally compile and install well. I've never tried using a prepackaged kernel driver. ALSA just works. The only issue I have sometimes is the kernel not recognizing the sound card and automatically loading the module, but a line in rc.modules (or a file in /etc/modprobe.d) fixes that.
I've had good luck with slamd64 as well. It runs on a couple of boxes at home and my main box at work, and I haven't had any problems with it. The most annoying thing is that Firefox doesn't release 64 bit packages.
Installing the official Slackware packages for 32-bit compatibility has worked very well for me if slamd64 doesn't have a 32 bit version of a library for some reason, and I can just run the 32-bit version of Firefox until slamd64 puts a new version out.
Meh, I just classify all that stuff under "human behavior" and go program a computer...
Yeah. Birth control. With that many wives, wouldn't it be necessary anyway?
Sugar is fattening, and of course if you leave yeast in some sugar water you end up with ethanol... Better ban all the foods that contain glucose/sucrose to be safe.
3) confusing computer scientists with English-speakers.
No. I'll have my answer regardless of how long I have to live. Besides, I can't live forever since I already know how I die.
Yeah, but you probably didn't account for the trauma team putting you back together again and waking you up afterward.