Slashdot Mirror

Rob Westervelt writes "Computer Associates is making its open sourced Ingres DBMS widely available today on Windows and Linux, pitching its mature features and 64-bit support at Oracle and SQL Server customers."

RideMax writes "Forbes today has posted a nice selection of printer-friendly halloween masks, including those of several dead celebrities, and of course, this famous billionaire." An anonymous reader sent in a strange Halloween Geek Test. And another reader sent in the iPod-O-Lantern.

Bug-Y2K writes "Looks like storage giant EMC, is buying longtime Mac software company Dantz Develpment. Dantz, makers of Retrospect have been the leader in backup technology for the Mac OS since dinosaurs roamed the earth. Mindshare has been slipping of late but the product is known for being better at restores than anything out there. I wonder what lies in store for Retrospect now?"

Amy Kucharik writes "Two new reports on open source validate office suite application alternatives like OpenOffice.org and StarOffice and their push into the mainstream against market giant Microsoft Office. "

Amy Kucharik writes "Two new reports on open source validate office suite application alternatives like OpenOffice.org and StarOffice and their push into the mainstream against market giant Microsoft Office. "

Michael S. Mimoso writes "A Yankee Group survey of 473 enterprise decision makers reveals that companies have put aside money for service-oriented architectures for 2005." This is a bigger deal than it sounds - if companies keep moving this away, it will mean a sea change in corporate technology usage - and change the way/why development is done. We're talking everything from SOAP stuff (ITMJ is part of OSTG) to wholesale ASP adoption like Salesforce.com.

Michael S. Mimoso writes "A Yankee Group survey of 473 enterprise decision makers reveals that companies have put aside money for service-oriented architectures for 2005." This is a bigger deal than it sounds - if companies keep moving this away, it will mean a sea change in corporate technology usage - and change the way/why development is done. We're talking everything from SOAP stuff (ITMJ is part of OSTG) to wholesale ASP adoption like Salesforce.com.

Michael S. Mimoso writes "Market research firm Radicati Group predict Web services spending to reach $6.2 billion by 2008 as companies invest heavily in development tools and security."

Michael S. Mimoso writes "Market research firm Radicati Group predict Web services spending to reach $6.2 billion by 2008 as companies invest heavily in development tools and security."

Alex Moskalyuk writes "'Open source is great, but where do we start?' This is probably one of the most frequently asked questions in the corporate world when CIOs are faced with the need to choose between open and proprietary solutions. How do you figure out when it's feasible to implement an open source solution? Are there any support or training options if the solution does get approved, or if the project chosen was an alpha version developed by some student, who's away for the summer? Bernard Golden from NavicaSoft has probably heard the same questions too often, and then decided to write the book." Read on for prostoalex's review. Succeeding with open source author Bernard Golden pages 272 publisher Addison-Wesley Professional rating 7 reviewer Alex Moskalyuk ISBN 0321268539 summary IT manager's guide into implementing an open-source solution

Implementing an open source solution requires a different approach from the buyer's point of view: There is no salesperson you'll get a call from, there are no license agreements to sign and no serial numbers to enter. Access to the software is simplified, but sometimes there are few pointers about what to do next.

Golden takes the reader through different aspects of dealing with open source technologies. As one can see from the table of contents, the information is presented from the business professional's point of view. This title is for an IT manager, not developers or IT personnel who might be using open source products already and feel strongly about them. The basic question that the book explores is this: When does it make sense for an organization to implement an open source product? How do you evaluate the product's maturity, functionality, ease of use, support infrastructure and documentation quality so that running open source within the organization starts making sense?

Golden's answer is the Open Source Maturity Model (OSMM), which the author developed himself. The model asks the IT manager to evaluate the software, support, training options, documentation, integration and professional services on 10-point scale. If the technology ranking reaches a certain score (which highly depends on the userbase), then it will make sense to implement it.

For example, on page 144, when the author discusses software support options, he suggests assigning 6 points for excellent community support, 3 points for available paid support and 1 point for availability of self-support (i.e., an employee who understands the product). So on the next page JBoss gets 6 points for community support (very helpful and respectful forums), 2 points for commercial support (since it was e-mail and phone only, and no on-site support) and 0 points for self-support (since no one within the organization stepped up to claim herself as JBoss expert).

JBoss is the prime example used by the author throughout the chapters, and turns out to be quite a convenient choice -- the company offers commercial support, training and documentation for an open-source product. Golden's model is supposed to help IT managers distinguish high-quality open source projects from 0.0.1 version, so widely available on SourceForge.

The book's primary market is business professionals and IT managers who would probably benefit from having a formal evaluation model instead of relying on pure gut feeling. Despite the book's ambiguous title, it's not a manual on how to create your own business with open-source products. Some chapters will be helpful for figuring that out (Chapter 2 talks about business models in the open source world), but it's mostly for people who are implementing rather than developing open source products. The language is somewhat dry, but if your weekly reading requires CIO Magazine, you're probably used to that.

Something I think the author would have done well to include is a collection of in-depth case studies on open source implementations. There's some data on Sabre and Charles Schwab running successful businesses on open-source infrastructure, but the details are not there. While certain companies publish hundreds of case studies to prove that their products will either save money or allow the customer to make more, the success stories are not that frequently publicized in the open source world. Having such material in the book would provide a confidence booster for an IT manager, I think.

The last chapter or the first appendix is where I would expect to find information on solid open-source products suitable for corporate deployment. I mean, if the evaluation model is introduced, why not list the most prominent projects out there for quick reference? The highest-ranked open-source operating system, office suite, corporate messaging system, accounting and tax package, etc.?

Overall the book is pretty good for a manager who has heard of open source, but has not read too much into it. Chapter 1 in PDF format is available from Addison Wesley site. Golden also wrote an article for OreillyNet that deals with bringing open source into the organization. There's also an interview with the author on TechTarget.

You can purchase Succeeding With Open Source from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Michael S. Mimoso writes "A Forrester Research report points out that major vendors are encroaching on the Web services market currently dominated by smaller specialty vendors. That could make for some trying times in the near future for enterprises exploring Web services and SOA."

Michael S. Mimoso writes "A Forrester Research report points out that major vendors are encroaching on the Web services market currently dominated by smaller specialty vendors. That could make for some trying times in the near future for enterprises exploring Web services and SOA."

An anonymous reader writes "Beowulf clustering turns 10 years old, and, in this interview, creator Donald Becker talks about how Beowulf can handle high-end computing on a par with supercomputers."

vincecate writes "In their 10-K filing, Microsoft says that Linux server units rose slightly faster on an absolute basis than Windows server units in fiscal 2004. To project the trends it is helpful to look at the percentages. Some Gartner Inc. statistics report Linux server unit shipments are up 61% giving it 9.5% of the overall market share. Windows has a much larger base, so it can get the same absolute unit growth with a much lower percentage. Gartner expects Linux to continue growing faster and have more than 1/2 of the new server shipment market by the end of 2008."

kinrowan writes "MIT, inventor of Kerberos, has announced a pair of vulnerabities in the software that will allow an attacker to either execute a DOS attack or execute code on the machine. Some details of the story are at SearchSecurity as well as ComputerWeekly. Details of the advisories themselves are also available. The vulnerabilities also affect the VPN 3000 line of Cisco VPN concentrators."

Dozix007 writes "There is an interesting article by Jan Stafford on the myths of Linux creation. This episode of the series of Linux creation myths, one fellow plays "I Spy," and the other reveals the true origins of the man from Redmond. The author is offering a $50 gift certificate and IT books to the best spinners of tall Linux creation tales. If you can outdo these tall tales."

Kardamon writes "In an article on DBAzine, Fabian Pascal writes that SQL is not a good representation of the relational model, and is afraid the situation will get worse with XML and XQUERY. An overview of some of the reactions on the positions Pascal and also C.J. Date take on this issue is given in this article over at SearchDatabase.com by Sara Cushman."

Anonymous Coward writes "Red Hat announced a new advanced certification today, Red Hat Certified Architect. One training expert, however, cautions that Red Hat certifications can lock administrators in to Red Hat-specific skills."

Read on below for tonight's edition of Slashback, with followups to several previous Slashdot stories, including the Linux-in-Munich saga, Harlan Ellison's feud with AOL, Hotmail's response to the growing space for webmail, and more. Read on for the details.

Please don't link "here": case in point. Kent Brewster writes "As previously mentioned here(1), here(2), and here(3), national treasure Harlan Ellison has been fighting a drawn-out battle with AOL over alt.binaries.e-book. Looks like a settlement has been reached; details (such as they are) are on AOL."

Papa Legba adds a link to an informative page on the suit's progress, with lots of informative links.

The basement dwellers burrow deeper. kevin_conaway writes "Accoring to this article on Tech Target, the DNS outage at Akamai was caused by a massive DDOS attack on Akamai's servers. Akamai Technologies Inc. said a 'sophisticated, large-scale distributed denial of service attack' on its domain name service bogged down several of its clients' Web sites yesterday morning, and that it's investigating the incident with federal authorities."

Time to quit your Winin' marmoset writes "As a followup to this story, Dave Winer has posted information about transitioning weblogs.com sites. Rogers Cadenhead and Steve Kirks pitched in to help. The plan includes a 90-day free evaluation period, during which the affected users will be able to make local copies of their data, sign up for paid hosting, or move to another hosting solution."

Pay up, Pal. ack154 writes "Following up from a previous slashdot story, PayPal may have reached a preliminary settlement in the class action lawsuit brought against them in 2002. The lawsuit was regarding the freezing of suspected fraud accounts and communication of limits on accounts. Limited details are available right now, but the eBay announcement states that anyone who signed up for a PayPal account between Oct 1999 and Jan 2004 may be eligible."

Forkenbrock points to this USAToday today article which says that "Ebay's Paypal will pay a total of 9.25 million dollars to its users (businesses and individuals)."

What about Java vs. T++? Stefan de Bruijn was one of several readers who reacted to the benchmarks cited in the Slashdot post titled 'Java faster than C++'.

He writes "I took the liberty to re-write a major piece of the C++ part of the benchmark. Furthermore, the Intel compiler has been tested as well. The Java code was assumed 'correct.'

The results are quite different than the former posting. Here, C++ appears to be a winner for the vast majority of programs; where Java scored better with (recursive) algorithms and the use of file IO (where it must be remarked that the C++ code uses iostreams)." joekaylor writes "I did a similar study 6-months ago to the study sited recently here on Slashdot, and I did it with java jdk 1.4.x. Java performance has been underestimated for QUITE some time. It's not the best tool every time, but it is not considered often enough and for the wrong reasons."

And an anonymous reader writes "This article by USC graphics researchers surveys a number of good (mostly numeric) benchmarks and then explains the theory of why maybe java should be faster than C++. It also raises the (unanswered) question of why geeks (ostensibly intelligent and scientifically-minded people) continue to believe some ideas (for example, 'garbage collection is slow') despite strong evidence to the contrary that has been available for many years."

Well, it's sort of like a gigabyte. helloanand writes "So, a day after yahoo relaunched their email service with 100 MB space, hotmail also expanded their offering to 25 MB. Just logged into my hotmail account and saw the space bumped up. The thing that I noticed is that MSN/Hotmail didn't make a big splash about it. Its actually a good thing for the users. Gmail started this trend by coming up with 1 GB (yes! gigabyte) worth of space. Then yahoo joined the party with their own 100 MB version and now the latest to join in bill gates & co (aka MSN Hotmail). Lets see what other changes does Gmail stimulate to the email service. Also the thing to note is that Google's gmail is being closely observed by the established players like MSN and Yahoo."

Each city represents a star system; players alternate by country. Wudbaer writes "The Munich city council has finally OK'ed the multi-step 30 Million Euro project to migrate the Munich city council to Linux, as heise news reports (German text). The planned high-profile migration of the administration of one of the largest cities in Germany has already created a lot of interest both in pro and anti-OSS camps, and was rumored to have run into substantial problems at the beginning of the year which might have endangered the council's final OK for the project. But now apparently the road is open for the project. Go Tux !"

Marcus links to this announcement on the city government's web page, and suggests that you put it through Google.

securitas writes "Hot on the heels of Munich's decision to go with Linux, the City of Bergen, Norway will replace its Unix and Windows core infrastructure with SUSE Linux Enterprise Server 8. The second part of the implementation will migrate the city's educational network - with 100 schools and 32,000 users - from 100 Windows application servers to 20 Linux IBM eServer BladeCenters. Bergen is Norway's second-largest city. ZDNet UK's Michael Parsons discusses the choice in an interview with Bergen CTO Ole Bjoern Tuftedal."

Making less of a mess. HishamMuhammad writes "The GoboLinux story featured recently on /. got the project some publicity, but again a number of misconceptions showed up, from people who think we are "just another user-friendly distro", because of our verbose pathnames like /System/Settings. Here is an article I wrote in order to explain the principles behind the design of GoboLinux (also in PDF), which tells our side of the story."

Anonymous Coward writes "Usenix Association president Marshall Kirk McKusick is a veteran of BSD's intellectual property scuffle with AT&T in the 1990s, and he's got some thoughts and advice for the keepers of the Linux kernel going forward, commenting: 'There isn't a well-documented ownership trail with Linux. So, they have opened themselves up to a swamp of 'he said-she said' about where code came from'."

Gudlyf writes "First the blinking LED security issue, now this: listening to tell-tale keyboard clicks to decipher from afar what a person is typing. This isn't limited to just computer keyboards -- ATM's, telephone keypads, security doors, etc. Apparently with $200 worth of sound equipment and software, these keyboard clicks can be translated to within 80% accuracy. Of course, a whole lot of this is just theory."

An anonymous reader writes "SearchEnterpriseLinux.com is featuring an interview with Novell/Ximian's Nat Friedman on the increasing interest about the Linux desktop. Quote from the interview - "A day doesn't go by when I don't talk to a Fortune 1000 customer from the financial services market, automotives or others that are not looking at dipping their feet into the Linux desktop." And by the way, both Nat Friedman and Miguel de Icaza's April 12th blog entry have a picture of Miguel and Nat dancing with David Vaskevitch, CTO of Microsoft. Now that's something you don't get to see everyday!"

jagger writes "Linux clustering was touted as the next big thing by many vendors last week at ClusterWorld Conference & Expo 2004. But supercomputer vendor Cray Inc. scoffed at the notion of putting Linux clusters in the high-performance computing (HPC) category. "Despite assertions made by Linux vendors, a Linux cluster is not a high performance computer," said Dr. Paul Terry, CTO of Cray Canada."

louismg writes "Data storage giant EMC announced upgrades to their storage hardware family this morning, and claimed performance increases of 25% to 100%, with increased capacity and disk speeds. This comes two weeks after competitor BlueArc announced Titan, the world's biggest ever NAS box, which claims throughput of 5 Gbps and 256 terabytes in a single hardware file system. How much is enough, and as IT administrators, what is the answer to today's issues - improved hardware, or software?"

Great_Jehovah writes "The CIO of Just Sports USA received an extortion letter from SCO, started a thread about it on the pgsql-general and then posted his response letter after weighing the various pieces of advice and info he received. Here's hoping that most of SCO's intended victims do the same." An anonymous reader submits a story in a Utah paper about SCO: "The Salt Lake City Weekly paper is running a front page article on the SCO shenanigans. The reporter interviewed Darl, Linus, Bruce Perens and others for the article with new choice quotes from them all." Also, IBM at Linuxworld claims it will win against SCO (miscellaneous plug: CmdrTaco will be speaking at Linuxworld later today).

mrSinclair writes "the 'Bagle' or 'Beagle' worm is expected to hit the U.S. by midweek, probably Tuesday as many employees return from a three-day weekend." He points to this Washington Post story (via Yahoo!), which describes the Windows mass-mailing worm as being transmitted via email as an .exe attachment and as installing "a program that lets attackers connect to infected machines, install malicious software or steal files." The article says Bagle has been detected in more than 100 countries. Other readers have sent in links to coverage at the BBC and at SearchSecurity.com.

scubacuda writes "DRMwatch reports that technologists acting on behalf of porn publisher Titan Media reported to Congress that P2P networks could (if they wanted to) use "fingerprinting" (aka "hashing") to detect copyrighted works and then filter them with the "spyware" installed on all nodes in the network."

scubacuda writes "DRMwatch reports that technologists acting on behalf of porn publisher Titan Media reported to Congress that P2P networks could (if they wanted to) use "fingerprinting" (aka "hashing") to detect copyrighted works and then filter them with the "spyware" installed on all nodes in the network."

hrhsoleil writes "In the category of: This seems like a no-brainer and why-didn't-someone-do-it-before, according to SearchMobileComputing, the Internet Protocol Detail Record Organization (IPDR) is pushing a set of specifications that would allow users to roam among different providers' hot spots. IPDR is an industry group that addresses billing issues for wireless carriers -- they've got the Wi-Fi Alliance, Gric Communications, and the Canadian Wireless Telecommunications Association backing them up on this one so it might actually get off the ground. It's about time that wireless ISPs get their act together and make roaming possible. If I can go to almost any bank machine in the world and be able to use it without needing to sign up for a new account, why can't I do the same with hot spots?"

VernonNemitz asks: "Light-Emitting Diodes (LEDs) have been around for decades, and they come in all colors. Here are the basic principles behind their operation, information on what's currently in production , and other practical info. Now, you would think it obvious that video displays should be made from LEDs, to take on the various competitors. Certainly this has been done on a large scale, and I am not the first to be interested in LED display technology for home viewing. The apparent goal of silicon LEDs these days seems to be tied up with optical communications between circuits, have they forgotten the possibility of making high-resolution display panels?"

"Achieving a good image will require smaller pixels, and now I have a better understanding of what has been holding it up, so would like to share what I found out. Basically, unlike a lot of electronic technology, LEDs are mostly -not- made from silicon. So, while silicon diodes are common, and large arrays of them are also made (for sensors), LEDs are not easy to incorporate into standard integrated-circuit manufacturing. Nevertheless, researchers have been pursuing and steadily making progress toward integrating silicon-based LEDs. Even whole arrays, 'suitable for large two-dimensional areas', of silicon laser LEDs have been made, as far back as three years ago."

hrhsoleil writes "Johnny Barnes, IBM's vice president of global IT solutions and standards, told attendees at a TechTarget conference this week that his company plans to migrate at least 80% of its more than 300,000 employees to voice over IP by 2008. The project will replace approximately 900 PBXs around the world with regional IP installations. IBM's server-based IP telephony platform is going to run on Linux."

techcon writes "An Australian startup Planetwide has launched an interesting product called Scan Me. The idea is simple, you redirect your snail mail to them and they scan your physical mail and email it all to you as a text searchable PDF. Targeted at the world wide traveller, it also looks like a good way to help prevent identity theft and getting nasty white powder in the mail."

techcon writes "An Australian startup Planetwide has launched an interesting product called Scan Me. The idea is simple, you redirect your snail mail to them and they scan your physical mail and email it all to you as a text searchable PDF. Targeted at the world wide traveller, it also looks like a good way to help prevent identity theft and getting nasty white powder in the mail."

HRHsoleil writes "If you're addicted to horoscopes, you going to love these Horoscopes for geeks." Mine was surprisingly accurate, thus proving beyond a shadow of a doubt the power that a gaseous orb a zillion miles away exhibits upon my laptop.

luetin asks: "Our company is at the point where our storage and backup infrastructure is ok, but not for much longer. We are looking into SAN, NAS, and variations thereof. We are a small IT department, with two sysadmins and two programmers. Right now we have stored/circulating about 2TB of data, and that's going to increase steadily in coming years. Does Slashdot have experience setting up SANs? Tales of costs and benefits of SANs versus a gaggle of NAS? Can SAN be implemented by reasonably seasoned IT people, or is it too dark an art?"

scubacuda writes "Using a honeypot to detect and surveil computer intruders might put you on the working end of federal wiretapping beef, or even get you sued by the next hacker that sticks his nose in the trap, according this (old) Security Focus article. Honeypots could be federal criminal law calls "interception of communications", a felony that carries up to five years in prison. Because the Federal Wiretap Act has civil provisions, as well as criminal, there's even a chance that a hacker could file a lawsuit against a honeypot operator that doesn't have their legal ducks in a row. "It would take chutzpah," said Richard Salgado, senior counsel for the Department of Justice's computer crime unit, "But there's a case where an accused kidnapper who was using a cloned cell phone sued for the interception of the cell phone conversations... And he won.""

doormat writes "According to this article, Gates says you can choose not to use the new secure PC technology that they're developing. Is that going to be a choice like being a vegetarian, or like choosing not to eat at all?" There's also a short piece about DRM and Linux, which is a follow-up to Linus on DRM.

scubacuda writes "Jon Lasser of the Register opines that we should "give up on the notion that computer security can be improved by putting more people in prison." He argues that a "harm reduction" approach (similar to that of "clean needle" campaign in the War on Drugs) might be more productive. If we, say, wrote in safer programming languages, used tools like Immunix's StackGuard, ProPolice, or OpenBSD 3.3, chroot and UML, we could reduce the damage a malicious hacker might do without damaging our civil liberities."

scubacuda writes "Jon Lasser of the Register opines that we should "give up on the notion that computer security can be improved by putting more people in prison." He argues that a "harm reduction" approach (similar to that of "clean needle" campaign in the War on Drugs) might be more productive. If we, say, wrote in safer programming languages, used tools like Immunix's StackGuard, ProPolice, or OpenBSD 3.3, chroot and UML, we could reduce the damage a malicious hacker might do without damaging our civil liberities."

scubacuda writes "Today's Bottom Line links to an article on Internet-over-powerline technology. St. Louis-based Ameren Corp and other utilities are testing are testing the technology, and, according to the article, "many consider it increasingly viable." Proponents claim the powergrid technology will bolster broadband competition, lower consumer prices and bridge the digital divide in rural areas. Skeptics say that few tests prove its financial and technical viability. Kludge, panacea, or hoax? (I'd think it was a total crock had I not personally known someone working in India with a PCL company)"

Orasis writes "The Open Content Network is a collaborative effort to help deliver open source, public domain, and Creative Commons-licensed content using peer-to-peer technology. The network is essentially a huge 'virtual web server' that links together thousands of computers for the purpose of helping out over-burdened/slashdotted web sites. Any existing mirror or web site can easily join the OCN by tweaking the HTML on their site."

We ran the "Call for questions" Monday, January 13, under the headline, Discuss BIOS and Palladium Issues With an AMIBIOS Rep. Note that Brian Richardson, AMI sales engineer, is a real engineer, not just a salesperson, and is also a staunch Slashdot reader who knows we have low tolerance for PR whitewashes around here. Brian's answers are real, not laundered, and he responded not only to the 10 questions we sent him but also to some he felt deserved answers even though they weren't moderated all the way up. Please note that in much of this interview he is speaking as "Brian Richardson, individual," and that his opinions do not necessarily reflect those of AMI's management. With that said, be prepared to learn a lot about the BIOS business, and how TCPA and Palladium relate (and don't relate) to it.

Preface:

I thought it might be handy for the audience to know who's handling their questions ...

My name is Brian Richardson. I work for American Megatrends, Inc . (AMI). AMI is a privately held company located in Norcross, GA (just north of Atlanta). We employ approximately 400 people worldwide (about 200 in the United States).

I am a "BIOS Sales Engineer", responsible for handling technical issues related to selling and marketing the AMIBIOS8 , our latest BIOS code revision. This includes writing whitepapers, demonstrating products, answering technical sales questions, speaking at industry conferences and handling requests from the press that may require more than a passing knowledge of technology (like this one).

I started at AMI in 1996. I've been in this job for two years. Before that I wrote BIOS code for our notebook team and helped design our Software Quality Automated Testing (SQuAT) system. I also maintain several company intranets and our Bugzilla server, used for tracking bugs during BIOS development.

In spare time, I serve on the board of directors of Tech Corps Georgia. I also managed the Hardware section of linux.com (old articles are archived at linux.omnipotent.net).

This interview covers BIOS in general, but the questions have a heavy slant towards TCPA & Palladium. I'm sure I won't address everybody's TCPA related questions here. AMI has a "TCPA and AMIBIOS8" whitepaper at our website which discusses AMI's implementation. There are also links to other information on TCPA.

To answer some of the more unusual questions that didn't make it into the Top 10:

• You use XOR to clear a register instead of a simple MOV instruction because of the instruction size (XOR uses a two byte opcode, MOV uses three bytes). The savings in space really adds up after a while.

• We haven't finished 1394 boot yet, but we do have USB & USB 2.0 boot support

• I don't know, I've never met Satan ... but I have been to WinHEC

Now on to the questions ...

1) On the Exclusionary Uses of TCPA

by the-banker

Is it (will it be) possible to use TCPA to effectively lock-out certain operating evironments from various services (software, media, etc) solely because the operating environment is not backed by a company, and has no mechanism for paying certification fees and licenses? Specifically, could TCPA be used against free OS's like Free/Open/netBSD and Linux to prevent those users from accessing the same content users of commercial OS's can?

Let me start out by reminding the audience I am not a security expert. I have been reading specs like a madman the past week, expecting such a question from the /. audience. I'm also not a professional TCPAadvocate ... my understanding of TCPA is in relation to what AMIBIOS must do to enable the TPM(a hardware component required by the spec). I'm going to refer toTCPA specifications & FAQ a lot, so verifying my answers will be an exercise left to the reader.

Your question brings up a lot of common issues people seem have with TCPA:

1. What does TCPA do?

2. What does AMIBIOS have to do with TCPA?

3. What is the licensing structure?

4. Can open-source software make use of TCPA?

5. Does this have anything to do with Digital Rights Management (DRM)?

Let's see if Brian can hash his way through these items in some sort of order ...

a) What does TCPA do? TCPA is an industry specification that defines mechanisms for "trusted" client/server interaction ("trust" and "security" are two different things).

TCPA works in a very similar fashion as other key-based security mechanisms (SSH, PGP, SSL). Transmissions are secured by hashing against a key. Keys tend to be very long (128 bits or more), so it is difficult for "bad people" to guess your key. In many mechanisms, the key also serves to identify the user (proof that they are who they say they are). This key is often contained in a file or some sort of removable media, like a smart card.

TCPA adds a few elements to this security scheme:

1. More keys and longer keys (some keys are 160 bits, most are 2048 bits)

2. A crypto-processor to speed key computations

3. Secure key storage on the system mainboard

