It's a series of images that, when stitched, conveniently exclude the arm.
True, but where does the arm attach to the rover? That end of the arm must be visible on any picture taking of that part of the rover. I am curious to see the individual parts, just to figure out how that part of the rover really looks.
And how many people have died because of Fukushima?
From the info I could find, it was none. However the tsunami did kill a lot of people. And in case somebody on the plant died, would that have been because of the nuclear power plant or because of the tsunami? I guess the question to ask would be, what would have happened to the people working there when the tsunami hit, in case it had been an oil or coal powered plant? Regardless of the answer, it seems pretty clear that the damage caused by the tsunami hitting a nuclear power plant was minor compared to the damage the tsunami did in other places on its path.
The issue with Android making the jump to the desktop hinges around one issue: User support. Android uses UIDs to separate apps. How would it keep users separate, which is a must on a desktop box.
The only way I can see that happening would be a hypervisor based system with each user on their own VM
You clearly don't know what sort of features exist in Linux for handling that. First of all, there are enough UIDs that one can be assigned to each application installed by each user. Additionally the file system separation has been supported by Linux since version 2.4.19 (according to the clone man page). Each user can have their own file system namespace. And no need for deduplication either. Those parts of the file system, which are read only (or only writable by root) can just be mounted in the same place in each namespace. Separate PID and IPC namespaces are also supported if you use a recent kernel.
Anybody who tries to blow up a group of people in order to inflict terror on a larger group of people is a terrorist.
Can't argue with that. I think that statement pretty much follows from the definition of the word terrorist. (Of course you don't have to search for a long time to find people who disagree on what the definition is.)
Since 11 Sept, all people caught trying to set off bombs on board planes, boarded those planes outside the US. So they didn't have much to do with US security regulations
Last time I travelled to the US, I had to go through an extra round of security checks before and after the normal security checks. So it seems the US has succeeded in imposing some version of their regulations on airports in other countries.
On the other hand, if you are a terrorist cell, you are probably not terribly concerned about U.S. law...
And from that you get a corollary saying that anybody who isn't terribly concerned about U.S. law is a terrorist. Of course deriving a corollary that way isn't logically sound, but the people who make up corollaries of the form "anybody who... is a terrorist" aren't terribly concerned about logic.
Wow. The encryption described in those slides is like state of the art of the 16th century. Nowadays that scheme doesn't even qualify as cryptography. It's not custom cryptography, it's a joke.
The slides do mention, that they have modified some details, probably as part of a responsible disclosure. But I suppose the sort of methods used and the strength of the encryption does correspond to the original version.
But as so often before, people are using "encryption" when it isn't what they need. 90% of the time where people use encryption, what they really need is integrity, which is not achieved through encryption but rather through message-authentication-codes or digital signatures. Encryption without integrity is rarely a good idea. If the integrity of the data on these tickets had been protected, there would be no need for encryption in the first place. After all, the plaintext version of the data is probably even printed on the ticket.
For bonus points, if possible, the report should list which files are damaged.
The interaction needed between the file system layer and the RAID layer needed for that goes well beyond what the actual block layer interface supports. What I would do in such a situation is to rebuild two copies of the block device, one in which I fill the lost area with all 0 bits and another in which I fill the lost area with all 1 bits. Then I use the file system to read both copies and compare the results. That requires quite some manual work, but it is rarely needed, and if data is at risk, I like to take that approach.
But on a slightly longer term, I will prefer to use file systems with builtin RAID functionality. They can respond much more intelligent to such problems.
I don't think it would be helpful or necessary to try and persistently track/manage unrecovered sectors on an ongoing basis.
I think it is, if you want to avoid silent corruption and still be able to read all the good data.
If it's just NataliePortmanHotGrits.avi, then not a problem.
You gotta be kidding.
I guess what I'm saying is, when the RAID rebuild fails, it's better to recover as much as possible
Of course. The tricky part is to automatically recover good data and still avoiding silent corruption. I don't like the RAID to complete a rebuild and leave the RAID in a state, where I can never find out which file was corrupted.
New file systems are being designed with checksums of each block and builtin RAID functionality. You can still run those on top of a hardware or software RAID, if you like to.
According to some other posts in the thread Red Hat and Fedora also has it. Fedora didn't have it, last time I set up a RAID on Fedora. But maybe more recent Fedora versions do have it.
better not to have arrived in that situation in the first place.
Agreed. RAID6 or periodic background reads can reduce the risk. But neither of them is a suitable replacement for an off-site backup. Combining the three can reduce the risk of data loss even further.
Even the Linux mdadm software will do a scheduled scan once a month in a default install
It didn't do that last time I set it up. But that was some years ago. A monthly read doesn't completely protect against this sort of problem. Two failures within a month is much more likely than two failures within the time it takes to rebuild a lost disk.
As far as security goes, I think one important aspect is transparency.
FTFA:
Threatpost: What are the most important features for the new OS?
Eugene Kaspersky: Alas, I cannot disclose many details about it.
A secure OS shouldn't need to be kept secret.
It should be publicly vetted like an encryption algorithm
That wasn't the sort of transparency I had in mind, when writing my comment. But I still agree with you. However I don't see a problem with it being kept secret in their design phase, as long as it is publicly vetted before being put in production. A bug bounty would also be a good idea.
Why can't the RAID controller just mark that one sector as unrecoverable, and go on to the next set of stripes?
There may be controllers that can do that. But doing so requires a much more complicated format. To the best of my knowledge, you cannot instruct a harddisk to turn a specific sector unreadable. So you either write something to that sector, and have silent data corruption, or you need an extra bit of storage somewhere to track which sectors are lost.
If you add a bit per sector to track which are lost, you cannot put that extra bit in the same sector. It won't fit. So you need bitmap sectors somewhere. Losing a bitmap sector would be bad. You'd not know which of the affected sectors contains good data, so you'd have to assume they were all bad. It would not be as bad as losing an entire disk, but you'd lose 2MB if the sector size was 512 bytes or 128MB if the sector size was 4096.
But you still haven't solved the problem. You could mark that one sector as invalid on the new disk. Effectively that one bad sector meant you lost two sectors (unless you were lucky and one of them was parity). But even worse, it put the remaining sectors at that position on other disks at risk. Since they no longer have any redundancy. So you need to actually do a new parity over the readable sectors, plus you need to keep the old parity to be able to recover if the disk with the unreadable sector is eventually able to read it. There is no way to do this in place, so the RAID layer need to set aside extra space somewhere to track this sort of complicated recovery.
If you have a RAID controller, which can take care of all of this, then it is probably using some proprietary layout of the data. That means if you lose the controller, then all the data is lost, unless you can find an identical controller. I haven't heard of any open standard for this sort of thing.
The format used for RAID 5 on Linux doesn't have any of this fancy stuff.
This is exactly why most RAID cards to patrol reads during low activity.
Of course that helps. But I still expect RAID 6 without patrol reads to provide better reliability than RAID 5 with patrol reads. I'm not sure which of the two is best for performance.
I'm not aware of any software raid implementation that does patrol reads
At some point in the past I setup a software RAID 5 on Linux and just created a weekly cron job to read through all the physical media. Not exactly a full solution, but does ensure that bad sectors will get noticed. I don't recall if software RAID 6 already existed at the time, but it certainly wasn't mature yet, so I didn't consider that option at the time.
It was my understanding that for traditional drives in a RAID you don't want to get all the same type of drive all made around the same time since they will fail around the same time too.
It's a claim I have seen often, but I have never seen evidence to support it. A much more likely scenario, which can easily be misdiagnosed as simultaneous drive failures is the following. One disk gets a bad sector, which at first goes unnoticed. A second disk dies. During reconstruction the first bad sector is noticed and causes reconstruction to fail. To protect against that you can use RAID 6 or RAID 1 across three or more drives.
Is there a reason to worry about simultaneous failure of multiple SSDs? I don't know for sure. The best protection against that might be RAID 1 across SSD and harddisk. I don't know if there exist a RAID system, which can do this intelligently, but it certainly is feasible.
I wouldn't do this directly on the harddisk because of the bad seek performance of the harddisk. Instead I would take advantage of the much larger capacity you get on harddisks at the same price. Add a logstructured layer that causes writes on the harddisk to be sequential. If the physical capacity of the harddisk is multiple times the logical capacity (which is set to match the size of the SSD), then most of the physical sectors are unused, and there will only rarely be a need to skip used sectors during write (or they can be migrated ahead of time).
In such a setup the mirror on the harddisk would have terrible read performance, so all reads would go to SSD. If you do need to recover after the SSD has failed, the recovery can happen with a decent performance by reading data in the order it is physically stored on the disk rather than in the logical order. The result of this is sequential reads on the harddisk and random access writes on the new SSD.
Again you can use three media to protect against bad sectors discovered during recovery. For performance reasons you'd probably want the third drive to be an SSD as well such that you have two SSDs and just one harddisk.
That is why one uses RAID 6 with lower tier drives and hot spares.
Best argument for RAID 6 is bad sectors discovered during reconstruction. Assume one of your disks have a bad sector somewhere. Unless you periodically read through all your disks, you may not notice this for a long time. Now assume a different disk dies. Reconstruction starts writing on your hot spare. But during reconstruction an unreadable sector is found on a different drive. On RAID 5, that means data loss.
I have on one occasion been assigned the task on recovering from pretty much that situation. And some of the data did not exist anywhere else. In the end my only option was to retry reading the bad media over and over until on one pass I got lucky.
With RAID 6 you are much better off. If one disk is completely lost and you start reconstructing to the hot spare, you can tolerate lots of bad sectors. As long as you are not so unlucky to find bad sectors in the exact same location on two different drives, reconstruction will succeed. An intelligent RAID 6 system will even correct bad sectors in the process. When a bad sector is detected during this reconstruction, the data for both the bad sector as well as this location on the hot spare are reconstructed simultaneously and both can be written to the respective disk.
At the end of the reconstruction you not only have reconstructed the lost disk, you have also reconstructed all the bad sectors found on any of the drives. Should one of the disks run out of space for remapping bad sectors in the process, then that disk is next in line to be replaced.
I do like the idea of an operating system designed with such security in mind. The operating system is probably also going to require some sort of real time guarantees, but otherwise no requirements for ultra high performance.
As far as security goes, I think one important aspect is transparency. Code running on the operating system should probably not have much freedom to modify the underlying system, but it is crucial that they can see what is going on, such that you can monitor that nothing unexpected is running on the system.
I guess for most SCADA systems the risk of bad stuff happening due to unauthorized changes is a much greater concern than leaking information from the system.
Are Kaspersky the right people to build the OS? Time will show.
The nice thing about wireless interconnects, though, is you can have a much broader range of network topologies.
Not really, no. Want two nodes connected in your network topology, just pull a wire or fibre between them. Requires lots of wires, but it is going to be better than wireless on throughput, latency, and reliability. Wireless is useful for devices that are constantly moved around. For anything stationary, pulling a wire is a better long term solution. And I assume servers in most data centers are considered stationary.
I know people who'd love to see wireless data centers become a reality (assuming they don't have to debug new problems). But I consider it to be a pipe dream. Wireless will never catch up with wired networks, because any wireless technology could be turned into something more reliable by using some sort of wires to ensure the signal gets where you want it, and not everywhere else.
Slashdot Mirror
The judge can now order the statement placed on the very top of the page, to make sure no one misses it. :)
And Apple can make the browser automatically scroll just past it when the page is opened.
True, but where does the arm attach to the rover? That end of the arm must be visible on any picture taking of that part of the rover. I am curious to see the individual parts, just to figure out how that part of the rover really looks.
But that clip is not really on topic for this thread. In this thread we need the real Darth Vader screaming noooooooo.
any non-trivial tasks would have required working with 100 projects at a time.
I don't think the IDE is to blame for that.
From the info I could find, it was none. However the tsunami did kill a lot of people. And in case somebody on the plant died, would that have been because of the nuclear power plant or because of the tsunami? I guess the question to ask would be, what would have happened to the people working there when the tsunami hit, in case it had been an oil or coal powered plant? Regardless of the answer, it seems pretty clear that the damage caused by the tsunami hitting a nuclear power plant was minor compared to the damage the tsunami did in other places on its path.
The issue with Android making the jump to the desktop hinges around one issue: User support. Android uses UIDs to separate apps. How would it keep users separate, which is a must on a desktop box.
The only way I can see that happening would be a hypervisor based system with each user on their own VM
You clearly don't know what sort of features exist in Linux for handling that. First of all, there are enough UIDs that one can be assigned to each application installed by each user. Additionally the file system separation has been supported by Linux since version 2.4.19 (according to the clone man page). Each user can have their own file system namespace. And no need for deduplication either. Those parts of the file system, which are read only (or only writable by root) can just be mounted in the same place in each namespace. Separate PID and IPC namespaces are also supported if you use a recent kernel.
Anybody who tries to blow up a group of people in order to inflict terror on a larger group of people is a terrorist.
Can't argue with that. I think that statement pretty much follows from the definition of the word terrorist. (Of course you don't have to search for a long time to find people who disagree on what the definition is.)
Since 11 Sept, all people caught trying to set off bombs on board planes, boarded those planes outside the US. So they didn't have much to do with US security regulations
Last time I travelled to the US, I had to go through an extra round of security checks before and after the normal security checks. So it seems the US has succeeded in imposing some version of their regulations on airports in other countries.
And from that you get a corollary saying that anybody who isn't terribly concerned about U.S. law is a terrorist. Of course deriving a corollary that way isn't logically sound, but the people who make up corollaries of the form "anybody who ... is a terrorist" aren't terribly concerned about logic.
Wow. The encryption described in those slides is like state of the art of the 16th century. Nowadays that scheme doesn't even qualify as cryptography. It's not custom cryptography, it's a joke.
The slides do mention, that they have modified some details, probably as part of a responsible disclosure. But I suppose the sort of methods used and the strength of the encryption does correspond to the original version.
But as so often before, people are using "encryption" when it isn't what they need. 90% of the time where people use encryption, what they really need is integrity, which is not achieved through encryption but rather through message-authentication-codes or digital signatures. Encryption without integrity is rarely a good idea. If the integrity of the data on these tickets had been protected, there would be no need for encryption in the first place. After all, the plaintext version of the data is probably even printed on the ticket.
Somebody else did post a link to the slides, though not in response to my question.
The article contains absolutely no information about what the vulnerability was. Have anybody been able to find a link to the actual presentation?
The interaction needed between the file system layer and the RAID layer needed for that goes well beyond what the actual block layer interface supports. What I would do in such a situation is to rebuild two copies of the block device, one in which I fill the lost area with all 0 bits and another in which I fill the lost area with all 1 bits. Then I use the file system to read both copies and compare the results. That requires quite some manual work, but it is rarely needed, and if data is at risk, I like to take that approach.
But on a slightly longer term, I will prefer to use file systems with builtin RAID functionality. They can respond much more intelligent to such problems.
I think it is, if you want to avoid silent corruption and still be able to read all the good data.
You gotta be kidding.
Of course. The tricky part is to automatically recover good data and still avoiding silent corruption. I don't like the RAID to complete a rebuild and leave the RAID in a state, where I can never find out which file was corrupted.
New file systems are being designed with checksums of each block and builtin RAID functionality. You can still run those on top of a hardware or software RAID, if you like to.
According to some other posts in the thread Red Hat and Fedora also has it. Fedora didn't have it, last time I set up a RAID on Fedora. But maybe more recent Fedora versions do have it.
Agreed. RAID6 or periodic background reads can reduce the risk. But neither of them is a suitable replacement for an off-site backup. Combining the three can reduce the risk of data loss even further.
It didn't do that last time I set it up. But that was some years ago. A monthly read doesn't completely protect against this sort of problem. Two failures within a month is much more likely than two failures within the time it takes to rebuild a lost disk.
As far as security goes, I think one important aspect is transparency.
FTFA:
Threatpost: What are the most important features for the new OS?
Eugene Kaspersky: Alas, I cannot disclose many details about it.
A secure OS shouldn't need to be kept secret. It should be publicly vetted like an encryption algorithm
That wasn't the sort of transparency I had in mind, when writing my comment. But I still agree with you. However I don't see a problem with it being kept secret in their design phase, as long as it is publicly vetted before being put in production. A bug bounty would also be a good idea.
There may be controllers that can do that. But doing so requires a much more complicated format. To the best of my knowledge, you cannot instruct a harddisk to turn a specific sector unreadable. So you either write something to that sector, and have silent data corruption, or you need an extra bit of storage somewhere to track which sectors are lost.
If you add a bit per sector to track which are lost, you cannot put that extra bit in the same sector. It won't fit. So you need bitmap sectors somewhere. Losing a bitmap sector would be bad. You'd not know which of the affected sectors contains good data, so you'd have to assume they were all bad. It would not be as bad as losing an entire disk, but you'd lose 2MB if the sector size was 512 bytes or 128MB if the sector size was 4096.
But you still haven't solved the problem. You could mark that one sector as invalid on the new disk. Effectively that one bad sector meant you lost two sectors (unless you were lucky and one of them was parity). But even worse, it put the remaining sectors at that position on other disks at risk. Since they no longer have any redundancy. So you need to actually do a new parity over the readable sectors, plus you need to keep the old parity to be able to recover if the disk with the unreadable sector is eventually able to read it. There is no way to do this in place, so the RAID layer need to set aside extra space somewhere to track this sort of complicated recovery.
If you have a RAID controller, which can take care of all of this, then it is probably using some proprietary layout of the data. That means if you lose the controller, then all the data is lost, unless you can find an identical controller. I haven't heard of any open standard for this sort of thing.
The format used for RAID 5 on Linux doesn't have any of this fancy stuff.
They want their capabilities architecture back.
Capabilities leads to complexity, complexity leads to bugs, bugs leads to vulnerabilities.
To build something secure, you need to aim for simplicity.
Of course that helps. But I still expect RAID 6 without patrol reads to provide better reliability than RAID 5 with patrol reads. I'm not sure which of the two is best for performance.
At some point in the past I setup a software RAID 5 on Linux and just created a weekly cron job to read through all the physical media. Not exactly a full solution, but does ensure that bad sectors will get noticed. I don't recall if software RAID 6 already existed at the time, but it certainly wasn't mature yet, so I didn't consider that option at the time.
It's a claim I have seen often, but I have never seen evidence to support it. A much more likely scenario, which can easily be misdiagnosed as simultaneous drive failures is the following. One disk gets a bad sector, which at first goes unnoticed. A second disk dies. During reconstruction the first bad sector is noticed and causes reconstruction to fail. To protect against that you can use RAID 6 or RAID 1 across three or more drives.
Is there a reason to worry about simultaneous failure of multiple SSDs? I don't know for sure. The best protection against that might be RAID 1 across SSD and harddisk. I don't know if there exist a RAID system, which can do this intelligently, but it certainly is feasible.
I wouldn't do this directly on the harddisk because of the bad seek performance of the harddisk. Instead I would take advantage of the much larger capacity you get on harddisks at the same price. Add a logstructured layer that causes writes on the harddisk to be sequential. If the physical capacity of the harddisk is multiple times the logical capacity (which is set to match the size of the SSD), then most of the physical sectors are unused, and there will only rarely be a need to skip used sectors during write (or they can be migrated ahead of time).
In such a setup the mirror on the harddisk would have terrible read performance, so all reads would go to SSD. If you do need to recover after the SSD has failed, the recovery can happen with a decent performance by reading data in the order it is physically stored on the disk rather than in the logical order. The result of this is sequential reads on the harddisk and random access writes on the new SSD.
Again you can use three media to protect against bad sectors discovered during recovery. For performance reasons you'd probably want the third drive to be an SSD as well such that you have two SSDs and just one harddisk.
Best argument for RAID 6 is bad sectors discovered during reconstruction. Assume one of your disks have a bad sector somewhere. Unless you periodically read through all your disks, you may not notice this for a long time. Now assume a different disk dies. Reconstruction starts writing on your hot spare. But during reconstruction an unreadable sector is found on a different drive. On RAID 5, that means data loss.
I have on one occasion been assigned the task on recovering from pretty much that situation. And some of the data did not exist anywhere else. In the end my only option was to retry reading the bad media over and over until on one pass I got lucky.
With RAID 6 you are much better off. If one disk is completely lost and you start reconstructing to the hot spare, you can tolerate lots of bad sectors. As long as you are not so unlucky to find bad sectors in the exact same location on two different drives, reconstruction will succeed. An intelligent RAID 6 system will even correct bad sectors in the process. When a bad sector is detected during this reconstruction, the data for both the bad sector as well as this location on the hot spare are reconstructed simultaneously and both can be written to the respective disk.
At the end of the reconstruction you not only have reconstructed the lost disk, you have also reconstructed all the bad sectors found on any of the drives. Should one of the disks run out of space for remapping bad sectors in the process, then that disk is next in line to be replaced.
I do like the idea of an operating system designed with such security in mind. The operating system is probably also going to require some sort of real time guarantees, but otherwise no requirements for ultra high performance.
As far as security goes, I think one important aspect is transparency. Code running on the operating system should probably not have much freedom to modify the underlying system, but it is crucial that they can see what is going on, such that you can monitor that nothing unexpected is running on the system.
I guess for most SCADA systems the risk of bad stuff happening due to unauthorized changes is a much greater concern than leaking information from the system.
Are Kaspersky the right people to build the OS? Time will show.
By the time you are considering using an atomic bomb, I guess being sued for patent infringement is the least of your concerns.
Great idea. Both Amiga OS and BSD has a Fast File System, Linux needs one as well.
Not really, no. Want two nodes connected in your network topology, just pull a wire or fibre between them. Requires lots of wires, but it is going to be better than wireless on throughput, latency, and reliability. Wireless is useful for devices that are constantly moved around. For anything stationary, pulling a wire is a better long term solution. And I assume servers in most data centers are considered stationary.
I know people who'd love to see wireless data centers become a reality (assuming they don't have to debug new problems). But I consider it to be a pipe dream. Wireless will never catch up with wired networks, because any wireless technology could be turned into something more reliable by using some sort of wires to ensure the signal gets where you want it, and not everywhere else.