I'm not sure. The locked instructions, compare and exchange and mfence ensure cache coherency so in my experience the flushes are not necessary.
Maybe driver code needs the flushes. Driver needs to know data is really in the RAM before hardware with DMA can get it.
Cache flush instructions seem to be a late addition with SSE2.
Here is the link to the earlier slashdot discussion on this prevalent hardware bug. The original paper suggested the possibility of exploit.
Late comer, but in case someone is looking for this bit of information.
Just got latest updates. Before the updates I tested with this tool and result was vulnerable.
After the updates it reports "not vulnerable".
There was some messup with libc dev packages. I had to force uninstall some dev packages and do "apt-get -f install" a couple of times, until the problem cleared. This is most likely just my machine...
I should still reboot to make sure the old libc is not loaded in some processes...
XD
JavaScript: The Good Parts by Douglas Crockford shows a way to write clean, conscise and predictable code in JavaScript. (It is also very short book, which I find hilarious. Even then the most important points in the book are in the first half or so.)
The most powerful idea IMHO is the use of function scopes as the main data structure instead of dictionaries. Another idea is avoiding or skipping completely some language features that behave in unusual ways and using simpler more fundamental constructs instead. I think the new-operator is the classic example of these.
I recommend this book wholeheartedly for anyone learning JavaScript and having some prior programming experience.
If you solve the dual NAT problem separately then Duplicity is one good complete solution. It adds backup schedules, strong client-side encryption and is still able to do incremental backups. Setting it up requires one line of cron on the client side and some kind of remote account for storing the backup archives (SSH, SFTP, FTP). Choosing the correct command line options and handling the passwords requires some care though.
Duplicity uses the same base tech as rsync (librsync) and it's written in Python. It tries hard not to reinvent the wheel using tar for archive files and gpg for encrypting them. This means that extracting files from backups can even be done with standard tools if things get bad. It's available out of the box at least on Ubuntu and Debian. Also installing on CentOS went pretty smoothly with RPM available from project site.
If Windows and Windows programs insist on controlling the boot sector (and stuff that comes after it), you can still boot Linux.
At least starting with Vista, Windows has completely extensible boot loader of its own (the configuration data is called BCD).
The idea is that the Grub (or whatever) is installed on the same Linux *partition* where all the system files are installed (not on the MBR).
(At least Ubuntu installer has the option to install Grub on a partition instead of MBR out of the box.)
Windows boot loader is then used to load Grub from the beginning of that partition. No matter what
windows updates, programs etc. do this does not break.
Too bad that the default Linux installers don't support this option, since it
has been very hassle free for me at least. The initial setup could just as well be automatic.
Instructions for doing this manually here:
The absence of labels [in ECL] is probably a good thing. -- T. Cheatham