4. Establish platform "trust". The two excerpts below are taken from the TCPA FAQ:
   12. What do you mean by trust?
   The ability to feel confident that the software environment in a platform is operating as expected. This is done by reliably measuring and reliably reporting (using aliasing) information about the platform.
   
   Another such benefit is improved control of access to data. Previously such access has depended upon authorization or authentication. Now such access can also be linked to the state of the software in the platform. This enables the denial of access to data if rogue software, such as a virus, is introduced into a platform, because such introduction necessarily changes the software state of the platform.

The crypto-processor and key storage are provided by the Trusted Platform Module (TPM). A TCPA enabled system will have a TPM on the motherboard. This TPM can be disabled, as per TCPA specification, if the user wants to opt-out.

One concern is that TCPA is equivalent to a unique identifier on your computer, which causes a large number of privacy concerns. There's a large section of the FAQ (Item #13) that covers this topic:

The solutions support privacy principles in a number of ways:

1. The owner controls personalization.

2. The owner and user control the trust relationship.

3. Provides private object storage and digital signature capability.

4. Private personalization information is never exposed.

5. User keys are encrypted prior to transmission.

6. Supports multiple certificate authorities giving the user choice.

It is also important to know what the solutions are not:

1. They are not global identifiers.

2. They are not personalized before user interaction.

3. They are not fixed functions - it can be disabled permanently.

4. They are not controlled by others (only the owner controls).

b) What does AMIBIOS have to do with TCPA? The TPM requires initialization during BIOS POST. This allows what they refer to as "metrics" to be stored that help establish that the BIOS & OS can be trusted (i.e. haven't been h4x0r3d). Our "TCPA & AMIBIOS8" whitepaper has more information.

c) What is the licensing structure? There isn't one. From the TCPA FAQ:

10. What are the licensing and/or royalty arrangements for the technologies outlined by the TCPA specification?

The TCPA spec is currently set up as a "just-publish" IP model.

d) Can open-source software make use of TCPA? Yes. From the TPM FAQ:

18. Does the TCPA support open source systems?

Yes. The ability to use the TPM functionality is available to all developers of software. An open source project could determine to use TPM functionally today. The concepts of measurement, protected storage and attestation of measurements are fundamental concepts that hold true for any type of OS or application. The platforms that support TCPA today are not limited to only one OS and if open source developers provided applications that used the TPM functionality they would find support.

Remember ... SSH, GPG and SSL aren't any less secure because they're open-source. The whole point of key-based security is that you can't see the data without the key, even if you know the decryption mechanism.

e) TCPA & DRM? This question wasn't directly asked, but it's on everybody's mind ...

TCPA has been connected to proposed legislation that would require "content protection" on most digital media devices (including PCs).

While somebody could write a DRM application using the TPM, they could also write one without it. Non-DRM applications can be developed under TCPA. The example I thought of is an improved VPN for companies that are super-paranoid about their data (think about it ... 2048 bit keys, no hash load on the system CPU, ability to tie accessibility to a unique platform).

Adding TCPA & a TPM to a system doesn't automatically add DRM to a platform. Some application has to tie the TPM to the "media" being "protected". Merely adding TCPA to AMIBIOS doesn't constitute DRM:

Captain: What happen?
Mechanic: Somebody set up us the DRM.
Cats: How are you gentlemen !! All your BIOS are belong to us.

2) Advantage

by TedCheshireAcad

What is the advantage to me, a Linux using consumer, to buying your product over those of your competitors?

First, the short answer: a proven and stable product based on nearly two decades in the PC industry, with support for the latest technology.

Now, the long answer: Let me give a little background on how BIOS gets onto your average motherboard. I know that's not what you asked, but it will explain product design and benefits to the end user.

AMI markets AMIBIOS directly to the motherboard manufacturer, who we see as the actual "BIOS customer". So many of our features are oriented to motherboard manufacturers or BIOS developer. The end result of using our codebase is to produce a stable BIOS for the motherboard manufacturer's customer (that's you, the end user).

You can break these down three major areas:

1. Code structure (ease of development, tools, source management, etc.)

2. Technology support (OS, chipsets, processors, peripherals, etc.)

3. Support after the sale

a) The "BIOS core" is a different code component from silicon support code. The same applies to our technology support modules (ACPI,USB, TCPA, ASF, SMBIOS, APM, etc.). This allows board developers to pick just the code they need for their system. An embedded Linux board for an industrial controller has different BIOS requirements than the typical "white box" motherboard (OS compatibility, supported hardware, power management, etc.).

AMI also developed a custom GUI to make BIOS development easier (Visual eBIOS, or VeB). Believe it or not, most BIOS development happens at the DOS prompt in x86 assembly code. We found it harder to get new engineers comfortable with DOS-based development (DOS is 22 years old, so is the average college graduate). VeB also incorporates source control, so engineers manage the code from the same place they edit the code.

b) Technology support is pretty broad. We have to work on new chipsets, technologies and devices while keeping backwards compatibility for older hardware we'd rather forget about. This involves a lot of work with hardware vendors (Intel, AMD, ServerWorks, nVIDIA, etc.), software companies (Microsoft, RedHat, etc.) and technical specification groups (there's one for most every acronym out there). As you might imagine, there's a lot of testing to make sure all these things play well together.

Technology support also applies to features that don't have cool three letter acronyms. One example of this is "Fast POST" (POST is Power On Self Test, BIOS execution from power-on to OS bootloader). There was customer demand to boot the PC faster. This pressure came from Microsoft for a better overall user experience (yes, the obvious joke is "boot speed doesn't matter when you don't have to reboot so often" ... but I'm taking the high road). So now Fast POST is standard in AMIBIOS8.

c) "Service after the sale" sounds like something you hear in a men's clothing store, but it applies to BIOS as well. Customers expect bugs to be fixed, new features to be added, and a voice on the phone when they can't quite figure out which bit goes where. Some customers develop using our source code (as a licensee), while others use our engineers to create their BIOS (as contractors).

That might have been more of a sales pitch than you were expecting (sorry). There's more product information at the AMIBIOS website.

3) Performance hit

by oliverthered

I assume that data pathways will be signable or encrypted in some way. What performance hit will the [operating system] take when using trusted system? e.g. How much extra data is added to form a signature, what methods are used for signing. and how will this benefit the end-user?

A: I assume this is in reference to TCPA, so I'll use what I know of that spec to answer the question.

Everybody who's used SSH or SCP has experienced computation overhead from data encryption. That's the main reason TCPA has the Trusted Platform Module (TPM). Along with storing keys, it had a dedicated crypto-processor to handle random number generation, hashing and digital signatures. Due to the size of a security key, these hash computations add overhead (overhead == delay).

In TCPA, the hash/generation stuff is offloaded to the TPM. Since this dedicated processor does the work, the main system processor doesn't have to. The TPM is also a function specific processor, meaning it's optimized for security tasks (translation: faster than your general purpose x86 CPU). This is a good thing, since most of the TPM keys are 2048 bits.

If you look at Transmeta's recent security press release, you see the same functionality. Although this story was reported as Transmeta releasing DRM, they are actually providing an integrated crypto-processor in the TM5800. This function-specific processor is accessible through an extension to the x86 instruction set (similar to MMX or 3DNow!). The difference between this & the TPM is how you access the functions.

Sidenote: does any open-source developer want to check if these extensions could be used to improve SSH, SCP or GPG performance?

The signing methods and potential benefits are outlined in the TCPA specification and FAQ.

4) Why are BIOSes closed source?

by mcelrath

Having recently had a lot of trouble with my laptop's BIOS, on an issue that I could most certainly fix if I had access to the code... I started wondering what benefit AMI and other vendors have by keeping BIOS code secret? I can think of none whatsoever.

An open-source TCPA BIOS might go a long way to alleviating the fears of the open source community, since we could see exactly what it is you're forcing on us. And hey, no doubt you'd get a few bug-fixing patches in return for your efforts.

So, is an open-source BIOS a possibility? (TCPA or otherwise)

Just to get this out of the way:

1. AMI isn't forcing anybody to take any product offering, TCPA or otherwise.

2. TCPA doesn't block open-source (see #18 in the TPM FAQ @ trustedpc.org).

3. The TPM Memory Present (MP) driver BIOS uses during POST isn't open-source (it's provided by the TPM manufacturer).

This was the focus of a linux.com article several years back. There's plenty of advantages to open-source, but there are two main reasons for closed source BIOS: Legal Restrictions & Economics.

The creation of an open-source BIOS isn't limited by the BIOS itself, but by the information required to create the BIOS. Let me take a second and explain how the BIOS works at a programming level. This may seem like a tangent, but it helps explain issues faced by open-source BIOS developers (just think of it as Good Eats for BIOS).

There's three major components of any BIOS:

1. Core Routines

2. Silicon Support Routines

3. Board Specific Routines

The core can be equated to the kernel of an operating system, except that it comprises a larger percentage of the codebase (both in functionality and actual code size). This is everything that's generic from one BIOS to the next.

Silicon Support applies to the chips on the board initialized by the BIOS (processor, northbridge, southbridge, I/O, flash). BIOS core routines will call silicon routines when hardware configuration is required. These routines are created according to an API, so swapping any of these code modules doesn't affect the structure of the core.

Board Specific Routines represent the motherboard manufacturer's configuration. If you look at motherboards from two manufacturers that use the exact same silicon components, you might expect the BIOS from one board to work on the other ... but you'd be wrong. The small hardware changes that differentiate Board Vendor A from Board Vendor B have a large impact on the BIOS. PCI Interrupt routing, chipset General Purpose I/O pins and other parts of vendor's "secret sauce" go into this BIOS layer.

"Fine," you say, "but what does this have to do with open-source BIOS?"

I'm sure you've noticed that there's a BIOS ready for a chipset the day it is announced. AMI and other BIOS companies don't just come along the day of the silicon release and slap a BIOS together. We work hand-in-hand with the chipset vendor for months before the release. They send us an alpha board, we boot it ... they send us a beta board, we add more features ... they send us final silicon, we validate it.

Now remember that this hardware isn't public when AMI gets it. AMI has to sign a has to sign a Non-Disclosure Agreement (NDA) to get a development board or advance specifications, which means we can't tell anybody what we know about the product. Vendor-supplied reference code (memory detection, bridge configuration, etc.) is also covered under NDA. AMI also signs NDAs to cover the motherboard manufacturer's confidential information.

So the BIOS that ends up on those motherboards is constructed using information we can't release to any party not covered by NDA. You might be able to understand how this doesn't fit into to the open-source model.

So an open-source BIOS developer has a big dilemma ... they need access to information, but legally can't include it in open-source code. Many chipset vendors provide information after their chipset is released, but not many board vendors hand out schematics. Reverse engineering might reveal this information, but some items controlled by the BIOS can damage the system if not set properly (data corruption, overheating, smoke, flame, etc.) ... so random bit flipping may not be the answer. And nobody wants to get into the legal issues of using disassembled code in place of reverse engineering.

I think the closing statement from the linux.com LinuxBIOS article still applies ... "The real question isn't if an open source BIOS will ever work on a handful of platforms, but if it will ever become viable for mass market across many platforms."

There's another issue that comes into keeping AMIBIOS source code closed (or for that matter anycommercial source code). This has to do with economics.

This is where I change hats from "AMI company representative" to "average techno-Joe". The next few paragraphs are my feelings, not necessarily those of my employer or anybody else on the planet.

I personally like the idea of open-source, and I use a lot of open-source programs at home and work (Mozilla, OpenOffice, RedHat, Mandrake, ClarkConnect, PostNuke, perl, php, Bugzilla). But I also buy and use regular closed-source programs (my DV editing and VCD/DVD authoring tools). The choice isn't whether or not the source is accessible, but if the tool fits my needs.

In either case, those programs are the product of somebody's time (in most cases, a large group of bodies). They're a conglomeration of people's ideas, a manifestation of their talents, and monetary investment (open-source isn't free to develop, somebody bought that computer hardware). Those people, and whatever company funded their efforts, have the choice to distribute their product anyway they choose.

If a company wants to go open-source, then they can't make money selling source or seat licenses. RedHat doesn't make money selling code, they make money selling a code package and support for that package. My company doesn't operate that way ... in the realm of BIOS, money is made licensing source and selling per-board licenses. That's the way every BIOS vendor makes money.

That doesn't mean there's no open-source within AMI (perl/php/PostNuke/apache intranets, Bugzilla bug tracking, ucLinux on our MegaRAC G2 management card). But the choice to go open-source is done product by product, company by company.

In an industry driven by innovation, many companies feel they loose competitive advantage by opening their source ... if everybody has access to their ideas, then why buy their product over another? That mentality may not fit well with open-source, but these inexpensive computers we currently enjoy are the product of market forces. If there was no profit in computing, would Intel and AMD even exist?

Thus ends my personal views ... back to the actual interview ...

5) Technical Explanation of BIOS Settings

by doppleganger871

I have been doing research on BIOS settings for many years, and I have found good articles on what the settings do, and how to tweak them for the best performance/stability mix. But, I would like to know if the BIOS manufacturer itself would be able to provide an in-depth manual of all the BIOS settings, and what exactly they do. All the manuals that come with motherboards are very short on explanations, and I would like to see someone within the company actually explain to us hardware enthusiasts the down 'n dirty, nitty gritty, dirt under the rug, needle in a haystack type of information that we could use to make our computers run the absolute best they can. Because, as we all know, optimizing software and firmware is a lot cheaper than upgrading parts.

A: I wish I had a great answer for this. Despite my verbose nature, there's not enough room in this interview to discuss every setting that is or will be in the BIOS. Some of the basic settings are covered in BIOS setup manuals, and a few websites do a good job of explain the ugly details. The problem is that those "cryptic" options change for every chipset on the market.

We're always looking at product improvements, and that includes documentation. Our setup manual is a generic template, designed for the motherboard customer as a starting point for their manuals. The "chipset specific setup information" is part of a new documentation effort within AMI (we talked about in meetings this week).

Outside of that, optimizing settings for a specific combination of board, memory and processor is still trial and error (tweak, reboot, benchmark, swear ... tweak, reboot, benchmark, swear ...). I don't know if better documentation will change that.

6) "Trusted" computer

by michael

A few related questions:

a) Isn't the goal of "trusted computing" to allow entities other than the owner of the computer to control what the owner does with his/her hardware? For example, "trusted computing" applied to music implies that the music publisher gains control over what the computer owner can do with the music data files. Isn't this the exact opposite of "trust" as that word is normally used - a trusted computer is one that can't be trusted by the computer's owner to perform the tasks asked of it, because other entities have veto power over the computer's actions?

b) Companies like AMI have repeatedly claimed that they aren't part of Palladium. However, isn't it true that without AMI's trusted BIOS (and all the other components necessary to build a "trusted computer"), Palladium wouldn't work? Why does AMI think they shouldn't be held responsible for enabling Palladium and similar schemes?

c) In what way does AMI benefit, financially or otherwise, from introducing a BIOS designed to make the computer it is installed in less useful to the purchaser of the computer? Please avoid saying that this is "optional"; AMI wouldn't create this BIOS if it wasn't intended to be used.

A: Let's take these in order ...

a) The Goal Of Trusted Computing: Despite the fact my company is a TCPA member company, the concept of trusted computing wasn't created by AMI (we're not even a founding member).

As far as the goals of the specification, I'm not the designated defender of TCPA. I'll let theTCPA speak to their own goals. You seem to automatically equate "trust" to DRM, but that's not what I get from reading the specifications and related materials (see part (e) of my answer to the first question).

b) Palladium & AMIBIOS: You are correct in understanding that Palladium will require some amount of BIOS support. The reason we keep saying "we're not a part of Palladium" is because Palladium doesn't exist in the marketplace ... it's a Microsoft initiative being developed under guarded care in a small circle of developers. It's not a public specification like TCPA, so our role in this scheme is unknown. My understanding is that we'll get a specification from Microsoft whenever they're ready to involve the BIOS developers, but I don't know under what terms it will be made public (my Magic 8 Ball says "Ask Again Later").

c) Financial Benefit: Yes, there is a financial benefit to supporting a technology that our customers ask for ... they continue to be our customers. Not every customer has asked for TCPA yet, but enough large customers have asked to make it financially reasonable. Keep in mind that this is just one more feature we offer, which the customer may or may not want to take.

So when a customer (or customers) comes to AMI and says "Our next motherboard will support TCPA, and we need a BIOS module", AMI has two choices:

1. Say yes, develop the code, make the customer happy

2. Say no

If we select option #2 (for whatever reason), our customer has one of two responses:

1. "No problem, we licensed your code ... we'll add the support ourselves."

2. "Too bad, you have a competitor who offers this support ... it was nice doing business with you."

Option B is an obvious downer, because customers give us money. Money can be exchanged for goods and services, like food ... and I find food to be an important part of a nutritious breakfast.

Option A presents another series of problems. Yes, we kept the customer, but now we have a forked version of our code floating around. If only one customer wants this feature, then it's not a big deal. If twenty customers want this feature, then there's twenty code forks. They're still our customers, so they expect support ... and this is a support nightmare.

Our decision to develop a TCPA option was driven by sufficient demand for the technology. We're not the only company in the marketplace offering TCPA. Phoenix, our largest competitor, has been working on TCPA for quite sometime. IBM is already shipping notebooks with TPM hardware (which run Linux, according to LinuxCare Labs). If AMI customers don't ship TCPA, they we spent time developing a feature nobody wanted (it wouldn't be the first time, but that's happens in cutting edge development), but we have customer goodwill because we're responsive to their needs. It's the same in our eyes as developing support for a chipset ... if nobody likes the chipset, then they don't buy the code to support it.

What we have done by choosing TCPA over any number of proprietary security solutions is present an option that isn't closed to third parties. If we enable TCPA on a board and you want to make use of it, read the spec and develop accordingly.

7) Hardware vendors

by cybermace5

Since a BIOS is only part of a motherboard: what steps will hardware vendors have to take, in order to incorporate your BIOS? Will they have to adhere to certain hardware design rules or controls in order to maintain the TCPA? Is there going to be a licensing procedure for hardware manufacturers?

A: Hardware vendors don't have to do much for AMIBIOS to support TCPA. The TCPA code module gets included as an add-on. The hardware manufacturer has to obtain a TPM to place on the motherboard, but that's available from a third party vendor.

The TCPA specification doesn't mandate licensing (see point #10 in the TCPA FAQ). It's not an AMI specification, so it's not our job to check for compliance. Third-party labs will most likely perform platform certification based on TCPA specifications.

8) Windows override

by Forkenhoppen

I have a question; on previous occassions on VIA hardware I've owned, I've noticed that occasionally, Windows will enable a feature even though I have turned it off in the BIOS.

My question is this; if I have TCPA disabled in my BIOS, will Windows drivers abide by this? Or will they still be able to use aspects of the BIOS originally put in place for use by TCPA even though I have it shut off?

What plans are in place to keep a Windows driver from hijacking TCPA-related information for it's own purposes?

A: A lot of that depends on how the motherboard vendor implements the TPM disable option mandated by the TCPA specification.

The TCPA specification has many options for disabling the TPM. It can be a BIOS setup question, jumper or software driven. The first two would be really hard to override in software (unless there's a robotic hand attached to the USB port). The third option could present a software override, but you would have to reboot to have the TPM enabled at power-on to set proper "root of trust" (you can't just turn it on midstream, since a TCPA system is supposed to hash the BIOS & bootloader).

9) TCPA & Palladium

by ignipotentis

Perhaps you can clarify the differences between the two (TCPA & Palladium). After reading up on both of them, i still find that they seem to be pretty much the same, just marketed differently.

A: From the information that's been made public concerning Palladium, I can try to elaborate on this. As I understand it, the major differences are listed below:

• Curtain Memory

• Control of Specification

• Intellectual Property (IP) Rights

The last two points are pretty self explanatory. Palladium it not a public specification, there may be licensing issues. TCPA is a public document created and reviewed by a number of different companies, with no licensing demands.

The first point is technical in nature. Here's how the Microsoft's Palladium FAQ describes "curtain memory":

The ability to wall off and hide pages of main memory so that each "Palladium" application can be assured that it is not modified or observed by any other application or even the operating system

This type of mechanism doesn't exist in TCPA, and would probably require some sort of support at the chipset level (which means it couldn't be implemented using current northbridge hardware). The total system impact isn't known, and it's any body's guess what this does to application development.

10) What do you think about Linux BIOS?

by lanner

At first, I was going to ask you about how you have cooperated, if at all, with the Linux BIOS project. After all, you often have historically cooperated with Microsoft and Novell. What are you doing to help Linux?

But then it occurred to me, if Linux BIOS was successful, it would put AMI out of the BIOS software development business. Linux BIOS is a competitor of AMI.

What is your personal perspective about Linux BIOS, and what does AMI think about it?

A: There's a lot of overlap with question #4 here. But there are two points I'd like to touch on:

1. Cooperation with Microsoft, Novell & Linux

2. Perspective on LinuxBIOS

a) Saying that we "cooperate" with Microsoft and Novell is misleading. AMI creates AMIBIOS for maximum hardware and software compatibility. For years, Microsoft and Novell were the primary OS vendors used by our customers. Microsoft also drives many PC specifications, and the majority of our customers use Microsoft operating systems. Development and testing are focused based on customer demand.

In the past few years, that situation has changed. Novell isn't a major consideration for our customers, but we still test compatibility. Linux is demanded by more customers, and our testing efforts have been increased to match that demand. We test RedHat, SuSe, Mandrake, Xandros, Lindows and FreeBSD by default (along with various beta distros).

Microsoft is still key to our testing and development (we test everything back to Win98). Customers still need that "Designed for Windows" sticker. But Linux is a major focus in our testing and development ... not just because we develop for compatibility, but because our customers ask for it by name.

b) In some areas, people see LinuxBIOS as competition to the other BIOS vendors.

• As far as the source licensing (open vs. closed), see my answer to question #4.

• In features, LinuxBIOS does some things that our BIOS doesn't (mostly in the areas of cluster management) ... AMI has advantages over LinuxBIOS as well (boot from USB/USB2, JPEG graphics as boot logo, broader chipset support, ACPI/APM power management, etc.).

• LinuxBIOS was developed for a specific application, but has broadened ... AMIBIOS aims to offer broad support in many market segments.

• AMIBIOS has been tested against a larger number of system configurations, works with a larger variety of hardware, and has a longer product history.

I'm not sure how others at AMI feel about LinuxBIOS, but all I have to say is "go for it". There's some neat stuff coming out of that project, and it's interesting to see what they've accomplished. Competition in the market is what makes technology improve ... one notch better than the last thing, one step ahead of the next guy.

Thus ends the interview. Thanks to Slashdot for the opportunity, and thanks to the readers for wading through the text.

We ran the "Call for questions" Monday, January 13, under the headline, Discuss BIOS and Palladium Issues With an AMIBIOS Rep. Note that Brian Richardson, AMI sales engineer, is a real engineer, not just a salesperson, and is also a staunch Slashdot reader who knows we have low tolerance for PR whitewashes around here. Brian's answers are real, not laundered, and he responded not only to the 10 questions we sent him but also to some he felt deserved answers even though they weren't moderated all the way up. Please note that in much of this interview he is speaking as "Brian Richardson, individual," and that his opinions do not necessarily reflect those of AMI's management. With that said, be prepared to learn a lot about the BIOS business, and how TCPA and Palladium relate (and don't relate) to it.

Preface:

I thought it might be handy for the audience to know who's handling their questions ...

My name is Brian Richardson. I work for American Megatrends, Inc . (AMI). AMI is a privately held company located in Norcross, GA (just north of Atlanta). We employ approximately 400 people worldwide (about 200 in the United States).

I am a "BIOS Sales Engineer", responsible for handling technical issues related to selling and marketing the AMIBIOS8 , our latest BIOS code revision. This includes writing whitepapers, demonstrating products, answering technical sales questions, speaking at industry conferences and handling requests from the press that may require more than a passing knowledge of technology (like this one).

I started at AMI in 1996. I've been in this job for two years. Before that I wrote BIOS code for our notebook team and helped design our Software Quality Automated Testing (SQuAT) system. I also maintain several company intranets and our Bugzilla server, used for tracking bugs during BIOS development.

In spare time, I serve on the board of directors of Tech Corps Georgia. I also managed the Hardware section of linux.com (old articles are archived at linux.omnipotent.net).

This interview covers BIOS in general, but the questions have a heavy slant towards TCPA & Palladium. I'm sure I won't address everybody's TCPA related questions here. AMI has a "TCPA and AMIBIOS8" whitepaper at our website which discusses AMI's implementation. There are also links to other information on TCPA.

To answer some of the more unusual questions that didn't make it into the Top 10:

• You use XOR to clear a register instead of a simple MOV instruction because of the instruction size (XOR uses a two byte opcode, MOV uses three bytes). The savings in space really adds up after a while.

• We haven't finished 1394 boot yet, but we do have USB & USB 2.0 boot support

• I don't know, I've never met Satan ... but I have been to WinHEC

Now on to the questions ...

1) On the Exclusionary Uses of TCPA

by the-banker

Is it (will it be) possible to use TCPA to effectively lock-out certain operating evironments from various services (software, media, etc) solely because the operating environment is not backed by a company, and has no mechanism for paying certification fees and licenses? Specifically, could TCPA be used against free OS's like Free/Open/netBSD and Linux to prevent those users from accessing the same content users of commercial OS's can?

Let me start out by reminding the audience I am not a security expert. I have been reading specs like a madman the past week, expecting such a question from the /. audience. I'm also not a professional TCPAadvocate ... my understanding of TCPA is in relation to what AMIBIOS must do to enable the TPM(a hardware component required by the spec). I'm going to refer toTCPA specifications & FAQ a lot, so verifying my answers will be an exercise left to the reader.

Your question brings up a lot of common issues people seem have with TCPA:

1. What does TCPA do?

2. What does AMIBIOS have to do with TCPA?

3. What is the licensing structure?

4. Can open-source software make use of TCPA?

5. Does this have anything to do with Digital Rights Management (DRM)?

Let's see if Brian can hash his way through these items in some sort of order ...

a) What does TCPA do? TCPA is an industry specification that defines mechanisms for "trusted" client/server interaction ("trust" and "security" are two different things).

