Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

AMI Guy Talks About TCPA, Palladium, and Other BIOS Issues

Roblimo posted more than 11 years ago | from the more-about-BIOS-than-you-may-have-thought-there-was-to-know dept.

Hardware 464

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.

cancel ×

464 comments

Sorry! There are no comments related to the filter you selected.

#6 (0, Insightful)

Anonymous Coward | more than 11 years ago | (#5102409)

Good to see michael modded himself into the question bin (see question #6)...

Re:#6 (2, Interesting)

Anonymous Coward | more than 11 years ago | (#5102525)

Notice the answers to #6 boil down to "RTFA you idiot".

"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."

And of course, he couldn't resist his usual snide idiotic comments.

"Please avoid saying that this is "optional"; AMI wouldn't create this BIOS if it wasn't intended to be used."

The answers were well thought out and complete, and the questions were all very well posed and designed to get some good details. Except #6 which was a whiney "I want free music" rant.

What a fucking embarassment that guy is.

We have staunch stance on PR whitewashes here? (0, Insightful)

inteller (599544) | more than 11 years ago | (#5102410)

Wow I would have never guessed! So I guess all that Anti-MS/Pro-Linux stuff isn't PR.

hahahaha (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5102421)

First Post!!!

They are scared...... (0, Troll)

sickboy_macosX (592550) | more than 11 years ago | (#5102446)

I think Microsoft is scared. they are running from the Linux/Open Source Communinity while trying to figure out how to live by the "if you cant beat em, join em" Business Plan. 20$ says Bill gates will see how bad the TCPA is, and scrap it, like he did with Microsoft Bob. Or at least I can hope... (Is this going to be the first on topic post??)

Re:They are scared...... (2, Insightful)

patch-rustem (641321) | more than 11 years ago | (#5102534)

Just because Microsoft are involved doesn't have to make something bad.

Thay may make it more interesting.

Re:They are scared...... (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5102719)

How sad. You are terribly naive.

Re:They are scared...... (1)

Planesdragon (210349) | more than 11 years ago | (#5102601)

I think Microsoft is scared. they are running from the Linux/Open Source Communinity while trying to figure out how to live by the "if you cant beat em, join em" Business Plan.

Did you even read this? Palladium is as much a step away from the "copy any bit you want" PC we have today as the original Macintosh was from "CLI and only CLI."

20$ says Bill gates will see how bad the TCPA is, and scrap it, like he did with Microsoft Bob. Or at least I can hope... (Is this going to be the first on topic post??)

You mean Palladium, right? I know you do...

(y'know, I have to wonder why no Linux security-freak has decided to take up TCPA for their own projects...)

Re:They are scared...... (1)

blazerw11 (68928) | more than 11 years ago | (#5102748)

I have to wonder why no Linux security-freak has decided to take up TCPA for their own projects.

They didn't need to. Linux doesn't need hardware help to be secure. A properly configured Windows box (newer versions) doesn't need it either.

Re:They are scared...... (1)

siskbc (598067) | more than 11 years ago | (#5102624)

I think Microsoft is scared. they are running from the Linux/Open Source Communinity while trying to figure out how to live by the "if you cant beat em, join em" Business Plan. 20$ says Bill gates will see how bad the TCPA is, and scrap it, like he did with Microsoft Bob.

1. TCPA is hardware and, as far as I can tell, an open spec. Bill can't "scrap" it. In fact, Bill isn't the major push for it - that would be the **AA, if you believe the conspiracy theories (I do). Not to say RTFA, but... And anyway, I have no idea what TCPA and Microsoft's stance on it has to do with Microsoft's fear of OpenSource.

Microsoft Bob...HAHAHAHA! Now THAT was funny. I would love to know who greenlighted that one - probably heading Microsoft Iceland right about now.

Re:They are scared...... (0)

Anonymous Coward | more than 11 years ago | (#5102775)

# Microsoft Bob...HAHAHAHA! Now THAT was funny. I would love to know who greenlighted that one


Bob was the pet project of the woman who became Bill Gates's wife. Not exactly Iceland...

Really? (0)

Anonymous Coward | more than 11 years ago | (#5102805)

Damn....at least that explains it, tho. Although I could contend that being married to Bill is, in effect, Microsoft Ice-land. I mean, he is a friggin' robot.

Re:They are scared...... (1)

Pxtl (151020) | more than 11 years ago | (#5102641)

RTFA. To me, it sounds like most of TCPA is allowing hardware-speed hashing which can be applied to your software to insure that they (or your data streams) aren't modified undesirably. Yes, that could be used for nasty DRM. But Microsoft would like that. So they will. Its just up to us independants to make sure there are ways to work with this to ensure that you have the power to control your PC (while leaving enough of the TCPA structure in place to allow its security features to still be useful).

Hmm (2, Funny)

jon787 (512497) | more than 11 years ago | (#5102447)

I don't think posting the entire article here is gonna stop people from posting beforing reading, nice try though.

Not at all a first post. (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5102450)

I hadn't noticed that there weren't any posts until I'd read the thing.

FUCKERS.

Alright! (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5102473)

Fourth Post!

XOR as clear (4, Interesting)

balister (225746) | more than 11 years ago | (#5102484)

I loved the XOR answer. I learned that trick when I was writing 8085 assembly as a coop in the very early 80's. I'm surprised it is regarded as unusual, by now I would have thought every good programmer would have discovered or seen this trick.

Thanks for the memories. Somewhere around here I have an IBM PC technical reference with the assmebly listing for the BIOS.

Philip

Yep (1)

Kourino (206616) | more than 11 years ago | (#5102617)

I don't have a listing of any of my (or anyone else's) BIOS sitting around anywhere, but I learned the xor trick back when I was learning graphics programming via x86 assembly. It got mentioned a few times if you read the right docs. (It was stuff geared towards demo writers, but I never got that good, nor that aware of the demo scene ... such a dork I was. ^^; ) I also want to say the professor of my machine architectures class in uni mentioned it. Don't remember. But yes, it seems pretty widely known among people who "wanted to program games" between, oh, the mid eighties and nineties.

Re:XOR as clear (1)

LordNimon (85072) | more than 11 years ago | (#5102646)

Instead of XOR, a lot of people use SUB.

Re:XOR as clear (0)

Anonymous Coward | more than 11 years ago | (#5102673)

It really depends on what the goal of the code is.

Size: XOR (2 bytes)*
Speed: SUB (one of the fastest pipelines in most modern x86 CPUs)
Clarity: MOV (very straight forward that you want to put 0 in a register)

*assuming native mode, otherwise 3 bytes (1 for size override prefix if needed)

Re:XOR as clear (2, Informative)

entrager (567758) | more than 11 years ago | (#5102704)

I learned this trick from the professor that taught me assembly. However, I think his reasoning for the use of the XOR trick is much better than "it takes less space." How about "it's much faster". By XORing a register with itself you don't need to pull anything from memory over the slow bus. A MOV instruction costs you precious bus cycles.

Re:XOR as clear (1)

mattdm (1931) | more than 11 years ago | (#5102762)

Your priorities are probably different from those of someone writing a BIOS, which has to live on a relatively small chip.

Re:XOR as clear (1)

chrisseaton (573490) | more than 11 years ago | (#5102715)

Agreed. I never thought it was any kind of trick. Simply the way to clear a register.

He did not awnser this (2, Interesting)

nervlord1 (529523) | more than 11 years ago | (#5102495)

2) Advantage

by TedCheshireAcad

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

His awnser was basically non existant, i belive the poster of this question was asking, what advantage does TCPA present for me, a linux user, in which case the awnser is a big fat nothing, and waht benifit for windows users? once again, nothing

Re:He did not awnser this (5, Informative)

grub (11606) | more than 11 years ago | (#5102540)


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

Actually he (sort of) answered your question. We, as end users, are not their actual customers. Their customers are the motherboard manufacturers, we don't buy a motherboard and then pick a BIOS. 'AMI markets AMIBIOS directly to the motherboard manufacturer, who we see as the actual "BIOS customer"'

Further down he does mention testing with various Linux distros and FreeBSD.

Re:He did not awnser this (5, Insightful)

stratjakt (596332) | more than 11 years ago | (#5102547)

It was a stupid question. You are not an AMI customer.

Their customers are motherboard vendors, not end users. Ask the mobo manufacturers or the dells and compaqs. They provided support for TPM because their customers asked for it. It's up to the mobo vendors to decide how to use it, if at all.

Re:He did not awnser this (1)

siphoncolder (533004) | more than 11 years ago | (#5102728)

I wish I had mod point to mod you up. Maybe another time ;)

I'll take a stab at answering this whole ball of yarn: It occurs to me that TPM is more like an API, not a different design of computer. It's an add-on, much like .NET is an API sort of add-on to windows. Applications have to specifically say "I want to use TPM" in order to access any trusted-computing functionality.

In that case, a mobo with TPM will not affect anything that currently exists.

However, what must be watched for is: hardware that requires TPM (i.e. your CD burner). Software that requires TPM (for whatever reason). I believe that in the end, the goal is that while piracy may still be possible for you & me, media vendors can use TCPA-enabled applications to serve media to TCPA-enabled computers, and deny it to non-TCPA enabled systems.

Another concern: some years from now, when all hardware that deals with media is TCPA-enabled, how exactly will you (for example) rip your songs off a CD/DVD and share it over the internet?

Another concern: how can this be used to usurp your rights in the future?

The issue is not "how this will affect Linux & pirateers", but: can this be used as a sort of "Hardware-EULA" that's forced on you?

You may want to practice living without buying CD's, DVD's, and not downloading any of that media for a while to get the full effect of what TCPA is going to do to you.

Re:He did not awnser this (2, Informative)

Kourino (206616) | more than 11 years ago | (#5102631)

Then they should have asked that. They asked "why should I buy Ami", and they got an Ami marketing pitch, more or less. Is this unusual?

Re:He did not awnser this (2, Insightful)

ehiris (214677) | more than 11 years ago | (#5102644)

Encrypting data prior to writing it to the hard drive in order to avoid putting yourself at risk of disclosing private data [slashdot.org] would be an excellent benefit.

Re:He did not awnser this (1)

briancnorton (586947) | more than 11 years ago | (#5102765)

improved VPN for companies that are super-paranoid about their data dedicated crypto-processor Secure key storage on the system mainboard Besides, when was the last time you were a customer of AMI? Chances are, NEVER. They sell to motherboard manufacturers.

Yes he did (0)

Anonymous Coward | more than 11 years ago | (#5102780)

He basically said that their project

a) Is well engineered
b) Supports lots of configurations
c) Is Well maintained

Re-read the answer. Also, read the answer to #10 for more reasons.

I think he did... (2, Informative)

fireboy1919 (257783) | more than 11 years ago | (#5102796)

I can't be absolutely certain what you're claiming he didn't answer because you used commas instead of periods in your last sentence, and none of the other necessary punctuation marks. Sometimes you need to use actual grammer rules to get your point across. He did explain what the benefit of the technology is.

It can be used to uniquely identify a particular computer with a low amount of computation. It's a glorified MAC address system, but with an encryption system based upon this as well.

I don't even see how this is even bad by itself. Is MAC bad? In addition, the only way it's going to be permanently encrypting data is if you put software on it that does that.

If that's what you want - data that is restricted to one machine - then just make an encryption scheme that combines serial numbers of all of the components in a machine to make a hash and use that. Is TCPA a technology that enables unique identification? Yeah, but so is a friggin' turing machine.

I won't accept a system that keeps my data from being portable. I won't use any XP product because when they're no longer supported, you won't be able to register them, and then even having the software won't mean you can use it. I won't use any DRM software that limits my rights to my files or is not portable among operating systems.

But if I can get a coprocessor that does encryption for free when I buy my board, and I don't have to be quite so paranoid in figuring out who is who because they have one too, I'm all for it. Maybe this'll help knock out the screwed up digital certificate market.

ALL YOUR BIOS ARE BELONG TO US! (1, Funny)

Anonymous Coward | more than 11 years ago | (#5102516)

Captain: What happen?

Mechanic: Somebody set up us the DRM.

Cats: How are you gentlemen !! All your BIOS are belong to us.

Very informative interview (-1)

Anonymous Coward | more than 11 years ago | (#5102524)

Kudos! Much better than William Shatner's interview.

Come visit our website or we will kill this monkey [pajonet.com] !

info (1)

LordCheese (642391) | more than 11 years ago | (#5102541)

Best info I have seen on the /. in a while

The power of Slashdot (1)

rxed (634882) | more than 11 years ago | (#5102550)

Maybe one day we'll be able to ask Bill Gates a question or two trough the Slashdot.

*Applause* (0, Redundant)

CableModemSniper (556285) | more than 11 years ago | (#5102561)

Now that, was a good interview.

Michael has no shame. (0, Troll)

MondoMor (262881) | more than 11 years ago | (#5102568)

He mods his own crackpot conspiracy theory question into the top 10, then gets schooled by someone much smarter than him.

Also, Roblimo said:
we have low tolerance for PR whitewashes around here

What the fuck is that? So all of the editor's smart-assed snide comments added to user-submitted stories (and the accepted stories themselves, which are often titled misleadingly and contain an obvious bias) are just my imagination?

Slashdot commits as much whitewashing and FUD spreading as any other organization. Lunix and open source are ALWAYS good, Microsoft is ALWAYS bad.

Goddamn hypocrites. Especially you, Michael "I HATE CENSORSHIP UNLESS I NEED TO BITCHSLAP A DISSENTING OPINION".

Watch. I had a comment posted the other day that was +5 Funny (despite getting modded by editors as "overrated" and "Troll"). How much you want to bet michael will magically make that post -1 real soon?

The users modded that up, dipshit. You don't have the right to override it ("bitchslapping") just because you don't like me.

Learn to live with your dissenters, Slashdot editors. We're actually trying to help, but you're too fucking hypocritical and insecure to see it.

Re:Michael has no shame. (-1, Offtopic)

mstyne (133363) | more than 11 years ago | (#5102707)

mod parent through the roof.

Not quite true (-1, Troll)

NigelJohnstone (242811) | more than 11 years ago | (#5102569)

"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"

The answer to this is yes, if you can't pay the fees, you don't get the certificate, so you're not trusted. However he waffled on with the "bore them to death with irrelevent crap" answer:

"Let me start out by reminding the audience I am not a security expert...."

"While somebody could write a DRM application using the TPM, they could also write one without it. "

If they wrote it without TPM then it would be hacked, so TPM is pretty much a pre-requisite.
So what he said is true, but yet not true.

"18. Does the TCPA support open source systems?
Yes. The ability to use the TPM functionality is available to all developers of software"

Sure, if you remove anything the thought police object to.

**************
What did you expect, you asked a PR man questions and you get back deflections, half truths, political waffle.

About the only thing he said that rung true was this:

"c) Financial Benefit: Yes, there is a financial benefit to supporting a technology that our customers ask for ... they continue to be our customers. "

Re:Not quite true (3, Interesting)

homer_ca (144738) | more than 11 years ago | (#5102708)

"The answer to this is yes, if you can't pay the fees, you don't get the certificate, so you're not trusted."

He clearly states that the user has a choice of Certificate Authorities. That means users should be able to self sign certificates just like with OpenSSL, and Redhat or FSF could issue their own certificates if they wanted to use TCPA features. Your RIAA-approved media player won't run if you booted with a self-signed TCPA certificate, but that just means you can't play RIAA-approved content you downloaded from a future Pressplay-type online service. That's not any different from today where there's virtually no RIAA content legally downloadable on the Internet.

Re:Not quite true (1)

gorilla (36491) | more than 11 years ago | (#5102797)

If they wrote it without TPM then it would be hacked, so TPM is pretty much a pre-requisite.

The opposite is also true, if they wrote it with TPM then it can still be hacked. If the object files for the DRM program are distributed on any non-trusted medium, for example the internet or CD-ROM, then they can be read on a non-TPM system, and attacked. It expect it won't be easy, I'd start with a TPM protected decyrption program, but non-easy and impossible are two different situations.

Whatever (0)

Anonymous Coward | more than 11 years ago | (#5102828)

Read it again -- no waffling here:

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.

You can clear a register with MOV?? (3, Funny)

kahei (466208) | more than 11 years ago | (#5102574)


Seriously, this article was the first time it ever occurred to me that MOV might be a more obvious way to clear a register.

Now I'm afraid that there are legions of people out there zeroing registers with MOV and I'm left out.

NO?!?! (0, Flamebait)

crown_whore (640078) | more than 11 years ago | (#5102589)

Once again, NO!!!

Give us an alternative or not, the choice is yours.
I will not buy TCPA enablied products, I don't care if I can turn it off or not
I will seek to return any TCPA product not labelled and I will discourage anybody from buying TCPA enabled products
I don't care if I'm running a 486 to do so
Anything within reason to discourage it's use

The failure is on your behalf; for not checking with your customers first and the undertaken should be written off at your expense.

I don't trust large corporations other than cash and sometimes a credit card, and that mistrust is not misplaced.

Re:NO?!?! (1)

rtkluttz (244325) | more than 11 years ago | (#5102766)

Exactly.
Even though he didn't answer my question that I posted when they were being gathered, he answered it indirectly.
The fact that it even COULD be included in a DRM solution actually means that it WILL be included in a DRM solution. I'm tired of having my fair use rights trampled on.
I don't care if 2 billion people are stealing content and only 1 who isn't, that doesn't give them the right to lock out every tool that could possibly be used to bypass their DRM technology, or to lock down every piece of media because they havn't approved how you plan to use it.

Here is a hypothetical... my company uses Microsoft products. We have an in house programmer. If (When) Microsoft starts tying their code to the Bioses and you have the choice of running the PC in entirely trusted or entirely untrusted modes, our workstations in the organization start having to be two workstations. Once to run nothing but trusted applications, and another to run our uncertified code created by our in house programmer where we used to have one PC.
And OMG what if they tie it to network access also, will the PC eventually have to be completely standalone to run untrusted code?
We have a few Linux machines here... time to start increasing their numbers and get the users used to using them.

.

Access to ideas (1, Insightful)

ryants (310088) | more than 11 years ago | (#5102595)

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?
This argument doesn't hold much water with me.

I have access to all of Stephen King's ideas, since he publishes them in an easy-to-read and often easy-to-carry format, and yet when it comes to book writing he has a considerable advantage over me.

Re:Access to ideas (0, Troll)

jmu1 (183541) | more than 11 years ago | (#5102640)

That is a great analogy.

It took me three years and a whole lot of jaw-wagging to convince several of my peers of that very idea.

Re:Access to ideas (3, Insightful)

stratjakt (596332) | more than 11 years ago | (#5102682)

No, it's a bad analogy.

Software doesn't compare to literature, it compares better to trade secrets.

Why should Colonel Sanders tell you what his 'secret blend of herbs and spices' are, or Budweiser give up all their brewing formulas and production techniques so their competitors can duplicate their products and eliminate whatever advantage they feel they have.

Re:Access to ideas (1)

Abcd1234 (188840) | more than 11 years ago | (#5102694)

Oooh, bad example... why would *anyone* want to duplicate Budweiser? *shudder* ;)

Re:Access to ideas (1)

jmu1 (183541) | more than 11 years ago | (#5102739)

This is a bios. It's not Nvidia's bleed'n proprietary methods of rendering the steam from a great big pile of shit.

These are pretty standard things that all computers do and use. It's a lot like that little kernel thingy.

Re:Access to ideas (1)

ryants (310088) | more than 11 years ago | (#5102813)

I have a recipe for ravioli passed down to me through the generations from my nonna (grandmother in Italian), and yet mine suck ass and hers I would kill for.

Better?

never met satan (5, Funny)

BigGar' (411008) | more than 11 years ago | (#5102598)

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

Man that's like having diner at the Whitehouse and not meeting the president.

Position Change (5, Funny)

Evilderek (641411) | more than 11 years ago | (#5102603)

So, since you left your first job you can now really say that you don't do SQuAT?

Does anyone else... (0, Troll)

jmu1 (183541) | more than 11 years ago | (#5102605)

feel dirty after reading that?

I don't mean porno dirty, but more like greasy used car salesman dirty.

It just seemed to me he was spending most of his time jusifying his existence, his 'geekishness'. We asked for answers and what we got was feelgood hyperbole. This bodes ill for the computing community.

Linux on the latest motherboards (1)

Standfast (36916) | more than 11 years ago | (#5102611)

Brian says:

We test RedHat, SuSe, Mandrake, Xandros, Lindows and FreeBSD by default (along with various beta distros).

This is great. It would be even better if there was a tighter relationship between motherboard, chipset and BIOS manufacturers on the one hand, and the Linux kernel community on the other hand.

For one thing, if instead of "beta distros" AMI would invest time working with the latest even and odd-revision kernels, both the kernels and the BIOSes would benefit.

In fact, I would not be surprised if this was already happening. I am just responding to what Brian said, and to the consistently higher level of problems I see reported on the kernel mailing list having to do with newer motherboards.

-David.

Interview (0)

Anonymous Coward | more than 11 years ago | (#5102613)

Wow! Thanks, Brian, for taking the time and effort to go well beyond most interviews here. I now feel I have a much better picture of the whole BIOS and TCPA scenario. And you make a lot of reasonable points.

This was great,

Lnuss

Good info! (4, Interesting)

Ageless (10680) | more than 11 years ago | (#5102615)

That was a great interview and some very good info in there. One thing I was particularly interested in was the mention that the onboard chip is responsible for generating random numbers. Is this the answer to the dream of every computer having a hardware RNG that generates true randomness? I for one would be thrilled to see a general purpose crypto processor in every computer.

"customers want it" (0)

Anonymous Coward | more than 11 years ago | (#5102626)

he keeps on insisting and he repeats several times through the "interview" customers want it. I don't know which customers he means. The OEM? The indivigual lusers who go into CompUSA and buy an HP with XP preinstalled? I built my own system a year ago by buying the indivigual components and putting them together. I certanly don't care to have a TCPA enabled BIOS. I am a customer too.

Overall, an OK interview. Yeah,sure Linux will work on any BIOS if its ceertified forit. That means a kernel that got re-compiled or changed won't work. That means if I d/l the brand new SuSE iso ver 8.5.3 and try to install it it won't work either.
This all means one thing:
Welcome to the end of computing as we know it.

We might have to start buyng China made boards in coupl a years.

Re:"customers want it" (3, Informative)

nuggz (69912) | more than 11 years ago | (#5102686)

He CLEARLY states the customer is the Motherboard designer.
They buy their product. Of course making sure their product works well for the end user is important. If their BIOS doesn't satisfy the system builders, or end users, the motherboard manufacturer wont' be happy either.

Re:"customers want it" (1)

revery (456516) | more than 11 years ago | (#5102726)

he keeps on insisting and he repeats several times through the "interview" customers want it. I don't know which customers he means. The OEM? The indivigual lusers who go into CompUSA and buy an HP with XP preinstalled? I built my own system a year ago by buying the indivigual components and putting them together. I certanly don't care to have a TCPA enabled BIOS. I am a customer too.

His customers are motherboard manufacturers, not end users.

hardware specs for open source (0)

Anonymous Coward | more than 11 years ago | (#5102628)

I asked Theo de Raadt of the OpenBSD project [openbsd.org] about this. In the interview answers, Mr Richardson of AMI asks "does any open-source developer want to check if these extensions could be used to improve SSH, SCP or GPG performance?" Given OpenBSD [openbsd.org] 's integrated crypto [openbsd.org] and more specifically crypto hardware [openbsd.org] support, I put the question to Theo. Within about a minute he responded. It was short, sweet and to the point. Will Mr. Richardson help follow through on this and get the OpenBSD project leading the way on using AMI's latest security developments at the OS level? From: Theo de Raadt Date: Fri Jan 17, 2003 12:12:47 PM America/New_York To: Anonymous Coward Subject: Re: /. interview regarding new security hardware on x86 If we had hardware docs.

Re:hardware specs for open source (2, Informative)

SalesEngineer (640818) | more than 11 years ago | (#5102695)

The OpenBSD project should be able to get TPM and Transmeta security extension specifications on their own. Do they need a contct name?

And just as a reminder ... it's not AMI's security developments, it AMI's support of an industry specification.

Wow, great answers (1, Insightful)

rosewood (99925) | more than 11 years ago | (#5102632)

I dont want to say I feel better about TCPA now but I know better now where to focus the fear. It seems that what needs to happen is the open source community needs to quickly jump on TCPA and make it worthwhile for doing REALLY cool things, long before someone else turns it into something that makes me unplug.

Re:Wow, great answers (0)

Anonymous Coward | more than 11 years ago | (#5102753)

Insightful my ass. This is a bit like saying "whoa, cool, let's make out own .NET implementation", with all the associated dangers.

TCPA is not a tool we can control, it is a tool for controlling US. The only way to deal with it is to get rid of it.

Standards (1)

Amsterdam Vallon (639622) | more than 11 years ago | (#5102642)

Brian,

As evident by the development of current Internet technologies such as TCP and IP by the Department of Defense-backed Advanced Research Projects Association (ARPA), we can only achieve a standard if one company or organization is behind both the medium and the protocol.

Do you feel that the Intel-backed TCPA and the Microsoft-owned Palladium technologies both have better chances of succeeding since they're one-man operations? If not, what alternatives do you suggest?

Re:Standards (2, Funny)

SalesEngineer (640818) | more than 11 years ago | (#5102743)

Well, there's over 150 companies behind TCPA (I don't know why you can't view the membership list from their website). They span all aspects of the computer industry, and publish their specifications. I don't know how that can be improved to be more open.

Performance hit (4, Insightful)

oliverthered (187439) | more than 11 years ago | (#5102650)

hmm... Well he didn't answer the question, more avioded it.
Any extra header data will have to travel around the system bus reducing bandwith.

Any processing overhead will introduce latency, not a nice thing to have kicking around.

So it may not affect the CPU in terms of processing overhead but there's an overall systems performance hit.

Re:Performance hit (1)

oliverthered (187439) | more than 11 years ago | (#5102662)

One extra thought, encrypted data is less compressible. Big performance hit if your encapsulating encrypted data.

Use TPM for other things? (5, Interesting)

Milo Fungus (232863) | more than 11 years ago | (#5102667)

A follow-up question: Is it possible to use the TPM for things other than security and TCPA-related calculations? If you boot in non-TCPA mode, is it possible to use the processor instead of just letting it sit there on the board doing nothing? I'm not a hardware guy, just a curious quasi-geek.

Re:Use TPM for other things? (1)

juuri (7678) | more than 11 years ago | (#5102732)

Good question.

This would be awesome if the encryption chip was available to the OS, this would be an awesome boon for SSL performance. Maybe this is an angle manufactors can push to get people to upgrade? "BUILT IN ENCRYPTION SPEED!!!"

Re:Use TPM for other things? (2, Informative)

Anonymous Coward | more than 11 years ago | (#5102779)

While he didn't really answer that, he did somewhat address it.
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.

Anyone else notice #6? (1, Interesting)

FortKnox (169099) | more than 11 years ago | (#5102676)

I really wonder if question #6 (posted by the editor michael) got modded up under normal moderations, not unlimited moderation points of the editors (or, if it got a last second mod-down if it was 'pushed back up' by the editor).

But, OTOH, its nice to see an editor get a "RTFM" response:
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.

Not Quite... (4, Insightful)

waltc (546961) | more than 11 years ago | (#5102679)

I think it is a bit silly to say, "Someone would have to write software to tie our bios initiatives to DRM," as if such a probability is extremely remote.

I think the correct answer might have been:

"If we weren't including and supporting these bios initiatives, there'd be nothing in our bios anyone could tie to a DRM software inititiative."

The problem here is that even though it can be disabled by the end user, and can't be software-enabled through the OS on the fly, the mere inclusion of it as a standard feature in a bios will encourage the DRM software author to say: "If you don't enable your bios control, you won't get any standard functionality out of our software." The mere fact that it is in the bios will be enough to spur software development in that direction.

The bright side to this is that it's all still years into the future--there are hundreds of millions of machines in use world wide which don't have any such bios capabilities and which aren't going to be discarded any time soon. And of course current machines being sold right now do not have it.

The question is will there be a market for this sort of thing? If implementers could guarantee me that using it means I can safely shut out Microsoft or any other company from doing *anything* (via the Internet) in my system without my express advance permission [and I don't mean EULA licensing--I mean per-occurrence notification as it happens]--well, even I might be interested at that point.

But the DRM initiative by private companies and the "privacy issue" for me seem entirely at cross purposes, and frankly I'm getting a little tired of hearing that these initiatives are promising that they can allow companies to inspect my system and control my software in the name of DRM, but at the same time will use the same technology to guarantee my privacy. I can't see how the two mix.

Re:Not Quite... (2, Insightful)

stratjakt (596332) | more than 11 years ago | (#5102735)

What I read was that DRM can exist with or without TCPA. Just like SSL exists with or without TCPA.

TCPA adds a dedicated crypto processor and a secure boot process, but there's nothing to prevent crypto for DRM being done on your system right now.

His answers were as honest and truthful as they could be. If someone wanted to create a DRM enabled app that only runs on a specific OS under Palladium, they could do so. If someone wanted to creat a DRM enabled app that only runs on a specific version of non-palladium Windows - they could do so too.

It's like asking "How does liscensing drivers prevent shoplifting?". The two are unrelated. It's a non sequiter.

It's worth noting that DRM has thus far proven to be an unpopular 'feature', and MSFT decided not to include it on Windows MCE. Of course news of MS making a 'good' decision isn't worth of a /. article.

Follow-Up Question: Use TPM for Other Things? (1)

Milo Fungus (232863) | more than 11 years ago | (#5102696)

If booted in non-TCPA mode, is it possible to use the TPM for other calculations? He mentioned the possibility of using it for SSH and other things. What about decoding audio/video formats?

Answer to what "trusted" means (2, Insightful)

KjetilK (186133) | more than 11 years ago | (#5102699)

Parts of the interview was very nice indeed, and it would certainly be cool to see what a dedicated processor for crypto can do for us.

Yet, I do not feel very confident, after reading how he tries to avoid question concerning the newspeak on what "trust" is supposed to mean. OK, so any technology can be used for good and bad, that is clear.

It is my firm belief that technologists have a great responsibility for the things that they make, because no one is better suited to understand the consequences of the tech that they develop than the techie himself.

So, just referring to TCPA and what they say, what their goals are, and so on, it doesn't cut it. Brian has a moral duty to try to understand what motives drive the stuff that he is doing, and if he thinks that these motives are bad, he has a moral duty to speak up about it.

I really haven't seen anything non-fuzzy from TCPA about what their real motives are, but one thing I know: If the real goal is to take away the control of the technology each individual uses away from the individiual, it will be the most drastic step towards an authoritarian society.

Few are better suited than Brian to examine these issues, and with that comes a huge responsibility to make sure that the technology he is developing does not move society in that direction.

After reading this interview, I do not feel confident that Brian takes this responsibility seriously enough.

Whether you agree with him or not... (3, Interesting)

gosand (234100) | more than 11 years ago | (#5102702)

Even if people complain about the content of his answers, at least he didn't "Shatner" the questions. Granted, they were two totally different types of interviews, but he answered the questions, expanded on them, gave opinion and fact, and even a little humor thrown in. Even though I am not much more comfortable with the whole idea, I liked the interview.

I've got to admit... (3, Insightful)

j3110 (193209) | more than 11 years ago | (#5102705)

I'm excited to see the end product. Cryptographic processors on all motherboards sounds to me like a great idea. I wonder how hard it will/would be to change the keys though... I hope they aren't hard-wired. Palladium is just another reason to not run windows, but TCPA could theoretically be disabled, and you can run Linux.

The only way this will improve DRM is by allowing stronger encryption of data. 2048 bit encryption will be tough to break, and with these chips in DVD players, strong encryption will be possible even for small devices. The media companies will always have the problem of "It has to get in my brain somehow, and if it does, I could store what I see with good enough technology." Because your brain doesn't have DRM, they can never really lock out illegal copying. It has to be in a human understandable format at some point in order for it to have value. The more they fight the inevitable, the sooner an illegal trust/monopoly will be out of business. Art will continue. It probably won't pay the ludicrous amounts that it does now, but it will survive as it always has.

BIOS security irrelevant (1)

master_p (608214) | more than 11 years ago | (#5102713)

Is PC BIOS security relevant to any modern OS ? Linux does not use the BIOS routines. And I don't see how a protected piece of data (video, audio, software) can't be reproduced by open source code.

Anything that is software can be hacked: just do a hardware debugging step-by-step execution and disable the relevant security calls. It is even easier today with all the virtual PC environments available. Of course, it would be a legal problem, but it is no different than today's piracy.

I believe that in the future, PC manufacturers will deny pre-installing any free O/S in a PC due to legal problems, and thus preventing the spreading of free operating systems.

Keys aren't Open (1)

echo (735) | more than 11 years ago | (#5102716)

While the TCPA stuff maybe be an "Open Standard", the crypto keys hidden in a chip on the motherboard are NOT open. That's what takes your control away.
SSL might be an open standard, but I can still encrypt something so YOU can't see it.

Isn't it possible that Computer Manufacturers could use this so these machines would only boot Windows? Maybe AMI is saying "You can disable it", but what will a Dell machine do? Will they sell a "Developer" version of thier machines that allow you to turn it off, but cost twice as much as the standard machines? This gives them the power to do such a thing....

Imagine, RedHat could even pay to get their kernels signed so they boot on such a machine, but the regular user wouldn't be able to recompile a custom kernel and use it!

If the keys on the motherboard get out though, then it's all over... anyone could use them to sign code.

I can imagine as soon as these show up, hardware and software hackers will work to extract the keys.... Maybe that's the only thing we can hope for to save us from losing control of our own computers....

We asked the wrong person (5, Interesting)

carambola5 (456983) | more than 11 years ago | (#5102717)

With regards to all the financially related questions on Palladium/TCPA, I believe we asked the wrong person.... not that we could help it, though.

In reference to Answer 6c, the people we need to be pressuring is the motherboard manufacturers (Asus, Shuttle, etc) and the final vendors (Dell, Compaq, etc). Writing in TCPA support to their product is a purely business move on AMI's part. They have no room for ethics here. It's sink or swim.

If we, however, convince the mobo and vendor people to not use this "technology," AMI will never be pressured into making a TCPA-compliant product.

So, I ask the Slashdot editors: Can we get a rep for Abit, Gigabyte, Gateway, or somewhere to do an interview? I think our Palladium-fluent readers will have much more success in crafting questions for these people.

Not to say this was a waste, though. It's good to see a fresh perspective: the man caught in the middle.

Bingo! (Re:We asked the wrong person) (1)

SalesEngineer (640818) | more than 11 years ago | (#5102834)

I think that's the best description of the situation I've seen yet. This guy has the right idea on how to handle TCPA from a consumer standpoint.

Brian Richardson (AMI)

IBM and the Holocaust (1, Insightful)

Anonymous Coward | more than 11 years ago | (#5102731)

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.
Have you read any of the books concerning how IBM's equipment was used by the Nazis to support the Holocaust, and how IBM continued to cash royalty checks from Germany well into 1942 (after their host country was at war with Germany)? As a technical professional does this bother you? Does AMI have any responsibility for how its products are used?

Re:IBM and the Holocaust (0)

Anonymous Coward | more than 11 years ago | (#5102771)

Do you sue Sears if somebody hits you over the head with a Craftsman hammer? Let me know when Hitler buys a new motherboard.

He's a weasel (4, Insightful)

legLess (127550) | more than 11 years ago | (#5102736)

[Yes, I've read the whole interview, and even a few of the links.]

The thrust of half those questions was: "TCPA seems to provide benefit only to those who wish to tell me what I can and cannot do with my computer. Is this true? If not, what's in it for me? If it is true, how can you sleep at night?"

I think Michael's questions were most on-point, and what I most wondered myself (there, I said something nice about him :). Brian totally fucking dodged every single one of them.
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?
Brian mumbles something about his reading of the TCPA spec and DRM, neither of which were the point of the question. The answer is obvious: "Yes, of course that's the goal. Shut up and eat your BIOS."
b) However, isn't it true that without AMI's trusted BIOS, Palladium wouldn't work?
The reason we keep saying "we're not a part of Palladium" is because Palladium doesn't exist in the marketplace...
This is splitting hairs at best, and another artful dodge. If Palladium were in the marketplace, would AMI be part of it? Of course they would. And right now they're laying the groundwork.
c) In what way does AMI benefit ... from introducing a BIOS designed to make the computer it is installed in less useful to the purchaser of the computer?
Here Brian reinforces that you and I are consumers, not customers - mobo manufacturers are customers, and they get the features they want. This is the way the market works, and I've got no special beef with it, but it's a bit of a wake-up call for those who still believe companies like AMI give a rat's ass about the average geek buying a motherboard.

If I sound harsh it's because I'm pissed. The goal of TCPA is transparent, and Brian The AMI Guy is either trying to pull the wool over our eyes or incompetent. Given that he used to hack this stuff for a living, and now has "Sales" in his title, I'd suggest the former.

Big Media nad Big Software are chortling in glee as they see their plans for "Trusted Computing" coming to fruition. The MPAA wants to turn your computer into a TV, and AMI is only to happy to help.

deer in headlights (0, Troll)

prell (584580) | more than 11 years ago | (#5102741)

I like how this interview starts out with what looks like a good understanding of the technology, its place, and AMI's place in it, but once we get to the key question (relating DRM, "trust," and pre-emptive behavior prevention in software), the interviewee completely opts out and suggests we all take a look at the extensive TCPA documentation. Yeah, we could do that, or we could interview a BIOS person. Oh wait..

I also LOVED where he said AMI doesnt' bear responsibility for palladium because it "doesnt exist yet." What a lame cop-out. "Yeah uh, Im gonna make this handcuff ring, but the other side isnt done yet, so you can just kind of wear it like a bracelet. I dunno what it will do!"

I also noticed this guy is from "sales," so naturally he's going to try and sell this to us. "It's not as bad as you think - you guys with your crazy linux stuff will love it! 0wnz0red!" Remember, people dont give away freedoms all at once - they do it piece by piece, being convinced by stuff like this.

I also enjoyed how he referenced Zero Wing. That shows he's really one of us. What a cool guy!

Follow-up question (1)

kiolbasa (122675) | more than 11 years ago | (#5102751)

So, roblimo says this guy reads Slahsdot, maybe he will answer follow-up questions here...

Please clarify, in 50 words or less, wether or not the trust model that TCPA implements will ever allow software to consider the owner and operator of a TCPA-enabled computer "not trusted."

You haven't met me yet? (1)

Zog (12506) | more than 11 years ago | (#5102757)

I don't know, I've never met Satan

You say you haven't met me yet? That's kind of funny. Well, regardless, I distinctly remember you.

Have a nice day.

Say good-bye to dual booting... (2, Insightful)

jgrider (165754) | more than 11 years ago | (#5102767)

Okay, I'll bite:

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).

If this is true, then how do we get our free bootloader (lilo?) to work? Will (insert free bootloader here) have to switch to binary only releases, and pass every one through a certificate authority?

I have a gut-wrenching feeling that either we aren't hearing the whole story, or this guy is oblivious to the larger strategies at work here...

He is doing his best (1)

dusanv (256645) | more than 11 years ago | (#5102772)

Really, everyone is being too hard on this guy. Altough he is involved with Linux he is just a salesman trying to make best out of a bad situation. I mean, AMI pays his salary. What is he supposed to say: Yeah, the primary use for our BIOS will be to secure a steady revenue stream for a couple of Hollywood/Redmond a$$es and take the fair use rights from the user. He is clinging hard to the fact that it may have other uses as well (VPN, whatever..) and that it may be disabled. In any case, e hasn't changed my mind a bit. That crap isn't going to make it into my house.

Smart guy, well spoken, but pushing BULLSHIT. (2, Insightful)

Eric_Cartman_South_P (594330) | more than 11 years ago | (#5102776)

In regards to supporting Palladium: Keep in mind that this is just one more feature we offer

No, it's not. On paper, it appears to be a feature. Get a BIOS pre-palladium. List features and count. For exmaple, lets say 110 "features". Now add palladium to that same chip. We now count 111 features. Again, on paper it looks good. But in the real world, where we live and where the chip will run, it's bullshit.

That 1 "feature" will reduce a very important part of my computing usage. "Freedom" and "choice" and "control" el. at. It's a net-negative. You added 1 "feature" on paper but reduced my "LIBERTY" as the user.

If Ford were to advertise "New Options! All cars CAN have a STEARING WHEEL and an ENGINE if you like!" they would be shut down. But in the digital world, AMI et. al. calls this type of selling a "feature". No thank you.

so can I sign my own software? (2, Interesting)

hopeless case (49791) | more than 11 years ago | (#5102789)

The one question I wanted to see an answer to was whether I could designate myself as a signing authority and get the motherboard to only run code I had signed, or whether there was a fixed list of signing authorities.

Perhaps I missed it, but I didn't see an answer to that. The answer seems to be no, which means the comsumer is being taken for a ride.

Quite interesting... (1, Insightful)

Anonymous Coward | more than 11 years ago | (#5102809)

The Trusted Computing Alliance is still annoyingly cloak-and-dagger, but this does clarify things a bit. (It's a shame more of the questions asked didn't take into account that TCPA obviously != Palladium, though TCPA -> Palladium.)

My thoughts here-

-Crypto offloading is great, if done properly. Question is, will it be self-perpetuating, or will the initial implementation be light-years ahead of general-purpose processing, but various issues bog down R&D and spec-updating until 'brute force' CPUs once again mop the floor with the specialized units?

-As we probably knew in the back of our heads, TCPA is just a 'technology,' like SSH, or more accurately, SNMP/WoL/other remote-management solutions. What would make things evil would be:

-TCPA-only hardware/systems models, roughly equivalent to Winmodems or anything else built under the assumption of proprietary licensing (of OSes, keys, etc). The real risk here doesn't sound like "Linux/BSD won't boot;" it sounds more like "Linux/BSD won't be able to boot 'Trusted' so you can't put that SAMBA server on your Windows network."

-In fact, let me repeat that. "Linux/BSD won't boot trusted, so you can't put that SAMBA server on your Windows network." This is why MS gives a hoot, and while TCPA itself might not be an idea with [good|evil] alignment, beware of influence to the spec. Network filesystems are a good idea; CIFS is an example of a good idea manipulated for lock-in.

-As to Palladium... first off, it's sounding more and more like another lovely exploitable mechanism. If, somehow, Gator or friends can inject code into the Palladium box, they get free reign and undetectability. Heck, imagine if worms could take advantage... [I'm not feeling up to speed on the spec today, so I may be ignoring how code gets into the Palladium box in the first place. Still, it's long been proven there's more than one way to skin a horse- Microsoft signatures aren't necessarily from Microsoft and all that. ;)]

-...secondly, it sounds like the full Palladium vision (in the sense of MS revoking the 'license' to your Word documents and so forth) is going to be an *application* of TCPA and other protocols, in the same way BackOrifice is an application of TCP/IP networking.

-Finally, as far as I can tell, most jumpers in this day and age simply set registers read by the BIOS at boot, so unless these are physically cutting power/pathways to various chips, I can't see why the TCPA processor can't be enabled later. After all, there've long been hacks like SoftFSB and similar. Whether that'd have actual utility is anyone's guess... The potential to curtain some memory in Palladium-ready chips based on an exploit's request sounds more disturbing.

TCPA is DRM, whether they want it to be or not. (2, Interesting)

geekoid (135745) | more than 11 years ago | (#5102816)

" Merely adding TCPA to AMIBIOS doesn't constitute DRM:"
then later he says that TCPA can be turned off three defferent ways: In the bios, jumper, or software.

Which way do you think Mother board manufacturers will want? I'm guessing the cheap route, Software.

So you can turn Off tcpa , then the OS could turn it back on 'for' you.

But that doesn't matter, because a company with a history of abuses in the market place, and a convicted monopoly, won't have an issue with popping up a message telling the user to enable tcpa, or there OS won't run. Probably After its been installed for a month for 'convience' sake.

My Concern (0)

Anonymous Coward | more than 11 years ago | (#5102826)

I believe this is a play, to set precedent for the digital tv turn over.

Services can be concidered any show you watch.

Very accurate information about every person that uses this new technology.

Instead of broad stroke appeals to certain demographics, precision strikes. Similar to a certain trusted news organization selling it's time and reporters to praise the virtues of hormone therapy, which ended up cutting short the lives of 10 million women in North America. With little to no mention of a retraction.

There are no laws to protect a countries citizens from such abuses.

Customer food chain (2, Insightful)

Distan (122159) | more than 11 years ago | (#5102837)

I'm going to address something Brian said from the perspective of a motherboard designer, because that is what my recent job was.

Brian says "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:"

This really is the key. AMI doesn't sell their BIOS to "Linux Users", nor do they sell it to any other end users. AMI's customers are the companies that either design or specify designs for motherboards (think Dell, IBM, HP, Intel, Tyan, etc.) AMI simply can't say "no" to these customers, as they will simply go somewhere else. Or, as he pointed out, since the motherboard designer usually has a license for the code, they can just have their own programmers put in the offending feature.

The next question you have to ask yourself is why are the motherboard designers pushing for this feature? Extending Brian's argument, it is because their customers are system integrators and the system integrators are demanding it. In the case of Dell or HP, the system integrator is just another group in the same company, in the case of Tyan it is another company altogether, but the case is the same either way.

So why are the system integrators demanding it? The simple answer is, Microsoft doesn't give you any choice. No PC maker can be competitive without that little "Designed for Windows 2004" sticker on the front of their box. Our contracts with Microsoft give us a big discount on Windows licenses if we meet their demands, and one of those demands is that the hardware platform we ship meet all the requirements of a MS/Intel driven design guide.

Ever notice that all computers now ship with a network port? Ever notice that no computers ship today with ISA slots? Ever wonder why? Because those are the demands that MS makes, and the costs of failing to meet their demands are so high that the PC makers really have no choice.

Don't get upset with AMI for enabling Palladium. They really have no choice. If you want to find out who you should be upset with, just follow the money and see where it leads.

We are Greedy-American-Capitalistic-Pig-Dogs (1)

Your Average Joe (303066) | more than 11 years ago | (#5102849)

The whole purpose behind TCPA/Palladium is to sell product. How do you think Microsoft will keep the Xbox a game console? They need to make it as proprietary as possible. Besides "Trusted Computing" is a Microsoft buzz word. Microsoft has buckets of money to protect the Xboxes future!

The motherboard manufacturers could have the economy model for home users that would only work with win9x or XP. The server, workstation or Linux versions would be priced much higher.. Now this would also work for Dell, say you have Dell servers and workstations and you have a server board failure, you would need to have an extra Server and Workstation since the motherboards have different BIOSes. The end result is companies have fewer choices while the VARs make more money. DUDE! Your Seagate IDE Server hard drive FAILED? We can send you one today, the replcemnet is $499! So you try to put a workstation drive in and it won't boot! You know capitalism, after all we are Greedy-American-Capitalistic-Pig-Dogs!

The next thing it will do it will allow poorly conceived business to stay afloat, like Net Appliance when all the hackers bought IOpeners and caused their business model to fail.

How do you become a BIOS hacker? (1)

MikeFM (12491) | more than 11 years ago | (#5102851)

I've often wondered how I'd go about developing my own BIOS if I should want to do so. I have years of programming experience and decent electronic engineering experience but I'm not really sure how I'd start on writing a BIOS. Are their books devoted to such a thing? Motherboard Design and BIOS Hacking for Dummies? I wouldn't mind tearing up some old mobos to get some practice in.

This is what I call a fundamental feature (5, Funny)

leoboiko (462141) | more than 11 years ago | (#5102868)

AMI has advantages over LinuxBIOS as well (...) JPEG graphics as boot logo...

That's it. I'm not interested in LinuxBIOS anymore until they support JPEG graphics.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>