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

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.

Comments

Hmm

[jon787]

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

XOR as clear

[balister]

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

Re:XOR as clear

[entrager]

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

[PetiePooo]

A MOV with an immediate doesn't pull anything over the memory bus other than the instruction and operands which any operation would. However, it would need to move the immediate from the CPU's instruction cache into the ALU.

Its still worse than XORing a register with itself, but its not as bad as you make it out to be. Really a moot point, being that XOR AX, AX is a better choice overall and MOV AX, #0 has absolutely no advantages.

Re:XOR as clear

[Rich0]

i=(i-i) is clearer than i=0? Hardly

To my grandmother they're both equally incomprehensible.

But my grandmother doesn't read C source code.

Likewise, the average C programmer might not get XOR AX, AX, but then again, they don't read 8086 assembly language either.

To somebody who knows ASM, XOR AX,AX is meaningful. To somembody who doesn't, MOV AX,0 is not. As a matter of fact, a C-only programmer would probably translate MOV BX,AX as AX=BX and not correctly as BX=AX (ie - move BX INTO AX, and not the correct meaning). (Heck - who decided to put the destination BEFORE the source in i86 ASM?)

He did not awnser this

[nervlord1]

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

[grub]

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

[stratjakt]

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

[Kourino]

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

[ehiris]

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

Re:#6

[Anonymous Coward]

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.

Re:They are scared......

[patch-rustem]

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

Thay may make it more interesting.

You can clear a register with MOV??

[kahei]

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.

never met satan

[BigGar']

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

[Evilderek]

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

Good info!

[Ageless]

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.

Performance hit

[oliverthered]

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

[Amazing Quantum Man]

No, because encrypted data is supposed to have no patterns (i.e. appear random). Therefore there is no redundant information to compress out.

Try this:

dd if=/dev/random of=/tmp/somefile bs=1 count=100000
ls -l /tmp/somefile
gzip -v -9 /tmp/somefile
ls -l /tmp/somefile.gz

You will get essentially 0 compression. Now try it with a GPG'ed file. Make sure you use a long enough key, and the file is also in the vicinity of 100K. You should also see close to 0 compression.

Use TPM for other things?

[Milo Fungus]

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?

[Anonymous Coward]

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.

Not Quite...

[waltc]

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

[stratjakt]

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.

Re:Not Quite...

[Torville]

This whole process reminds me of a ill-formed logic problem, where a series of individually reasonable-sounding steps somehow leads you to an untenable and unacceptable conclusion.

Did anyone ask if disabling the TPM counts as a DMCA violation... or is that a foregone conclusion?

Re:Not Quite...

[impto]

You make some interesting points but altogether your argument is flawed. Somehow you managed to make the same jump from TCPA to DRM that most other people around here do so easily. DRM does not require TCPA and TCPA was not sole designed for DRM. That's not to say that TCPA won't make certain DRM schemes harder to circumvent.

[T]he 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."

If the standard functionality of a program requires TCPA enabled DRM to function then either it wouldn't work without it (e.g. secure methods for copy control) and there is no getting around it or it would work without it, in which case a competitor could easily copy the functionality and market or give away that same functionality without the annoyance of having TCPA enabled.

The mere fact that it is in the bios will be enough to spur software development in that direction.

The demand for DRM is already there. From the [MP|RI]AA and from people who just plain want to get paid for their work. Including TCPA is not spurring on DRM, however useful it is to that end. In effect, you are using the same logic used by the MPAA against DeCSS. Just because it can be used in an illegal manner doesn't make it bad altogether.

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

How about this: If you don't want Microsoft doing anything on your computer of which you don't approve, don't run Microsoft software.

Re:Not Quite...

[waltc]

Frankly, I don't understand people who fail to make the jump...;) It's like a connect-the-dots restaurant placemat, you know?

I've been computing on the desktop for 18 years and over multiple platforms and it's truly mind-boggling what I've been able to do without the "helpful" technologies of DRM, Palladium, and TCPA (now you might make the technically accurate point that TCPA is not DRM, and you'd be correct. However, that does not alter the fact that A] it's not needed, and b] TCPA may in fact be leveraged by software DRM applications.)