TCPA works in a very similar fashion as other key-based security mechanisms (SSH, PGP, SSL). Transmissions are secured by hashing against a key. Keys tend to be very long (128 bits or more), so it is difficult for "bad people" to guess your key. In many mechanisms, the key also serves to identify the user (proof that they are who they say they are). This key is often contained in a file or some sort of removable media, like a smart card.

TCPA adds a few elements to this security scheme:

1. More keys and longer keys (some keys are 160 bits, most are 2048 bits)

2. A crypto-processor to speed key computations

3. Secure key storage on the system mainboard

4. Establish platform "trust". The two excerpts below are taken from the TCPA FAQ:
   12. What do you mean by trust?
   The ability to feel confident that the software environment in a platform is operating as expected. This is done by reliably measuring and reliably reporting (using aliasing) information about the platform.
   
   Another such benefit is improved control of access to data. Previously such access has depended upon authorization or authentication. Now such access can also be linked to the state of the software in the platform. This enables the denial of access to data if rogue software, such as a virus, is introduced into a platform, because such introduction necessarily changes the software state of the platform.

The crypto-processor and key storage are provided by the Trusted Platform Module (TPM). A TCPA enabled system will have a TPM on the motherboard. This TPM can be disabled, as per TCPA specification, if the user wants to opt-out.

One concern is that TCPA is equivalent to a unique identifier on your computer, which causes a large number of privacy concerns. There's a large section of the FAQ (Item #13) that covers this topic:

The solutions support privacy principles in a number of ways:

1. The owner controls personalization.

2. The owner and user control the trust relationship.

3. Provides private object storage and digital signature capability.

4. Private personalization information is never exposed.

5. User keys are encrypted prior to transmission.

6. Supports multiple certificate authorities giving the user choice.

It is also important to know what the solutions are not:

1. They are not global identifiers.

2. They are not personalized before user interaction.

3. They are not fixed functions - it can be disabled permanently.

4. They are not controlled by others (only the owner controls).

b) What does AMIBIOS have to do with TCPA? The TPM requires initialization during BIOS POST. This allows what they refer to as "metrics" to be stored that help establish that the BIOS & OS can be trusted (i.e. haven't been h4x0r3d). Our "TCPA & AMIBIOS8" whitepaper has more information.

c) What is the licensing structure? There isn't one. From the TCPA FAQ:

10. What are the licensing and/or royalty arrangements for the technologies outlined by the TCPA specification?

The TCPA spec is currently set up as a "just-publish" IP model.

d) Can open-source software make use of TCPA? Yes. From the TPM FAQ:

18. Does the TCPA support open source systems?

Yes. The ability to use the TPM functionality is available to all developers of software. An open source project could determine to use TPM functionally today. The concepts of measurement, protected storage and attestation of measurements are fundamental concepts that hold true for any type of OS or application. The platforms that support TCPA today are not limited to only one OS and if open source developers provided applications that used the TPM functionality they would find support.

Remember ... SSH, GPG and SSL aren't any less secure because they're open-source. The whole point of key-based security is that you can't see the data without the key, even if you know the decryption mechanism.

e) TCPA & DRM? This question wasn't directly asked, but it's on everybody's mind ...

TCPA has been connected to proposed legislation that would require "content protection" on most digital media devices (including PCs).

While somebody could write a DRM application using the TPM, they could also write one without it. Non-DRM applications can be developed under TCPA. The example I thought of is an improved VPN for companies that are super-paranoid about their data (think about it ... 2048 bit keys, no hash load on the system CPU, ability to tie accessibility to a unique platform).

Adding TCPA & a TPM to a system doesn't automatically add DRM to a platform. Some application has to tie the TPM to the "media" being "protected". Merely adding TCPA to AMIBIOS doesn't constitute DRM:

Captain: What happen?
Mechanic: Somebody set up us the DRM.
Cats: How are you gentlemen !! All your BIOS are belong to us.

2) Advantage

by TedCheshireAcad

What is the advantage to me, a Linux using consumer, to buying your product over those of your competitors?

First, the short answer: a proven and stable product based on nearly two decades in the PC industry, with support for the latest technology.

Now, the long answer: Let me give a little background on how BIOS gets onto your average motherboard. I know that's not what you asked, but it will explain product design and benefits to the end user.

AMI markets AMIBIOS directly to the motherboard manufacturer, who we see as the actual "BIOS customer". So many of our features are oriented to motherboard manufacturers or BIOS developer. The end result of using our codebase is to produce a stable BIOS for the motherboard manufacturer's customer (that's you, the end user).

You can break these down three major areas:

1. Code structure (ease of development, tools, source management, etc.)

2. Technology support (OS, chipsets, processors, peripherals, etc.)

3. Support after the sale

a) The "BIOS core" is a different code component from silicon support code. The same applies to our technology support modules (ACPI,USB, TCPA, ASF, SMBIOS, APM, etc.). This allows board developers to pick just the code they need for their system. An embedded Linux board for an industrial controller has different BIOS requirements than the typical "white box" motherboard (OS compatibility, supported hardware, power management, etc.).

AMI also developed a custom GUI to make BIOS development easier (Visual eBIOS, or VeB). Believe it or not, most BIOS development happens at the DOS prompt in x86 assembly code. We found it harder to get new engineers comfortable with DOS-based development (DOS is 22 years old, so is the average college graduate). VeB also incorporates source control, so engineers manage the code from the same place they edit the code.

b) Technology support is pretty broad. We have to work on new chipsets, technologies and devices while keeping backwards compatibility for older hardware we'd rather forget about. This involves a lot of work with hardware vendors (Intel, AMD, ServerWorks, nVIDIA, etc.), software companies (Microsoft, RedHat, etc.) and technical specification groups (there's one for most every acronym out there). As you might imagine, there's a lot of testing to make sure all these things play well together.

Technology support also applies to features that don't have cool three letter acronyms. One example of this is "Fast POST" (POST is Power On Self Test, BIOS execution from power-on to OS bootloader). There was customer demand to boot the PC faster. This pressure came from Microsoft for a better overall user experience (yes, the obvious joke is "boot speed doesn't matter when you don't have to reboot so often" ... but I'm taking the high road). So now Fast POST is standard in AMIBIOS8.

c) "Service after the sale" sounds like something you hear in a men's clothing store, but it applies to BIOS as well. Customers expect bugs to be fixed, new features to be added, and a voice on the phone when they can't quite figure out which bit goes where. Some customers develop using our source code (as a licensee), while others use our engineers to create their BIOS (as contractors).

That might have been more of a sales pitch than you were expecting (sorry). There's more product information at the AMIBIOS website.

3) Performance hit

by oliverthered

I assume that data pathways will be signable or encrypted in some way. What performance hit will the [operating system] take when using trusted system? e.g. How much extra data is added to form a signature, what methods are used for signing. and how will this benefit the end-user?

A: I assume this is in reference to TCPA, so I'll use what I know of that spec to answer the question.

Everybody who's used SSH or SCP has experienced computation overhead from data encryption. That's the main reason TCPA has the Trusted Platform Module (TPM). Along with storing keys, it had a dedicated crypto-processor to handle random number generation, hashing and digital signatures. Due to the size of a security key, these hash computations add overhead (overhead == delay).

In TCPA, the hash/generation stuff is offloaded to the TPM. Since this dedicated processor does the work, the main system processor doesn't have to. The TPM is also a function specific processor, meaning it's optimized for security tasks (translation: faster than your general purpose x86 CPU). This is a good thing, since most of the TPM keys are 2048 bits.

If you look at Transmeta's recent security press release, you see the same functionality. Although this story was reported as Transmeta releasing DRM, they are actually providing an integrated crypto-processor in the TM5800. This function-specific processor is accessible through an extension to the x86 instruction set (similar to MMX or 3DNow!). The difference between this & the TPM is how you access the functions.

Sidenote: does any open-source developer want to check if these extensions could be used to improve SSH, SCP or GPG performance?

The signing methods and potential benefits are outlined in the TCPA specification and FAQ.

4) Why are BIOSes closed source?

by mcelrath

Having recently had a lot of trouble with my laptop's BIOS, on an issue that I could most certainly fix if I had access to the code... I started wondering what benefit AMI and other vendors have by keeping BIOS code secret? I can think of none whatsoever.

An open-source TCPA BIOS might go a long way to alleviating the fears of the open source community, since we could see exactly what it is you're forcing on us. And hey, no doubt you'd get a few bug-fixing patches in return for your efforts.

So, is an open-source BIOS a possibility? (TCPA or otherwise)

Just to get this out of the way:

1. AMI isn't forcing anybody to take any product offering, TCPA or otherwise.

2. TCPA doesn't block open-source (see #18 in the TPM FAQ @ trustedpc.org).

3. The TPM Memory Present (MP) driver BIOS uses during POST isn't open-source (it's provided by the TPM manufacturer).

This was the focus of a linux.com article several years back. There's plenty of advantages to open-source, but there are two main reasons for closed source BIOS: Legal Restrictions & Economics.

The creation of an open-source BIOS isn't limited by the BIOS itself, but by the information required to create the BIOS. Let me take a second and explain how the BIOS works at a programming level. This may seem like a tangent, but it helps explain issues faced by open-source BIOS developers (just think of it as Good Eats for BIOS).

There's three major components of any BIOS:

1. Core Routines

2. Silicon Support Routines

3. Board Specific Routines

The core can be equated to the kernel of an operating system, except that it comprises a larger percentage of the codebase (both in functionality and actual code size). This is everything that's generic from one BIOS to the next.

Silicon Support applies to the chips on the board initialized by the BIOS (processor, northbridge, southbridge, I/O, flash). BIOS core routines will call silicon routines when hardware configuration is required. These routines are created according to an API, so swapping any of these code modules doesn't affect the structure of the core.

Board Specific Routines represent the motherboard manufacturer's configuration. If you look at motherboards from two manufacturers that use the exact same silicon components, you might expect the BIOS from one board to work on the other ... but you'd be wrong. The small hardware changes that differentiate Board Vendor A from Board Vendor B have a large impact on the BIOS. PCI Interrupt routing, chipset General Purpose I/O pins and other parts of vendor's "secret sauce" go into this BIOS layer.

"Fine," you say, "but what does this have to do with open-source BIOS?"

I'm sure you've noticed that there's a BIOS ready for a chipset the day it is announced. AMI and other BIOS companies don't just come along the day of the silicon release and slap a BIOS together. We work hand-in-hand with the chipset vendor for months before the release. They send us an alpha board, we boot it ... they send us a beta board, we add more features ... they send us final silicon, we validate it.

Now remember that this hardware isn't public when AMI gets it. AMI has to sign a has to sign a Non-Disclosure Agreement (NDA) to get a development board or advance specifications, which means we can't tell anybody what we know about the product. Vendor-supplied reference code (memory detection, bridge configuration, etc.) is also covered under NDA. AMI also signs NDAs to cover the motherboard manufacturer's confidential information.

So the BIOS that ends up on those motherboards is constructed using information we can't release to any party not covered by NDA. You might be able to understand how this doesn't fit into to the open-source model.

So an open-source BIOS developer has a big dilemma ... they need access to information, but legally can't include it in open-source code. Many chipset vendors provide information after their chipset is released, but not many board vendors hand out schematics. Reverse engineering might reveal this information, but some items controlled by the BIOS can damage the system if not set properly (data corruption, overheating, smoke, flame, etc.) ... so random bit flipping may not be the answer. And nobody wants to get into the legal issues of using disassembled code in place of reverse engineering.

I think the closing statement from the linux.com LinuxBIOS article still applies ... "The real question isn't if an open source BIOS will ever work on a handful of platforms, but if it will ever become viable for mass market across many platforms."

There's another issue that comes into keeping AMIBIOS source code closed (or for that matter anycommercial source code). This has to do with economics.

This is where I change hats from "AMI company representative" to "average techno-Joe". The next few paragraphs are my feelings, not necessarily those of my employer or anybody else on the planet.

I personally like the idea of open-source, and I use a lot of open-source programs at home and work (Mozilla, OpenOffice, RedHat, Mandrake, ClarkConnect, PostNuke, perl, php, Bugzilla). But I also buy and use regular closed-source programs (my DV editing and VCD/DVD authoring tools). The choice isn't whether or not the source is accessible, but if the tool fits my needs.

In either case, those programs are the product of somebody's time (in most cases, a large group of bodies). They're a conglomeration of people's ideas, a manifestation of their talents, and monetary investment (open-source isn't free to develop, somebody bought that computer hardware). Those people, and whatever company funded their efforts, have the choice to distribute their product anyway they choose.

If a company wants to go open-source, then they can't make money selling source or seat licenses. RedHat doesn't make money selling code, they make money selling a code package and support for that package. My company doesn't operate that way ... in the realm of BIOS, money is made licensing source and selling per-board licenses. That's the way every BIOS vendor makes money.

That doesn't mean there's no open-source within AMI (perl/php/PostNuke/apache intranets, Bugzilla bug tracking, ucLinux on our MegaRAC G2 management card). But the choice to go open-source is done product by product, company by company.

In an industry driven by innovation, many companies feel they loose competitive advantage by opening their source ... if everybody has access to their ideas, then why buy their product over another? That mentality may not fit well with open-source, but these inexpensive computers we currently enjoy are the product of market forces. If there was no profit in computing, would Intel and AMD even exist?

Thus ends my personal views ... back to the actual interview ...

5) Technical Explanation of BIOS Settings

by doppleganger871

I have been doing research on BIOS settings for many years, and I have found good articles on what the settings do, and how to tweak them for the best performance/stability mix. But, I would like to know if the BIOS manufacturer itself would be able to provide an in-depth manual of all the BIOS settings, and what exactly they do. All the manuals that come with motherboards are very short on explanations, and I would like to see someone within the company actually explain to us hardware enthusiasts the down 'n dirty, nitty gritty, dirt under the rug, needle in a haystack type of information that we could use to make our computers run the absolute best they can. Because, as we all know, optimizing software and firmware is a lot cheaper than upgrading parts.

A: I wish I had a great answer for this. Despite my verbose nature, there's not enough room in this interview to discuss every setting that is or will be in the BIOS. Some of the basic settings are covered in BIOS setup manuals, and a few websites do a good job of explain the ugly details. The problem is that those "cryptic" options change for every chipset on the market.

We're always looking at product improvements, and that includes documentation. Our setup manual is a generic template, designed for the motherboard customer as a starting point for their manuals. The "chipset specific setup information" is part of a new documentation effort within AMI (we talked about in meetings this week).

Outside of that, optimizing settings for a specific combination of board, memory and processor is still trial and error (tweak, reboot, benchmark, swear ... tweak, reboot, benchmark, swear ...). I don't know if better documentation will change that.

6) "Trusted" computer

by michael

A few related questions:

a) Isn't the goal of "trusted computing" to allow entities other than the owner of the computer to control what the owner does with his/her hardware? For example, "trusted computing" applied to music implies that the music publisher gains control over what the computer owner can do with the music data files. Isn't this the exact opposite of "trust" as that word is normally used - a trusted computer is one that can't be trusted by the computer's owner to perform the tasks asked of it, because other entities have veto power over the computer's actions?

b) Companies like AMI have repeatedly claimed that they aren't part of Palladium. However, isn't it true that without AMI's trusted BIOS (and all the other components necessary to build a "trusted computer"), Palladium wouldn't work? Why does AMI think they shouldn't be held responsible for enabling Palladium and similar schemes?

c) In what way does AMI benefit, financially or otherwise, from introducing a BIOS designed to make the computer it is installed in less useful to the purchaser of the computer? Please avoid saying that this is "optional"; AMI wouldn't create this BIOS if it wasn't intended to be used.

A: Let's take these in order ...

a) The Goal Of Trusted Computing: Despite the fact my company is a TCPA member company, the concept of trusted computing wasn't created by AMI (we're not even a founding member).

As far as the goals of the specification, I'm not the designated defender of TCPA. I'll let theTCPA speak to their own goals. You seem to automatically equate "trust" to DRM, but that's not what I get from reading the specifications and related materials (see part (e) of my answer to the first question).

b) Palladium & AMIBIOS: You are correct in understanding that Palladium will require some amount of BIOS support. The reason we keep saying "we're not a part of Palladium" is because Palladium doesn't exist in the marketplace ... it's a Microsoft initiative being developed under guarded care in a small circle of developers. It's not a public specification like TCPA, so our role in this scheme is unknown. My understanding is that we'll get a specification from Microsoft whenever they're ready to involve the BIOS developers, but I don't know under what terms it will be made public (my Magic 8 Ball says "Ask Again Later").

c) Financial Benefit: Yes, there is a financial benefit to supporting a technology that our customers ask for ... they continue to be our customers. Not every customer has asked for TCPA yet, but enough large customers have asked to make it financially reasonable. Keep in mind that this is just one more feature we offer, which the customer may or may not want to take.

So when a customer (or customers) comes to AMI and says "Our next motherboard will support TCPA, and we need a BIOS module", AMI has two choices:

1. Say yes, develop the code, make the customer happy

2. Say no

If we select option #2 (for whatever reason), our customer has one of two responses:

1. "No problem, we licensed your code ... we'll add the support ourselves."

2. "Too bad, you have a competitor who offers this support ... it was nice doing business with you."

Option B is an obvious downer, because customers give us money. Money can be exchanged for goods and services, like food ... and I find food to be an important part of a nutritious breakfast.

Option A presents another series of problems. Yes, we kept the customer, but now we have a forked version of our code floating around. If only one customer wants this feature, then it's not a big deal. If twenty customers want this feature, then there's twenty code forks. They're still our customers, so they expect support ... and this is a support nightmare.

Our decision to develop a TCPA option was driven by sufficient demand for the technology. We're not the only company in the marketplace offering TCPA. Phoenix, our largest competitor, has been working on TCPA for quite sometime. IBM is already shipping notebooks with TPM hardware (which run Linux, according to LinuxCare Labs). If AMI customers don't ship TCPA, they we spent time developing a feature nobody wanted (it wouldn't be the first time, but that's happens in cutting edge development), but we have customer goodwill because we're responsive to their needs. It's the same in our eyes as developing support for a chipset ... if nobody likes the chipset, then they don't buy the code to support it.

What we have done by choosing TCPA over any number of proprietary security solutions is present an option that isn't closed to third parties. If we enable TCPA on a board and you want to make use of it, read the spec and develop accordingly.

7) Hardware vendors

by cybermace5

Since a BIOS is only part of a motherboard: what steps will hardware vendors have to take, in order to incorporate your BIOS? Will they have to adhere to certain hardware design rules or controls in order to maintain the TCPA? Is there going to be a licensing procedure for hardware manufacturers?

A: Hardware vendors don't have to do much for AMIBIOS to support TCPA. The TCPA code module gets included as an add-on. The hardware manufacturer has to obtain a TPM to place on the motherboard, but that's available from a third party vendor.

The TCPA specification doesn't mandate licensing (see point #10 in the TCPA FAQ). It's not an AMI specification, so it's not our job to check for compliance. Third-party labs will most likely perform platform certification based on TCPA specifications.

8) Windows override

by Forkenhoppen

I have a question; on previous occassions on VIA hardware I've owned, I've noticed that occasionally, Windows will enable a feature even though I have turned it off in the BIOS.

My question is this; if I have TCPA disabled in my BIOS, will Windows drivers abide by this? Or will they still be able to use aspects of the BIOS originally put in place for use by TCPA even though I have it shut off?

What plans are in place to keep a Windows driver from hijacking TCPA-related information for it's own purposes?

A: A lot of that depends on how the motherboard vendor implements the TPM disable option mandated by the TCPA specification.

The TCPA specification has many options for disabling the TPM. It can be a BIOS setup question, jumper or software driven. The first two would be really hard to override in software (unless there's a robotic hand attached to the USB port). The third option could present a software override, but you would have to reboot to have the TPM enabled at power-on to set proper "root of trust" (you can't just turn it on midstream, since a TCPA system is supposed to hash the BIOS & bootloader).

9) TCPA & Palladium

by ignipotentis

Perhaps you can clarify the differences between the two (TCPA & Palladium). After reading up on both of them, i still find that they seem to be pretty much the same, just marketed differently.

A: From the information that's been made public concerning Palladium, I can try to elaborate on this. As I understand it, the major differences are listed below:

• Curtain Memory

• Control of Specification

• Intellectual Property (IP) Rights

The last two points are pretty self explanatory. Palladium it not a public specification, there may be licensing issues. TCPA is a public document created and reviewed by a number of different companies, with no licensing demands.

The first point is technical in nature. Here's how the Microsoft's Palladium FAQ describes "curtain memory":

The ability to wall off and hide pages of main memory so that each "Palladium" application can be assured that it is not modified or observed by any other application or even the operating system

This type of mechanism doesn't exist in TCPA, and would probably require some sort of support at the chipset level (which means it couldn't be implemented using current northbridge hardware). The total system impact isn't known, and it's any body's guess what this does to application development.

10) What do you think about Linux BIOS?

by lanner

At first, I was going to ask you about how you have cooperated, if at all, with the Linux BIOS project. After all, you often have historically cooperated with Microsoft and Novell. What are you doing to help Linux?

But then it occurred to me, if Linux BIOS was successful, it would put AMI out of the BIOS software development business. Linux BIOS is a competitor of AMI.

What is your personal perspective about Linux BIOS, and what does AMI think about it?

A: There's a lot of overlap with question #4 here. But there are two points I'd like to touch on:

1. Cooperation with Microsoft, Novell & Linux

2. Perspective on LinuxBIOS

a) Saying that we "cooperate" with Microsoft and Novell is misleading. AMI creates AMIBIOS for maximum hardware and software compatibility. For years, Microsoft and Novell were the primary OS vendors used by our customers. Microsoft also drives many PC specifications, and the majority of our customers use Microsoft operating systems. Development and testing are focused based on customer demand.

In the past few years, that situation has changed. Novell isn't a major consideration for our customers, but we still test compatibility. Linux is demanded by more customers, and our testing efforts have been increased to match that demand. We test RedHat, SuSe, Mandrake, Xandros, Lindows and FreeBSD by default (along with various beta distros).

Microsoft is still key to our testing and development (we test everything back to Win98). Customers still need that "Designed for Windows" sticker. But Linux is a major focus in our testing and development ... not just because we develop for compatibility, but because our customers ask for it by name.

b) In some areas, people see LinuxBIOS as competition to the other BIOS vendors.

• As far as the source licensing (open vs. closed), see my answer to question #4.

• In features, LinuxBIOS does some things that our BIOS doesn't (mostly in the areas of cluster management) ... AMI has advantages over LinuxBIOS as well (boot from USB/USB2, JPEG graphics as boot logo, broader chipset support, ACPI/APM power management, etc.).

• LinuxBIOS was developed for a specific application, but has broadened ... AMIBIOS aims to offer broad support in many market segments.

• AMIBIOS has been tested against a larger number of system configurations, works with a larger variety of hardware, and has a longer product history.

I'm not sure how others at AMI feel about LinuxBIOS, but all I have to say is "go for it". There's some neat stuff coming out of that project, and it's interesting to see what they've accomplished. Competition in the market is what makes technology improve ... one notch better than the last thing, one step ahead of the next guy.

Thus ends the interview. Thanks to Slashdot for the opportunity, and thanks to the readers for wading through the text.

We ran the "Call for questions" Monday, January 13, under the headline, Discuss BIOS and Palladium Issues With an AMIBIOS Rep. Note that Brian Richardson, AMI sales engineer, is a real engineer, not just a salesperson, and is also a staunch Slashdot reader who knows we have low tolerance for PR whitewashes around here. Brian's answers are real, not laundered, and he responded not only to the 10 questions we sent him but also to some he felt deserved answers even though they weren't moderated all the way up. Please note that in much of this interview he is speaking as "Brian Richardson, individual," and that his opinions do not necessarily reflect those of AMI's management. With that said, be prepared to learn a lot about the BIOS business, and how TCPA and Palladium relate (and don't relate) to it.

Preface:

I thought it might be handy for the audience to know who's handling their questions ...

My name is Brian Richardson. I work for American Megatrends, Inc . (AMI). AMI is a privately held company located in Norcross, GA (just north of Atlanta). We employ approximately 400 people worldwide (about 200 in the United States).

I am a "BIOS Sales Engineer", responsible for handling technical issues related to selling and marketing the AMIBIOS8 , our latest BIOS code revision. This includes writing whitepapers, demonstrating products, answering technical sales questions, speaking at industry conferences and handling requests from the press that may require more than a passing knowledge of technology (like this one).

I started at AMI in 1996. I've been in this job for two years. Before that I wrote BIOS code for our notebook team and helped design our Software Quality Automated Testing (SQuAT) system. I also maintain several company intranets and our Bugzilla server, used for tracking bugs during BIOS development.

In spare time, I serve on the board of directors of Tech Corps Georgia. I also managed the Hardware section of linux.com (old articles are archived at linux.omnipotent.net).

This interview covers BIOS in general, but the questions have a heavy slant towards TCPA & Palladium. I'm sure I won't address everybody's TCPA related questions here. AMI has a "TCPA and AMIBIOS8" whitepaper at our website which discusses AMI's implementation. There are also links to other information on TCPA.

To answer some of the more unusual questions that didn't make it into the Top 10:

• You use XOR to clear a register instead of a simple MOV instruction because of the instruction size (XOR uses a two byte opcode, MOV uses three bytes). The savings in space really adds up after a while.

• We haven't finished 1394 boot yet, but we do have USB & USB 2.0 boot support

• I don't know, I've never met Satan ... but I have been to WinHEC

Now on to the questions ...

1) On the Exclusionary Uses of TCPA

by the-banker

Is it (will it be) possible to use TCPA to effectively lock-out certain operating evironments from various services (software, media, etc) solely because the operating environment is not backed by a company, and has no mechanism for paying certification fees and licenses? Specifically, could TCPA be used against free OS's like Free/Open/netBSD and Linux to prevent those users from accessing the same content users of commercial OS's can?

Let me start out by reminding the audience I am not a security expert. I have been reading specs like a madman the past week, expecting such a question from the /. audience. I'm also not a professional TCPAadvocate ... my understanding of TCPA is in relation to what AMIBIOS must do to enable the TPM(a hardware component required by the spec). I'm going to refer toTCPA specifications & FAQ a lot, so verifying my answers will be an exercise left to the reader.

Your question brings up a lot of common issues people seem have with TCPA:

1. What does TCPA do?

