A common application of RAID is fault-tolerant storage.
If one does not test one's product in the same configuration as used by one's customers, one's customers may find a failure mode that one's tests are incapable of finding. In AMCC's case I was concerned about the Special Magic that Apple used to convert 64-bit system calls to 32-bit.
The opinion of the engineer who originally wrote the driver I maintained was that a 32-bit tool was sufficient to test a 32-bit driver.
My opinion is that a 64-bit tool was required to test Apple's Special Magic. I have found and reported numerous bugs in Apple's kernels, all but two were promptly fixed.
I struggled to convince Apple to fix the other two, but was refused. One was fixed a year later after someone else reported it, the other is a spectacular zero-day that I could exploit in a heartbeat but I won't tell you what it is not so much because Apple refuses to fix it but because the fix would break a lot of existing code.
In 1990 I was testing MacTCP 1.0.1 or maybe 1.1. My manager Bruce Southwick suggested I beta test A/UX 2.0, in large part so I could help with A/UX' MacTCP emulation which was a wrapper around Berkeley sockets.
Among the first things I did was to verify A/UX' compliance with each of the CERT recommendations. When I found a security hole I dropped a dime to some random A/UX team member:
"May I speak to your Security Manager?"
"What's a Security Manager?"
Me and the A/UX people went back and forth for quite a long time until I attached a 12 or maybe 15 line remote root exploit to a Radar bug report. I then blasted an eMail all over G-d's Creation that pointed out that "The United States Air Force isn't going to want to pay seventy million dollars for this."
Their reply?
"We'll let the Air Force take care of it."
I could have fixed the zero day in ten minutes without breaking anything whatsover. Even so it was not fixed until A/UX 3.0.
A common application of RAID is fault-tolerant storage.
If one does not test one's product in the same configuration as used by one's customers, one's customers may find a failure mode that one's tests are incapable of finding. In AMCC's case I was concerned about the Special Magic that Apple used to convert 64-bit system calls to 32-bit.
The opinion of the engineer who originally wrote the driver I maintained was that a 32-bit tool was sufficient to test a 32-bit driver.
My opinion is that a 64-bit tool was required to test Apple's Special Magic. I have found and reported numerous bugs in Apple's kernels, all but two were promptly fixed.
I struggled to convince Apple to fix the other two, but was refused. One was fixed a year later after someone else reported it, the other is a spectacular zero-day that I could exploit in a heartbeat but I won't tell you what it is not so much because Apple refuses to fix it but because the fix would break a lot of existing code.
In 1990 I was testing MacTCP 1.0.1 or maybe 1.1. My manager Bruce Southwick suggested I beta test A/UX 2.0, in large part so I could help with A/UX' MacTCP emulation which was a wrapper around Berkeley sockets.
Among the first things I did was to verify A/UX' compliance with each of the CERT recommendations. When I found a security hole I dropped a dime to some random A/UX team member:
"May I speak to your Security Manager?"
"What's a Security Manager?"
Me and the A/UX people went back and forth for quite a long time until I attached a 12 or maybe 15 line remote root exploit to a Radar bug report. I then blasted an eMail all over G-d's Creation that pointed out that "The United States Air Force isn't going to want to pay seventy million dollars for this."
Their reply?
"We'll let the Air Force take care of it."
I could have fixed the zero day in ten minutes without breaking anything whatsover. Even so it was not fixed until A/UX 3.0.