You've got quite a few things backwards. It's actually the software companies which are accusing honest people of illegality (pirating software) and are stating loud and clear that they don't trust *me* as in individual enough to take my word that I don't pirate software (which I don't), but prefer instead to attempt to control my personal computing environment so they won't have to take my word for anything. I think this stinks--and I also think that in short order the DMCA will be repealed--the abuse of it already by private corporations is staggering. I'm for a *balance* between corporate rights and the state--I don't want to see the rights of individuals trampled by the rights of corporations.

Interesting, isn't it, how Microsoft's present financial position and strength owes nothing to DRM, Palladium, TCPA or Product Activation? The first three have yet to exist in the marketplace, and Microsoft was very rich long before it initiated Product Activation schemes. Absolute proof, then, that these initiatives are not about software piracy at all (at least from MIcrosoft's position.)

I think in the end it all boils down to greed and greedy men who fear the loss of a $ so much that they would cheerfully usurp the rights of everyone over private property simply because these greedy people consider that their right to make a profit is the Supreme Right in the Universe. That's nonsense, of course.

But as I said this is much ado about nothing at this point because DRM and Palladium are effectively nothing at the moment and control no one's hardware and software environment. Even with a complete acceptance by the markets this technology (after it is finished of course) would take years to penetrate before it would make any fundamental differences. Like the DMCA, though, I suspect it has a very shaky future in store, because there are a lot of people like me who want nothing to do with it--and the corporations which now exist will simply have to find a way to live with that--just as they found ways to "survive" the recording VCR which that idiot Jack Valenti proclaimed would be the "ruination" of Hollywood. (Come to think of it, maybe sending Hollywood down the tubes is not such a bad idea after all...;))

Re:Not Quite...

[finkployd]

Point of fact, the Supreme Court did not do anything with copywrite, Congress did. All the SP said was that what Congress did was not unconstitutional (although there were some comments that they believe it was wrong, that is a different matter)

Place blame where blame is due.

Finkployd

Re:Access to ideas

[stratjakt]

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:"customers want it"

[nuggz]

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:hardware specs for open source

[SalesEngineer]

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.

Answer to what "trusted" means

[KjetilK]

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

[gosand]

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

[j3110]

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.

Re:Not quite true

[homer_ca]

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

We asked the wrong person

[carambola5]

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.

He's a weasel

[legLess]

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

Re:He's a weasel

[SalesEngineer]

Well, that is a bit harsh. You make sound like I'm hanging out in Hollywood, smoking cigars with agents as the MPAA hands me a contract for their next line of motherboards.

I think I can addess my feelings on the situation using the following vernacular: "Don't hate tha playa, hate tha game."

Just remember that it's not the tool, but how you use it. I can build with a hammer, or I can use it to break bone. I can use GPG to send my personal e-mail, or I can use it to sneak nuclear secrets to the North Koreans.

Brian Richardson

Re:He's a weasel

[legLess]

Thanks for replying, Brian.

This is peripheral to the main point, but:

"Don't hate tha playa, hate tha game."

...is not an excuse, justification, or defense. At best it's a rationalization, and a poor one. If the best thing you (and I mean "you" in the general sense) can say about your actions is, "Everyone else is doing it, so I might as well make my lettuce while I can," then you're in sorry shape indeed.

But I said that was peripheral and it is. My main point is: your answers to the uncomfortable questions were evasive. I know you're not the architect of this scheme, and perhaps the world would be different if you ran it all, but that isn't the point. The geeks here asked you a number of questions because you're an authority. I think that either (a) I'm not just harsh but incorrect in my criticisms, in which case I'll apologize, or (b) my criticisms are correct and you did not, in fact, provide us with the honesty you could have.

Re:He's a weasel

[bofkentucky]

We are customers, of Abit and Dell. Call them and complain, tell them you won't buy TCPA hardware, they can use that feedback to tell Phenoix and AMI to stuff their TCPA hardware. As much as we think Dell would die without Microsoft, it works the other way as well. Microsoft needs (relatively) cheap hardware to spread to every home, just the same as Dell needs a easy to use OS for the masses. Frankly, quit bitching and get to work if you want to bring about change. Vote and buy based on what you believe, support projects with others who seek the same goals as you and eventually someone might quit making bone-headed decisiions.

Re:He's a weasel

[SalesEngineer]

We don't have access to any released applications that make use of the TPM outside of basic test utilities. I have no real idea how the final products will work. Some of them may be good, some may suck. I gave as much information as I could based on the specs I have. I may be considered an 'authority' on BIOS, but I am far from an authority on security issues. My company got sucked into this whirlwind because of the politics of TCPA/Palladium, and I decided to do what I could to try and separate fact from fiction (I can't do anything about the paranoia, but I hear there is a pill for that). Brian Richardson (AMI)

Re:He's a weasel

[Danse]

What paranoia? The intent of TCPA/Palladium is clear. There is no conspiracy. There is no mystery. The goal is to remove at least some degree of control over the computer from the owner of the computer. This will be done in an attempt to protect the interests of content-owners. I think we understand that AMI is supporting this for the same reason that anyone supports it, because it will make them money. The only people with no good reason to support it are the consumers. So, like some others here have said, if we have a problem with it, we need to take it up with the hardware manufacturers, not AMI or any of the higher level suppliers. I think that sums it up. Thank you, drive through.

Re:He's a weasel

[TyrionLannister]

You must realize that there is no such things as consumers anymore. The US government has decided that consumers only exist to serve the interest of the corporations that feed it campaign donations.

Until campaigns are publicly funded, this will only get worse. The difference between our future and that in Orwell's 1984 is that it will not be a monolithic govrenment running our lives. It will be a government granting the power to corporations to run our lives.

I don't agree with all of McCain's ideas by any stretch of the imagination, but I would love to see him elected because his is the only guy with the balls and the clout to give the government back to the people.

Re:He's a weasel

[WNight]

The problem is that you can have all the code signing in the world and crap OSes and crap mail-readers will still let shit happen.

It's not like there's a "Mail my private documents to everyone under the sun" feature in Outlook that people just forgot the password. The problem is that an email client needs to do certain things to function, access files in a read-only mode, and create/receive email. A virus will still be able to cause a stack-overflow, or something similar, and cause outlook to do something you didn't want, using only allowed resources.

It helps that Outlook (maybe) won't have write access to files, but that doesn't help people whose files have been copied to everyone else.

And applications that have write access will still be vulnerable. If you use Kazaa to download legit MP3s (sure) and someone tricks it into overwriting them all with "hahaha RIAA 0wn3r3d you!" you still lost your collection of Greatful Dead concert recordings.

It's like how a Unix person says "Unix can't get viruses - if you run a malicious program, the most it can do is wipe your user files." That's good, except that user files are the only things of value on the average, end-user computer.

Similarly, TCPA/Palladium/Whatever will make sure that while some buggy program destroys your personal data, it won't be able to copy the precious hollywood movies you're "renting".

There's no security for the user in this. There's security *against* the user here. That's great for me, if I'm a government or corp, and I don't trust the user. But if I'm a home user, I don't really want to buy a computer that won't do what I want it to do.

Re:He's a weasel

[WNight]

The problem is that while TCPA is a tool, it's one only wanted by the "bad guys". Imagine if your local Thugs and Vandals Association put in an order for hammers and spray-paint. The police would be right to suspect mayhem.

Similarly, if consumers were pressing for this because GPG ran slowly (which it doesn't, nor does SSH. SSH can saturate 100Mbps networks on a P2-600 easily) then we'd trust it. But with the main movers behind this being the MPAA/RIAA, Microsoft, and the Bush Administration, we're justifiably nervous.

TCPA/Etc are supposed to allow user protection by code signing, etc. Even if these worked perfectly it still wouldn't stop the attacks that hurt most people. Buffer overflows masquerade as legit data so you don't check them for a certificate before accidentally executing them. Similarly, programs can be fed bad data and through a lack of error-checking, do bad things.

Take an example like Outlook. In a secure system you'd give outlook write permission to it's own files and read access to things you may want to send as attachments. Unless you want to okay everything it does seperately, you'll have a blanket permission policy. Now, someone sends you email with a buffer overflow and runs their own code. The OS won't let them write to any useful files, but your email. That's gone... After it signals your IMAP server to delete it as well. And any personal files it has access to, it'll send those out to everyone in your address book, and a few mailing lists too.

But, you're protected right. I mean, that trusted architecture made sure that if the email virus tried to copy your precious copies of those "Hollywood Movies" that it wouldn't be able to. I bet you feel much better.

Meanwhile, the same guy who wrote the email virus is sitting back, watching a very high quality bootleg of that movie that was made by someone in another country, with studio-quality analog gear and then dumped, sans watermark, onto the p2p networks.

But yeah, I'm sure there are good applications for this technology... As long as you're looking at it from the point of view of controlling what legitimate users, those without the facilities to find bugs and backdoors, can do.

But yes, it is unfair to pick on you. And thank you for at least letting us know what's going on. We'll try not to shoot the messenger, but pardon us for not believing in the benign intentions of those in charge of this.

Re:He's a weasel

[NigelJohnstone]

"If we can't agree on that, then there's no answer that I can ever give to make you happy"

Yes there is, you can say this:

"Microsoft told us that if we didn't put it in, then we would wake up to find Windows wouldn't run on our BIOS and we would have no market. We won't kid you, its not in your interests, its serves no useful purpose to you, we had to do it because we had no choice"

There, truth sounds so much nicer doesn't it. The whole board is full of you and Brian dodging questions and some very iffy moderation doesn't hide that.

Re:He's a weasel

[KjetilK]

Well, if you get thrown in jail for not letting it take control over you, then it is not so much a matter of individual choices anymore.

Of course, we can always try to destroy what you are creating, illegal or not, if it gets out of hand. Would you want that? If it did get out of hand, and it would need to be destroyed, then what would you say?

You have a huge responsibility for the things that you develop, Brian, are you ready to assume that responsibility?

Re:He's a weasel

[solferino]

Don't hate tha playa, hate tha game."

no players -> no game

without people prepared to bend their ethics there are no unethical games - a game only exists if it played, to be played it requires players

Just remember that it's not the tool, but how you use it.

This is the fundamental philosophy of the technocrat i.e. that tools are neutral - when fully examined this is completely bogus - tools are designed by people and have those people's moral frameworks built in i.e. if you do not believe in killing you do not design, manufacture and sell guns

the only 'tools' that are neutral are natural objects i.e. a big rock could never be considered a 'suspect' object even if it had been used to hit someone over the head - a land mine on the other hand will always be an evil object and an embodiement of the lapsed moral standards of it creators and manufacturers

Re:He's a weasel

[spitzak]

You have no idea what you are talking about. Every one of your examples can be done by software and virtual memory hardware that exists today. The TCP/IP driver can peek at the VPN passwords because the programmer was too stupid to put the things in different memory spaces. If you think having a different form of protection in TCPA is going to suddenly make the programmer smart enough to not do this mistake, you are seriously deluded. However I think you are trying to make excuses.

TCPA means there is a public crypto key in the hardware. THERE IS NO PRIVATE KEY. This means that the owner of the computer CANNOT SIGN CODE!!! (by owner I mean the same thing you mean, the IT department, not the dumb secretary who is at the desk). The fact that the owner cannot sign code is the ONLY difference between TCPA and all the well-established security schemes in existence.

The entire purpose of TCPA is to make sure that people cannot program their own computers. It is not a magic thing that is going to suddenly make software have no bugs!! It is going to sign those bugs and say they are "trusted".

Re:Standards

[SalesEngineer]

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.

Say good-bye to dual booting...

[jgrider]

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

Smart guy, well spoken, but pushing BULLSHIT.

[Eric_Cartman_South_P]

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.

Re:Smart guy, well spoken, but pushing BULLSHIT.

[Hobophile]

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.

I think it's a great feature. Seriously, sign me up.

No, I'm not crazy, and I'm not trolling. See, I'm a big fan of online gaming in general, and have logged more than my fair share of hours in quite a few games. Diablo 2 and Warcraft 3 are among those.

Now, as anyone who played Diablo 2 longer than a few months after release knows, hacking and cheating were rampant on the supposedly secure realm servers. And anyone doing ladder games for Warcraft 3 presently knows that finding hack free games is increasingly rare, with the abundance of map hacks and disconnect hacks and the like circulating.

How would this be different in a TCPA-enabled future? Well, if Warcraft 3 ran in a trusted environment, with the memory regions it used isolated from non-trusted applications, then the creators of these hacks would have nowhere to begin, effectively eliminating the cheating problem.

It's my understanding that this is the sort of multiplayer environment Xbox Live can guarantee. And honestly, I really envy that. Hackers and cheaters can easily ruin the fun of the game for players that do not use such "aids." A case in point is the utter joke the Diablo 2 realm economy eventually became.

I'm not saying Blizzard or anyone else should actively shut out players who didn't have TCPA-based hardware; just that those of us who did have it could use that feature to play the game without the cheaters. In fact, I would go so far as to say that this particular sort of software would become more valuable to me if that sort of unbreakable, trustworthy guarantee of a clean game was available. And the more emphasis that was placed upon this feature -- such as by requiring all ladder games to take place between opponents running the game on a TCPA-enabled platform-- the more valuable it would become.

And to me that settles once and for all the question of whether or not TCPA and things like it are just "bullshit" as you claim.

Can it be abused? Yes. Of course. Most features of note can be, even down to the ability to execute programs on your computer, which can be abused to compromise your system in the event you execute malicious code.

So: don't run viruses, and don't run programs that demand you use any other feature, TCPA included, in a way that abuses and tramples your rights as a computer user. Believe it or not, such abusive "features" are unpopular and cause companies that employ them to lose market share. Companies that continue to do so, or fail to remove such abuses when pressured publicly to do so, do not continue to receive money from intelligent consumers.

so can I sign my own software?

[hopeless case]

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.

I think he did...

[fireboy1919]

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.

TCPA is DRM, whether they want it to be or not.

[geekoid]

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

Re:TCPA is DRM, whether they want it to be or not.

[autopr0n]

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

Actualy, the system needs to be started when the computer is powered up, otherwise it dosn't work. The AMI guy mentioned that, but he didn't really emphasize it as much as he should have. if TCPA could be started back up by the OS, then it could also be started back up by some cracking software, or something.

Re:TCPA is DRM, whether they want it to be or not.

[NigelJohnstone]

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

More likely, you will find that unless you turn it on, your machine will interoperate less and less with other machines.
So you will turn it on because you the alternative is to live as a hermit in the hills.

Customer food chain

[Distan]

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.

This is what I call a fundamental feature

[leoboiko]

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.

DRM turns sales into bad rentals?

[TyrionLannister]

Can anyone tell me what happens to materials I have purchased on PC #1 when I upgrade to PC #2. IS it just me, or does it seem that there should be legislation guaranteeing this ability. If there isn't this is going to be the biggest rip-off for consumers in history. When you purchase DRM content, not only will you not be able to play it on more than one electronic device, but you will lose the ability to use it at all when you upgrade computer or switch mobos or if your mobo goes bad.

Or is there some mechanism to avoid this?

Why BIOS at all?

[mdxi]

I wish I'd thought to ask this earlier. I'd love to know why PCs still use the old, crufty, ugly, BIOS at all. Why does the Intel architecture industry not use an implementation of the powerful, flexible, architecture-independent OpenBoot (IEEE 1275) standard?

SPARC, PowerPC, and Alpha machines use it. Why is the x86 world stuck in 1980? (This, the clever reader will observe, is a rhetorical question.)

Re:Why BIOS at all?

[IntlHarvester]

Nobody really answered your question, so I'll take a shot at it -- the primary reason for the BIOS is backwards compatiblilty.

The following OSes are designed to require a classic PC AT-style BIOS, at least for the boot sequence:

DOS
Win 9x
OS/2
Novell Netware (bootstraps from DOS)

Note that the first 3 are "obsolete" and aren't being updated but are still in very widescale use. I believe it's possible to still order machines with Windows ME.

Anyway, you could make a legacy-free firmware that could boot lightly modified versions of XP or Linux, but that doesn't help the installed base at all. Maybe in 10 years, but not now.

The BIOS is just the tip of the iceburg -- a modern PC is still very much "AT-Compatible" -- and that has radical effect on the hardware design. For example, ATA/IDE has to be continually improved, rather than replaced, because it offers the highest compatibility.

As a secondary problem, even modern OSes like NT/2K/XP and Linux have a bunch of dependancies on BIOSy things like ACPI.

Re:They are scared......

[Planesdragon]

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.

You seem to think that security is an absolute thing, rather than a never-ending qualitive bit.

Linux is not magically secure--it and windows can be improved through all manner of devices and programs, and this will be so for a long, long time.

Well ... yes, I did answer the question.

[SalesEngineer]

He asked me why to buy AMI over a competitor ... that's what I answered. That's what I do for a living, so I had an answer.

If he wanted to ask about something else, he should have asked a different question.

Brian Richardson - AMI

XOR Trick

[PetiePooo]

When I hear the phrase "XOR trick," I think of its usefulness for exchanging registers.

If you don't have an XCHG op like the Motorola 68k to exchange two registers, you can use the following trick:
XOR AX, BX
XOR BX, AX
XOR AX, BX

Now, that's a real trick!

a ^= b ^= a ^= b gets optimized out

[yerricde]

The old swap trick a ^= b ^= a ^= b may have worked well on older architectures without a swap instruction, but modern processors can swap R1, R2 in one cycle as opposed to the three cycles a ^= b ^= a ^= b takes. In fact, GCC will optimize a ^= b ^= a ^= b to swap R1, R2 on such architectures.

Re:Anyone else notice #6?

[Roblimo]

Michael's question was modded up by normal moderators. If I use an editor-written question in an interview that does not get chosen by the same system as all other questions, it is clearly marked as a "bonus question from [editor]" or some such.

This has only happened once or twice in over three years' worth of Slashdot reader-generated interviews, BTW.

- Robin

Some thoughts as I read though

[John Sullivan]

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

Understood - this isn't personal, just a few points which I though were unclear or misstated.

TCPA adds a few elements to this security scheme [...] longer keys (some keys are 160 bits, most are 2048 bits)

I would assume that the 128 and 160-bit keys are keys for some symmetric cipher, and the 2048 bit keys are RSA keys. It is wrong to suggest that key length correlates to strength without taking the algorithm into account, and even then practicality limits the usefulness of longer and longer keys. 128 bits is probably safe enough, and though I'd be happy to use a 160 or 256 bit key in a symmetric cipher, longer than that gets silly: at 128 bits you're already never going to see the key brute forced.

The benefits of 2048 bit RSA keys come not from strength through length, but from the fact that they belong to a different class of algorithm, which allows you to do very different things with them.

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.

I have yet to be convinced that this is true of data in the general sense and malware. All real world software contains bugs, some of which can be exploited to subvert the system. No amount of hardware trickery can stop this being true, the best you can hope for is to contain the spread of corruption by compartmentalizing the system. If you only have one compartment, or only one compartment you really care about, which I suspect will be the case for the majority of systems, then containing malicious code to that compartment provides little benefit. Even if you care about other compartments, the premise of containment assumes no bugs in the boundaries between neighbouring compartments.

In all likelihood you can make things prohibitively difficult for individuals to do something against the policy of the creator of the platform/application, even with their own property, but you can't make the guarantee that the platform is immune from malware.

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

This is not necessarily useful. Anyone may well be able to implement TCPA features, just as anyone can implement an SSH client. Without access to the necessary keys, you can still be prevented from accessing particular data or functionality, just as your own SSH client won't allow you to login to any extra servers. With open access to the keys, you've lost any security guarantees that rested on them. This makes the exercise somewhat pointless in many cases.

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

DRM without hardware support can never be secure. At some point the data being protected has to be decrypted, and since the DRM implementation doesn't have the secure platform guarantee the TPM provides, it can't be sure there isn't something out there waiting to extract the data. It's even relatively easy to directly subvert the software, but subverting secure hardware is very much more difficult. This is significant because the R in DRM is not directly tied to law - it can be used to enforce policy that extends beyond the data owner's rights, by restricting rights that the end user does have.

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

This can of course be done without TCPA. You could easily push the crypto into the NIC. nCipher make a variety of crypto hardware accelerators for networking, storage and other uses, which don't impact the architecture of the whole of the rest of the system.

Re:Follow-up question

[Hobophile]

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

Oh come on. Let's face reality: the fact of the matter is that your (proprietary) software hasn't trusted you for a while now. What exactly do CD keys and registration requirements indicate if not a complete distrust of the end user's good intentions?

Take the recent story on Quicken's Turbo Tax program, where Quicken removed your option to print returns on a computer other than the one the software was originally activated on. Do you think maybe Quicken did this because they don't trust you?

Another example off the top of my head are those annoying product activations the new Microsoft Office products require. Why would Microsoft do this if they trusted their customers? Hint: they wouldn't.

If you honestly believe any major software company trusts you to protect their own interests when your convenience or money is on the line, you are quite deluded. Management at these companies is only going to trust you insofar as this aligns with their long term strategic interests. Once this is no longer the case they will do everything in their power to make sure the untrusted end user cannot impact those interests, even if it makes their software substantially less useful to you.

Bottom line: software companies do not trust you. They have no reason to, and therefore should not be expected to. Adding TCPA does not change this reality; they will still not trust you. But they'll be more comfortable dealing with you because your potentially damaging actions are verifiably constrained by their software.

Don't like this? Buy/support/use software that does not constrain you. That's your option. Boycotting AMI or TCPA-enabled motherboards does not solve the problem; those manufacturers are responding to a demand from software developers and content owners. It is up to you to show those people that you do not want to be curtailed and restricted and denied at every juncture.

Re:They are scared......

[tzanger]

They didn't need to. Linux doesn't need hardware help to be secure.

You are so wrong. Linux can do nothing if I've got a rogue PCI card or USB device installed. Linux can do nothing if I've got an ICE on the processor. Windows, OS/2, Mac, nobody can. It's beyond the scope of the OS' current capabilities, and it has no way of assuring itself within reasonable doubt that whatever it's talking to has not been tampered.

TCPA is all about that level of security. I can write TCPA-enhanced drivers which will validate that the PCI card I'm talking to hasn't been tampered from its original spec, almost right up to the output DACs or input ADCs. (I can still tap off any analog output or feed funky values to any analog input, but that's not a problem for most people designing this TCPA and Palladium stuff.)

Question 10 reply

[lanner]

Dear Brian

I was the author of question number 10, "What do you think about Linux BIOS?". Thank you very much for your answers.

You appropriately split up this question into two parts, which was great. Novell is not much of a player anymore, but Microsoft is, and of course you have to support them. But I am happy to hear that you test for BSD and Linux comparability too. My preferences are Debian GNU/Linux, and FreeBSD.

When I think of the possibilities of LinuxBIOS, I think of my Sun SparcSTATION 10 which I have here at home. It was built in 1993, and has an EEPROM BIOS, called the PROM in the Sun world. It uses Forth and has a lot of cool features. Basically, it is a small OS built into the BIOS which allows you to modify settings, boot from CDROM, tape, and other devices, you can configure the network interfaces without booting into the OS, have pretty logos and such, shunt the CLI to a serial port (ding ding ding!), and much much more, all from a little CLI. This computer is ten years old!

Of course, Sun is like Apple -- they don't have all of the crazy hardware that we deal with on the PC platform. This is why the PC had to wait so long to get all of this support.

When I spoke about LinuxBIOS, I did not necessarily mean to imply the GPL licensing. If there was a FreeBSD-BIOS, I would be just as happy. This would allow you to keep the source to yourself. The true utility in my mind is the CLI interface, versus a simple GUI. I am after the utility. BIOS has gotten better over the years, but there are still some things that I desire. This is especially true of serial port control IO, remote power and reset control, diagnostics, and a few other little things. Being able to do a 'cat /proc/pci' would make me dance.

Of course, if this LinuxBIOS or FreeBSD-BIOS ever came into being real, would they have to support booting from Microsoft's operating systems? Absolutely they would. Doing otherwise would be as bad as,... Microsoft.

I appreciate your positive competition attitude!

Take care

Good points...

[waltc]

Oh, I think Brian's answers were very truthful...have no complaints about his forthrightness.

But you have to admit the logic in all of this gets a little tangled...if it's as unrelated as you say, then why would any software maker think of writing a DRM application that uses TCPA? Apparently Brian thinks it would be possible to integrate if not suborn TCPA into a DRM software application. The idea, as well as its feasibility, has occurred to him and apparently he's concluded that the two are not so dissimilar as to rule out someone writing such a DRM software application. If he thought that I think he would have said so.

I think you missed my point--if TCPA isn't in a bios, and Palladium chips aren't on motherboards--then obviously nobody's going to write software that integrates either one or requires either one, as is currently the case today.

As far as TCPA goes I'm interested in what is meant by an "authenticated" boot. IMO, this could conceivably have several meanings and not strictly refer to the unspoiled state of the kernel.

It's surprising to me, but as detail oriented as you have to be to get things done in this industry, I've friends and acquaintances who really have trouble seeing connections and subtleties that to me, anyway, seem quite obvious. This is like a Pandora's box of sorts because what you start with, regardless of how inoffensive it may seem, and what you end up are likely to be very different things.

(Microsoft has, however, continued DRM support in WMP9, I note, and the fact that WinXP Product Activation is not popular has not dissuaded Microsoft's continued use of it--which they have now spread to a program as innocuous as Plus!. But that's really not the point here....)

You make a very good point, which perhaps you ought to consider a bit more--like you say, DRM is currently possible on existing hardware--just as is SSL (which I think seems to work pretty darn well.) Something like SSL does *not require* DRM or Palladium to function properly.

So whence cometh the need for Palladium, TCPA, and DRM...? (DRM is the obvious one, of course.) IMHO, the others will be used as system foundations for more "advanced" (more invasive) DRM software technology.

I used to laugh at the notions people had when they said that Microsoft wanted to take over the world. In fact, I still find it pretty darn funny. However, with Microsoft pushing technologies like these I do think Microsoft wants to take over my desktop--and yours--and everyone else's. I don't find that to be outlandish at all. Microsoft is pushing to be the traffic cop on my machine and seeking to install software and firmware initiatives so that Microsoft, not me, decides what and when I can run something on my computer. The problem with the whole Digital Rights initiative is that my Constitutional right to the ownership of private property (which I consider my computers to be as well as the software that resides on them) is usurped in favor of the *imagined rights* of corporations to invade my privacy to "help me" remain honest.

So why does an end user "need" TCPA or DRM or Palladium?

Re:Follow-up question

[SalesEngineer]

Don't like this? Buy/support/use software that does not constrain you. That's your option. Boycotting AMI or TCPA-enabled motherboards does not solve the problem; those manufacturers are responding to a demand from software developers and content owners. It is up to you to show those people that you do not want to be curtailed and restricted and denied at every juncture.

That's a good way to explain it. Perhaps I should have said that in the interview.

Brian Richardson - AMI

Re:Quite interesting...

[Hobophile]

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

If this is truly Microsoft's plan, then Linux users can rejoice: they are about to inflict a mortal wound on themselves.

How many businesses with any serious investment in technology would willingly upgrade to an operating system / platform which deliberately breaks compatibility with servers and systems they have spent so much time and effort getting to interact correctly in the first place?

It takes years for products to gather momentum in a corporate environment, particularly in this era of reduced IT spending. If Microsoft's new server release won't trust the Unix servers down the hall that have been working right for the past decade, the chances of that server release actually making it out of testing stages are virtually nonexistent. Only the most reckless businesses would voluntarily buy in to a scheme which made them utterly dependent on the whims of a convicted monopoly.

Would Microsoft love it if businesses went along and ignored any misgivings? Of course! But why should businesses do this? Linux is being taken increasingly seriously on small to mid-end servers, and Windows has never had much of a foothold on big iron machines. Such an obvious ploy to cement Microsoft's hold just would not work. Microsoft would have to proceed gradually, carefully putting in compatibility problems and introducing difficulties where none previously existed, until finally they created an environment in which only Microsoft products can be used.

But even then businesses would stop one point release before total incompatibility is achieved, and refuse to go further. Moreover, as compatibility broke at an increasing pace, businesses would slow their upgrade rate to glacial speeds. They'd have to, to give time for compatibility fixes and hacks to come out from Microsoft's competitors, as well as to test future releases for similar issues.

One might observe that the above has been Microsoft's strategy for a long time now, and it may well be that DRM-based efforts like Palladium represent that final push towards full incompatibility. But to believe that Microsoft will succeed fails to take into account the increasing (and deserved) mistrust Microsoft has earned for itself over the years.

Yo, cornholio

[jmorris42]

[flame]

Ever heard of Public Key Crypto? If they decide to ignore their prior promises of allowing the end user to load keys it is over. You won't need to crack the keys out of the module, the BIOS will happily SHOW them because they are the Public keys. The software vendors (i.e. M$) will have the Private keys. Think XBox.

[/flame]

Hardware RNG already exists today

[DakotaSandstone]

The Intel Firmware Hub, which contains the BIOS code on current Intel chipsets (the FLASH chip), already has a hardware RNG in it.

I don't think many apps are using this yet. Intel has a FAQ on this technology here, and they even have a Windows driver to support this.

Re:Real Engineers Don't Exist

[SalesEngineer]

Preach on brother!

I can agree that engineers are born, not made. That type of thing seems to run in my family. I'm doing this 'engineering' thing because I love it, not because it looks good on a resume. I saw way too many people wash out of engineering programs because they got into it for the wrong reasons.

BTW, I do have BSEE & MSEE degrees from Clemson. I taught one year as a part-time processor at Devry, and two years of lab at Clemson. I am in the 'sales' end because I happen to be more comfortable traveling and talking to customers than my counterparts (and most of those guys were 'born engineers').

Brian Richardson - AMI

MOV #0 != XOR != SUB

[clem.dickey]

It should be mentioned that, even leaving the effect on IP aside, the three instructions
MOV AX,#0
XOR AX,AX
SUB AX,AX
are not equivalent. MOV leaves the AF bit alone, SUB sets it to a defined value (0, I think in this case), and XOR leaves it undefined. Or don't assembly hackers notice condition bits these days?

One at a time...

[waltc]

What exactly do CD keys and registration requirements indicate if not a complete distrust of the end user's good intentions?

Actually, CD keys are *reasonable* and non-invasive steps a software company could and should take with its software. As the software companies are quite aware that a single valid CD key could indeed athenticate scads of bootleg copies, they are in fact trusting the end user to a very great extent, CD key or no.

Take the recent story on Quicken's Turbo Tax program, where Quicken removed your option to print returns on a computer other than the one the software was originally activated on. Do you think maybe Quicken did this because they don't trust you?

No, I think Quicken did this out of a fevered, greed-drenched imagination which caused them to hallucinate losing billions of $ to software piracy. Greed, not trust, is the issue here.

Why would Microsoft do this if they trusted their customers? Hint: they wouldn't.

Ironically, however, Microsoft has no trouble trusting corporations who buy as few as 5 licenses, since they do not have to jump through the product activation hoops at all. I'm sure you knew that. Microsoft simply did this to penalize the small user (who has little clout individually with the company because he doesn't buy thousands of licenses at a time) who has 2-3 machines at home and was installing a single legitimately purchased copy to both machines--and Microsoft wanted to double its money. Greed again (not necessarily intelligence for the long haul.)

Bottom line: software companies do not trust you.

True, no doubt. However it is more an issue of greed than I think it is one of trust. After all, Microsoft got very, very rich before the first copy of Product Activated WinXP was sold (all their "piracy estimates" notwithstanding.)

Don't like this? Buy/support/use software that does not constrain you. That's your option. Boycotting AMI or TCPA-enabled motherboards does not solve the problem; those manufacturers are responding to a demand from software developers and content owners.

What a load...;) There is no reason any bios company has to stop selling its non-TCPA builds. They can sell both, and the idea that they would have "no demand" for non-TCPA formats is ludicrous. After all, who is the ultimate customer of the bios company--hint: it's not the software developers, it's not the content owners--it's the *end users who buy the motherboards.* Was it the "content owners" which influenced bios companies to start making bios versions with all kinds of adjustable parameters, parameters that for years were excluded from the user CMOS interface (ram timings, voltage regulation, etc?) *chuckle* Hardly (snicker)

Companies large and small who forget who their actual cutomer base is will regret it, I predict, because their customers will go elsewhere. There's an old capitalist adage that businesses today would be well-advised to heed: the customer is always right. It would appear that some companies today are so confused they don't even know who their customers actually are--they think the middlemen they sell to are their customers. However, it's the needs and demands of the end user that shape the order of the middlemen companies. If the last guy in the chain loses his business (in this case the motherboard makers) then everybody upriver loses theirs, too. I shouldn't even have to say any of this it's so obvious.

Only someone who doesn't know what a bios does...

[waltc]

...would ask this question.

First of all, the modern x86 bioses are self-configuring and can be safely ignored if the end user wishes to do so. However, a bios offers *hardware configuration options* that I personally find invaluable and could not imagine doing without. Suppose that I want to adjust the motherboard voltage regulation and raise or lower the voltage the motherboard provides to the cpu, the ram, the AGP bus, I/O--etc? (Whether or not a person thinks this is "necessary" is utterly irrelevant *chuckle* so please don't go off on that silly tangent.) The fact is that these are the kinds of hardware configuration options, among many, many more, which a modern bios provides.

If you don't have a bios you are autoconfigured and the bios is still there--it's just hidden from you completely and you have no control over it whatever. This is progress? I think not.

Ten years ago on an Amiga 3000 I was booting a bios image to ram from hard drive and using the MMU of the 68030 to point the system to it--whoopee-doo--big deal *chuckle* It was maybe marginally quicker to change out the file as opposed to flashing a bios--but the priciple is exactly the same--and the bios is a lot less cumbersome than something like I used with the Amiga (temporarily as I went back to the standard bios after failing to discern a benefit--ram and HD space was very limited in those days--plus I wanted to use the 68030 MMU for other things.) I see no advantage to something like that at all (though I dearly loved my Amigas!)

PCs use a bios still because of the enormous hardware choices available in the x86 marketplace that do not exist for small, closed hardware companies like Apple, for instance. Sometimes it's very nice to go into the the bios and configure a piece of hardware you've installed as opposed to packing up the system and dropping it off at the dealer's and telling him to fix it--just because the system locks the end user out of some of the internals. OpenBoot wouldn't work well at all in the x86 desktop market (I don't think) because you have so very many more hardware choices than these other cpu markets support.

Re:They are scared......

[bobetov]

296 times bitten, 297 times shy, I guess.

that is apples and oranges

[Archfeld]

No system is secure if you have physical access.
Most people have mastered locking their doors, locking their servers is a totally different matter. None of the solutions provided deal with physical access, only logical...

A very good point, but one threat remains...

[Eric_Cartman_South_P]

...you had a VERY good point on the gaming example.

I would enjoy a "safe-spot" in my PC for things to run clean and safe and where computers can identify me when I want them to (Citibank, EA game servers, etc). But what will happen with this control VERY quickly will be bad enough to negate any and all good aspects.

>Believe it or not, such abusive "features" are unpopular and cause companies that employ them to lose market share.

True... EXCEPT for Microsoft. That's the threat. That's the worry. That is what will - despite my passion for free computing, free information, etc - turn every computer into an X-Box type device in 5-10 years. Don't envy X-Box users. When ALL computing is done on a closed PC, where opening the box will get us arrested, we'll remember the days back on Slashdot when all this was nothing more than wild paranoia.

I remember only a few years ago people joking around about being arrested for swapping songs. "Never gonna happen." was the general response.

Re:IBM and the Holocaust

[prowley]

Er, wouldn't caching Nazi checks help the Allied war effort by moving money from Nazi Germany to USA?

Re:Not quite true

[MrResistor]

A trusted machine is one that conforms to a certification process. You don't define the certification, the remote service requires it of you. So using your metaphor, the hammer that kills someone is not in your control, you just swing it as per instructions.

The point of my metaphor is that TPM is just a tool, like a hammer. It has beneficial uses and harmful uses, and which use it is put to is not up to the tool. In the event the TPM is used to lock out certain OSs it makes no sense to blame TPM or even TCPA, the blame rests squarly on the issuer of the certificate. Most likely that would be MS, but it could just as easily be RH as I attempted to point out.

I can change software, those tiny silicon transitors are a damn site harder. But yes I agree they could do the useful stuff in software - there is no need for this stuff.

You're right, there isn't strictly a need for this. However, it would be really useful to me if I could put really strong crypto (say 2048 bit) on an ssh connection to a server I'm responsible for without bringing that server, or my home computer, to it's knees processing the encryption algorythms. It would also be really nice if there were a way to limit what machines my server would accept connections from specific remote machines. Since I can't do that currently, I err on the side of caution and leave no possibility for remote administartion.

Please read the bills before Congress, particular the "DRM in all devices" bill. To be paranoid I have to *suspect* something that is not true, not *read* something that is true.

There are no bills before Congress. Congress is not currently in session, and any bills which were undecided upon at the close of the last session are now gone, and will have to be reintroduced to the next session, which is unlikely considering the backlash against the Hollings bill, the fact that Hollings is no longer in the same position of power he was in which would have enabled him to push the bill through comittee, and the fact that the RIAA has stated that it no longer seeks such legislation.Based on that evidence I think it's quite reasonable to say that the threat no longer exists, therefore you are paranoid.

That said, though, the statement that was in response to had nothing to do with DRM.

Re:Follow-up question

[Alsee]

Bottom line: software companies do not trust you.

Fine. But we are not talking about software companies. We are talking about MY COMPUTER. And my computer is suppossed to serve ME. It it MY agent, not some software company's agent. Why the hell should my computer prevent me from doing perfectly legal things like read my data or modify my data or copy my data? Hell, why should my computer even prevent me from doing something illegal?

The ONLY reason computers are going to include TCPA is because Microsoft is REQUIRING TCPA support for their next operating system.

-