2. What does AMIBIOS have to do with TCPA?

3. What is the licensing structure?

4. Can open-source software make use of TCPA?

5. Does this have anything to do with Digital Rights Management (DRM)?

Let's see if Brian can hash his way through these items in some sort of order ...

a) What does TCPA do? TCPA is an industry specification that defines mechanisms for "trusted" client/server interaction ("trust" and "security" are two different things).

TCPA works in a very similar fashion as other key-based security mechanisms (SSH, PGP, SSL). Transmissions are secured by hashing against a key. Keys tend to be very long (128 bits or more), so it is difficult for "bad people" to guess your key. In many mechanisms, the key also serves to identify the user (proof that they are who they say they are). This key is often contained in a file or some sort of removable media, like a smart card.

TCPA adds a few elements to this security scheme:

1. More keys and longer keys (some keys are 160 bits, most are 2048 bits)

2. A crypto-processor to speed key computations

3. Secure key storage on the system mainboard

4. Establish platform "trust". The two excerpts below are taken from the TCPA FAQ:
   12. What do you mean by trust?
   The ability to feel confident that the software environment in a platform is operating as expected. This is done by reliably measuring and reliably reporting (using aliasing) information about the platform.
   
   Another such benefit is improved control of access to data. Previously such access has depended upon authorization or authentication. Now such access can also be linked to the state of the software in the platform. This enables the denial of access to data if rogue software, such as a virus, is introduced into a platform, because such introduction necessarily changes the software state of the platform.

The crypto-processor and key storage are provided by the Trusted Platform Module (TPM). A TCPA enabled system will have a TPM on the motherboard. This TPM can be disabled, as per TCPA specification, if the user wants to opt-out.

One concern is that TCPA is equivalent to a unique identifier on your computer, which causes a large number of privacy concerns. There's a large section of the FAQ (Item #13) that covers this topic:

The solutions support privacy principles in a number of ways:

1. The owner controls personalization.

2. The owner and user control the trust relationship.

3. Provides private object storage and digital signature capability.

4. Private personalization information is never exposed.

5. User keys are encrypted prior to transmission.

6. Supports multiple certificate authorities giving the user choice.

It is also important to know what the solutions are not:

1. They are not global identifiers.

2. They are not personalized before user interaction.

3. They are not fixed functions - it can be disabled permanently.

4. They are not controlled by others (only the owner controls).

b) What does AMIBIOS have to do with TCPA? The TPM requires initialization during BIOS POST. This allows what they refer to as "metrics" to be stored that help establish that the BIOS & OS can be trusted (i.e. haven't been h4x0r3d). Our "TCPA & AMIBIOS8" whitepaper has more information.

c) What is the licensing structure? There isn't one. From the TCPA FAQ:

10. What are the licensing and/or royalty arrangements for the technologies outlined by the TCPA specification?

The TCPA spec is currently set up as a "just-publish" IP model.

d) Can open-source software make use of TCPA? Yes. From the TPM FAQ:

18. Does the TCPA support open source systems?

Yes. The ability to use the TPM functionality is available to all developers of software. An open source project could determine to use TPM functionally today. The concepts of measurement, protected storage and attestation of measurements are fundamental concepts that hold true for any type of OS or application. The platforms that support TCPA today are not limited to only one OS and if open source developers provided applications that used the TPM functionality they would find support.

Remember ... SSH, GPG and SSL aren't any less secure because they're open-source. The whole point of key-based security is that you can't see the data without the key, even if you know the decryption mechanism.

e) TCPA & DRM? This question wasn't directly asked, but it's on everybody's mind ...

TCPA has been connected to proposed legislation that would require "content protection" on most digital media devices (including PCs).

While somebody could write a DRM application using the TPM, they could also write one without it. Non-DRM applications can be developed under TCPA. The example I thought of is an improved VPN for companies that are super-paranoid about their data (think about it ... 2048 bit keys, no hash load on the system CPU, ability to tie accessibility to a unique platform).

Adding TCPA & a TPM to a system doesn't automatically add DRM to a platform. Some application has to tie the TPM to the "media" being "protected". Merely adding TCPA to AMIBIOS doesn't constitute DRM:

Captain: What happen?
Mechanic: Somebody set up us the DRM.
Cats: How are you gentlemen !! All your BIOS are belong to us.

2) Advantage

by TedCheshireAcad

What is the advantage to me, a Linux using consumer, to buying your product over those of your competitors?

First, the short answer: a proven and stable product based on nearly two decades in the PC industry, with support for the latest technology.

Now, the long answer: Let me give a little background on how BIOS gets onto your average motherboard. I know that's not what you asked, but it will explain product design and benefits to the end user.

AMI markets AMIBIOS directly to the motherboard manufacturer, who we see as the actual "BIOS customer". So many of our features are oriented to motherboard manufacturers or BIOS developer. The end result of using our codebase is to produce a stable BIOS for the motherboard manufacturer's customer (that's you, the end user).

You can break these down three major areas:

1. Code structure (ease of development, tools, source management, etc.)

2. Technology support (OS, chipsets, processors, peripherals, etc.)

3. Support after the sale

a) The "BIOS core" is a different code component from silicon support code. The same applies to our technology support modules (ACPI,USB, TCPA, ASF, SMBIOS, APM, etc.). This allows board developers to pick just the code they need for their system. An embedded Linux board for an industrial controller has different BIOS requirements than the typical "white box" motherboard (OS compatibility, supported hardware, power management, etc.).

AMI also developed a custom GUI to make BIOS development easier (Visual eBIOS, or VeB). Believe it or not, most BIOS development happens at the DOS prompt in x86 assembly code. We found it harder to get new engineers comfortable with DOS-based development (DOS is 22 years old, so is the average college graduate). VeB also incorporates source control, so engineers manage the code from the same place they edit the code.

b) Technology support is pretty broad. We have to work on new chipsets, technologies and devices while keeping backwards compatibility for older hardware we'd rather forget about. This involves a lot of work with hardware vendors (Intel, AMD, ServerWorks, nVIDIA, etc.), software companies (Microsoft, RedHat, etc.) and technical specification groups (there's one for most every acronym out there). As you might imagine, there's a lot of testing to make sure all these things play well together.

Technology support also applies to features that don't have cool three letter acronyms. One example of this is "Fast POST" (POST is Power On Self Test, BIOS execution from power-on to OS bootloader). There was customer demand to boot the PC faster. This pressure came from Microsoft for a better overall user experience (yes, the obvious joke is "boot speed doesn't matter when you don't have to reboot so often" ... but I'm taking the high road). So now Fast POST is standard in AMIBIOS8.

c) "Service after the sale" sounds like something you hear in a men's clothing store, but it applies to BIOS as well. Customers expect bugs to be fixed, new features to be added, and a voice on the phone when they can't quite figure out which bit goes where. Some customers develop using our source code (as a licensee), while others use our engineers to create their BIOS (as contractors).

That might have been more of a sales pitch than you were expecting (sorry). There's more product information at the AMIBIOS website.

3) Performance hit

by oliverthered

I assume that data pathways will be signable or encrypted in some way. What performance hit will the [operating system] take when using trusted system? e.g. How much extra data is added to form a signature, what methods are used for signing. and how will this benefit the end-user?

A: I assume this is in reference to TCPA, so I'll use what I know of that spec to answer the question.

Everybody who's used SSH or SCP has experienced computation overhead from data encryption. That's the main reason TCPA has the Trusted Platform Module (TPM). Along with storing keys, it had a dedicated crypto-processor to handle random number generation, hashing and digital signatures. Due to the size of a security key, these hash computations add overhead (overhead == delay).

In TCPA, the hash/generation stuff is offloaded to the TPM. Since this dedicated processor does the work, the main system processor doesn't have to. The TPM is also a function specific processor, meaning it's optimized for security tasks (translation: faster than your general purpose x86 CPU). This is a good thing, since most of the TPM keys are 2048 bits.

If you look at Transmeta's recent security press release, you see the same functionality. Although this story was reported as Transmeta releasing DRM, they are actually providing an integrated crypto-processor in the TM5800. This function-specific processor is accessible through an extension to the x86 instruction set (similar to MMX or 3DNow!). The difference between this & the TPM is how you access the functions.

Sidenote: does any open-source developer want to check if these extensions could be used to improve SSH, SCP or GPG performance?

The signing methods and potential benefits are outlined in the TCPA specification and FAQ.

4) Why are BIOSes closed source?

by mcelrath

Having recently had a lot of trouble with my laptop's BIOS, on an issue that I could most certainly fix if I had access to the code... I started wondering what benefit AMI and other vendors have by keeping BIOS code secret? I can think of none whatsoever.

An open-source TCPA BIOS might go a long way to alleviating the fears of the open source community, since we could see exactly what it is you're forcing on us. And hey, no doubt you'd get a few bug-fixing patches in return for your efforts.

So, is an open-source BIOS a possibility? (TCPA or otherwise)

Just to get this out of the way:

1. AMI isn't forcing anybody to take any product offering, TCPA or otherwise.

2. TCPA doesn't block open-source (see #18 in the TPM FAQ @ trustedpc.org).

3. The TPM Memory Present (MP) driver BIOS uses during POST isn't open-source (it's provided by the TPM manufacturer).

This was the focus of a linux.com article several years back. There's plenty of advantages to open-source, but there are two main reasons for closed source BIOS: Legal Restrictions & Economics.

The creation of an open-source BIOS isn't limited by the BIOS itself, but by the information required to create the BIOS. Let me take a second and explain how the BIOS works at a programming level. This may seem like a tangent, but it helps explain issues faced by open-source BIOS developers (just think of it as Good Eats for BIOS).

There's three major components of any BIOS:

1. Core Routines

2. Silicon Support Routines

3. Board Specific Routines

The core can be equated to the kernel of an operating system, except that it comprises a larger percentage of the codebase (both in functionality and actual code size). This is everything that's generic from one BIOS to the next.

Silicon Support applies to the chips on the board initialized by the BIOS (processor, northbridge, southbridge, I/O, flash). BIOS core routines will call silicon routines when hardware configuration is required. These routines are created according to an API, so swapping any of these code modules doesn't affect the structure of the core.

Board Specific Routines represent the motherboard manufacturer's configuration. If you look at motherboards from two manufacturers that use the exact same silicon components, you might expect the BIOS from one board to work on the other ... but you'd be wrong. The small hardware changes that differentiate Board Vendor A from Board Vendor B have a large impact on the BIOS. PCI Interrupt routing, chipset General Purpose I/O pins and other parts of vendor's "secret sauce" go into this BIOS layer.

"Fine," you say, "but what does this have to do with open-source BIOS?"

I'm sure you've noticed that there's a BIOS ready for a chipset the day it is announced. AMI and other BIOS companies don't just come along the day of the silicon release and slap a BIOS together. We work hand-in-hand with the chipset vendor for months before the release. They send us an alpha board, we boot it ... they send us a beta board, we add more features ... they send us final silicon, we validate it.

Now remember that this hardware isn't public when AMI gets it. AMI has to sign a has to sign a Non-Disclosure Agreement (NDA) to get a development board or advance specifications, which means we can't tell anybody what we know about the product. Vendor-supplied reference code (memory detection, bridge configuration, etc.) is also covered under NDA. AMI also signs NDAs to cover the motherboard manufacturer's confidential information.

So the BIOS that ends up on those motherboards is constructed using information we can't release to any party not covered by NDA. You might be able to understand how this doesn't fit into to the open-source model.

So an open-source BIOS developer has a big dilemma ... they need access to information, but legally can't include it in open-source code. Many chipset vendors provide information after their chipset is released, but not many board vendors hand out schematics. Reverse engineering might reveal this information, but some items controlled by the BIOS can damage the system if not set properly (data corruption, overheating, smoke, flame, etc.) ... so random bit flipping may not be the answer. And nobody wants to get into the legal issues of using disassembled code in place of reverse engineering.

I think the closing statement from the linux.com LinuxBIOS article still applies ... "The real question isn't if an open source BIOS will ever work on a handful of platforms, but if it will ever become viable for mass market across many platforms."

There's another issue that comes into keeping AMIBIOS source code closed (or for that matter anycommercial source code). This has to do with economics.

This is where I change hats from "AMI company representative" to "average techno-Joe". The next few paragraphs are my feelings, not necessarily those of my employer or anybody else on the planet.

I personally like the idea of open-source, and I use a lot of open-source programs at home and work (Mozilla, OpenOffice, RedHat, Mandrake, ClarkConnect, PostNuke, perl, php, Bugzilla). But I also buy and use regular closed-source programs (my DV editing and VCD/DVD authoring tools). The choice isn't whether or not the source is accessible, but if the tool fits my needs.

In either case, those programs are the product of somebody's time (in most cases, a large group of bodies). They're a conglomeration of people's ideas, a manifestation of their talents, and monetary investment (open-source isn't free to develop, somebody bought that computer hardware). Those people, and whatever company funded their efforts, have the choice to distribute their product anyway they choose.

If a company wants to go open-source, then they can't make money selling source or seat licenses. RedHat doesn't make money selling code, they make money selling a code package and support for that package. My company doesn't operate that way ... in the realm of BIOS, money is made licensing source and selling per-board licenses. That's the way every BIOS vendor makes money.

That doesn't mean there's no open-source within AMI (perl/php/PostNuke/apache intranets, Bugzilla bug tracking, ucLinux on our MegaRAC G2 management card). But the choice to go open-source is done product by product, company by company.

In an industry driven by innovation, many companies feel they loose competitive advantage by opening their source ... if everybody has access to their ideas, then why buy their product over another? That mentality may not fit well with open-source, but these inexpensive computers we currently enjoy are the product of market forces. If there was no profit in computing, would Intel and AMD even exist?

Thus ends my personal views ... back to the actual interview ...

5) Technical Explanation of BIOS Settings

by doppleganger871

I have been doing research on BIOS settings for many years, and I have found good articles on what the settings do, and how to tweak them for the best performance/stability mix. But, I would like to know if the BIOS manufacturer itself would be able to provide an in-depth manual of all the BIOS settings, and what exactly they do. All the manuals that come with motherboards are very short on explanations, and I would like to see someone within the company actually explain to us hardware enthusiasts the down 'n dirty, nitty gritty, dirt under the rug, needle in a haystack type of information that we could use to make our computers run the absolute best they can. Because, as we all know, optimizing software and firmware is a lot cheaper than upgrading parts.

A: I wish I had a great answer for this. Despite my verbose nature, there's not enough room in this interview to discuss every setting that is or will be in the BIOS. Some of the basic settings are covered in BIOS setup manuals, and a few websites do a good job of explain the ugly details. The problem is that those "cryptic" options change for every chipset on the market.

We're always looking at product improvements, and that includes documentation. Our setup manual is a generic template, designed for the motherboard customer as a starting point for their manuals. The "chipset specific setup information" is part of a new documentation effort within AMI (we talked about in meetings this week).

Outside of that, optimizing settings for a specific combination of board, memory and processor is still trial and error (tweak, reboot, benchmark, swear ... tweak, reboot, benchmark, swear ...). I don't know if better documentation will change that.

6) "Trusted" computer

by michael

A few related questions:

a) Isn't the goal of "trusted computing" to allow entities other than the owner of the computer to control what the owner does with his/her hardware? For example, "trusted computing" applied to music implies that the music publisher gains control over what the computer owner can do with the music data files. Isn't this the exact opposite of "trust" as that word is normally used - a trusted computer is one that can't be trusted by the computer's owner to perform the tasks asked of it, because other entities have veto power over the computer's actions?

b) Companies like AMI have repeatedly claimed that they aren't part of Palladium. However, isn't it true that without AMI's trusted BIOS (and all the other components necessary to build a "trusted computer"), Palladium wouldn't work? Why does AMI think they shouldn't be held responsible for enabling Palladium and similar schemes?

c) In what way does AMI benefit, financially or otherwise, from introducing a BIOS designed to make the computer it is installed in less useful to the purchaser of the computer? Please avoid saying that this is "optional"; AMI wouldn't create this BIOS if it wasn't intended to be used.

A: Let's take these in order ...

a) The Goal Of Trusted Computing: Despite the fact my company is a TCPA member company, the concept of trusted computing wasn't created by AMI (we're not even a founding member).

As far as the goals of the specification, I'm not the designated defender of TCPA. I'll let theTCPA speak to their own goals. You seem to automatically equate "trust" to DRM, but that's not what I get from reading the specifications and related materials (see part (e) of my answer to the first question).

b) Palladium & AMIBIOS: You are correct in understanding that Palladium will require some amount of BIOS support. The reason we keep saying "we're not a part of Palladium" is because Palladium doesn't exist in the marketplace ... it's a Microsoft initiative being developed under guarded care in a small circle of developers. It's not a public specification like TCPA, so our role in this scheme is unknown. My understanding is that we'll get a specification from Microsoft whenever they're ready to involve the BIOS developers, but I don't know under what terms it will be made public (my Magic 8 Ball says "Ask Again Later").

c) Financial Benefit: Yes, there is a financial benefit to supporting a technology that our customers ask for ... they continue to be our customers. Not every customer has asked for TCPA yet, but enough large customers have asked to make it financially reasonable. Keep in mind that this is just one more feature we offer, which the customer may or may not want to take.

So when a customer (or customers) comes to AMI and says "Our next motherboard will support TCPA, and we need a BIOS module", AMI has two choices:

1. Say yes, develop the code, make the customer happy

2. Say no

If we select option #2 (for whatever reason), our customer has one of two responses:

1. "No problem, we licensed your code ... we'll add the support ourselves."

2. "Too bad, you have a competitor who offers this support ... it was nice doing business with you."

Option B is an obvious downer, because customers give us money. Money can be exchanged for goods and services, like food ... and I find food to be an important part of a nutritious breakfast.

Option A presents another series of problems. Yes, we kept the customer, but now we have a forked version of our code floating around. If only one customer wants this feature, then it's not a big deal. If twenty customers want this feature, then there's twenty code forks. They're still our customers, so they expect support ... and this is a support nightmare.

Our decision to develop a TCPA option was driven by sufficient demand for the technology. We're not the only company in the marketplace offering TCPA. Phoenix, our largest competitor, has been working on TCPA for quite sometime. IBM is already shipping notebooks with TPM hardware (which run Linux, according to LinuxCare Labs). If AMI customers don't ship TCPA, they we spent time developing a feature nobody wanted (it wouldn't be the first time, but that's happens in cutting edge development), but we have customer goodwill because we're responsive to their needs. It's the same in our eyes as developing support for a chipset ... if nobody likes the chipset, then they don't buy the code to support it.

What we have done by choosing TCPA over any number of proprietary security solutions is present an option that isn't closed to third parties. If we enable TCPA on a board and you want to make use of it, read the spec and develop accordingly.

7) Hardware vendors

by cybermace5

Since a BIOS is only part of a motherboard: what steps will hardware vendors have to take, in order to incorporate your BIOS? Will they have to adhere to certain hardware design rules or controls in order to maintain the TCPA? Is there going to be a licensing procedure for hardware manufacturers?

A: Hardware vendors don't have to do much for AMIBIOS to support TCPA. The TCPA code module gets included as an add-on. The hardware manufacturer has to obtain a TPM to place on the motherboard, but that's available from a third party vendor.

The TCPA specification doesn't mandate licensing (see point #10 in the TCPA FAQ). It's not an AMI specification, so it's not our job to check for compliance. Third-party labs will most likely perform platform certification based on TCPA specifications.

8) Windows override

by Forkenhoppen

I have a question; on previous occassions on VIA hardware I've owned, I've noticed that occasionally, Windows will enable a feature even though I have turned it off in the BIOS.

My question is this; if I have TCPA disabled in my BIOS, will Windows drivers abide by this? Or will they still be able to use aspects of the BIOS originally put in place for use by TCPA even though I have it shut off?

What plans are in place to keep a Windows driver from hijacking TCPA-related information for it's own purposes?

A: A lot of that depends on how the motherboard vendor implements the TPM disable option mandated by the TCPA specification.

The TCPA specification has many options for disabling the TPM. It can be a BIOS setup question, jumper or software driven. The first two would be really hard to override in software (unless there's a robotic hand attached to the USB port). The third option could present a software override, but you would have to reboot to have the TPM enabled at power-on to set proper "root of trust" (you can't just turn it on midstream, since a TCPA system is supposed to hash the BIOS & bootloader).

9) TCPA & Palladium

by ignipotentis

Perhaps you can clarify the differences between the two (TCPA & Palladium). After reading up on both of them, i still find that they seem to be pretty much the same, just marketed differently.

A: From the information that's been made public concerning Palladium, I can try to elaborate on this. As I understand it, the major differences are listed below:

• Curtain Memory

• Control of Specification

• Intellectual Property (IP) Rights

The last two points are pretty self explanatory. Palladium it not a public specification, there may be licensing issues. TCPA is a public document created and reviewed by a number of different companies, with no licensing demands.

The first point is technical in nature. Here's how the Microsoft's Palladium FAQ describes "curtain memory":

The ability to wall off and hide pages of main memory so that each "Palladium" application can be assured that it is not modified or observed by any other application or even the operating system

This type of mechanism doesn't exist in TCPA, and would probably require some sort of support at the chipset level (which means it couldn't be implemented using current northbridge hardware). The total system impact isn't known, and it's any body's guess what this does to application development.

10) What do you think about Linux BIOS?

by lanner

At first, I was going to ask you about how you have cooperated, if at all, with the Linux BIOS project. After all, you often have historically cooperated with Microsoft and Novell. What are you doing to help Linux?

But then it occurred to me, if Linux BIOS was successful, it would put AMI out of the BIOS software development business. Linux BIOS is a competitor of AMI.

What is your personal perspective about Linux BIOS, and what does AMI think about it?

A: There's a lot of overlap with question #4 here. But there are two points I'd like to touch on:

1. Cooperation with Microsoft, Novell & Linux

2. Perspective on LinuxBIOS

a) Saying that we "cooperate" with Microsoft and Novell is misleading. AMI creates AMIBIOS for maximum hardware and software compatibility. For years, Microsoft and Novell were the primary OS vendors used by our customers. Microsoft also drives many PC specifications, and the majority of our customers use Microsoft operating systems. Development and testing are focused based on customer demand.

In the past few years, that situation has changed. Novell isn't a major consideration for our customers, but we still test compatibility. Linux is demanded by more customers, and our testing efforts have been increased to match that demand. We test RedHat, SuSe, Mandrake, Xandros, Lindows and FreeBSD by default (along with various beta distros).

Microsoft is still key to our testing and development (we test everything back to Win98). Customers still need that "Designed for Windows" sticker. But Linux is a major focus in our testing and development ... not just because we develop for compatibility, but because our customers ask for it by name.

b) In some areas, people see LinuxBIOS as competition to the other BIOS vendors.

• As far as the source licensing (open vs. closed), see my answer to question #4.

• In features, LinuxBIOS does some things that our BIOS doesn't (mostly in the areas of cluster management) ... AMI has advantages over LinuxBIOS as well (boot from USB/USB2, JPEG graphics as boot logo, broader chipset support, ACPI/APM power management, etc.).

• LinuxBIOS was developed for a specific application, but has broadened ... AMIBIOS aims to offer broad support in many market segments.

• AMIBIOS has been tested against a larger number of system configurations, works with a larger variety of hardware, and has a longer product history.

I'm not sure how others at AMI feel about LinuxBIOS, but all I have to say is "go for it". There's some neat stuff coming out of that project, and it's interesting to see what they've accomplished. Competition in the market is what makes technology improve ... one notch better than the last thing, one step ahead of the next guy.

Thus ends the interview. Thanks to Slashdot for the opportunity, and thanks to the readers for wading through the text.

We ran the "Call for questions" Monday, January 13, under the headline, Discuss BIOS and Palladium Issues With an AMIBIOS Rep. Note that Brian Richardson, AMI sales engineer, is a real engineer, not just a salesperson, and is also a staunch Slashdot reader who knows we have low tolerance for PR whitewashes around here. Brian's answers are real, not laundered, and he responded not only to the 10 questions we sent him but also to some he felt deserved answers even though they weren't moderated all the way up. Please note that in much of this interview he is speaking as "Brian Richardson, individual," and that his opinions do not necessarily reflect those of AMI's management. With that said, be prepared to learn a lot about the BIOS business, and how TCPA and Palladium relate (and don't relate) to it.

Preface:

I thought it might be handy for the audience to know who's handling their questions ...

My name is Brian Richardson. I work for American Megatrends, Inc . (AMI). AMI is a privately held company located in Norcross, GA (just north of Atlanta). We employ approximately 400 people worldwide (about 200 in the United States).

I am a "BIOS Sales Engineer", responsible for handling technical issues related to selling and marketing the AMIBIOS8 , our latest BIOS code revision. This includes writing whitepapers, demonstrating products, answering technical sales questions, speaking at industry conferences and handling requests from the press that may require more than a passing knowledge of technology (like this one).

I started at AMI in 1996. I've been in this job for two years. Before that I wrote BIOS code for our notebook team and helped design our Software Quality Automated Testing (SQuAT) system. I also maintain several company intranets and our Bugzilla server, used for tracking bugs during BIOS development.

In spare time, I serve on the board of directors of Tech Corps Georgia. I also managed the Hardware section of linux.com (old articles are archived at linux.omnipotent.net).

This interview covers BIOS in general, but the questions have a heavy slant towards TCPA & Palladium. I'm sure I won't address everybody's TCPA related questions here. AMI has a "TCPA and AMIBIOS8" whitepaper at our website which discusses AMI's implementation. There are also links to other information on TCPA.

To answer some of the more unusual questions that didn't make it into the Top 10:

• You use XOR to clear a register instead of a simple MOV instruction because of the instruction size (XOR uses a two byte opcode, MOV uses three bytes). The savings in space really adds up after a while.

• We haven't finished 1394 boot yet, but we do have USB & USB 2.0 boot support

• I don't know, I've never met Satan ... but I have been to WinHEC

Now on to the questions ...

1) On the Exclusionary Uses of TCPA

by the-banker

Is it (will it be) possible to use TCPA to effectively lock-out certain operating evironments from various services (software, media, etc) solely because the operating environment is not backed by a company, and has no mechanism for paying certification fees and licenses? Specifically, could TCPA be used against free OS's like Free/Open/netBSD and Linux to prevent those users from accessing the same content users of commercial OS's can?

