As a former college lab instructor, I have a lot of experience with CompSci students that don't understand how a computer works. Some assembly language would have helped, but it's not the only solution.
I used to teach a lab at Clemson University for Computer & Electrical Engineering students (ECE371). Students built a piece of hardware for the ISA bus, then wrote software to control the hardware... in other words, build a peripheral and write a driver. The lab used a combination of C & assembly code.
Assembly Language was a pre-requisite for the ECE students, but CompSci students could take it without the pre-requisites. In general, I had to spend more time explaining basic concepts like input & output to the CompSci students than the ECE students.
Most of these students had no exposure to assembly language of any form (RISC or CISC). The inner workings of the processor were described in general terms, but they had no practical knowledge.
The industry trend in firmware development is away from assembly, moving to something like C that is abstracted from the platform. This is good because it requires more 'general' programming knowledge, but it can backfire if the C programmer a company tries to convert to a firmware/embedded developer doesn't understand how the computer works... then you end up with bad code (too big, too slow, large memory footprint, etc.).
The point of learning assembly isn't to know assembly... it's to understand the computer at it's lowest and most fundamental layer. If you don't think it makes a difference, go check out the educational background of the average Indian programmer.
Most (but not all) "casual" Rockports lack any type of metal reinforcement in the sole, and use plastic for the lace holes. I wear those the most when I go on day-trips with no luggage.
In three years of US & international travel, those shoes have never set off a metal detector (even the wand-type detector). My dress shoes have set off several detectors, since they have metal lace holes & a metal arch support built into the sole. I have had to run through Boston's Logan Airport in my socks, making the choice to put my shoes back on or miss the plane.
I have been tempted to go through security in my slippers (the ones with cigar-smoking bulldogs on the end), just to emphasize the absurdity of our "airline security" process. We'd all be better off if the TSA spent more time looking for terrorists instead of potential weapons. Being unarmed is a state of mind... just ask those Okinawian farmers who turned common tools into what we consider traditional martial arts weapons after the Japanese occupied the island and took away their swords.
RedHat & other distros already support EFI booting into IA64. The boot process isn't different from IA32 to IA64 (the spec is hardware-agnostic), and I know it's already been verified working on IA32 EFI systems.
Those 'BIOS destroyer' viruses worked because of how Intel engineered a particular reference design, not due to a BIOS flaw.
The Intel reference design motherboard of the day used a software general purpose input/output (GPIO) pin to control if the flash was in read-ony or reprogramming mode. This was a departure from the normal designs of the time, which used a hardware jumper to protect the flash ROM.
At the time, everybody making boards in Taiwan did little more that copy the reference design... so they took the design with the flash reprogramming GPIO as-is.
Somebody hacked/reverse-engineered/leaked the pin configuration from the Intel reference design. This lead to the virus. The fact the virus worked on so many systems is that the Intel chipset was very popular, hence the reference design got copied a lot.
Now it's much harder to pull this type of virus off. Different motherboard designers use different methods to protect against this. Intel's answer was to combine a hardware jumper with their own proprietary encryption system on their motherboards.
Intel's EFI Framework allows for a 'Compatibility Support Module' (CSM) that the board vendor can put in the firmware. It basically provides runtime services just like a legacy BIOS.
The whole thing is designed so the OS can use EFI firmware interface or a legacy BIOS interface, so one platform can support both. Even though it adds some size to the firmware image, it makes the industry transition easier.
Test utilities... lots and lots of test utilities. BIOS flash, PCI tests, disk utilities.
All on a nice, shiny 128MB USB key that's formatted to boot DOS (sigh).
I mistyped... I think the more appropriate statement is "The only way technology controls you is if you let it".
You've got two themes in your statement... one is how entities attempt to control how you use technology, the other is who to hold accountable for the undesirable application of technology.
I: Business organizations that provide software and media content want to protect their product. By "protect", I mean they want to deliver product to paying customers and prevent people who don't pay for that product from using it. Crackers, warez sites and p2p programs give these companies a good reason to explore security products.
The point is... these "copyright holders" only care about preventing non-paying users from using their product. They care about controlling their product, not your personal data. The fact that many of these "copyright holders" act like asshats in the way they attempt to implement these controls doesn't mean they don't have a right to stop people who don't pay from using their products.
So how does using a security product to stop a wannabe cracker from pirating software differ from using a security product to prevent the same wannabe cracker from reading your e-mail? The assumption that content protection only works one way sounds to me like people saying they don't have control over the technology they use... and I think that's bull.
II: If you're pressed for time, I'll sum up my feelings in one sentence: I honestly believe that ethical & moral issues of technology application fall to it's final use, not it's initial development.
If you have more time, read on...
Do I think about where technology is going... yes, all the time. I think about the fact that the technology I work on goes into passenger airplanes, server farms and people's homes. I also think about the fact that it goes into tanks and computers that simulate missile targeting systems.
The difference between the "consumer" and "military" applications isn't in the technology, but it's application. That applies as much to TCPA as anything else.
Think about this:Let's say weapons inspectors in Iraq raid a lab and discover nuclear weapons development. They start to go through the computers and find that they all run Debian Linux, setup in Beowulf clusters. The documentation of the development is done in OpenOffice, GPG was used to send coded e-mails to equipment dealers, and GNU Octave is used for all of the simulations.
Did the developers of these open-source programs consider the fact that their programs would be used to create weapons? Would they have stopped development? Are they responsible for the weapons created because they created tools used in their development?
We use MySQL as a backend... but RedHat Bugzilla uses a slightly different database structure. We forked database structure ourselves a while back to add some new fields.
We don't use public access (it's internal only, behind a firewall), so the security concerns aren't as severe. We have looked at moving back to the official Bugzilla, but we have also looked at migrating to other tools (php/MySQL based).
Well, you might be mad because we're using an old version of RedHat Bugzilla (2.7)... at the time, it was easier to install and the testers liked the interface more (even though I've hacked it quite a bit).
I don't mind if you put it on the page... it's not like I can deny it after saying it in an interview.
I'm not sure where to get a clear list of what motherboards boot to USB/USB2, but it should be a very popular feature this year.
BIOS provides USB boot for DOS by using the INT 13h disk access routines to fool DOS into thinking it's talking to a good'ol fashioned hard disk (the same way that MSCDEX.EXE works).
Any other operating system will support a 'handoff' that's outlined in the USB specification. The BIOS handles the boot loader, then the OS makes a transition from the BIOS USB handler to its own driver.
Windows doesn't support boot to USB right now (they have issues with drive hosting the OS being on a bus that supports 'suprise removal'). I have no idea if Linux supports USB boot (I think it does, but never tried it).
Windows 2000 and higher can be installed from bootable CD on USB (not USB 2.0). Windows XP SP1 can be installed from bootable CD on USB 2.0.
I can agree that engineers are born, not made. That type of thing seems to run in my family. I'm doing this 'engineering' thing because I love it, not because it looks good on a resume. I saw way too many people wash out of engineering programs because they got into it for the wrong reasons.
BTW, I do have BSEE & MSEE degrees from Clemson. I taught one year as a part-time processor at Devry, and two years of lab at Clemson. I am in the 'sales' end because I happen to be more comfortable traveling and talking to customers than my counterparts (and most of those guys were 'born engineers').
Yeah, we could do that, or we could interview a BIOS person.
You got an interview with a BIOS person, not a security person. The deeper questions you want answered aren't in my realm... which was the main thing I wanted to explain in the interview.
Don't like this? Buy/support/use software that does not constrain you. That's your option. Boycotting AMI or TCPA-enabled motherboards does not solve the problem; those manufacturers are responding to a demand from software developers and content owners. It is up to you to show those people that you do not want to be curtailed and restricted and denied at every juncture.
That's a good way to explain it. Perhaps I should have said that in the interview.
We don't have access to any released applications that make use of the TPM outside of basic test utilities. I have no real idea how the final products will work. Some of them may be good, some may suck.
I gave as much information as I could based on the specs I have. I may be considered an 'authority' on BIOS, but I am far from an authority on security issues.
My company got sucked into this whirlwind because of the politics of TCPA/Palladium, and I decided to do what I could to try and separate fact from fiction (I can't do anything about the paranoia, but I hear there is a pill for that).
Brian Richardson (AMI)
Well, that is a bit harsh. You make sound like I'm hanging out in Hollywood, smoking cigars with agents as the MPAA hands me a contract for their next line of motherboards.
I think I can addess my feelings on the situation using the following vernacular: "Don't hate tha playa, hate tha game."
Just remember that it's not the tool, but how you use it. I can build with a hammer, or I can use it to break bone. I can use GPG to send my personal e-mail, or I can use it to sneak nuclear secrets to the North Koreans.
Well, there's over 150 companies behind TCPA (I don't know why you can't view the membership list from their website). They span all aspects of the computer industry, and publish their specifications. I don't know how that can be improved to be more open.
Slashdot Mirror
As a former college lab instructor, I have a lot of experience with CompSci students that don't understand how a computer works. Some assembly language would have helped, but it's not the only solution.
... in other words, build a peripheral and write a driver. The lab used a combination of C & assembly code.
... then you end up with bad code (too big, too slow, large memory footprint, etc.).
... it's to understand the computer at it's lowest and most fundamental layer. If you don't think it makes a difference, go check out the educational background of the average Indian programmer.
I used to teach a lab at Clemson University for Computer & Electrical Engineering students (ECE371). Students built a piece of hardware for the ISA bus, then wrote software to control the hardware
Assembly Language was a pre-requisite for the ECE students, but CompSci students could take it without the pre-requisites. In general, I had to spend more time explaining basic concepts like input & output to the CompSci students than the ECE students.
Most of these students had no exposure to assembly language of any form (RISC or CISC). The inner workings of the processor were described in general terms, but they had no practical knowledge.
The industry trend in firmware development is away from assembly, moving to something like C that is abstracted from the platform. This is good because it requires more 'general' programming knowledge, but it can backfire if the C programmer a company tries to convert to a firmware/embedded developer doesn't understand how the computer works
The point of learning assembly isn't to know assembly
Most (but not all) "casual" Rockports lack any type of metal reinforcement in the sole, and use plastic for the lace holes. I wear those the most when I go on day-trips with no luggage.
... just ask those Okinawian farmers who turned common tools into what we consider traditional martial arts weapons after the Japanese occupied the island and took away their swords.
In three years of US & international travel, those shoes have never set off a metal detector (even the wand-type detector). My dress shoes have set off several detectors, since they have metal lace holes & a metal arch support built into the sole. I have had to run through Boston's Logan Airport in my socks, making the choice to put my shoes back on or miss the plane.
I have been tempted to go through security in my slippers (the ones with cigar-smoking bulldogs on the end), just to emphasize the absurdity of our "airline security" process. We'd all be better off if the TSA spent more time looking for terrorists instead of potential weapons. Being unarmed is a state of mind
RedHat & other distros already support EFI booting into IA64. The boot process isn't different from IA32 to IA64 (the spec is hardware-agnostic), and I know it's already been verified working on IA32 EFI systems.
Those 'BIOS destroyer' viruses worked because of how Intel engineered a particular reference design, not due to a BIOS flaw.
... so they took the design with the flash reprogramming GPIO as-is.
The Intel reference design motherboard of the day used a software general purpose input/output (GPIO) pin to control if the flash was in read-ony or reprogramming mode. This was a departure from the normal designs of the time, which used a hardware jumper to protect the flash ROM.
At the time, everybody making boards in Taiwan did little more that copy the reference design
Somebody hacked/reverse-engineered/leaked the pin configuration from the Intel reference design. This lead to the virus. The fact the virus worked on so many systems is that the Intel chipset was very popular, hence the reference design got copied a lot.
Now it's much harder to pull this type of virus off. Different motherboard designers use different methods to protect against this. Intel's answer was to combine a hardware jumper with their own proprietary encryption system on their motherboards.
Link to presentation
The whole thing is designed so the OS can use EFI firmware interface or a legacy BIOS interface, so one platform can support both. Even though it adds some size to the firmware image, it makes the industry transition easier.
My dual PPro 150 MHz (yes, the rare 150) runs my home firewall & server using ClarkConnect. It's been up almost three years straight.
Test utilities ... lots and lots of test utilities. BIOS flash, PCI tests, disk utilities.
All on a nice, shiny 128MB USB key that's formatted to boot DOS (sigh).
I'm glad to see IBM directly address TCPA issues. Their explaination of how TCPA works is better than what I had for the AMI/Slashdot interview.
I'm also happy to see a TCPA/TPM driver for Linux (was wondering when sopmebody would get around to that).
Brian Richardson - AMI
You've got two themes in your statement ... one is how entities attempt to control how you use technology, the other is who to hold accountable for the undesirable application of technology.
I: Business organizations that provide software and media content want to protect their product. By "protect", I mean they want to deliver product to paying customers and prevent people who don't pay for that product from using it. Crackers, warez sites and p2p programs give these companies a good reason to explore security products.
The point is ... these "copyright holders" only care about preventing non-paying users from using their product. They care about controlling their product, not your personal data. The fact that many of these "copyright holders" act like asshats in the way they attempt to implement these controls doesn't mean they don't have a right to stop people who don't pay from using their products.
So how does using a security product to stop a wannabe cracker from pirating software differ from using a security product to prevent the same wannabe cracker from reading your e-mail? The assumption that content protection only works one way sounds to me like people saying they don't have control over the technology they use ... and I think that's bull.
II: If you're pressed for time, I'll sum up my feelings in one sentence: I honestly believe that ethical & moral issues of technology application fall to it's final use, not it's initial development.
If you have more time, read on ...
Do I think about where technology is going ... yes, all the time. I think about the fact that the technology I work on goes into passenger airplanes, server farms and people's homes. I also think about the fact that it goes into tanks and computers that simulate missile targeting systems.
The difference between the "consumer" and "military" applications isn't in the technology, but it's application. That applies as much to TCPA as anything else.
Think about this: Let's say weapons inspectors in Iraq raid a lab and discover nuclear weapons development. They start to go through the computers and find that they all run Debian Linux, setup in Beowulf clusters. The documentation of the development is done in OpenOffice, GPG was used to send coded e-mails to equipment dealers, and GNU Octave is used for all of the simulations.
Did the developers of these open-source programs consider the fact that their programs would be used to create weapons? Would they have stopped development? Are they responsible for the weapons created because they created tools used in their development?
We use MySQL as a backend ... but RedHat Bugzilla uses a slightly different database structure. We forked database structure ourselves a while back to add some new fields.
We don't use public access (it's internal only, behind a firewall), so the security concerns aren't as severe. We have looked at moving back to the official Bugzilla, but we have also looked at migrating to other tools (php/MySQL based).
I'm now a member of the Tech Corps board of directors. We haven't finished the new web page yet. That information will be part of the new page.
And, yes, our website is really in need of an update. We're letting the board member who works at Earthlink handle that.
Well, you might be mad because we're using an old version of RedHat Bugzilla (2.7) ... at the time, it was easier to install and the testers liked the interface more (even though I've hacked it quite a bit).
... it's not like I can deny it after saying it in an interview.
I don't mind if you put it on the page
If we can't agree on that, then there's no answer that I can ever give to make you happy.
BIOS provides USB boot for DOS by using the INT 13h disk access routines to fool DOS into thinking it's talking to a good'ol fashioned hard disk (the same way that MSCDEX.EXE works).
Any other operating system will support a 'handoff' that's outlined in the USB specification. The BIOS handles the boot loader, then the OS makes a transition from the BIOS USB handler to its own driver.
Windows doesn't support boot to USB right now (they have issues with drive hosting the OS being on a bus that supports 'suprise removal'). I have no idea if Linux supports USB boot (I think it does, but never tried it).
Windows 2000 and higher can be installed from bootable CD on USB (not USB 2.0). Windows XP SP1 can be installed from bootable CD on USB 2.0.
Brian Richardson - AMI
Preach on brother!
I can agree that engineers are born, not made. That type of thing seems to run in my family. I'm doing this 'engineering' thing because I love it, not because it looks good on a resume. I saw way too many people wash out of engineering programs because they got into it for the wrong reasons.
BTW, I do have BSEE & MSEE degrees from Clemson. I taught one year as a part-time processor at Devry, and two years of lab at Clemson. I am in the 'sales' end because I happen to be more comfortable traveling and talking to customers than my counterparts (and most of those guys were 'born engineers').
Brian Richardson - AMI
You got an interview with a BIOS person, not a security person. The deeper questions you want answered aren't in my realm ... which was the main thing I wanted to explain in the interview.
Brian Richardson - AMI
That's a good way to explain it. Perhaps I should have said that in the interview.
Brian Richardson - AMI
I did write this in OpenOffice ... I guess there's still some bugs in the spell/grammar check.
... that's not bad for me. Just don't let my mom read it.
Eleven errors in eleven pages
Brian Richardson - AMI
We don't have access to any released applications that make use of the TPM outside of basic test utilities. I have no real idea how the final products will work. Some of them may be good, some may suck. I gave as much information as I could based on the specs I have. I may be considered an 'authority' on BIOS, but I am far from an authority on security issues. My company got sucked into this whirlwind because of the politics of TCPA/Palladium, and I decided to do what I could to try and separate fact from fiction (I can't do anything about the paranoia, but I hear there is a pill for that). Brian Richardson (AMI)
He asked me why to buy AMI over a competitor ... that's what I answered. That's what I do for a living, so I had an answer.
If he wanted to ask about something else, he should have asked a different question.
Brian Richardson - AMI
Actually, it's the EE degree from Clemson and the 6.5 years on the job writing code. Brian Richardson (AMI)
Well, that is a bit harsh. You make sound like I'm hanging out in Hollywood, smoking cigars with agents as the MPAA hands me a contract for their next line of motherboards.
I think I can addess my feelings on the situation using the following vernacular: "Don't hate tha playa, hate tha game."
Just remember that it's not the tool, but how you use it. I can build with a hammer, or I can use it to break bone. I can use GPG to send my personal e-mail, or I can use it to sneak nuclear secrets to the North Koreans.
Brian Richardson
I think that's the best description of the situation I've seen yet. This guy has the right idea on how to handle TCPA from a consumer standpoint.
Brian Richardson (AMI)
Well, there's over 150 companies behind TCPA (I don't know why you can't view the membership list from their website). They span all aspects of the computer industry, and publish their specifications. I don't know how that can be improved to be more open.