Slashdot Mirror
Discuss BIOS and Palladium Issues With an AMIBIOS Rep
After this Slashdot discussion about the relationship between BIOS biggie American Megatrends Inc. (AMI) and Palladium appeared, we got an email from AMI sales engineer (and former Linux.com contributor) Brian Richardson, who wrote, "I am a bit concerned that the information you provided misled your readers into thinking AMI was promoting Palladium or taking some sort of anti-open-source stance. This might be due to the fact that TCPA was mistakenly equated to Palladium, or questioning how Linux would run on a TCPA-enabled system ... or by the horde of angry Slashdot readers telling us they would never buy an AMI product because we were forcing standards on them." Brian offered himself up as (his words) a "Slashdot interview victim" to clear things up.(Update by RM: And, says Brian, he's happy to answer other BIOS questions as well.) So ask, already, and let's get things cleared up. (Usual Slashdot interview rules.)
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.
d) What is a "sales engineer"? Is your job primarily public relations, or primarily engineering, or primarily product sales?
currently if you try to install vendor drivers on windows, the OS tells you things like "are you sure you want to use these untested third-party drivers, which will no doubt ruin your computer because you're a bad boy for not using windows." Can you assure us that linux, bsd, and all other "alternative" operating systems will be treated as _equals_ of microsoft products? Can you assure us that there will be no preferential treatment for any os, and that there won't be any "are you really sure?" messages?
What is the advantage to me, a Linux using consumer, to buying your product over those of your competitors?
You can use it to defeat the GPL.
Oh, for crying out loud.
The GPL was not, ever, ever, ever, meant to make it so buying software wasn't worthwhile. In fact, the situation outlined in the parent post is _an ideal business model_ for GPL'd software.
You keep all of the rights the GPL was designed to preserve (distributing and re-working code you buy), and there's still something worthwhile for buying the software.
Okay, now hear this! In the "Real World" you can't randomly pull things apart and ask for a refund. Computers are not different than other products. If I buy a box of tissues and only use half of them I can't return the other half for a refund.
If I buy a phone that has a caller id function but I don't subscribe to the service I can't pull the LCD and pry the caller id chips out and ask for a refund.
Damn, read the shit you type before submitting it and try to remember exactly when it was that you lost all semblence of sanity.
It plainly is anti open-source.
TPM has no benefit to end users. All it does is give Microsoft an argument to use with ISVs as to why they shouldn't develop products for open source platforms. They can say: "If you ever release your product for Linux, some people will disassemble it. But with our "trusted" OSes, you'll never have to worry about crackers, because we don't let our customers control their own machines".
It's a powerful argument. There may even be a few ISVs stupid enough to fall for it. (Most ISVs don't go out of business from cracks, they die when Microsoft itself uses its monopoly power to sieze the market the ISV developed.)
But it's all a moot point. Why shouldn't we be trying to nip this in the bud? Why shouldn't we be spreading the word to everyone we know that people who buy AMI will very soon have to accept whatever draconian "Clickthrough" is on the software package, giving up their legal rights for no consideration whatsoever?
In short, why shouldn't we be trying to drive AMI out of business?
Sounds like a plan to me.
Unless the BIOS has a provision of the owner of the machine to add keys to accept as legitimate signatures or disable the signature checking, having software I can change is no good. Unless there's some way for the end user to say, look I own the machine, and I'm technically competent to verify the software I trust, let me run it the source code is relatively useless.
If that mean's there's a dongle, switch or jumper that has to set up correctly, that's fine by me. Then RedHat and other major distributors can get there kernels certified and signed, and all of the other binaries out there. Then the masses can get trusted computing, and I can certify my own stuff as trusted.
Kirby
Just what problem is this trying to solve?
Why can't my computer be trusted?
Is this trying to fix a fundamental flaw in operating systems?
Will the next computer you personally buy implement these features?
Who will you give access to your machine (Microsoft, RIAA, MPAA, Homeland Security)?
When the thought police come to round up us 'Criminals' that will not give up our 'untrusted' systems will you be able to sleep at night?
SD
âoeWho knew something as harmless as willful ignorance could end up having real consequences?â
I was actually thinking of something along the lines of...
:o)
"The operating system about to be loaded does not have a valid security signature. As such it is not possible for the BIOS to prevent unsafe software from operating. Are you sure that you wish to continue loading this software."
But yours is just as good
Matt Thompson - Actuality - Insert product here.
Palladium and any other DRM-enabling doodad are products that are inherently designed to enable vendors who do not trust their customers to exercise some degree of control over how those customers use the vendors' products. At the same time, those vendors expect customers to trust that the use of DRM products will not result in side effects that may be detrimental to users' freedom to use legally obtained products as they see fit provided such use is within the law.
Since AMI appears to be taking the side of those vendors who feel they cannot trust their customers, why should we as customers trust AMI to create products that do not infringe upon our rights as customers? Why should we not take our business to vendors who are willing to trust that we will not do anything illegal with their products, instead of assuming up front that all customers have some sort of illegal intent?
Palladium claims to have the freedom to choose whether you want to connect to another palladium machine. This freedom is at an individual level, in the same was I can choose to use Abiword.
If Palladium achieves mass market how will my freedom not to use Palladium be possible? Will it be like having the Freedom to speak Esperanto?
--Giving to trolls for the benefit of us all
What I find most interesting is how Palladium is advertized as having features like letting content creators (e.g. a person sending you an e-mail) control what you can do with it (automatic deletion, no forwarding, no printing).
However, we never get a say in this, we never agree to any such "contract". If your company is producing a product as part of a system designed to disempower me in favor of a machine, does it really surprise you that I don't like it?
TCPA/Palladium has never been about how I, the end user can come in control of my machine, because I am already in total control (up to the limitations of my tools). TCPA can for me, at best, be a hardware version of a "sandbox", where I control what resources are availible to a given program. But such programs already exists in software and has no need for hardware backing.
Many people have compared TCPA to being a program running in Ring -1 (Ring 0 being the OS kernel). The only thing it can control in addition to what the OS already can control, is what runs in Ring 0. So why do you need to control what runs in Ring 0? Answer me that.
Because you can't trust me, isn't it?. Isn't that what it's all about? Having a trust chain that I can't break. So the content, and my machine can negoiate a deal, without me ever getting a say. So that they two can decide, regardsless of rights granted by law (like fair use and first sale), when, how, where and what I can see, hear, use and do. And you don't find that offensive?
Kjella
Live today, because you never know what tomorrow brings
Why is AMI doing this?
Do they think people want their OS to be able to lock them out of certain parts of their machine?
You see, I can't really see any application for TCPA / Palladium besides taking control away from the owner of a computer. Any of the other "security" features TCPA/Palladium provides can/have been easily implemented in software. The only application that requires BIOS/hardware level modifications, is one where you are trying to prevent the person who owns the computer from have full control over it.
Lately I've been beginning to notice that some companies have internal conflicts of interest that cause them to do stupid things, which are not what consumers want. (Stupid because, they loose money because consumers go elsewhere to get hardware that isn't crippled and any piracy that was going to happen still happens anyways.)
Sony, for example. Being both a hardware company and a media company, they seem to have an internal conflict of interest: To many RIAA/MPAA types CD/DVD burners are synonymous with piracy, this must lead to internal pressure on the hardware branch of the company to try and control what people can do with Sony hardware. Ex: It's rumored that Sony DVD burners can burn Xbox games but not PS2 games, Sony Discmans have often had sub-par CDR playing ability, Sony Minidisc recorders had an annoying copy protection flag that prevented you from making many digital copies of a minidisc.
This whole thing reminds me very much of the whole CPUID debacle. CPU manufacturer X starts putting unique ID numbers inside their CPU. They claim it will allow increased security for web transactions blah, blah, blah. The problem was there was not good reason why your average computer user would want a unique unchangable serial number for his computer. There was a tremendous potential for violation user's privacy and no good reason why they needed it in the first place. Why? A unique id could be implemented in software. The only reason to have it in hardware is to prevent the owner of the computer from changing
People didn't want them, and CPUIDs failed. Why does AMI think this is any different?
Life is too short to proofread.
That's it. It doesn't mean the software is secure. It does mean, that any joe user can't just run any old code they compile up. However, if they disable my ability to write shell scripts, they are screwed. SA's will not under any circumstance give up the ability to write quick little shell scripts. It'll never happen. They will vote with their wallet on that one.
So when a security hole is found in the cryptographic software, they won't be able to just download new binaries to trojan my system. However, they can still just follow the flaw they have found in all the time. They can still script up various badnesses. They will still be able to do all variety of badness to me. They just can't put a trojan'ed version of SSH on my machine to get my passwords. Instead they will script up ssh to run out of gdb, and write the passwords in the clear out of gdb, and run as per normal. Hiding what is going on will be difficult because root kits will be more difficult to install. Now all they have to do is uninstall, the binary once they have the appropriate pieces of information to authenticate to your machine. Now they just authenticate like a normal user. They are in, and can poke around all they want.
Signed binaries, only means your running binaries that you got from the vendor, that's it. It'll change how the cracks work, but it won't mean you don't get cracked. Trust me, given enough time and research a person can break into your machine using only the binaries RedHat or the Debian, or whatever vendor you use. I'll still be able to ship off your private data, I'll still be able to deface your web site. I'll still be able to compromise the CGI's. Oh wait, are you saying I've got to get the CGI's certified too. That'll never happen. Not in a million zillion years. Internal busniess processes move to fast to do that.
Signed binaries are no silver bullet. The best they can do is refuse to sign them until a full audit has happened. You don't need signed binaries for that, only install things that have had a full audit, and it's just as good security for the initial break-in. Once the intial break in happens, that's about monitoring for odd behavior, which again has nothing to do with signed binaries. Of course don't get too pissed off, if you don't get a shell with your new Linux distro.
On certain binaries, it would be nice to enforce the signatures on, like standard libraries, and the kernel. However, most people use tripwire to do that things like that. Maybe the ability for RPM's to carry around the signatures of the files they installed, then verify those signatures after the fact using read-only bootable media, with the RPM signatures on it.
Signed binaries are a good thing, but I don't see them as the end all be all of security. I don't see them as a useful tool, because they will just get in the way anyplace where you release binaries on a regular basis like I do where I work. If the signed binaries don't, they they aren't providing the security that I hear advertised for them.
Kirby
Now, I've been here a while, so when phrases like 'Usual interview rules apply' are tossed around, I understand the meaning.
But it occurs to me, there's probably many who don't. Why not have a page outlining the usual interview rules, and link to it when saying something like that?
Trusted operating systems can be a GREAT thing, it's merely a question of who controls the TORA [trusted operating root authority]. IMHO, if I control the TORA, it gives me power over my computer that wouldn't normally be possible, even with the various mandatory access control systems available across different platforms.
All of these are software, while the TCPA system's hardware-based system, if properly implemented, will be much more resistant to attack than any software-based solution.
If you've ever typed ctrl-alt-delete on a PC, you've used a 'trusted' feature, since it generates an interrupt which cannot be trapped by usermode software. Last time I checked, ctrl-alt-delete didn't present a clear and present danger to the operation of my computer -- merely my sanity.
We should focus on the real issues -- ownership of the TORA, as well as the distribution of simple methods to regain control of your computer's TORA through simple hardware hacking, much like the chipping of games consoles that still goes on fairly freely even in these dark days of DMCA, SSSCA, etc.
[standard disclaimers: not a hardware expert, info above is provided to the best of my knowledge but details may be incorrect...]
You've said that AMI has nothing to do with Palladium. Of course, that's true. One is a BIOS, and the other is an operating system made by another company. I have no issue with that.
However, we ALL know that Palladium will run in TCPA trusted mode, and TCPA functions will be active.
So here's the question (ahem):
If:
- I, as a Linux user, want to BUY the next version of Microsoft Office(tm) and run it on my Linux box under WINE, and:
- said version of Office requires that it be run on a trusted platform (i.e. it requires TCPA authentication),
WHAT WILL HAPPEN?
I'm sure you think this is a loaded question. It is, and it isn't. It is in the sense that I suspect what the answer will be, but I want to hear you answer it. It isn't, in the sense that this is a very serious issue and has enormous ramifications for the entire industry. You see, I think that TCPA+Palladium are really schemes for killing Linux by denying it the ability to run Microsoft applications. To that end, I don't consider you accomplices, but perhaps dupes. I ask you the above question in all seriousness, and I challenge you to prove me wrong.
Dear AMI BIOS Developer
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?
Thank you
The LinuxBIOS Home Page
http://www.acl.lanl.gov/linuxbios/
Slashdot | Linux BIOS
http://slashdot.org/articles/00/06/14/21102
# Jesse Molina
Will you opensource your BIOS so _we_ (so-called users of trusted BIOS) will be able to verify that your product doesn't harm our privacy or infridge our legally own rights (whichever country we come from) ? So that WE can trust YOU ?
> Unless there's some way for the end user to say, look I
> own the machine, and I'm technically competent to
> verify the software I trust, let me run it the
> source code is relatively useless.
You miss the point. The "trust" involved in the Trusted Computing Platform is not you trusting the software, it is content vendors (RIAA, MPAA, etc.) trusting that the software running on the computer won't let you do things they don't want you to do with the content you've bought from them.
That's why you will not be able to sign your own Linux kernel, for example. You might have added code to present an MP3 encoder in place of the audio card driver...
I have to wonder:
.DOC files to disk (thus making it impossible for 3rd party apps to read them) or, if a judge won't allow it, obfuscate the file format as much as possible and use patents+legal threats to protect them (once again, to lock out 3rd party apps). The point here is to make the new version of Office indispensible. It is important to note that, even if there is a lawsuit over this against Microsoft, it could take 8 years or so for it to come to a head, and the judge may side with MS in the end anyway.
.DOC file format.
.DOC later, the damage will have been done as the original .DOC formatting would have been damaged or lost.
- Introduce a new version of Office that introduces a new default file format. This is key, since in five years this file format would be ubiquitous, and the new version of Office would be required to read these files. Forget about sticking with Office 2k/XP. It isn't an option.
- Either use TCPA to encrypt the new
- Make this shiny new version of Office require a "trusted" platform (i.e. TCPA mode) to run with full functionality. You've just locked out Linux+WINE and made it very hard for vendors to sell or offer PC's without Windows, since they will not only be unable to run Office, they won't even be able to read the new
Voila! You've managed to use your Office software monopoly to preserve your OS monopoly. Switching to Linux+WINE a few years from now will make it impossible to read documents in the new Office, without perhaps exporting those documents to some other format (which would of course by design lose some vital formatting information). It makes it really hard for companies to switch, and dissuades people from migrating since they'll have to not only leave Office behind, but their Office documents as well. It also totally breaks the ability to share documents between the Linux and Windows worlds, without first changing to a (likely inferior) common format first. While you could probably convert back to the new
I wish I felt wrong about this, but I really believe that this is Microsoft's strategy to kill Linux. IMHO TCPA really is that dangerous--the whole thing about online music and movies is trivial by comparison (maybe it's a smoke screen).
Hear, hear.
This, IMO, is the core of Microsoft's evil plan. I will even dare to say that, as much as I am interested in theis AMI guy's answers, his company is not the one with for the plan --they are merely dragged into it, and I think they can't do squat about it. You will get no relief from him.
See, I really don't think AMI, or any BIOS manufacturer, will ever make one that plainly refuses to boot a bootloader because it lacks a signature from a CA it trusts. That opens a class vulnerability in the scheme (a single CA key is compromised and you lose the whole system). Also, it is just too bloody obvious to the EFF and the likes. And it is unnecessary for the evil plan to succeed. The BIOS will always boot whatever you ask it to boot. I'm ready to take a bet on that. That is not the problem.
The problem is, the BIOS will checksum the bootloader, and store that checksum in a safe place. Furthermore, the BIOS will provide, to any program that asks for it, be it "trusted" or not, that hash, cryptographically signed with the BIOS key (btw the only key that has to reside in the BIOS, and you can bet it will be hardcoded in the silicon, not overridable). From that point on, you can build "trusted" data delivery paths entirely in software.
Here's an example: Say, you want to watch a movie trailer. So your browser connects to Universal Pictures' server, which demands cryptographic proof that it can "trust" your computer. So your media player software obtains that proof from the OS, and delivers it. What the OS delivers the hash of the media player, signed with the OS key. To guarantee the integrity of the OS, it includes the OS' hash, signed by the bootloader. To guarantee the bootloader's integrity, it includes the bootloader's hash, signed by the BIOS. Voilá, you have crypto proof that your entire system is kosher. Universal's server has only to verify that the BIOS's key is trustable, which they can do by checking it against AMI, or whatever. If that key is compromised (e.g., you crack the key of your BIOS), then they have a problem with a single individual, not a class compromise.
But the point is: you have NO say on which keys are trustable or not, because the verifying is not done by you. It is done by Universal. The best you can do is not buy Universal.
But now imagine this thread's scenario: your ISP is the one that requires proof of "trustability" before letting you connect. You will have to either (1) make your ISP include your OS's key in their trust list, or (2) switch to Windows, or (3) switch to another ISP that does not require this. But you will have option (3) for just some time: just picture the logical progression of this. Extend to almost everything else: online banking, electronic commerce, fucking email! You have MS Internet[TM], what Bill has always wanted.
And you can bet it will be eagerly adopted by banks, media companies, and the likes, because it is the single scheme that allows them to "protect" their data against their own customers. And all the time we will be scratching our own heads, wondering how we let that happen, if we, after all, successfully coerced AMI into not making a BIOS that refuses to boot Linux.
This is pure, concentrated evil. I stand in awe of Microsoft. I'm very, very concerned about this.