Let me start out by reminding the audience I am not a security expert. I have been reading specs like a madman the past week, expecting such a question from the /. audience. I'm also not a professional TCPAadvocate ... my understanding of TCPA is in relation to what AMIBIOS must do to enable the TPM(a hardware component required by the spec). I'm going to refer toTCPA specifications & FAQ a lot, so verifying my answers will be an exercise left to the reader.

Your question brings up a lot of common issues people seem have with TCPA:

1. What does TCPA do?

2. What does AMIBIOS have to do with TCPA?

3. What is the licensing structure?

4. Can open-source software make use of TCPA?

5. Does this have anything to do with Digital Rights Management (DRM)?

Let's see if Brian can hash his way through these items in some sort of order ...

a) What does TCPA do? TCPA is an industry specification that defines mechanisms for "trusted" client/server interaction ("trust" and "security" are two different things).

TCPA works in a very similar fashion as other key-based security mechanisms (SSH, PGP, SSL). Transmissions are secured by hashing against a key. Keys tend to be very long (128 bits or more), so it is difficult for "bad people" to guess your key. In many mechanisms, the key also serves to identify the user (proof that they are who they say they are). This key is often contained in a file or some sort of removable media, like a smart card.

TCPA adds a few elements to this security scheme:

1. More keys and longer keys (some keys are 160 bits, most are 2048 bits)

2. A crypto-processor to speed key computations

3. Secure key storage on the system mainboard

4. Establish platform "trust". The two excerpts below are taken from the TCPA FAQ:
   12. What do you mean by trust?
   The ability to feel confident that the software environment in a platform is operating as expected. This is done by reliably measuring and reliably reporting (using aliasing) information about the platform.
   
   Another such benefit is improved control of access to data. Previously such access has depended upon authorization or authentication. Now such access can also be linked to the state of the software in the platform. This enables the denial of access to data if rogue software, such as a virus, is introduced into a platform, because such introduction necessarily changes the software state of the platform.

The crypto-processor and key storage are provided by the Trusted Platform Module (TPM). A TCPA enabled system will have a TPM on the motherboard. This TPM can be disabled, as per TCPA specification, if the user wants to opt-out.

One concern is that TCPA is equivalent to a unique identifier on your computer, which causes a large number of privacy concerns. There's a large section of the FAQ (Item #13) that covers this topic:

The solutions support privacy principles in a number of ways:

1. The owner controls personalization.

2. The owner and user control the trust relationship.

3. Provides private object storage and digital signature capability.

4. Private personalization information is never exposed.

5. User keys are encrypted prior to transmission.

6. Supports multiple certificate authorities giving the user choice.

It is also important to know what the solutions are not:

1. They are not global identifiers.

2. They are not personalized before user interaction.

3. They are not fixed functions - it can be disabled permanently.

4. They are not controlled by others (only the owner controls).

b) What does AMIBIOS have to do with TCPA? The TPM requires initialization during BIOS POST. This allows what they refer to as "metrics" to be stored that help establish that the BIOS & OS can be trusted (i.e. haven't been h4x0r3d). Our "TCPA & AMIBIOS8" whitepaper has more information.

c) What is the licensing structure? There isn't one. From the TCPA FAQ:

10. What are the licensing and/or royalty arrangements for the technologies outlined by the TCPA specification?

The TCPA spec is currently set up as a "just-publish" IP model.

d) Can open-source software make use of TCPA? Yes. From the TPM FAQ:

18. Does the TCPA support open source systems?

Yes. The ability to use the TPM functionality is available to all developers of software. An open source project could determine to use TPM functionally today. The concepts of measurement, protected storage and attestation of measurements are fundamental concepts that hold true for any type of OS or application. The platforms that support TCPA today are not limited to only one OS and if open source developers provided applications that used the TPM functionality they would find support.

Remember ... SSH, GPG and SSL aren't any less secure because they're open-source. The whole point of key-based security is that you can't see the data without the key, even if you know the decryption mechanism.

e) TCPA & DRM? This question wasn't directly asked, but it's on everybody's mind ...

TCPA has been connected to proposed legislation that would require "content protection" on most digital media devices (including PCs).

While somebody could write a DRM application using the TPM, they could also write one without it. Non-DRM applications can be developed under TCPA. The example I thought of is an improved VPN for companies that are super-paranoid about their data (think about it ... 2048 bit keys, no hash load on the system CPU, ability to tie accessibility to a unique platform).

Adding TCPA & a TPM to a system doesn't automatically add DRM to a platform. Some application has to tie the TPM to the "media" being "protected". Merely adding TCPA to AMIBIOS doesn't constitute DRM:

Captain: What happen?
Mechanic: Somebody set up us the DRM.
Cats: How are you gentlemen !! All your BIOS are belong to us.

2) Advantage

by TedCheshireAcad

What is the advantage to me, a Linux using consumer, to buying your product over those of your competitors?

First, the short answer: a proven and stable product based on nearly two decades in the PC industry, with support for the latest technology.

Now, the long answer: Let me give a little background on how BIOS gets onto your average motherboard. I know that's not what you asked, but it will explain product design and benefits to the end user.

AMI markets AMIBIOS directly to the motherboard manufacturer, who we see as the actual "BIOS customer". So many of our features are oriented to motherboard manufacturers or BIOS developer. The end result of using our codebase is to produce a stable BIOS for the motherboard manufacturer's customer (that's you, the end user).

You can break these down three major areas:

1. Code structure (ease of development, tools, source management, etc.)

2. Technology support (OS, chipsets, processors, peripherals, etc.)

3. Support after the sale

a) The "BIOS core" is a different code component from silicon support code. The same applies to our technology support modules (ACPI,USB, TCPA, ASF, SMBIOS, APM, etc.). This allows board developers to pick just the code they need for their system. An embedded Linux board for an industrial controller has different BIOS requirements than the typical "white box" motherboard (OS compatibility, supported hardware, power management, etc.).

AMI also developed a custom GUI to make BIOS development easier (Visual eBIOS, or VeB). Believe it or not, most BIOS development happens at the DOS prompt in x86 assembly code. We found it harder to get new engineers comfortable with DOS-based development (DOS is 22 years old, so is the average college graduate). VeB also incorporates source control, so engineers manage the code from the same place they edit the code.

b) Technology support is pretty broad. We have to work on new chipsets, technologies and devices while keeping backwards compatibility for older hardware we'd rather forget about. This involves a lot of work with hardware vendors (Intel, AMD, ServerWorks, nVIDIA, etc.), software companies (Microsoft, RedHat, etc.) and technical specification groups (there's one for most every acronym out there). As you might imagine, there's a lot of testing to make sure all these things play well together.

Technology support also applies to features that don't have cool three letter acronyms. One example of this is "Fast POST" (POST is Power On Self Test, BIOS execution from power-on to OS bootloader). There was customer demand to boot the PC faster. This pressure came from Microsoft for a better overall user experience (yes, the obvious joke is "boot speed doesn't matter when you don't have to reboot so often" ... but I'm taking the high road). So now Fast POST is standard in AMIBIOS8.

c) "Service after the sale" sounds like something you hear in a men's clothing store, but it applies to BIOS as well. Customers expect bugs to be fixed, new features to be added, and a voice on the phone when they can't quite figure out which bit goes where. Some customers develop using our source code (as a licensee), while others use our engineers to create their BIOS (as contractors).

That might have been more of a sales pitch than you were expecting (sorry). There's more product information at the AMIBIOS website.

3) Performance hit

by oliverthered

I assume that data pathways will be signable or encrypted in some way. What performance hit will the [operating system] take when using trusted system? e.g. How much extra data is added to form a signature, what methods are used for signing. and how will this benefit the end-user?

A: I assume this is in reference to TCPA, so I'll use what I know of that spec to answer the question.

Everybody who's used SSH or SCP has experienced computation overhead from data encryption. That's the main reason TCPA has the Trusted Platform Module (TPM). Along with storing keys, it had a dedicated crypto-processor to handle random number generation, hashing and digital signatures. Due to the size of a security key, these hash computations add overhead (overhead == delay).

In TCPA, the hash/generation stuff is offloaded to the TPM. Since this dedicated processor does the work, the main system processor doesn't have to. The TPM is also a function specific processor, meaning it's optimized for security tasks (translation: faster than your general purpose x86 CPU). This is a good thing, since most of the TPM keys are 2048 bits.

If you look at Transmeta's recent security press release, you see the same functionality. Although this story was reported as Transmeta releasing DRM, they are actually providing an integrated crypto-processor in the TM5800. This function-specific processor is accessible through an extension to the x86 instruction set (similar to MMX or 3DNow!). The difference between this & the TPM is how you access the functions.

Sidenote: does any open-source developer want to check if these extensions could be used to improve SSH, SCP or GPG performance?

The signing methods and potential benefits are outlined in the TCPA specification and FAQ.

4) Why are BIOSes closed source?

by mcelrath

Having recently had a lot of trouble with my laptop's BIOS, on an issue that I could most certainly fix if I had access to the code... I started wondering what benefit AMI and other vendors have by keeping BIOS code secret? I can think of none whatsoever.

An open-source TCPA BIOS might go a long way to alleviating the fears of the open source community, since we could see exactly what it is you're forcing on us. And hey, no doubt you'd get a few bug-fixing patches in return for your efforts.

So, is an open-source BIOS a possibility? (TCPA or otherwise)

Just to get this out of the way:

1. AMI isn't forcing anybody to take any product offering, TCPA or otherwise.

2. TCPA doesn't block open-source (see #18 in the TPM FAQ @ trustedpc.org).

3. The TPM Memory Present (MP) driver BIOS uses during POST isn't open-source (it's provided by the TPM manufacturer).

This was the focus of a linux.com article several years back. There's plenty of advantages to open-source, but there are two main reasons for closed source BIOS: Legal Restrictions & Economics.

The creation of an open-source BIOS isn't limited by the BIOS itself, but by the information required to create the BIOS. Let me take a second and explain how the BIOS works at a programming level. This may seem like a tangent, but it helps explain issues faced by open-source BIOS developers (just think of it as Good Eats for BIOS).

There's three major components of any BIOS:

1. Core Routines

2. Silicon Support Routines

3. Board Specific Routines

The core can be equated to the kernel of an operating system, except that it comprises a larger percentage of the codebase (both in functionality and actual code size). This is everything that's generic from one BIOS to the next.

Silicon Support applies to the chips on the board initialized by the BIOS (processor, northbridge, southbridge, I/O, flash). BIOS core routines will call silicon routines when hardware configuration is required. These routines are created according to an API, so swapping any of these code modules doesn't affect the structure of the core.

Board Specific Routines represent the motherboard manufacturer's configuration. If you look at motherboards from two manufacturers that use the exact same silicon components, you might expect the BIOS from one board to work on the other ... but you'd be wrong. The small hardware changes that differentiate Board Vendor A from Board Vendor B have a large impact on the BIOS. PCI Interrupt routing, chipset General Purpose I/O pins and other parts of vendor's "secret sauce" go into this BIOS layer.

"Fine," you say, "but what does this have to do with open-source BIOS?"

I'm sure you've noticed that there's a BIOS ready for a chipset the day it is announced. AMI and other BIOS companies don't just come along the day of the silicon release and slap a BIOS together. We work hand-in-hand with the chipset vendor for months before the release. They send us an alpha board, we boot it ... they send us a beta board, we add more features ... they send us final silicon, we validate it.

Now remember that this hardware isn't public when AMI gets it. AMI has to sign a has to sign a Non-Disclosure Agreement (NDA) to get a development board or advance specifications, which means we can't tell anybody what we know about the product. Vendor-supplied reference code (memory detection, bridge configuration, etc.) is also covered under NDA. AMI also signs NDAs to cover the motherboard manufacturer's confidential information.

So the BIOS that ends up on those motherboards is constructed using information we can't release to any party not covered by NDA. You might be able to understand how this doesn't fit into to the open-source model.

So an open-source BIOS developer has a big dilemma ... they need access to information, but legally can't include it in open-source code. Many chipset vendors provide information after their chipset is released, but not many board vendors hand out schematics. Reverse engineering might reveal this information, but some items controlled by the BIOS can damage the system if not set properly (data corruption, overheating, smoke, flame, etc.) ... so random bit flipping may not be the answer. And nobody wants to get into the legal issues of using disassembled code in place of reverse engineering.

I think the closing statement from the linux.com LinuxBIOS article still applies ... "The real question isn't if an open source BIOS will ever work on a handful of platforms, but if it will ever become viable for mass market across many platforms."

There's another issue that comes into keeping AMIBIOS source code closed (or for that matter anycommercial source code). This has to do with economics.

This is where I change hats from "AMI company representative" to "average techno-Joe". The next few paragraphs are my feelings, not necessarily those of my employer or anybody else on the planet.

I personally like the idea of open-source, and I use a lot of open-source programs at home and work (Mozilla, OpenOffice, RedHat, Mandrake, ClarkConnect, PostNuke, perl, php, Bugzilla). But I also buy and use regular closed-source programs (my DV editing and VCD/DVD authoring tools). The choice isn't whether or not the source is accessible, but if the tool fits my needs.

In either case, those programs are the product of somebody's time (in most cases, a large group of bodies). They're a conglomeration of people's ideas, a manifestation of their talents, and monetary investment (open-source isn't free to develop, somebody bought that computer hardware). Those people, and whatever company funded their efforts, have the choice to distribute their product anyway they choose.

If a company wants to go open-source, then they can't make money selling source or seat licenses. RedHat doesn't make money selling code, they make money selling a code package and support for that package. My company doesn't operate that way ... in the realm of BIOS, money is made licensing source and selling per-board licenses. That's the way every BIOS vendor makes money.

That doesn't mean there's no open-source within AMI (perl/php/PostNuke/apache intranets, Bugzilla bug tracking, ucLinux on our MegaRAC G2 management card). But the choice to go open-source is done product by product, company by company.

In an industry driven by innovation, many companies feel they loose competitive advantage by opening their source ... if everybody has access to their ideas, then why buy their product over another? That mentality may not fit well with open-source, but these inexpensive computers we currently enjoy are the product of market forces. If there was no profit in computing, would Intel and AMD even exist?

Thus ends my personal views ... back to the actual interview ...

5) Technical Explanation of BIOS Settings

by doppleganger871

I have been doing research on BIOS settings for many years, and I have found good articles on what the settings do, and how to tweak them for the best performance/stability mix. But, I would like to know if the BIOS manufacturer itself would be able to provide an in-depth manual of all the BIOS settings, and what exactly they do. All the manuals that come with motherboards are very short on explanations, and I would like to see someone within the company actually explain to us hardware enthusiasts the down 'n dirty, nitty gritty, dirt under the rug, needle in a haystack type of information that we could use to make our computers run the absolute best they can. Because, as we all know, optimizing software and firmware is a lot cheaper than upgrading parts.

A: I wish I had a great answer for this. Despite my verbose nature, there's not enough room in this interview to discuss every setting that is or will be in the BIOS. Some of the basic settings are covered in BIOS setup manuals, and a few websites do a good job of explain the ugly details. The problem is that those "cryptic" options change for every chipset on the market.

We're always looking at product improvements, and that includes documentation. Our setup manual is a generic template, designed for the motherboard customer as a starting point for their manuals. The "chipset specific setup information" is part of a new documentation effort within AMI (we talked about in meetings this week).

Outside of that, optimizing settings for a specific combination of board, memory and processor is still trial and error (tweak, reboot, benchmark, swear ... tweak, reboot, benchmark, swear ...). I don't know if better documentation will change that.

6) "Trusted" computer

by michael

A few related questions:

a) Isn't the goal of "trusted computing" to allow entities other than the owner of the computer to control what the owner does with his/her hardware? For example, "trusted computing" applied to music implies that the music publisher gains control over what the computer owner can do with the music data files. Isn't this the exact opposite of "trust" as that word is normally used - a trusted computer is one that can't be trusted by the computer's owner to perform the tasks asked of it, because other entities have veto power over the computer's actions?

b) Companies like AMI have repeatedly claimed that they aren't part of Palladium. However, isn't it true that without AMI's trusted BIOS (and all the other components necessary to build a "trusted computer"), Palladium wouldn't work? Why does AMI think they shouldn't be held responsible for enabling Palladium and similar schemes?

c) In what way does AMI benefit, financially or otherwise, from introducing a BIOS designed to make the computer it is installed in less useful to the purchaser of the computer? Please avoid saying that this is "optional"; AMI wouldn't create this BIOS if it wasn't intended to be used.

A: Let's take these in order ...

a) The Goal Of Trusted Computing: Despite the fact my company is a TCPA member company, the concept of trusted computing wasn't created by AMI (we're not even a founding member).

As far as the goals of the specification, I'm not the designated defender of TCPA. I'll let theTCPA speak to their own goals. You seem to automatically equate "trust" to DRM, but that's not what I get from reading the specifications and related materials (see part (e) of my answer to the first question).

b) Palladium & AMIBIOS: You are correct in understanding that Palladium will require some amount of BIOS support. The reason we keep saying "we're not a part of Palladium" is because Palladium doesn't exist in the marketplace ... it's a Microsoft initiative being developed under guarded care in a small circle of developers. It's not a public specification like TCPA, so our role in this scheme is unknown. My understanding is that we'll get a specification from Microsoft whenever they're ready to involve the BIOS developers, but I don't know under what terms it will be made public (my Magic 8 Ball says "Ask Again Later").

c) Financial Benefit: Yes, there is a financial benefit to supporting a technology that our customers ask for ... they continue to be our customers. Not every customer has asked for TCPA yet, but enough large customers have asked to make it financially reasonable. Keep in mind that this is just one more feature we offer, which the customer may or may not want to take.

So when a customer (or customers) comes to AMI and says "Our next motherboard will support TCPA, and we need a BIOS module", AMI has two choices:

1. Say yes, develop the code, make the customer happy

2. Say no

If we select option #2 (for whatever reason), our customer has one of two responses:

1. "No problem, we licensed your code ... we'll add the support ourselves."

2. "Too bad, you have a competitor who offers this support ... it was nice doing business with you."

Option B is an obvious downer, because customers give us money. Money can be exchanged for goods and services, like food ... and I find food to be an important part of a nutritious breakfast.

Option A presents another series of problems. Yes, we kept the customer, but now we have a forked version of our code floating around. If only one customer wants this feature, then it's not a big deal. If twenty customers want this feature, then there's twenty code forks. They're still our customers, so they expect support ... and this is a support nightmare.

Our decision to develop a TCPA option was driven by sufficient demand for the technology. We're not the only company in the marketplace offering TCPA. Phoenix, our largest competitor, has been working on TCPA for quite sometime. IBM is already shipping notebooks with TPM hardware (which run Linux, according to LinuxCare Labs). If AMI customers don't ship TCPA, they we spent time developing a feature nobody wanted (it wouldn't be the first time, but that's happens in cutting edge development), but we have customer goodwill because we're responsive to their needs. It's the same in our eyes as developing support for a chipset ... if nobody likes the chipset, then they don't buy the code to support it.

What we have done by choosing TCPA over any number of proprietary security solutions is present an option that isn't closed to third parties. If we enable TCPA on a board and you want to make use of it, read the spec and develop accordingly.

7) Hardware vendors

by cybermace5

Since a BIOS is only part of a motherboard: what steps will hardware vendors have to take, in order to incorporate your BIOS? Will they have to adhere to certain hardware design rules or controls in order to maintain the TCPA? Is there going to be a licensing procedure for hardware manufacturers?

A: Hardware vendors don't have to do much for AMIBIOS to support TCPA. The TCPA code module gets included as an add-on. The hardware manufacturer has to obtain a TPM to place on the motherboard, but that's available from a third party vendor.

The TCPA specification doesn't mandate licensing (see point #10 in the TCPA FAQ). It's not an AMI specification, so it's not our job to check for compliance. Third-party labs will most likely perform platform certification based on TCPA specifications.

8) Windows override

by Forkenhoppen

I have a question; on previous occassions on VIA hardware I've owned, I've noticed that occasionally, Windows will enable a feature even though I have turned it off in the BIOS.

My question is this; if I have TCPA disabled in my BIOS, will Windows drivers abide by this? Or will they still be able to use aspects of the BIOS originally put in place for use by TCPA even though I have it shut off?

What plans are in place to keep a Windows driver from hijacking TCPA-related information for it's own purposes?

A: A lot of that depends on how the motherboard vendor implements the TPM disable option mandated by the TCPA specification.

The TCPA specification has many options for disabling the TPM. It can be a BIOS setup question, jumper or software driven. The first two would be really hard to override in software (unless there's a robotic hand attached to the USB port). The third option could present a software override, but you would have to reboot to have the TPM enabled at power-on to set proper "root of trust" (you can't just turn it on midstream, since a TCPA system is supposed to hash the BIOS & bootloader).

9) TCPA & Palladium

by ignipotentis

Perhaps you can clarify the differences between the two (TCPA & Palladium). After reading up on both of them, i still find that they seem to be pretty much the same, just marketed differently.

A: From the information that's been made public concerning Palladium, I can try to elaborate on this. As I understand it, the major differences are listed below:

• Curtain Memory

• Control of Specification

• Intellectual Property (IP) Rights

The last two points are pretty self explanatory. Palladium it not a public specification, there may be licensing issues. TCPA is a public document created and reviewed by a number of different companies, with no licensing demands.

The first point is technical in nature. Here's how the Microsoft's Palladium FAQ describes "curtain memory":

The ability to wall off and hide pages of main memory so that each "Palladium" application can be assured that it is not modified or observed by any other application or even the operating system

This type of mechanism doesn't exist in TCPA, and would probably require some sort of support at the chipset level (which means it couldn't be implemented using current northbridge hardware). The total system impact isn't known, and it's any body's guess what this does to application development.

10) What do you think about Linux BIOS?

by lanner

At first, I was going to ask you about how you have cooperated, if at all, with the Linux BIOS project. After all, you often have historically cooperated with Microsoft and Novell. What are you doing to help Linux?

But then it occurred to me, if Linux BIOS was successful, it would put AMI out of the BIOS software development business. Linux BIOS is a competitor of AMI.

What is your personal perspective about Linux BIOS, and what does AMI think about it?

A: There's a lot of overlap with question #4 here. But there are two points I'd like to touch on:

1. Cooperation with Microsoft, Novell & Linux

2. Perspective on LinuxBIOS

a) Saying that we "cooperate" with Microsoft and Novell is misleading. AMI creates AMIBIOS for maximum hardware and software compatibility. For years, Microsoft and Novell were the primary OS vendors used by our customers. Microsoft also drives many PC specifications, and the majority of our customers use Microsoft operating systems. Development and testing are focused based on customer demand.

In the past few years, that situation has changed. Novell isn't a major consideration for our customers, but we still test compatibility. Linux is demanded by more customers, and our testing efforts have been increased to match that demand. We test RedHat, SuSe, Mandrake, Xandros, Lindows and FreeBSD by default (along with various beta distros).

Microsoft is still key to our testing and development (we test everything back to Win98). Customers still need that "Designed for Windows" sticker. But Linux is a major focus in our testing and development ... not just because we develop for compatibility, but because our customers ask for it by name.

b) In some areas, people see LinuxBIOS as competition to the other BIOS vendors.

• As far as the source licensing (open vs. closed), see my answer to question #4.

• In features, LinuxBIOS does some things that our BIOS doesn't (mostly in the areas of cluster management) ... AMI has advantages over LinuxBIOS as well (boot from USB/USB2, JPEG graphics as boot logo, broader chipset support, ACPI/APM power management, etc.).

• LinuxBIOS was developed for a specific application, but has broadened ... AMIBIOS aims to offer broad support in many market segments.

• AMIBIOS has been tested against a larger number of system configurations, works with a larger variety of hardware, and has a longer product history.

I'm not sure how others at AMI feel about LinuxBIOS, but all I have to say is "go for it". There's some neat stuff coming out of that project, and it's interesting to see what they've accomplished. Competition in the market is what makes technology improve ... one notch better than the last thing, one step ahead of the next guy.

Thus ends the interview. Thanks to Slashdot for the opportunity, and thanks to the readers for wading through the text.

We ran the "Call for questions" Monday, January 13, under the headline, Discuss BIOS and Palladium Issues With an AMIBIOS Rep. Note that Brian Richardson, AMI sales engineer, is a real engineer, not just a salesperson, and is also a staunch Slashdot reader who knows we have low tolerance for PR whitewashes around here. Brian's answers are real, not laundered, and he responded not only to the 10 questions we sent him but also to some he felt deserved answers even though they weren't moderated all the way up. Please note that in much of this interview he is speaking as "Brian Richardson, individual," and that his opinions do not necessarily reflect those of AMI's management. With that said, be prepared to learn a lot about the BIOS business, and how TCPA and Palladium relate (and don't relate) to it.

Preface:

I thought it might be handy for the audience to know who's handling their questions ...

My name is Brian Richardson. I work for American Megatrends, Inc . (AMI). AMI is a privately held company located in Norcross, GA (just north of Atlanta). We employ approximately 400 people worldwide (about 200 in the United States).

I am a "BIOS Sales Engineer", responsible for handling technical issues related to selling and marketing the AMIBIOS8 , our latest BIOS code revision. This includes writing whitepapers, demonstrating products, answering technical sales questions, speaking at industry conferences and handling requests from the press that may require more than a passing knowledge of technology (like this one).

I started at AMI in 1996. I've been in this job for two years. Before that I wrote BIOS code for our notebook team and helped design our Software Quality Automated Testing (SQuAT) system. I also maintain several company intranets and our Bugzilla server, used for tracking bugs during BIOS development.

In spare time, I serve on the board of directors of Tech Corps Georgia. I also managed the Hardware section of linux.com (old articles are archived at linux.omnipotent.net).

This interview covers BIOS in general, but the questions have a heavy slant towards TCPA & Palladium. I'm sure I won't address everybody's TCPA related questions here. AMI has a "TCPA and AMIBIOS8" whitepaper at our website which discusses AMI's implementation. There are also links to other information on TCPA.

To answer some of the more unusual questions that didn't make it into the Top 10:

• You use XOR to clear a register instead of a simple MOV instruction because of the instruction size (XOR uses a two byte opcode, MOV uses three bytes). The savings in space really adds up after a while.

• We haven't finished 1394 boot yet, but we do have USB & USB 2.0 boot support

• I don't know, I've never met Satan ... but I have been to WinHEC

Now on to the questions ...

1) On the Exclusionary Uses of TCPA

by the-banker

Is it (will it be) possible to use TCPA to effectively lock-out certain operating evironments from various services (software, media, etc) solely because the operating environment is not backed by a company, and has no mechanism for paying certification fees and licenses? Specifically, could TCPA be used against free OS's like Free/Open/netBSD and Linux to prevent those users from accessing the same content users of commercial OS's can?

Let me start out by reminding the audience I am not a security expert. I have been reading specs like a madman the past week, expecting such a question from the /. audience. I'm also not a professional TCPAadvocate ... my understanding of TCPA is in relation to what AMIBIOS must do to enable the TPM(a hardware component required by the spec). I'm going to refer toTCPA specifications & FAQ a lot, so verifying my answers will be an exercise left to the reader.

Your question brings up a lot of common issues people seem have with TCPA:

1. What does TCPA do?

2. What does AMIBIOS have to do with TCPA?

3. What is the licensing structure?

4. Can open-source software make use of TCPA?

5. Does this have anything to do with Digital Rights Management (DRM)?

Let's see if Brian can hash his way through these items in some sort of order ...

a) What does TCPA do? TCPA is an industry specification that defines mechanisms for "trusted" client/server interaction ("trust" and "security" are two different things).

TCPA works in a very similar fashion as other key-based security mechanisms (SSH, PGP, SSL). Transmissions are secured by hashing against a key. Keys tend to be very long (128 bits or more), so it is difficult for "bad people" to guess your key. In many mechanisms, the key also serves to identify the user (proof that they are who they say they are). This key is often contained in a file or some sort of removable media, like a smart card.

TCPA adds a few elements to this security scheme:

1. More keys and longer keys (some keys are 160 bits, most are 2048 bits)

2. A crypto-processor to speed key computations

3. Secure key storage on the system mainboard

4. Establish platform "trust". The two excerpts below are taken from the TCPA FAQ:
   12. What do you mean by trust?
   The ability to feel confident that the software environment in a platform is operating as expected. This is done by reliably measuring and reliably reporting (using aliasing) information about the platform.
   
   Another such benefit is improved control of access to data. Previously such access has depended upon authorization or authentication. Now such access can also be linked to the state of the software in the platform. This enables the denial of access to data if rogue software, such as a virus, is introduced into a platform, because such introduction necessarily changes the software state of the platform.

The crypto-processor and key storage are provided by the Trusted Platform Module (TPM). A TCPA enabled system will have a TPM on the motherboard. This TPM can be disabled, as per TCPA specification, if the user wants to opt-out.

One concern is that TCPA is equivalent to a unique identifier on your computer, which causes a large number of privacy concerns. There's a large section of the FAQ (Item #13) that covers this topic:

The solutions support privacy principles in a number of ways:

1. The owner controls personalization.

2. The owner and user control the trust relationship.

3. Provides private object storage and digital signature capability.

4. Private personalization information is never exposed.

5. User keys are encrypted prior to transmission.

6. Supports multiple certificate authorities giving the user choice.

It is also important to know what the solutions are not:

1. They are not global identifiers.

2. They are not personalized before user interaction.

3. They are not fixed functions - it can be disabled permanently.

4. They are not controlled by others (only the owner controls).

b) What does AMIBIOS have to do with TCPA? The TPM requires initialization during BIOS POST. This allows what they refer to as "metrics" to be stored that help establish that the BIOS & OS can be trusted (i.e. haven't been h4x0r3d). Our "TCPA & AMIBIOS8" whitepaper has more information.

c) What is the licensing structure? There isn't one. From the TCPA FAQ:

10. What are the licensing and/or royalty arrangements for the technologies outlined by the TCPA specification?

The TCPA spec is currently set up as a "just-publish" IP model.

d) Can open-source software make use of TCPA? Yes. From the TPM FAQ:

18. Does the TCPA support open source systems?

Yes. The ability to use the TPM functionality is available to all developers of software. An open source project could determine to use TPM functionally today. The concepts of measurement, protected storage and attestation of measurements are fundamental concepts that hold true for any type of OS or application. The platforms that support TCPA today are not limited to only one OS and if open source developers provided applications that used the TPM functionality they would find support.

Remember ... SSH, GPG and SSL aren't any less secure because they're open-source. The whole point of key-based security is that you can't see the data without the key, even if you know the decryption mechanism.

e) TCPA & DRM? This question wasn't directly asked, but it's on everybody's mind ...

TCPA has been connected to proposed legislation that would require "content protection" on most digital media devices (including PCs).

While somebody could write a DRM application using the TPM, they could also write one without it. Non-DRM applications can be developed under TCPA. The example I thought of is an improved VPN for companies that are super-paranoid about their data (think about it ... 2048 bit keys, no hash load on the system CPU, ability to tie accessibility to a unique platform).

Adding TCPA & a TPM to a system doesn't automatically add DRM to a platform. Some application has to tie the TPM to the "media" being "protected". Merely adding TCPA to AMIBIOS doesn't constitute DRM:

Captain: What happen?
Mechanic: Somebody set up us the DRM.
Cats: How are you gentlemen !! All your BIOS are belong to us.

2) Advantage

by TedCheshireAcad

What is the advantage to me, a Linux using consumer, to buying your product over those of your competitors?

First, the short answer: a proven and stable product based on nearly two decades in the PC industry, with support for the latest technology.

Now, the long answer: Let me give a little background on how BIOS gets onto your average motherboard. I know that's not what you asked, but it will explain product design and benefits to the end user.

AMI markets AMIBIOS directly to the motherboard manufacturer, who we see as the actual "BIOS customer". So many of our features are oriented to motherboard manufacturers or BIOS developer. The end result of using our codebase is to produce a stable BIOS for the motherboard manufacturer's customer (that's you, the end user).

You can break these down three major areas:

1. Code structure (ease of development, tools, source management, etc.)

2. Technology support (OS, chipsets, processors, peripherals, etc.)

3. Support after the sale

a) The "BIOS core" is a different code component from silicon support code. The same applies to our technology support modules (ACPI,USB, TCPA, ASF, SMBIOS, APM, etc.). This allows board developers to pick just the code they need for their system. An embedded Linux board for an industrial controller has different BIOS requirements than the typical "white box" motherboard (OS compatibility, supported hardware, power management, etc.).

AMI also developed a custom GUI to make BIOS development easier (Visual eBIOS, or VeB). Believe it or not, most BIOS development happens at the DOS prompt in x86 assembly code. We found it harder to get new engineers comfortable with DOS-based development (DOS is 22 years old, so is the average college graduate). VeB also incorporates source control, so engineers manage the code from the same place they edit the code.

b) Technology support is pretty broad. We have to work on new chipsets, technologies and devices while keeping backwards compatibility for older hardware we'd rather forget about. This involves a lot of work with hardware vendors (Intel, AMD, ServerWorks, nVIDIA, etc.), software companies (Microsoft, RedHat, etc.) and technical specification groups (there's one for most every acronym out there). As you might imagine, there's a lot of testing to make sure all these things play well together.

Technology support also applies to features that don't have cool three letter acronyms. One example of this is "Fast POST" (POST is Power On Self Test, BIOS execution from power-on to OS bootloader). There was customer demand to boot the PC faster. This pressure came from Microsoft for a better overall user experience (yes, the obvious joke is "boot speed doesn't matter when you don't have to reboot so often" ... but I'm taking the high road). So now Fast POST is standard in AMIBIOS8.

c) "Service after the sale" sounds like something you hear in a men's clothing store, but it applies to BIOS as well. Customers expect bugs to be fixed, new features to be added, and a voice on the phone when they can't quite figure out which bit goes where. Some customers develop using our source code (as a licensee), while others use our engineers to create their BIOS (as contractors).

That might have been more of a sales pitch than you were expecting (sorry). There's more product information at the AMIBIOS website.

3) Performance hit

by oliverthered

I assume that data pathways will be signable or encrypted in some way. What performance hit will the [operating system] take when using trusted system? e.g. How much extra data is added to form a signature, what methods are used for signing. and how will this benefit the end-user?

A: I assume this is in reference to TCPA, so I'll use what I know of that spec to answer the question.

Everybody who's used SSH or SCP has experienced computation overhead from data encryption. That's the main reason TCPA has the Trusted Platform Module (TPM). Along with storing keys, it had a dedicated crypto-processor to handle random number generation, hashing and digital signatures. Due to the size of a security key, these hash computations add overhead (overhead == delay).

In TCPA, the hash/generation stuff is offloaded to the TPM. Since this dedicated processor does the work, the main system processor doesn't have to. The TPM is also a function specific processor, meaning it's optimized for security tasks (translation: faster than your general purpose x86 CPU). This is a good thing, since most of the TPM keys are 2048 bits.

If you look at Transmeta's recent security press release, you see the same functionality. Although this story was reported as Transmeta releasing DRM, they are actually providing an integrated crypto-processor in the TM5800. This function-specific processor is accessible through an extension to the x86 instruction set (similar to MMX or 3DNow!). The difference between this & the TPM is how you access the functions.

Sidenote: does any open-source developer want to check if these extensions could be used to improve SSH, SCP or GPG performance?

The signing methods and potential benefits are outlined in the TCPA specification and FAQ.

4) Why are BIOSes closed source?

by mcelrath

Having recently had a lot of trouble with my laptop's BIOS, on an issue that I could most certainly fix if I had access to the code... I started wondering what benefit AMI and other vendors have by keeping BIOS code secret? I can think of none whatsoever.

An open-source TCPA BIOS might go a long way to alleviating the fears of the open source community, since we could see exactly what it is you're forcing on us. And hey, no doubt you'd get a few bug-fixing patches in return for your efforts.

So, is an open-source BIOS a possibility? (TCPA or otherwise)

Just to get this out of the way:

1. AMI isn't forcing anybody to take any product offering, TCPA or otherwise.

2. TCPA doesn't block open-source (see #18 in the TPM FAQ @ trustedpc.org).

3. The TPM Memory Present (MP) driver BIOS uses during POST isn't open-source (it's provided by the TPM manufacturer).

This was the focus of a linux.com article several years back. There's plenty of advantages to open-source, but there are two main reasons for closed source BIOS: Legal Restrictions & Economics.

The creation of an open-source BIOS isn't limited by the BIOS itself, but by the information required to create the BIOS. Let me take a second and explain how the BIOS works at a programming level. This may seem like a tangent, but it helps explain issues faced by open-source BIOS developers (just think of it as Good Eats for BIOS).

There's three major components of any BIOS:

1. Core Routines

2. Silicon Support Routines

3. Board Specific Routines

The core can be equated to the kernel of an operating system, except that it comprises a larger percentage of the codebase (both in functionality and actual code size). This is everything that's generic from one BIOS to the next.

Silicon Support applies to the chips on the board initialized by the BIOS (processor, northbridge, southbridge, I/O, flash). BIOS core routines will call silicon routines when hardware configuration is required. These routines are created according to an API, so swapping any of these code modules doesn't affect the structure of the core.

Board Specific Routines represent the motherboard manufacturer's configuration. If you look at motherboards from two manufacturers that use the exact same silicon components, you might expect the BIOS from one board to work on the other ... but you'd be wrong. The small hardware changes that differentiate Board Vendor A from Board Vendor B have a large impact on the BIOS. PCI Interrupt routing, chipset General Purpose I/O pins and other parts of vendor's "secret sauce" go into this BIOS layer.

"Fine," you say, "but what does this have to do with open-source BIOS?"

I'm sure you've noticed that there's a BIOS ready for a chipset the day it is announced. AMI and other BIOS companies don't just come along the day of the silicon release and slap a BIOS together. We work hand-in-hand with the chipset vendor for months before the release. They send us an alpha board, we boot it ... they send us a beta board, we add more features ... they send us final silicon, we validate it.

Now remember that this hardware isn't public when AMI gets it. AMI has to sign a has to sign a Non-Disclosure Agreement (NDA) to get a development board or advance specifications, which means we can't tell anybody what we know about the product. Vendor-supplied reference code (memory detection, bridge configuration, etc.) is also covered under NDA. AMI also signs NDAs to cover the motherboard manufacturer's confidential information.

So the BIOS that ends up on those motherboards is constructed using information we can't release to any party not covered by NDA. You might be able to understand how this doesn't fit into to the open-source model.

So an open-source BIOS developer has a big dilemma ... they need access to information, but legally can't include it in open-source code. Many chipset vendors provide information after their chipset is released, but not many board vendors hand out schematics. Reverse engineering might reveal this information, but some items controlled by the BIOS can damage the system if not set properly (data corruption, overheating, smoke, flame, etc.) ... so random bit flipping may not be the answer. And nobody wants to get into the legal issues of using disassembled code in place of reverse engineering.

I think the closing statement from the linux.com LinuxBIOS article still applies ... "The real question isn't if an open source BIOS will ever work on a handful of platforms, but if it will ever become viable for mass market across many platforms."

There's another issue that comes into keeping AMIBIOS source code closed (or for that matter anycommercial source code). This has to do with economics.

This is where I change hats from "AMI company representative" to "average techno-Joe". The next few paragraphs are my feelings, not necessarily those of my employer or anybody else on the planet.

I personally like the idea of open-source, and I use a lot of open-source programs at home and work (Mozilla, OpenOffice, RedHat, Mandrake, ClarkConnect, PostNuke, perl, php, Bugzilla). But I also buy and use regular closed-source programs (my DV editing and VCD/DVD authoring tools). The choice isn't whether or not the source is accessible, but if the tool fits my needs.

In either case, those programs are the product of somebody's time (in most cases, a large group of bodies). They're a conglomeration of people's ideas, a manifestation of their talents, and monetary investment (open-source isn't free to develop, somebody bought that computer hardware). Those people, and whatever company funded their efforts, have the choice to distribute their product anyway they choose.

If a company wants to go open-source, then they can't make money selling source or seat licenses. RedHat doesn't make money selling code, they make money selling a code package and support for that package. My company doesn't operate that way ... in the realm of BIOS, money is made licensing source and selling per-board licenses. That's the way every BIOS vendor makes money.

That doesn't mean there's no open-source within AMI (perl/php/PostNuke/apache intranets, Bugzilla bug tracking, ucLinux on our MegaRAC G2 management card). But the choice to go open-source is done product by product, company by company.

In an industry driven by innovation, many companies feel they loose competitive advantage by opening their source ... if everybody has access to their ideas, then why buy their product over another? That mentality may not fit well with open-source, but these inexpensive computers we currently enjoy are the product of market forces. If there was no profit in computing, would Intel and AMD even exist?

Thus ends my personal views ... back to the actual interview ...

5) Technical Explanation of BIOS Settings

by doppleganger871

I have been doing research on BIOS settings for many years, and I have found good articles on what the settings do, and how to tweak them for the best performance/stability mix. But, I would like to know if the BIOS manufacturer itself would be able to provide an in-depth manual of all the BIOS settings, and what exactly they do. All the manuals that come with motherboards are very short on explanations, and I would like to see someone within the company actually explain to us hardware enthusiasts the down 'n dirty, nitty gritty, dirt under the rug, needle in a haystack type of information that we could use to make our computers run the absolute best they can. Because, as we all know, optimizing software and firmware is a lot cheaper than upgrading parts.

A: I wish I had a great answer for this. Despite my verbose nature, there's not enough room in this interview to discuss every setting that is or will be in the BIOS. Some of the basic settings are covered in BIOS setup manuals, and a few websites do a good job of explain the ugly details. The problem is that those "cryptic" options change for every chipset on the market.

We're always looking at product improvements, and that includes documentation. Our setup manual is a generic template, designed for the motherboard customer as a starting point for their manuals. The "chipset specific setup information" is part of a new documentation effort within AMI (we talked about in meetings this week).

Outside of that, optimizing settings for a specific combination of board, memory and processor is still trial and error (tweak, reboot, benchmark, swear ... tweak, reboot, benchmark, swear ...). I don't know if better documentation will change that.

6) "Trusted" computer

by michael

A few related questions:

a) Isn't the goal of "trusted computing" to allow entities other than the owner of the computer to control what the owner does with his/her hardware? For example, "trusted computing" applied to music implies that the music publisher gains control over what the computer owner can do with the music data files. Isn't this the exact opposite of "trust" as that word is normally used - a trusted computer is one that can't be trusted by the computer's owner to perform the tasks asked of it, because other entities have veto power over the computer's actions?

b) Companies like AMI have repeatedly claimed that they aren't part of Palladium. However, isn't it true that without AMI's trusted BIOS (and all the other components necessary to build a "trusted computer"), Palladium wouldn't work? Why does AMI think they shouldn't be held responsible for enabling Palladium and similar schemes?

c) In what way does AMI benefit, financially or otherwise, from introducing a BIOS designed to make the computer it is installed in less useful to the purchaser of the computer? Please avoid saying that this is "optional"; AMI wouldn't create this BIOS if it wasn't intended to be used.

A: Let's take these in order ...

a) The Goal Of Trusted Computing: Despite the fact my company is a TCPA member company, the concept of trusted computing wasn't created by AMI (we're not even a founding member).

As far as the goals of the specification, I'm not the designated defender of TCPA. I'll let theTCPA speak to their own goals. You seem to automatically equate "trust" to DRM, but that's not what I get from reading the specifications and related materials (see part (e) of my answer to the first question).

b) Palladium & AMIBIOS: You are correct in understanding that Palladium will require some amount of BIOS support. The reason we keep saying "we're not a part of Palladium" is because Palladium doesn't exist in the marketplace ... it's a Microsoft initiative being developed under guarded care in a small circle of developers. It's not a public specification like TCPA, so our role in this scheme is unknown. My understanding is that we'll get a specification from Microsoft whenever they're ready to involve the BIOS developers, but I don't know under what terms it will be made public (my Magic 8 Ball says "Ask Again Later").

c) Financial Benefit: Yes, there is a financial benefit to supporting a technology that our customers ask for ... they continue to be our customers. Not every customer has asked for TCPA yet, but enough large customers have asked to make it financially reasonable. Keep in mind that this is just one more feature we offer, which the customer may or may not want to take.

So when a customer (or customers) comes to AMI and says "Our next motherboard will support TCPA, and we need a BIOS module", AMI has two choices:

1. Say yes, develop the code, make the customer happy

2. Say no

If we select option #2 (for whatever reason), our customer has one of two responses:

1. "No problem, we licensed your code ... we'll add the support ourselves."

2. "Too bad, you have a competitor who offers this support ... it was nice doing business with you."

Option B is an obvious downer, because customers give us money. Money can be exchanged for goods and services, like food ... and I find food to be an important part of a nutritious breakfast.

Option A presents another series of problems. Yes, we kept the customer, but now we have a forked version of our code floating around. If only one customer wants this feature, then it's not a big deal. If twenty customers want this feature, then there's twenty code forks. They're still our customers, so they expect support ... and this is a support nightmare.

Our decision to develop a TCPA option was driven by sufficient demand for the technology. We're not the only company in the marketplace offering TCPA. Phoenix, our largest competitor, has been working on TCPA for quite sometime. IBM is already shipping notebooks with TPM hardware (which run Linux, according to LinuxCare Labs). If AMI customers don't ship TCPA, they we spent time developing a feature nobody wanted (it wouldn't be the first time, but that's happens in cutting edge development), but we have customer goodwill because we're responsive to their needs. It's the same in our eyes as developing support for a chipset ... if nobody likes the chipset, then they don't buy the code to support it.

What we have done by choosing TCPA over any number of proprietary security solutions is present an option that isn't closed to third parties. If we enable TCPA on a board and you want to make use of it, read the spec and develop accordingly.

7) Hardware vendors

by cybermace5

Since a BIOS is only part of a motherboard: what steps will hardware vendors have to take, in order to incorporate your BIOS? Will they have to adhere to certain hardware design rules or controls in order to maintain the TCPA? Is there going to be a licensing procedure for hardware manufacturers?

A: Hardware vendors don't have to do much for AMIBIOS to support TCPA. The TCPA code module gets included as an add-on. The hardware manufacturer has to obtain a TPM to place on the motherboard, but that's available from a third party vendor.

The TCPA specification doesn't mandate licensing (see point #10 in the TCPA FAQ). It's not an AMI specification, so it's not our job to check for compliance. Third-party labs will most likely perform platform certification based on TCPA specifications.

8) Windows override

by Forkenhoppen

I have a question; on previous occassions on VIA hardware I've owned, I've noticed that occasionally, Windows will enable a feature even though I have turned it off in the BIOS.

My question is this; if I have TCPA disabled in my BIOS, will Windows drivers abide by this? Or will they still be able to use aspects of the BIOS originally put in place for use by TCPA even though I have it shut off?

What plans are in place to keep a Windows driver from hijacking TCPA-related information for it's own purposes?

A: A lot of that depends on how the motherboard vendor implements the TPM disable option mandated by the TCPA specification.

The TCPA specification has many options for disabling the TPM. It can be a BIOS setup question, jumper or software driven. The first two would be really hard to override in software (unless there's a robotic hand attached to the USB port). The third option could present a software override, but you would have to reboot to have the TPM enabled at power-on to set proper "root of trust" (you can't just turn it on midstream, since a TCPA system is supposed to hash the BIOS & bootloader).

9) TCPA & Palladium

by ignipotentis

Perhaps you can clarify the differences between the two (TCPA & Palladium). After reading up on both of them, i still find that they seem to be pretty much the same, just marketed differently.

A: From the information that's been made public concerning Palladium, I can try to elaborate on this. As I understand it, the major differences are listed below:

• Curtain Memory

• Control of Specification

• Intellectual Property (IP) Rights

The last two points are pretty self explanatory. Palladium it not a public specification, there may be licensing issues. TCPA is a public document created and reviewed by a number of different companies, with no licensing demands.

The first point is technical in nature. Here's how the Microsoft's Palladium FAQ describes "curtain memory":

The ability to wall off and hide pages of main memory so that each "Palladium" application can be assured that it is not modified or observed by any other application or even the operating system

This type of mechanism doesn't exist in TCPA, and would probably require some sort of support at the chipset level (which means it couldn't be implemented using current northbridge hardware). The total system impact isn't known, and it's any body's guess what this does to application development.

10) What do you think about Linux BIOS?

by lanner

At first, I was going to ask you about how you have cooperated, if at all, with the Linux BIOS project. After all, you often have historically cooperated with Microsoft and Novell. What are you doing to help Linux?

But then it occurred to me, if Linux BIOS was successful, it would put AMI out of the BIOS software development business. Linux BIOS is a competitor of AMI.

What is your personal perspective about Linux BIOS, and what does AMI think about it?

A: There's a lot of overlap with question #4 here. But there are two points I'd like to touch on:

1. Cooperation with Microsoft, Novell & Linux

2. Perspective on LinuxBIOS

a) Saying that we "cooperate" with Microsoft and Novell is misleading. AMI creates AMIBIOS for maximum hardware and software compatibility. For years, Microsoft and Novell were the primary OS vendors used by our customers. Microsoft also drives many PC specifications, and the majority of our customers use Microsoft operating systems. Development and testing are focused based on customer demand.

In the past few years, that situation has changed. Novell isn't a major consideration for our customers, but we still test compatibility. Linux is demanded by more customers, and our testing efforts have been increased to match that demand. We test RedHat, SuSe, Mandrake, Xandros, Lindows and FreeBSD by default (along with various beta distros).

Microsoft is still key to our testing and development (we test everything back to Win98). Customers still need that "Designed for Windows" sticker. But Linux is a major focus in our testing and development ... not just because we develop for compatibility, but because our customers ask for it by name.

b) In some areas, people see LinuxBIOS as competition to the other BIOS vendors.

• As far as the source licensing (open vs. closed), see my answer to question #4.

• In features, LinuxBIOS does some things that our BIOS doesn't (mostly in the areas of cluster management) ... AMI has advantages over LinuxBIOS as well (boot from USB/USB2, JPEG graphics as boot logo, broader chipset support, ACPI/APM power management, etc.).

• LinuxBIOS was developed for a specific application, but has broadened ... AMIBIOS aims to offer broad support in many market segments.

• AMIBIOS has been tested against a larger number of system configurations, works with a larger variety of hardware, and has a longer product history.

I'm not sure how others at AMI feel about LinuxBIOS, but all I have to say is "go for it". There's some neat stuff coming out of that project, and it's interesting to see what they've accomplished. Competition in the market is what makes technology improve ... one notch better than the last thing, one step ahead of the next guy.

Thus ends the interview. Thanks to Slashdot for the opportunity, and thanks to the readers for wading through the text.

We ran the "Call for questions" Monday, January 13, under the headline, Discuss BIOS and Palladium Issues With an AMIBIOS Rep. Note that Brian Richardson, AMI sales engineer, is a real engineer, not just a salesperson, and is also a staunch Slashdot reader who knows we have low tolerance for PR whitewashes around here. Brian's answers are real, not laundered, and he responded not only to the 10 questions we sent him but also to some he felt deserved answers even though they weren't moderated all the way up. Please note that in much of this interview he is speaking as "Brian Richardson, individual," and that his opinions do not necessarily reflect those of AMI's management. With that said, be prepared to learn a lot about the BIOS business, and how TCPA and Palladium relate (and don't relate) to it.

Preface:

I thought it might be handy for the audience to know who's handling their questions ...

My name is Brian Richardson. I work for American Megatrends, Inc . (AMI). AMI is a privately held company located in Norcross, GA (just north of Atlanta). We employ approximately 400 people worldwide (about 200 in the United States).

I am a "BIOS Sales Engineer", responsible for handling technical issues related to selling and marketing the AMIBIOS8 , our latest BIOS code revision. This includes writing whitepapers, demonstrating products, answering technical sales questions, speaking at industry conferences and handling requests from the press that may require more than a passing knowledge of technology (like this one).

I started at AMI in 1996. I've been in this job for two years. Before that I wrote BIOS code for our notebook team and helped design our Software Quality Automated Testing (SQuAT) system. I also maintain several company intranets and our Bugzilla server, used for tracking bugs during BIOS development.

In spare time, I serve on the board of directors of Tech Corps Georgia. I also managed the Hardware section of linux.com (old articles are archived at linux.omnipotent.net).

This interview covers BIOS in general, but the questions have a heavy slant towards TCPA & Palladium. I'm sure I won't address everybody's TCPA related questions here. AMI has a "TCPA and AMIBIOS8" whitepaper at our website which discusses AMI's implementation. There are also links to other information on TCPA.

To answer some of the more unusual questions that didn't make it into the Top 10:

• You use XOR to clear a register instead of a simple MOV instruction because of the instruction size (XOR uses a two byte opcode, MOV uses three bytes). The savings in space really adds up after a while.

• We haven't finished 1394 boot yet, but we do have USB & USB 2.0 boot support

• I don't know, I've never met Satan ... but I have been to WinHEC

Now on to the questions ...

1) On the Exclusionary Uses of TCPA

by the-banker

Is it (will it be) possible to use TCPA to effectively lock-out certain operating evironments from various services (software, media, etc) solely because the operating environment is not backed by a company, and has no mechanism for paying certification fees and licenses? Specifically, could TCPA be used against free OS's like Free/Open/netBSD and Linux to prevent those users from accessing the same content users of commercial OS's can?

Let me start out by reminding the audience I am not a security expert. I have been reading specs like a madman the past week, expecting such a question from the /. audience. I'm also not a professional TCPAadvocate ... my understanding of TCPA is in relation to what AMIBIOS must do to enable the TPM(a hardware component required by the spec). I'm going to refer toTCPA specifications & FAQ a lot, so verifying my answers will be an exercise left to the reader.

Your question brings up a lot of common issues people seem have with TCPA:

1. What does TCPA do?

2. What does AMIBIOS have to do with TCPA?

3. What is the licensing structure?

4. Can open-source software make use of TCPA?

5. Does this have anything to do with Digital Rights Management (DRM)?

Let's see if Brian can hash his way through these items in some sort of order ...

a) What does TCPA do? TCPA is an industry specification that defines mechanisms for "trusted" client/server interaction ("trust" and "security" are two different things).

TCPA works in a very similar fashion as other key-based security mechanisms (SSH, PGP, SSL). Transmissions are secured by hashing against a key. Keys tend to be very long (128 bits or more), so it is difficult for "bad people" to guess your key. In many mechanisms, the key also serves to identify the user (proof that they are who they say they are). This key is often contained in a file or some sort of removable media, like a smart card.

TCPA adds a few elements to this security scheme:

1. More keys and longer keys (some keys are 160 bits, most are 2048 bits)

2. A crypto-processor to speed key computations

3. Secure key storage on the system mainboard

4. Establish platform "trust". The two excerpts below are taken from the TCPA FAQ:
   12. What do you mean by trust?
   The ability to feel confident that the software environment in a platform is operating as expected. This is done by reliably measuring and reliably reporting (using aliasing) information about the platform.
   
   Another such benefit is improved control of access to data. Previously such access has depended upon authorization or authentication. Now such access can also be linked to the state of the software in the platform. This enables the denial of access to data if rogue software, such as a virus, is introduced into a platform, because such introduction necessarily changes the software state of the platform.

The crypto-processor and key storage are provided by the Trusted Platform Module (TPM). A TCPA enabled system will have a TPM on the motherboard. This TPM can be disabled, as per TCPA specification, if the user wants to opt-out.

One concern is that TCPA is equivalent to a unique identifier on your computer, which causes a large number of privacy concerns. There's a large section of the FAQ (Item #13) that covers this topic:

The solutions support privacy principles in a number of ways:

1. The owner controls personalization.

2. The owner and user control the trust relationship.

3. Provides private object storage and digital signature capability.

4. Private personalization information is never exposed.

5. User keys are encrypted prior to transmission.

6. Supports multiple certificate authorities giving the user choice.

It is also important to know what the solutions are not:

1. They are not global identifiers.

2. They are not personalized before user interaction.

3. They are not fixed functions - it can be disabled permanently.

4. They are not controlled by others (only the owner controls).

b) What does AMIBIOS have to do with TCPA? The TPM requires initialization during BIOS POST. This allows what they refer to as "metrics" to be stored that help establish that the BIOS & OS can be trusted (i.e. haven't been h4x0r3d). Our "TCPA & AMIBIOS8" whitepaper has more information.

c) What is the licensing structure? There isn't one. From the TCPA FAQ:

10. What are the licensing and/or royalty arrangements for the technologies outlined by the TCPA specification?

The TCPA spec is currently set up as a "just-publish" IP model.

d) Can open-source software make use of TCPA? Yes. From the TPM FAQ:

18. Does the TCPA support open source systems?

Yes. The ability to use the TPM functionality is available to all developers of software. An open source project could determine to use TPM functionally today. The concepts of measurement, protected storage and attestation of measurements are fundamental concepts that hold true for any type of OS or application. The platforms that support TCPA today are not limited to only one OS and if open source developers provided applications that used the TPM functionality they would find support.

Remember ... SSH, GPG and SSL aren't any less secure because they're open-source. The whole point of key-based security is that you can't see the data without the key, even if you know the decryption mechanism.

e) TCPA & DRM? This question wasn't directly asked, but it's on everybody's mind ...

TCPA has been connected to proposed legislation that would require "content protection" on most digital media devices (including PCs).

While somebody could write a DRM application using the TPM, they could also write one without it. Non-DRM applications can be developed under TCPA. The example I thought of is an improved VPN for companies that are super-paranoid about their data (think about it ... 2048 bit keys, no hash load on the system CPU, ability to tie accessibility to a unique platform).

Adding TCPA & a TPM to a system doesn't automatically add DRM to a platform. Some application has to tie the TPM to the "media" being "protected". Merely adding TCPA to AMIBIOS doesn't constitute DRM:

Captain: What happen?
Mechanic: Somebody set up us the DRM.
Cats: How are you gentlemen !! All your BIOS are belong to us.

2) Advantage

by TedCheshireAcad

What is the advantage to me, a Linux using consumer, to buying your product over those of your competitors?

First, the short answer: a proven and stable product based on nearly two decades in the PC industry, with support for the latest technology.

Now, the long answer: Let me give a little background on how BIOS gets onto your average motherboard. I know that's not what you asked, but it will explain product design and benefits to the end user.

AMI markets AMIBIOS directly to the motherboard manufacturer, who we see as the actual "BIOS customer". So many of our features are oriented to motherboard manufacturers or BIOS developer. The end result of using our codebase is to produce a stable BIOS for the motherboard manufacturer's customer (that's you, the end user).

You can break these down three major areas:

1. Code structure (ease of development, tools, source management, etc.)

2. Technology support (OS, chipsets, processors, peripherals, etc.)

3. Support after the sale

a) The "BIOS core" is a different code component from silicon support code. The same applies to our technology support modules (ACPI,USB, TCPA, ASF, SMBIOS, APM, etc.). This allows board developers to pick just the code they need for their system. An embedded Linux board for an industrial controller has different BIOS requirements than the typical "white box" motherboard (OS compatibility, supported hardware, power management, etc.).

AMI also developed a custom GUI to make BIOS development easier (Visual eBIOS, or VeB). Believe it or not, most BIOS development happens at the DOS prompt in x86 assembly code. We found it harder to get new engineers comfortable with DOS-based development (DOS is 22 years old, so is the average college graduate). VeB also incorporates source control, so engineers manage the code from the same place they edit the code.

b) Technology support is pretty broad. We have to work on new chipsets, technologies and devices while keeping backwards compatibility for older hardware we'd rather forget about. This involves a lot of work with hardware vendors (Intel, AMD, ServerWorks, nVIDIA, etc.), software companies (Microsoft, RedHat, etc.) and technical specification groups (there's one for most every acronym out there). As you might imagine, there's a lot of testing to make sure all these things play well together.

Technology support also applies to features that don't have cool three letter acronyms. One example of this is "Fast POST" (POST is Power On Self Test, BIOS execution from power-on to OS bootloader). There was customer demand to boot the PC faster. This pressure came from Microsoft for a better overall user experience (yes, the obvious joke is "boot speed doesn't matter when you don't have to reboot so often" ... but I'm taking the high road). So now Fast POST is standard in AMIBIOS8.

c) "Service after the sale" sounds like something you hear in a men's clothing store, but it applies to BIOS as well. Customers expect bugs to be fixed, new features to be added, and a voice on the phone when they can't quite figure out which bit goes where. Some customers develop using our source code (as a licensee), while others use our engineers to create their BIOS (as contractors).

That might have been more of a sales pitch than you were expecting (sorry). There's more product information at the AMIBIOS website.

3) Performance hit

by oliverthered

I assume that data pathways will be signable or encrypted in some way. What performance hit will the [operating system] take when using trusted system? e.g. How much extra data is added to form a signature, what methods are used for signing. and how will this benefit the end-user?

A: I assume this is in reference to TCPA, so I'll use what I know of that spec to answer the question.

Everybody who's used SSH or SCP has experienced computation overhead from data encryption. That's the main reason TCPA has the Trusted Platform Module (TPM). Along with storing keys, it had a dedicated crypto-processor to handle random number generation, hashing and digital signatures. Due to the size of a security key, these hash computations add overhead (overhead == delay).

In TCPA, the hash/generation stuff is offloaded to the TPM. Since this dedicated processor does the work, the main system processor doesn't have to. The TPM is also a function specific processor, meaning it's optimized for security tasks (translation: faster than your general purpose x86 CPU). This is a good thing, since most of the TPM keys are 2048 bits.

If you look at Transmeta's recent security press release, you see the same functionality. Although this story was reported as Transmeta releasing DRM, they are actually providing an integrated crypto-processor in the TM5800. This function-specific processor is accessible through an extension to the x86 instruction set (similar to MMX or 3DNow!). The difference between this & the TPM is how you access the functions.

Sidenote: does any open-source developer want to check if these extensions could be used to improve SSH, SCP or GPG performance?

The signing methods and potential benefits are outlined in the TCPA specification and FAQ.

4) Why are BIOSes closed source?

by mcelrath

Having recently had a lot of trouble with my laptop's BIOS, on an issue that I could most certainly fix if I had access to the code... I started wondering what benefit AMI and other vendors have by keeping BIOS code secret? I can think of none whatsoever.

An open-source TCPA BIOS might go a long way to alleviating the fears of the open source community, since we could see exactly what it is you're forcing on us. And hey, no doubt you'd get a few bug-fixing patches in return for your efforts.

So, is an open-source BIOS a possibility? (TCPA or otherwise)

Just to get this out of the way:

1. AMI isn't forcing anybody to take any product offering, TCPA or otherwise.

2. TCPA doesn't block open-source (see #18 in the TPM FAQ @ trustedpc.org).

3. The TPM Memory Present (MP) driver BIOS uses during POST isn't open-source (it's provided by the TPM manufacturer).

This was the focus of a linux.com article several years back. There's plenty of advantages to open-source, but there are two main reasons for closed source BIOS: Legal Restrictions & Economics.

The creation of an open-source BIOS isn't limited by the BIOS itself, but by the information required to create the BIOS. Let me take a second and explain how the BIOS works at a programming level. This may seem like a tangent, but it helps explain issues faced by open-source BIOS developers (just think of it as Good Eats for BIOS).

There's three major components of any BIOS:

1. Core Routines

2. Silicon Support Routines

3. Board Specific Routines

The core can be equated to the kernel of an operating system, except that it comprises a larger percentage of the codebase (both in functionality and actual code size). This is everything that's generic from one BIOS to the next.

Silicon Support applies to the chips on the board initialized by the BIOS (processor, northbridge, southbridge, I/O, flash). BIOS core routines will call silicon routines when hardware configuration is required. These routines are created according to an API, so swapping any of these code modules doesn't affect the structure of the core.

Board Specific Routines represent the motherboard manufacturer's configuration. If you look at motherboards from two manufacturers that use the exact same silicon components, you might expect the BIOS from one board to work on the other ... but you'd be wrong. The small hardware changes that differentiate Board Vendor A from Board Vendor B have a large impact on the BIOS. PCI Interrupt routing, chipset General Purpose I/O pins and other parts of vendor's "secret sauce" go into this BIOS layer.

"Fine," you say, "but what does this have to do with open-source BIOS?"

I'm sure you've noticed that there's a BIOS ready for a chipset the day it is announced. AMI and other BIOS companies don't just come along the day of the silicon release and slap a BIOS together. We work hand-in-hand with the chipset vendor for months before the release. They send us an alpha board, we boot it ... they send us a beta board, we add more features ... they send us final silicon, we validate it.

Now remember that this hardware isn't public when AMI gets it. AMI has to sign a has to sign a Non-Disclosure Agreement (NDA) to get a development board or advance specifications, which means we can't tell anybody what we know about the product. Vendor-supplied reference code (memory detection, bridge configuration, etc.) is also covered under NDA. AMI also signs NDAs to cover the motherboard manufacturer's confidential information.

So the BIOS that ends up on those motherboards is constructed using information we can't release to any party not covered by NDA. You might be able to understand how this doesn't fit into to the open-source model.

So an open-source BIOS developer has a big dilemma ... they need access to information, but legally can't include it in open-source code. Many chipset vendors provide information after their chipset is released, but not many board vendors hand out schematics. Reverse engineering might reveal this information, but some items controlled by the BIOS can damage the system if not set properly (data corruption, overheating, smoke, flame, etc.) ... so random bit flipping may not be the answer. And nobody wants to get into the legal issues of using disassembled code in place of reverse engineering.

I think the closing statement from the linux.com LinuxBIOS article still applies ... "The real question isn't if an open source BIOS will ever work on a handful of platforms, but if it will ever become viable for mass market across many platforms."

There's another issue that comes into keeping AMIBIOS source code closed (or for that matter anycommercial source code). This has to do with economics.

This is where I change hats from "AMI company representative" to "average techno-Joe". The next few paragraphs are my feelings, not necessarily those of my employer or anybody else on the planet.

I personally like the idea of open-source, and I use a lot of open-source programs at home and work (Mozilla, OpenOffice, RedHat, Mandrake, ClarkConnect, PostNuke, perl, php, Bugzilla). But I also buy and use regular closed-source programs (my DV editing and VCD/DVD authoring tools). The choice isn't whether or not the source is accessible, but if the tool fits my needs.

In either case, those programs are the product of somebody's time (in most cases, a large group of bodies). They're a conglomeration of people's ideas, a manifestation of their talents, and monetary investment (open-source isn't free to develop, somebody bought that computer hardware). Those people, and whatever company funded their efforts, have the choice to distribute their product anyway they choose.

If a company wants to go open-source, then they can't make money selling source or seat licenses. RedHat doesn't make money selling code, they make money selling a code package and support for that package. My company doesn't operate that way ... in the realm of BIOS, money is made licensing source and selling per-board licenses. That's the way every BIOS vendor makes money.

That doesn't mean there's no open-source within AMI (perl/php/PostNuke/apache intranets, Bugzilla bug tracking, ucLinux on our MegaRAC G2 management card). But the choice to go open-source is done product by product, company by company.

In an industry driven by innovation, many companies feel they loose competitive advantage by opening their source ... if everybody has access to their ideas, then why buy their product over another? That mentality may not fit well with open-source, but these inexpensive computers we currently enjoy are the product of market forces. If there was no profit in computing, would Intel and AMD even exist?

Thus ends my personal views ... back to the actual interview ...

5) Technical Explanation of BIOS Settings

by doppleganger871

I have been doing research on BIOS settings for many years, and I have found good articles on what the settings do, and how to tweak them for the best performance/stability mix. But, I would like to know if the BIOS manufacturer itself would be able to provide an in-depth manual of all the BIOS settings, and what exactly they do. All the manuals that come with motherboards are very short on explanations, and I would like to see someone within the company actually explain to us hardware enthusiasts the down 'n dirty, nitty gritty, dirt under the rug, needle in a haystack type of information that we could use to make our computers run the absolute best they can. Because, as we all know, optimizing software and firmware is a lot cheaper than upgrading parts.

A: I wish I had a great answer for this. Despite my verbose nature, there's not enough room in this interview to discuss every setting that is or will be in the BIOS. Some of the basic settings are covered in BIOS setup manuals, and a few websites do a good job of explain the ugly details. The problem is that those "cryptic" options change for every chipset on the market.

We're always looking at product improvements, and that includes documentation. Our setup manual is a generic template, designed for the motherboard customer as a starting point for their manuals. The "chipset specific setup information" is part of a new documentation effort within AMI (we talked about in meetings this week).

Outside of that, optimizing settings for a specific combination of board, memory and processor is still trial and error (tweak, reboot, benchmark, swear ... tweak, reboot, benchmark, swear ...). I don't know if better documentation will change that.

6) "Trusted" computer

by michael

A few related questions:

a) Isn't the goal of "trusted computing" to allow entities other than the owner of the computer to control what the owner does with his/her hardware? For example, "trusted computing" applied to music implies that the music publisher gains control over what the computer owner can do with the music data files. Isn't this the exact opposite of "trust" as that word is normally used - a trusted computer is one that can't be trusted by the computer's owner to perform the tasks asked of it, because other entities have veto power over the computer's actions?

b) Companies like AMI have repeatedly claimed that they aren't part of Palladium. However, isn't it true that without AMI's trusted BIOS (and all the other components necessary to build a "trusted computer"), Palladium wouldn't work? Why does AMI think they shouldn't be held responsible for enabling Palladium and similar schemes?

c) In what way does AMI benefit, financially or otherwise, from introducing a BIOS designed to make the computer it is installed in less useful to the purchaser of the computer? Please avoid saying that this is "optional"; AMI wouldn't create this BIOS if it wasn't intended to be used.

A: Let's take these in order ...

a) The Goal Of Trusted Computing: Despite the fact my company is a TCPA member company, the concept of trusted computing wasn't created by AMI (we're not even a founding member).

As far as the goals of the specification, I'm not the designated defender of TCPA. I'll let theTCPA speak to their own goals. You seem to automatically equate "trust" to DRM, but that's not what I get from reading the specifications and related materials (see part (e) of my answer to the first question).

b) Palladium & AMIBIOS: You are correct in understanding that Palladium will require some amount of BIOS support. The reason we keep saying "we're not a part of Palladium" is because Palladium doesn't exist in the marketplace ... it's a Microsoft initiative being developed under guarded care in a small circle of developers. It's not a public specification like TCPA, so our role in this scheme is unknown. My understanding is that we'll get a specification from Microsoft whenever they're ready to involve the BIOS developers, but I don't know under what terms it will be made public (my Magic 8 Ball says "Ask Again Later").

c) Financial Benefit: Yes, there is a financial benefit to supporting a technology that our customers ask for ... they continue to be our customers. Not every customer has asked for TCPA yet, but enough large customers have asked to make it financially reasonable. Keep in mind that this is just one more feature we offer, which the customer may or may not want to take.

So when a customer (or customers) comes to AMI and says "Our next motherboard will support TCPA, and we need a BIOS module", AMI has two choices:

1. Say yes, develop the code, make the customer happy

2. Say no

If we select option #2 (for whatever reason), our customer has one of two responses:

1. "No problem, we licensed your code ... we'll add the support ourselves."

2. "Too bad, you have a competitor who offers this support ... it was nice doing business with you."

Option B is an obvious downer, because customers give us money. Money can be exchanged for goods and services, like food ... and I find food to be an important part of a nutritious breakfast.

Option A presents another series of problems. Yes, we kept the customer, but now we have a forked version of our code floating around. If only one customer wants this feature, then it's not a big deal. If twenty customers want this feature, then there's twenty code forks. They're still our customers, so they expect support ... and this is a support nightmare.

Our decision to develop a TCPA option was driven by sufficient demand for the technology. We're not the only company in the marketplace offering TCPA. Phoenix, our largest competitor, has been working on TCPA for quite sometime. IBM is already shipping notebooks with TPM hardware (which run Linux, according to LinuxCare Labs). If AMI customers don't ship TCPA, they we spent time developing a feature nobody wanted (it wouldn't be the first time, but that's happens in cutting edge development), but we have customer goodwill because we're responsive to their needs. It's the same in our eyes as developing support for a chipset ... if nobody likes the chipset, then they don't buy the code to support it.

What we have done by choosing TCPA over any number of proprietary security solutions is present an option that isn't closed to third parties. If we enable TCPA on a board and you want to make use of it, read the spec and develop accordingly.

7) Hardware vendors

by cybermace5

Since a BIOS is only part of a motherboard: what steps will hardware vendors have to take, in order to incorporate your BIOS? Will they have to adhere to certain hardware design rules or controls in order to maintain the TCPA? Is there going to be a licensing procedure for hardware manufacturers?

A: Hardware vendors don't have to do much for AMIBIOS to support TCPA. The TCPA code module gets included as an add-on. The hardware manufacturer has to obtain a TPM to place on the motherboard, but that's available from a third party vendor.

The TCPA specification doesn't mandate licensing (see point #10 in the TCPA FAQ). It's not an AMI specification, so it's not our job to check for compliance. Third-party labs will most likely perform platform certification based on TCPA specifications.

8) Windows override

by Forkenhoppen

I have a question; on previous occassions on VIA hardware I've owned, I've noticed that occasionally, Windows will enable a feature even though I have turned it off in the BIOS.

My question is this; if I have TCPA disabled in my BIOS, will Windows drivers abide by this? Or will they still be able to use aspects of the BIOS originally put in place for use by TCPA even though I have it shut off?

What plans are in place to keep a Windows driver from hijacking TCPA-related information for it's own purposes?

A: A lot of that depends on how the motherboard vendor implements the TPM disable option mandated by the TCPA specification.

The TCPA specification has many options for disabling the TPM. It can be a BIOS setup question, jumper or software driven. The first two would be really hard to override in software (unless there's a robotic hand attached to the USB port). The third option could present a software override, but you would have to reboot to have the TPM enabled at power-on to set proper "root of trust" (you can't just turn it on midstream, since a TCPA system is supposed to hash the BIOS & bootloader).

9) TCPA & Palladium

by ignipotentis

Perhaps you can clarify the differences between the two (TCPA & Palladium). After reading up on both of them, i still find that they seem to be pretty much the same, just marketed differently.

A: From the information that's been made public concerning Palladium, I can try to elaborate on this. As I understand it, the major differences are listed below:

• Curtain Memory

• Control of Specification

• Intellectual Property (IP) Rights

The last two points are pretty self explanatory. Palladium it not a public specification, there may be licensing issues. TCPA is a public document created and reviewed by a number of different companies, with no licensing demands.

The first point is technical in nature. Here's how the Microsoft's Palladium FAQ describes "curtain memory":

The ability to wall off and hide pages of main memory so that each "Palladium" application can be assured that it is not modified or observed by any other application or even the operating system

This type of mechanism doesn't exist in TCPA, and would probably require some sort of support at the chipset level (which means it couldn't be implemented using current northbridge hardware). The total system impact isn't known, and it's any body's guess what this does to application development.

10) What do you think about Linux BIOS?

by lanner

At first, I was going to ask you about how you have cooperated, if at all, with the Linux BIOS project. After all, you often have historically cooperated with Microsoft and Novell. What are you doing to help Linux?

But then it occurred to me, if Linux BIOS was successful, it would put AMI out of the BIOS software development business. Linux BIOS is a competitor of AMI.

What is your personal perspective about Linux BIOS, and what does AMI think about it?

A: There's a lot of overlap with question #4 here. But there are two points I'd like to touch on:

1. Cooperation with Microsoft, Novell & Linux

2. Perspective on LinuxBIOS

a) Saying that we "cooperate" with Microsoft and Novell is misleading. AMI creates AMIBIOS for maximum hardware and software compatibility. For years, Microsoft and Novell were the primary OS vendors used by our customers. Microsoft also drives many PC specifications, and the majority of our customers use Microsoft operating systems. Development and testing are focused based on customer demand.

In the past few years, that situation has changed. Novell isn't a major consideration for our customers, but we still test compatibility. Linux is demanded by more customers, and our testing efforts have been increased to match that demand. We test RedHat, SuSe, Mandrake, Xandros, Lindows and FreeBSD by default (along with various beta distros).

Microsoft is still key to our testing and development (we test everything back to Win98). Customers still need that "Designed for Windows" sticker. But Linux is a major focus in our testing and development ... not just because we develop for compatibility, but because our customers ask for it by name.

b) In some areas, people see LinuxBIOS as competition to the other BIOS vendors.

• As far as the source licensing (open vs. closed), see my answer to question #4.

• In features, LinuxBIOS does some things that our BIOS doesn't (mostly in the areas of cluster management) ... AMI has advantages over LinuxBIOS as well (boot from USB/USB2, JPEG graphics as boot logo, broader chipset support, ACPI/APM power management, etc.).

• LinuxBIOS was developed for a specific application, but has broadened ... AMIBIOS aims to offer broad support in many market segments.

• AMIBIOS has been tested against a larger number of system configurations, works with a larger variety of hardware, and has a longer product history.

I'm not sure how others at AMI feel about LinuxBIOS, but all I have to say is "go for it". There's some neat stuff coming out of that project, and it's interesting to see what they've accomplished. Competition in the market is what makes technology improve ... one notch better than the last thing, one step ahead of the next guy.

Thus ends the interview. Thanks to Slashdot for the opportunity, and thanks to the readers for wading through the text.

We ran the "Call for questions" Monday, January 13, under the headline, Discuss BIOS and Palladium Issues With an AMIBIOS Rep. Note that Brian Richardson, AMI sales engineer, is a real engineer, not just a salesperson, and is also a staunch Slashdot reader who knows we have low tolerance for PR whitewashes around here. Brian's answers are real, not laundered, and he responded not only to the 10 questions we sent him but also to some he felt deserved answers even though they weren't moderated all the way up. Please note that in much of this interview he is speaking as "Brian Richardson, individual," and that his opinions do not necessarily reflect those of AMI's management. With that said, be prepared to learn a lot about the BIOS business, and how TCPA and Palladium relate (and don't relate) to it.

Preface:

I thought it might be handy for the audience to know who's handling their questions ...

My name is Brian Richardson. I work for American Megatrends, Inc . (AMI). AMI is a privately held company located in Norcross, GA (just north of Atlanta). We employ approximately 400 people worldwide (about 200 in the United States).

I am a "BIOS Sales Engineer", responsible for handling technical issues related to selling and marketing the AMIBIOS8 , our latest BIOS code revision. This includes writing whitepapers, demonstrating products, answering technical sales questions, speaking at industry conferences and handling requests from the press that may require more than a passing knowledge of technology (like this one).

I started at AMI in 1996. I've been in this job for two years. Before that I wrote BIOS code for our notebook team and helped design our Software Quality Automated Testing (SQuAT) system. I also maintain several company intranets and our Bugzilla server, used for tracking bugs during BIOS development.

In spare time, I serve on the board of directors of Tech Corps Georgia. I also managed the Hardware section of linux.com (old articles are archived at linux.omnipotent.net).

This interview covers BIOS in general, but the questions have a heavy slant towards TCPA & Palladium. I'm sure I won't address everybody's TCPA related questions here. AMI has a "TCPA and AMIBIOS8" whitepaper at our website which discusses AMI's implementation. There are also links to other information on TCPA.

To answer some of the more unusual questions that didn't make it into the Top 10:

• You use XOR to clear a register instead of a simple MOV instruction because of the instruction size (XOR uses a two byte opcode, MOV uses three bytes). The savings in space really adds up after a while.

• We haven't finished 1394 boot yet, but we do have USB & USB 2.0 boot support

• I don't know, I've never met Satan ... but I have been to WinHEC

Now on to the questions ...

1) On the Exclusionary Uses of TCPA

by the-banker

Is it (will it be) possible to use TCPA to effectively lock-out certain operating evironments from various services (software, media, etc) solely because the operating environment is not backed by a company, and has no mechanism for paying certification fees and licenses? Specifically, could TCPA be used against free OS's like Free/Open/netBSD and Linux to prevent those users from accessing the same content users of commercial OS's can?

Let me start out by reminding the audience I am not a security expert. I have been reading specs like a madman the past week, expecting such a question from the /. audience. I'm also not a professional TCPAadvocate ... my understanding of TCPA is in relation to what AMIBIOS must do to enable the TPM(a hardware component required by the spec). I'm going to refer toTCPA specifications & FAQ a lot, so verifying my answers will be an exercise left to the reader.

Your question brings up a lot of common issues people seem have with TCPA:

1. What does TCPA do?

2. What does AMIBIOS have to do with TCPA?

3. What is the licensing structure?

4. Can open-source software make use of TCPA?

5. Does this have anything to do with Digital Rights Management (DRM)?

Let's see if Brian can hash his way through these items in some sort of order ...

a) What does TCPA do? TCPA is an industry specification that defines mechanisms for "trusted" client/server interaction ("trust" and "security" are two different things).

TCPA works in a very similar fashion as other key-based security mechanisms (SSH, PGP, SSL). Transmissions are secured by hashing against a key. Keys tend to be very long (128 bits or more), so it is difficult for "bad people" to guess your key. In many mechanisms, the key also serves to identify the user (proof that they are who they say they are). This key is often contained in a file or some sort of removable media, like a smart card.

TCPA adds a few elements to this security scheme:

1. More keys and longer keys (some keys are 160 bits, most are 2048 bits)

2. A crypto-processor to speed key computations

3. Secure key storage on the system mainboard

4. Establish platform "trust". The two excerpts below are taken from the TCPA FAQ:
   12. What do you mean by trust?
   The ability to feel confident that the software environment in a platform is operating as expected. This is done by reliably measuring and reliably reporting (using aliasing) information about the platform.
   
   Another such benefit is improved control of access to data. Previously such access has depended upon authorization or authentication. Now such access can also be linked to the state of the software in the platform. This enables the denial of access to data if rogue software, such as a virus, is introduced into a platform, because such introduction necessarily changes the software state of the platform.

The crypto-processor and key storage are provided by the Trusted Platform Module (TPM). A TCPA enabled system will have a TPM on the motherboard. This TPM can be disabled, as per TCPA specification, if the user wants to opt-out.

One concern is that TCPA is equivalent to a unique identifier on your computer, which causes a large number of privacy concerns. There's a large section of the FAQ (Item #13) that covers this topic:

The solutions support privacy principles in a number of ways:

1. The owner controls personalization.

2. The owner and user control the trust relationship.

3. Provides private object storage and digital signature capability.

4. Private personalization information is never exposed.

5. User keys are encrypted prior to transmission.

6. Supports multiple certificate authorities giving the user choice.

It is also important to know what the solutions are not:

1. They are not global identifiers.

2. They are not personalized before user interaction.

3. They are not fixed functions - it can be disabled permanently.

4. They are not controlled by others (only the owner controls).

b) What does AMIBIOS have to do with TCPA? The TPM requires initialization during BIOS POST. This allows what they refer to as "metrics" to be stored that help establish that the BIOS & OS can be trusted (i.e. haven't been h4x0r3d). Our "TCPA & AMIBIOS8" whitepaper has more information.

c) What is the licensing structure? There isn't one. From the TCPA FAQ:

10. What are the licensing and/or royalty arrangements for the technologies outlined by the TCPA specification?

The TCPA spec is currently set up as a "just-publish" IP model.

d) Can open-source software make use of TCPA? Yes. From the TPM FAQ:

18. Does the TCPA support open source systems?

Yes. The ability to use the TPM functionality is available to all developers of software. An open source project could determine to use TPM functionally today. The concepts of measurement, protected storage and attestation of measurements are fundamental concepts that hold true for any type of OS or application. The platforms that support TCPA today are not limited to only one OS and if open source developers provided applications that used the TPM functionality they would find support.

Remember ... SSH, GPG and SSL aren't any less secure because they're open-source. The whole point of key-based security is that you can't see the data without the key, even if you know the decryption mechanism.

e) TCPA & DRM? This question wasn't directly asked, but it's on everybody's mind ...

TCPA has been connected to proposed legislation that would require "content protection" on most digital media devices (including PCs).

While somebody could write a DRM application using the TPM, they could also write one without it. Non-DRM applications can be developed under TCPA. The example I thought of is an improved VPN for companies that are super-paranoid about their data (think about it ... 2048 bit keys, no hash load on the system CPU, ability to tie accessibility to a unique platform).

Adding TCPA & a TPM to a system doesn't automatically add DRM to a platform. Some application has to tie the TPM to the "media" being "protected". Merely adding TCPA to AMIBIOS doesn't constitute DRM:

Captain: What happen?
Mechanic: Somebody set up us the DRM.
Cats: How are you gentlemen !! All your BIOS are belong to us.

2) Advantage

by TedCheshireAcad

What is the advantage to me, a Linux using consumer, to buying your product over those of your competitors?

First, the short answer: a proven and stable product based on nearly two decades in the PC industry, with support for the latest technology.

Now, the long answer: Let me give a little background on how BIOS gets onto your average motherboard. I know that's not what you asked, but it will explain product design and benefits to the end user.

AMI markets AMIBIOS directly to the motherboard manufacturer, who we see as the actual "BIOS customer". So many of our features are oriented to motherboard manufacturers or BIOS developer. The end result of using our codebase is to produce a stable BIOS for the motherboard manufacturer's customer (that's you, the end user).

You can break these down three major areas:

1. Code structure (ease of development, tools, source management, etc.)

2. Technology support (OS, chipsets, processors, peripherals, etc.)

3. Support after the sale

a) The "BIOS core" is a different code component from silicon support code. The same applies to our technology support modules (ACPI,USB, TCPA, ASF, SMBIOS, APM, etc.). This allows board developers to pick just the code they need for their system. An embedded Linux board for an industrial controller has different BIOS requirements than the typical "white box" motherboard (OS compatibility, supported hardware, power management, etc.).

AMI also developed a custom GUI to make BIOS development easier (Visual eBIOS, or VeB). Believe it or not, most BIOS development happens at the DOS prompt in x86 assembly code. We found it harder to get new engineers comfortable with DOS-based development (DOS is 22 years old, so is the average college graduate). VeB also incorporates source control, so engineers manage the code from the same place they edit the code.

b) Technology support is pretty broad. We have to work on new chipsets, technologies and devices while keeping backwards compatibility for older hardware we'd rather forget about. This involves a lot of work with hardware vendors (Intel, AMD, ServerWorks, nVIDIA, etc.), software companies (Microsoft, RedHat, etc.) and technical specification groups (there's one for most every acronym out there). As you might imagine, there's a lot of testing to make sure all these things play well together.

Technology support also applies to features that don't have cool three letter acronyms. One example of this is "Fast POST" (POST is Power On Self Test, BIOS execution from power-on to OS bootloader). There was customer demand to boot the PC faster. This pressure came from Microsoft for a better overall user experience (yes, the obvious joke is "boot speed doesn't matter when you don't have to reboot so often" ... but I'm taking the high road). So now Fast POST is standard in AMIBIOS8.

c) "Service after the sale" sounds like something you hear in a men's clothing store, but it applies to BIOS as well. Customers expect bugs to be fixed, new features to be added, and a voice on the phone when they can't quite figure out which bit goes where. Some customers develop using our source code (as a licensee), while others use our engineers to create their BIOS (as contractors).

That might have been more of a sales pitch than you were expecting (sorry). There's more product information at the AMIBIOS website.

3) Performance hit

by oliverthered

I assume that data pathways will be signable or encrypted in some way. What performance hit will the [operating system] take when using trusted system? e.g. How much extra data is added to form a signature, what methods are used for signing. and how will this benefit the end-user?

A: I assume this is in reference to TCPA, so I'll use what I know of that spec to answer the question.

Everybody who's used SSH or SCP has experienced computation overhead from data encryption. That's the main reason TCPA has the Trusted Platform Module (TPM). Along with storing keys, it had a dedicated crypto-processor to handle random number generation, hashing and digital signatures. Due to the size of a security key, these hash computations add overhead (overhead == delay).

In TCPA, the hash/generation stuff is offloaded to the TPM. Since this dedicated processor does the work, the main system processor doesn't have to. The TPM is also a function specific processor, meaning it's optimized for security tasks (translation: faster than your general purpose x86 CPU). This is a good thing, since most of the TPM keys are 2048 bits.

If you look at Transmeta's recent security press release, you see the same functionality. Although this story was reported as Transmeta releasing DRM, they are actually providing an integrated crypto-processor in the TM5800. This function-specific processor is accessible through an extension to the x86 instruction set (similar to MMX or 3DNow!). The difference between this & the TPM is how you access the functions.

Sidenote: does any open-source developer want to check if these extensions could be used to improve SSH, SCP or GPG performance?

The signing methods and potential benefits are outlined in the TCPA specification and FAQ.

4) Why are BIOSes closed source?

by mcelrath

Having recently had a lot of trouble with my laptop's BIOS, on an issue that I could most certainly fix if I had access to the code... I started wondering what benefit AMI and other vendors have by keeping BIOS code secret? I can think of none whatsoever.

An open-source TCPA BIOS might go a long way to alleviating the fears of the open source community, since we could see exactly what it is you're forcing on us. And hey, no doubt you'd get a few bug-fixing patches in return for your efforts.

So, is an open-source BIOS a possibility? (TCPA or otherwise)

Just to get this out of the way:

1. AMI isn't forcing anybody to take any product offering, TCPA or otherwise.

2. TCPA doesn't block open-source (see #18 in the TPM FAQ @ trustedpc.org).

3. The TPM Memory Present (MP) driver BIOS uses during POST isn't open-source (it's provided by the TPM manufacturer).

This was the focus of a linux.com article several years back. There's plenty of advantages to open-source, but there are two main reasons for closed source BIOS: Legal Restrictions & Economics.

The creation of an open-source BIOS isn't limited by the BIOS itself, but by the information required to create the BIOS. Let me take a second and explain how the BIOS works at a programming level. This may seem like a tangent, but it helps explain issues faced by open-source BIOS developers (just think of it as Good Eats for BIOS).

There's three major components of any BIOS:

1. Core Routines

2. Silicon Support Routines

3. Board Specific Routines

The core can be equated to the kernel of an operating system, except that it comprises a larger percentage of the codebase (both in functionality and actual code size). This is everything that's generic from one BIOS to the next.

Silicon Support applies to the chips on the board initialized by the BIOS (processor, northbridge, southbridge, I/O, flash). BIOS core routines will call silicon routines when hardware configuration is required. These routines are created according to an API, so swapping any of these code modules doesn't affect the structure of the core.

Board Specific Routines represent the motherboard manufacturer's configuration. If you look at motherboards from two manufacturers that use the exact same silicon components, you might expect the BIOS from one board to work on the other ... but you'd be wrong. The small hardware changes that differentiate Board Vendor A from Board Vendor B have a large impact on the BIOS. PCI Interrupt routing, chipset General Purpose I/O pins and other parts of vendor's "secret sauce" go into this BIOS layer.

"Fine," you say, "but what does this have to do with open-source BIOS?"

I'm sure you've noticed that there's a BIOS ready for a chipset the day it is announced. AMI and other BIOS companies don't just come along the day of the silicon release and slap a BIOS together. We work hand-in-hand with the chipset vendor for months before the release. They send us an alpha board, we boot it ... they send us a beta board, we add more features ... they send us final silicon, we validate it.

Now remember that this hardware isn't public when AMI gets it. AMI has to sign a has to sign a Non-Disclosure Agreement (NDA) to get a development board or advance specifications, which means we can't tell anybody what we know about the product. Vendor-supplied reference code (memory detection, bridge configuration, etc.) is also covered under NDA. AMI also signs NDAs to cover the motherboard manufacturer's confidential information.

So the BIOS that ends up on those motherboards is constructed using information we can't release to any party not covered by NDA. You might be able to understand how this doesn't fit into to the open-source model.

So an open-source BIOS developer has a big dilemma ... they need access to information, but legally can't include it in open-source code. Many chipset vendors provide information after their chipset is released, but not many board vendors hand out schematics. Reverse engineering might reveal this information, but some items controlled by the BIOS can damage the system if not set properly (data corruption, overheating, smoke, flame, etc.) ... so random bit flipping may not be the answer. And nobody wants to get into the legal issues of using disassembled code in place of reverse engineering.

I think the closing statement from the linux.com LinuxBIOS article still applies ... "The real question isn't if an open source BIOS will ever work on a handful of platforms, but if it will ever become viable for mass market across many platforms."

There's another issue that comes into keeping AMIBIOS source code closed (or for that matter anycommercial source code). This has to do with economics.

This is where I change hats from "AMI company representative" to "average techno-Joe". The next few paragraphs are my feelings, not necessarily those of my employer or anybody else on the planet.

I personally like the idea of open-source, and I use a lot of open-source programs at home and work (Mozilla, OpenOffice, RedHat, Mandrake, ClarkConnect, PostNuke, perl, php, Bugzilla). But I also buy and use regular closed-source programs (my DV editing and VCD/DVD authoring tools). The choice isn't whether or not the source is accessible, but if the tool fits my needs.

In either case, those programs are the product of somebody's time (in most cases, a large group of bodies). They're a conglomeration of people's ideas, a manifestation of their talents, and monetary investment (open-source isn't free to develop, somebody bought that computer hardware). Those people, and whatever company funded their efforts, have the choice to distribute their product anyway they choose.

If a company wants to go open-source, then they can't make money selling source or seat licenses. RedHat doesn't make money selling code, they make money selling a code package and support for that package. My company doesn't operate that way ... in the realm of BIOS, money is made licensing source and selling per-board licenses. That's the way every BIOS vendor makes money.

That doesn't mean there's no open-source within AMI (perl/php/PostNuke/apache intranets, Bugzilla bug tracking, ucLinux on our MegaRAC G2 management card). But the choice to go open-source is done product by product, company by company.

In an industry driven by innovation, many companies feel they loose competitive advantage by opening their source ... if everybody has access to their ideas, then why buy their product over another? That mentality may not fit well with open-source, but these inexpensive computers we currently enjoy are the product of market forces. If there was no profit in computing, would Intel and AMD even exist?

Thus ends my personal views ... back to the actual interview ...

5) Technical Explanation of BIOS Settings

by doppleganger871

I have been doing research on BIOS settings for many years, and I have found good articles on what the settings do, and how to tweak them for the best performance/stability mix. But, I would like to know if the BIOS manufacturer itself would be able to provide an in-depth manual of all the BIOS settings, and what exactly they do. All the manuals that come with motherboards are very short on explanations, and I would like to see someone within the company actually explain to us hardware enthusiasts the down 'n dirty, nitty gritty, dirt under the rug, needle in a haystack type of information that we could use to make our computers run the absolute best they can. Because, as we all know, optimizing software and firmware is a lot cheaper than upgrading parts.

A: I wish I had a great answer for this. Despite my verbose nature, there's not enough room in this interview to discuss every setting that is or will be in the BIOS. Some of the basic settings are covered in BIOS setup manuals, and a few websites do a good job of explain the ugly details. The problem is that those "cryptic" options change for every chipset on the market.

We're always looking at product improvements, and that includes documentation. Our setup manual is a generic template, designed for the motherboard customer as a starting point for their manuals. The "chipset specific setup information" is part of a new documentation effort within AMI (we talked about in meetings this week).

Outside of that, optimizing settings for a specific combination of board, memory and processor is still trial and error (tweak, reboot, benchmark, swear ... tweak, reboot, benchmark, swear ...). I don't know if better documentation will change that.

6) "Trusted" computer

by michael

A few related questions:

a) Isn't the goal of "trusted computing" to allow entities other than the owner of the computer to control what the owner does with his/her hardware? For example, "trusted computing" applied to music implies that the music publisher gains control over what the computer owner can do with the music data files. Isn't this the exact opposite of "trust" as that word is normally used - a trusted computer is one that can't be trusted by the computer's owner to perform the tasks asked of it, because other entities have veto power over the computer's actions?

b) Companies like AMI have repeatedly claimed that they aren't part of Palladium. However, isn't it true that without AMI's trusted BIOS (and all the other components necessary to build a "trusted computer"), Palladium wouldn't work? Why does AMI think they shouldn't be held responsible for enabling Palladium and similar schemes?

c) In what way does AMI benefit, financially or otherwise, from introducing a BIOS designed to make the computer it is installed in less useful to the purchaser of the computer? Please avoid saying that this is "optional"; AMI wouldn't create this BIOS if it wasn't intended to be used.

A: Let's take these in order ...

a) The Goal Of Trusted Computing: Despite the fact my company is a TCPA member company, the concept of trusted computing wasn't created by AMI (we're not even a founding member).

As far as the goals of the specification, I'm not the designated defender of TCPA. I'll let theTCPA speak to their own goals. You seem to automatically equate "trust" to DRM, but that's not what I get from reading the specifications and related materials (see part (e) of my answer to the first question).

b) Palladium & AMIBIOS: You are correct in understanding that Palladium will require some amount of BIOS support. The reason we keep saying "we're not a part of Palladium" is because Palladium doesn't exist in the marketplace ... it's a Microsoft initiative being developed under guarded care in a small circle of developers. It's not a public specification like TCPA, so our role in this scheme is unknown. My understanding is that we'll get a specification from Microsoft whenever they're ready to involve the BIOS developers, but I don't know under what terms it will be made public (my Magic 8 Ball says "Ask Again Later").

c) Financial Benefit: Yes, there is a financial benefit to supporting a technology that our customers ask for ... they continue to be our customers. Not every customer has asked for TCPA yet, but enough large customers have asked to make it financially reasonable. Keep in mind that this is just one more feature we offer, which the customer may or may not want to take.

So when a customer (or customers) comes to AMI and says "Our next motherboard will support TCPA, and we need a BIOS module", AMI has two choices:

1. Say yes, develop the code, make the customer happy

2. Say no

If we select option #2 (for whatever reason), our customer has one of two responses:

1. "No problem, we licensed your code ... we'll add the support ourselves."

2. "Too bad, you have a competitor who offers this support ... it was nice doing business with you."

Option B is an obvious downer, because customers give us money. Money can be exchanged for goods and services, like food ... and I find food to be an important part of a nutritious breakfast.

Option A presents another series of problems. Yes, we kept the customer, but now we have a forked version of our code floating around. If only one customer wants this feature, then it's not a big deal. If twenty customers want this feature, then there's twenty code forks. They're still our customers, so they expect support ... and this is a support nightmare.

Our decision to develop a TCPA option was driven by sufficient demand for the technology. We're not the only company in the marketplace offering TCPA. Phoenix, our largest competitor, has been working on TCPA for quite sometime. IBM is already shipping notebooks with TPM hardware (which run Linux, according to LinuxCare Labs). If AMI customers don't ship TCPA, they we spent time developing a feature nobody wanted (it wouldn't be the first time, but that's happens in cutting edge development), but we have customer goodwill because we're responsive to their needs. It's the same in our eyes as developing support for a chipset ... if nobody likes the chipset, then they don't buy the code to support it.

What we have done by choosing TCPA over any number of proprietary security solutions is present an option that isn't closed to third parties. If we enable TCPA on a board and you want to make use of it, read the spec and develop accordingly.

7) Hardware vendors

by cybermace5

Since a BIOS is only part of a motherboard: what steps will hardware vendors have to take, in order to incorporate your BIOS? Will they have to adhere to certain hardware design rules or controls in order to maintain the TCPA? Is there going to be a licensing procedure for hardware manufacturers?

A: Hardware vendors don't have to do much for AMIBIOS to support TCPA. The TCPA code module gets included as an add-on. The hardware manufacturer has to obtain a TPM to place on the motherboard, but that's available from a third party vendor.

The TCPA specification doesn't mandate licensing (see point #10 in the TCPA FAQ). It's not an AMI specification, so it's not our job to check for compliance. Third-party labs will most likely perform platform certification based on TCPA specifications.

8) Windows override

by Forkenhoppen

I have a question; on previous occassions on VIA hardware I've owned, I've noticed that occasionally, Windows will enable a feature even though I have turned it off in the BIOS.

My question is this; if I have TCPA disabled in my BIOS, will Windows drivers abide by this? Or will they still be able to use aspects of the BIOS originally put in place for use by TCPA even though I have it shut off?

What plans are in place to keep a Windows driver from hijacking TCPA-related information for it's own purposes?

A: A lot of that depends on how the motherboard vendor implements the TPM disable option mandated by the TCPA specification.

The TCPA specification has many options for disabling the TPM. It can be a BIOS setup question, jumper or software driven. The first two would be really hard to override in software (unless there's a robotic hand attached to the USB port). The third option could present a software override, but you would have to reboot to have the TPM enabled at power-on to set proper "root of trust" (you can't just turn it on midstream, since a TCPA system is supposed to hash the BIOS & bootloader).

9) TCPA & Palladium

by ignipotentis

Perhaps you can clarify the differences between the two (TCPA & Palladium). After reading up on both of them, i still find that they seem to be pretty much the same, just marketed differently.

A: From the information that's been made public concerning Palladium, I can try to elaborate on this. As I understand it, the major differences are listed below:

• Curtain Memory

• Control of Specification

• Intellectual Property (IP) Rights

The last two points are pretty self explanatory. Palladium it not a public specification, there may be licensing issues. TCPA is a public document created and reviewed by a number of different companies, with no licensing demands.

The first point is technical in nature. Here's how the Microsoft's Palladium FAQ describes "curtain memory":

The ability to wall off and hide pages of main memory so that each "Palladium" application can be assured that it is not modified or observed by any other application or even the operating system

This type of mechanism doesn't exist in TCPA, and would probably require some sort of support at the chipset level (which means it couldn't be implemented using current northbridge hardware). The total system impact isn't known, and it's any body's guess what this does to application development.

10) What do you think about Linux BIOS?

by lanner

At first, I was going to ask you about how you have cooperated, if at all, with the Linux BIOS project. After all, you often have historically cooperated with Microsoft and Novell. What are you doing to help Linux?

But then it occurred to me, if Linux BIOS was successful, it would put AMI out of the BIOS software development business. Linux BIOS is a competitor of AMI.

What is your personal perspective about Linux BIOS, and what does AMI think about it?

A: There's a lot of overlap with question #4 here. But there are two points I'd like to touch on:

1. Cooperation with Microsoft, Novell & Linux

2. Perspective on LinuxBIOS

a) Saying that we "cooperate" with Microsoft and Novell is misleading. AMI creates AMIBIOS for maximum hardware and software compatibility. For years, Microsoft and Novell were the primary OS vendors used by our customers. Microsoft also drives many PC specifications, and the majority of our customers use Microsoft operating systems. Development and testing are focused based on customer demand.

In the past few years, that situation has changed. Novell isn't a major consideration for our customers, but we still test compatibility. Linux is demanded by more customers, and our testing efforts have been increased to match that demand. We test RedHat, SuSe, Mandrake, Xandros, Lindows and FreeBSD by default (along with various beta distros).

Microsoft is still key to our testing and development (we test everything back to Win98). Customers still need that "Designed for Windows" sticker. But Linux is a major focus in our testing and development ... not just because we develop for compatibility, but because our customers ask for it by name.

b) In some areas, people see LinuxBIOS as competition to the other BIOS vendors.

• As far as the source licensing (open vs. closed), see my answer to question #4.

• In features, LinuxBIOS does some things that our BIOS doesn't (mostly in the areas of cluster management) ... AMI has advantages over LinuxBIOS as well (boot from USB/USB2, JPEG graphics as boot logo, broader chipset support, ACPI/APM power management, etc.).

• LinuxBIOS was developed for a specific application, but has broadened ... AMIBIOS aims to offer broad support in many market segments.

• AMIBIOS has been tested against a larger number of system configurations, works with a larger variety of hardware, and has a longer product history.

I'm not sure how others at AMI feel about LinuxBIOS, but all I have to say is "go for it". There's some neat stuff coming out of that project, and it's interesting to see what they've accomplished. Competition in the market is what makes technology improve ... one notch better than the last thing, one step ahead of the next guy.

Thus ends the interview. Thanks to Slashdot for the opportunity, and thanks to the readers for wading through the text.

scubacuda writes "Arnold Kling, in his article, Content is Crap, writes, 'While there are many Net-heads who share Dan Gillmor's [and Larry Lessig's] enthusiasm for Creative Commons, I do not. It has little or no significance, because it is based on a strikingly naive 60's-retro ideological view of how content intermediaries function.' He compares artists' works to, well, raw sewage that publishers filter into something that can be later consumed by the public. 'What Creative Commons lets you do as an author is label your stuff before you flush it down the toilet.' Kling points to Bayesian Intermediaries (filters based on flexible keyword weights and 'trained' by user preferences) and weblogs as good ways to filter out the drivel that many content creators produce. (Dan Gilmore and Siva Vaidhayanatha respond, to which Kling responds in his blog."

TheSync writes "SearchWebServices.Com has an article claiming that Microsoft is working on a functional language named 'X#'. The language is supposed to be data-oriented and LISP-like, but set up to handle XML."