Slashdot Mirror

AEton writes "Vnunet and others are reporting that Windows XP's Service Pack 1 has introduced a flaw into the operating system. Changes to memory handling code result in programs which often allocate memory (which is many of them) can take up to ten times longer than normal to start. Microsoft has acknowledged the problem in Q815411, and while a patch is available by request from Microsoft Product Services, it will not be widely released until Service Pack 2."

shmigget writes "The Register is reporting that Microsoft is throwing in the towel as far as NT 4 is concerned on the latest security flaw to affect Windows 2000, XP, and NT 4. They quote Microsoft as saying 'The architectural limitations of Windows NT 4.0 do not support the changes that would be required to remove this vulnerability.'" There still is a workaround for NT 4.0. Instead of patching the problem, it's advised to firewall off port 135 on an affected machine.

shmigget writes "The Register is reporting that Microsoft is throwing in the towel as far as NT 4 is concerned on the latest security flaw to affect Windows 2000, XP, and NT 4. They quote Microsoft as saying 'The architectural limitations of Windows NT 4.0 do not support the changes that would be required to remove this vulnerability.'" There still is a workaround for NT 4.0. Instead of patching the problem, it's advised to firewall off port 135 on an affected machine.

An anonymous reader writes "This article on newsforge takes a speculative look at what would have to happen if Microsoft decided to jump on the Open Source bandwagon (using Microsoft Project as the source of speculation). Amusing to think about, unlikely to happen."

jobugeek writes "Neowin has an article that shows the progression of Microsoft Windows from pre-windows 1.0 through the 2003 server. For those of you who have used all of them, I'm sorry."

rf0 writes "Well CERT is reporting a new overflow attack for IIS 5.0. Microsoft has released a bulletin. Better download those patches and fix another security hole." According to this CNET story, Microsoft says that this is already being exploited, at the very least since last Wednesday.

rf0 writes "Well CERT is reporting a new overflow attack for IIS 5.0. Microsoft has released a bulletin. Better download those patches and fix another security hole." According to this CNET story, Microsoft says that this is already being exploited, at the very least since last Wednesday.

rf0 writes "Well CERT is reporting a new overflow attack for IIS 5.0. Microsoft has released a bulletin. Better download those patches and fix another security hole." According to this CNET story, Microsoft says that this is already being exploited, at the very least since last Wednesday.

News for nerds writes "Eidos, maker of Tomb Raider, said it doesn't plan to make games for Xbox Live because Microsoft controls the system and manages subscriptions itself, leaving no incentive for a publisher to collaborate. Sony's approach is to sell just the equipment needed to connect to other's services, such as those run by game makers. Electronics Arts, which makes titles such as 2002 FIFA World Cup and NHL 2003 for the Xbox console, is also reluctant to join Microsoft's system, while supporting GameCube."

miguelk asks: "I'm helping a company (in Brazil) legalize their desktop operating system licenses by migrating to Linux on the desktop. WINE was tried but unfortunately did not work out for this particular case, so the idea is to install a Linux server with Win4Lin Terminal Server for 5 users, since the company has 5 Windows98 licenses to use for this purpose. All of the other 50+ desktops would be running Linux and would access these 5 licenses as needed, whenever they use a legacy Windows application. I have a question about the legal aspect of using the Windows desktop remotely. From all I have researched so far, this is legal since the actual Windows code will be installed on only one computer and will not be loaded in RAM on any other computer. I see it as equivalent to having 5 PCs on a desk and users walking up and using whatever PC happens to be available. I suspect that a direct, unprepared question to Microsoft is not a good idea, so I want to prepare first. Can anybody comment on this solution or share their experiences?"

SkyLeach asks: "I work for a medical company which wants to provide medical imaging solutions to their clients without having to install software on the clients' machines. We had been using Java, but this is becoming more and more difficult as the Microsoft VM becomes more outdated. According to this FAQ from Microsoft, java will receive no more support at all in the future. Without using a Windows-only solution such as ActiveX, what other options are there? Keep in mind that the only absolute requirement I have been given is that the physicians never be required to install anything on their computers: Sun's JVM and Microsoft .NET, included."

miladus writes "Microsoft has formed an academic Think Tank on Trustworthy Computing. The Academic Board is to advise Microsoft on 'security, privacy and reliability enhancements in[...] products and technologies so that Microsoft can obtain critical feedback on product and policy issues related to its Trustworthy Computing.' An interview with two members of the board is an interesting read, especially concerning the global implications of privacy. Of note, is the absence of DRM discussion. But DRM shows up as 'Rights Management Services' in the promised Widows Rights Management Services to be released later this year. it will deliver a 'platform-based approach to persistent policy rights for Web content and sensitive corporate documents of all types'"

miladus writes "Microsoft has formed an academic Think Tank on Trustworthy Computing. The Academic Board is to advise Microsoft on 'security, privacy and reliability enhancements in[...] products and technologies so that Microsoft can obtain critical feedback on product and policy issues related to its Trustworthy Computing.' An interview with two members of the board is an interesting read, especially concerning the global implications of privacy. Of note, is the absence of DRM discussion. But DRM shows up as 'Rights Management Services' in the promised Widows Rights Management Services to be released later this year. it will deliver a 'platform-based approach to persistent policy rights for Web content and sensitive corporate documents of all types'"

miladus writes "Microsoft has formed an academic Think Tank on Trustworthy Computing. The Academic Board is to advise Microsoft on 'security, privacy and reliability enhancements in[...] products and technologies so that Microsoft can obtain critical feedback on product and policy issues related to its Trustworthy Computing.' An interview with two members of the board is an interesting read, especially concerning the global implications of privacy. Of note, is the absence of DRM discussion. But DRM shows up as 'Rights Management Services' in the promised Widows Rights Management Services to be released later this year. it will deliver a 'platform-based approach to persistent policy rights for Web content and sensitive corporate documents of all types'"

miladus writes "Microsoft has formed an academic Think Tank on Trustworthy Computing. The Academic Board is to advise Microsoft on 'security, privacy and reliability enhancements in[...] products and technologies so that Microsoft can obtain critical feedback on product and policy issues related to its Trustworthy Computing.' An interview with two members of the board is an interesting read, especially concerning the global implications of privacy. Of note, is the absence of DRM discussion. But DRM shows up as 'Rights Management Services' in the promised Widows Rights Management Services to be released later this year. it will deliver a 'platform-based approach to persistent policy rights for Web content and sensitive corporate documents of all types'"

superpat writes "The Register reports that Microsoft licensed SQL Server technology from Timeline. Trouble is, they didn't license the tech for use by MS customers... After 3 1/2 years in the courts, the final judgement rules that MS SQL Server customers must pay Timeline patent royalties. The argument that Microsoft said it was OK is no defence, apparently." News.com.com.com has another story.

Anonymous Coward writes "The Inquirer reports: Microsoft contemplating charging for emails. 'MICROSOFT IS UNFOLDING something it calls the Penny Black project in which people sending emails might have to pay for the privilege.' Microsoft's explanation of the project is here: The Penny Black Project." There are a lot of things going on at Microsoft Research -- no guarantee that particular ones are going to be released in the real world. (And Microsoft isn't the only party interested in sender-pays, or at least sender-risks-paying systems.)

thasmudyan writes "Like probably many others I followed the recent link to Heise only to get a much more interesting story than the one about Mozilla/OpenOffice: Dave Stutz, an influencial guy at Microsoft, is resigning his position. He posted an open letter to his ex-employer and this rest of the world, explaining what MS is doing wrong in his opinion. I thought it made an interesting read, maybe Open Source projects should consider some of the key points (as MS seems to be too slow to adapt, it may be good time to move faster than 'the industry')." (Read this Slashdot post from 2001 to see an interesting interview with Stutz about "shared source" and .NET.)

jlowery writes "Robert X. Cringely seems to think so. Forget the hardware side: what does this mean to the future of Java? Will there be enough incentive to continue to develop the language for whoever acquires Sun? Or will Java developers have to swallow hard and submit to the whims of the dark overlord? Maybe I'll switch to Mac development, after all."

Vivek writes "BBC is reporting that Londoners will have to pay a 5 pound "Congestion Charge" starting Feb 17. According to this Times of India article, an Indian software firm called Mastek developed the .NET based software to implement the plan. In the absence of toll booths, it reportedly uses character recognition from 700 surveillance cameras to identify defaulting license plates." See our previous story for background.

superflex writes "CNet and others have articles today related to a story that appeared here a couple months ago regarding Acacia Media Technologies, who hold several U.S. and international patents that they claim give them exclusive rights to compressed digital media transmission technologies. The previous article, for the lazy among you, was an AskSlashdot about whether the askers' pr0n site should pay license fees to these guys. Seems that since then, they've moved on to some internet radio sites, and are actually getting fees out of them. Their claims haven't been challenged in court yet, but they appear very broad, possibly covering PPV on cable/satellite as well as internet-based streaming. One wonders if they might try going after one of the big boys soon."

An anonymous reader submits: "I use Microsoft's .NET Framework at my place of employment to create website applications for the general public. I have noticed a number of issues that can make web applications developed in .NET incompatible with Netscape and Mozilla." Read on below for his specific complaints; have you encountered the same incompatibilities, and can you suggest any workarounds?

"The most egregious issue I have run into is this bug in .NET framework, that can prevent posts (the facility for the web browser to send information to the server) in Netscape and Mozilla (all versions) because MS used Internet Explorer specific Javascript. Microsoft buried a mention of a hotfix addressing the bug shortly after the first Framework Service Pack. However, the latest Service Pack (SP2) came out several months later and it still does not contain the fix. The only way to obtain the hotfix is to contact Microsoft's paid support. ("In special cases, charges that are ordinarily incurred for support calls may be canceled if a Microsoft Support Professional determines that a specific update will resolve your problem" -- from the knowledgebase article). Keeping the patch as a hotfix that is not freely downloadable ensures that hosting providers will not have it installed.

A Unicode encoding issue in .NET can cause all fonts to display as squares instead of letters in Netscape 4. I am not saying that MS has to support NS4. I think the decision of whether or not to support Netscape 4 should be up to the developer, not Microsoft. MS describes a workaround in the knowledgebase article. (Anecdotally) all other web development environments I have seen allow proper code to work in Netscape without a workaround.

Standards-compliant websites utilizing most web-development platforms usually work fine in Netscape and Mozilla, even if the developer did not to test or develop for Netscape and/or Mozilla. However, Microsoft's .NET Framework inserts code and encodings into web applications that categorically break these browsers."

An anonymous reader submits: "I use Microsoft's .NET Framework at my place of employment to create website applications for the general public. I have noticed a number of issues that can make web applications developed in .NET incompatible with Netscape and Mozilla." Read on below for his specific complaints; have you encountered the same incompatibilities, and can you suggest any workarounds?

"The most egregious issue I have run into is this bug in .NET framework, that can prevent posts (the facility for the web browser to send information to the server) in Netscape and Mozilla (all versions) because MS used Internet Explorer specific Javascript. Microsoft buried a mention of a hotfix addressing the bug shortly after the first Framework Service Pack. However, the latest Service Pack (SP2) came out several months later and it still does not contain the fix. The only way to obtain the hotfix is to contact Microsoft's paid support. ("In special cases, charges that are ordinarily incurred for support calls may be canceled if a Microsoft Support Professional determines that a specific update will resolve your problem" -- from the knowledgebase article). Keeping the patch as a hotfix that is not freely downloadable ensures that hosting providers will not have it installed.

A Unicode encoding issue in .NET can cause all fonts to display as squares instead of letters in Netscape 4. I am not saying that MS has to support NS4. I think the decision of whether or not to support Netscape 4 should be up to the developer, not Microsoft. MS describes a workaround in the knowledgebase article. (Anecdotally) all other web development environments I have seen allow proper code to work in Netscape without a workaround.

Standards-compliant websites utilizing most web-development platforms usually work fine in Netscape and Mozilla, even if the developer did not to test or develop for Netscape and/or Mozilla. However, Microsoft's .NET Framework inserts code and encodings into web applications that categorically break these browsers."

An anonymous reader submits: "I use Microsoft's .NET Framework at my place of employment to create website applications for the general public. I have noticed a number of issues that can make web applications developed in .NET incompatible with Netscape and Mozilla." Read on below for his specific complaints; have you encountered the same incompatibilities, and can you suggest any workarounds?

"The most egregious issue I have run into is this bug in .NET framework, that can prevent posts (the facility for the web browser to send information to the server) in Netscape and Mozilla (all versions) because MS used Internet Explorer specific Javascript. Microsoft buried a mention of a hotfix addressing the bug shortly after the first Framework Service Pack. However, the latest Service Pack (SP2) came out several months later and it still does not contain the fix. The only way to obtain the hotfix is to contact Microsoft's paid support. ("In special cases, charges that are ordinarily incurred for support calls may be canceled if a Microsoft Support Professional determines that a specific update will resolve your problem" -- from the knowledgebase article). Keeping the patch as a hotfix that is not freely downloadable ensures that hosting providers will not have it installed.

A Unicode encoding issue in .NET can cause all fonts to display as squares instead of letters in Netscape 4. I am not saying that MS has to support NS4. I think the decision of whether or not to support Netscape 4 should be up to the developer, not Microsoft. MS describes a workaround in the knowledgebase article. (Anecdotally) all other web development environments I have seen allow proper code to work in Netscape without a workaround.

Standards-compliant websites utilizing most web-development platforms usually work fine in Netscape and Mozilla, even if the developer did not to test or develop for Netscape and/or Mozilla. However, Microsoft's .NET Framework inserts code and encodings into web applications that categorically break these browsers."

An anonymous reader submits: "I use Microsoft's .NET Framework at my place of employment to create website applications for the general public. I have noticed a number of issues that can make web applications developed in .NET incompatible with Netscape and Mozilla." Read on below for his specific complaints; have you encountered the same incompatibilities, and can you suggest any workarounds?

"The most egregious issue I have run into is this bug in .NET framework, that can prevent posts (the facility for the web browser to send information to the server) in Netscape and Mozilla (all versions) because MS used Internet Explorer specific Javascript. Microsoft buried a mention of a hotfix addressing the bug shortly after the first Framework Service Pack. However, the latest Service Pack (SP2) came out several months later and it still does not contain the fix. The only way to obtain the hotfix is to contact Microsoft's paid support. ("In special cases, charges that are ordinarily incurred for support calls may be canceled if a Microsoft Support Professional determines that a specific update will resolve your problem" -- from the knowledgebase article). Keeping the patch as a hotfix that is not freely downloadable ensures that hosting providers will not have it installed.

A Unicode encoding issue in .NET can cause all fonts to display as squares instead of letters in Netscape 4. I am not saying that MS has to support NS4. I think the decision of whether or not to support Netscape 4 should be up to the developer, not Microsoft. MS describes a workaround in the knowledgebase article. (Anecdotally) all other web development environments I have seen allow proper code to work in Netscape without a workaround.

Standards-compliant websites utilizing most web-development platforms usually work fine in Netscape and Mozilla, even if the developer did not to test or develop for Netscape and/or Mozilla. However, Microsoft's .NET Framework inserts code and encodings into web applications that categorically break these browsers."

MondoMor writes "Microsoft's forgot to patch some of its own servers to protect it from the months-old vulnerability exploited by the Slammer Worm, reports C|Net. Oops. Apparently Redmond's network was hit pretty hard. Just goes to show that no matter who you are, you'd better keep your apps patched." Update: 01/29 01:59 GMT by T : And if you're running systems which might be affected, take note: whitehorse writes "The Microsoft KB article for the Slammer patch found here has an incorrect URL for 'Download the patch' referring to KB Q316333 which is only a handle leak fix. The real patch may be found later in the article."

MondoMor writes "Microsoft's forgot to patch some of its own servers to protect it from the months-old vulnerability exploited by the Slammer Worm, reports C|Net. Oops. Apparently Redmond's network was hit pretty hard. Just goes to show that no matter who you are, you'd better keep your apps patched." Update: 01/29 01:59 GMT by T : And if you're running systems which might be affected, take note: whitehorse writes "The Microsoft KB article for the Slammer patch found here has an incorrect URL for 'Download the patch' referring to KB Q316333 which is only a handle leak fix. The real patch may be found later in the article."

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

Preface:

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

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

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

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

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

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

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

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

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

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

Now on to the questions ...

1) On the Exclusionary Uses of TCPA

by the-banker

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

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

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

1. What does TCPA do?

2. What does AMIBIOS have to do with TCPA?

3. What is the licensing structure?

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

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

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

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

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

TCPA adds a few elements to this security scheme:

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

2. A crypto-processor to speed key computations

3. Secure key storage on the system mainboard

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

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

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

The solutions support privacy principles in a number of ways:

1. The owner controls personalization.

2. The owner and user control the trust relationship.

3. Provides private object storage and digital signature capability.

4. Private personalization information is never exposed.

5. User keys are encrypted prior to transmission.

6. Supports multiple certificate authorities giving the user choice.

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

1. They are not global identifiers.

2. They are not personalized before user interaction.

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

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

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

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

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

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

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

18. Does the TCPA support open source systems?

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

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

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

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

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

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

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

2) Advantage

by TedCheshireAcad

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

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

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

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

You can break these down three major areas:

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

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

3. Support after the sale

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

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

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

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

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

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

3) Performance hit

by oliverthered

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

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

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

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

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

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

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

4) Why are BIOSes closed source?

by mcelrath

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

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

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

Just to get this out of the way:

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

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

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

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

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

There's three major components of any BIOS:

1. Core Routines

2. Silicon Support Routines

3. Board Specific Routines

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5) Technical Explanation of BIOS Settings

by doppleganger871

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

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

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

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

6) "Trusted" computer

by michael

A few related questions:

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

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

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

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

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

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

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

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

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

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

2. Say no

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

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

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

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

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

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

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

7) Hardware vendors

by cybermace5

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

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

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

8) Windows override

by Forkenhoppen

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

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

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

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

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

9) TCPA & Palladium

by ignipotentis

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

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

• Curtain Memory

• Control of Specification

• Intellectual Property (IP) Rights

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

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

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

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

10) What do you think about Linux BIOS?

by lanner

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

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

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

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

1. Cooperation with Microsoft, Novell & Linux

2. Perspective on LinuxBIOS

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

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

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

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

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

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

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

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

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

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

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

Preface:

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

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

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

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

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

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

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

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

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

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

Now on to the questions ...

1) On the Exclusionary Uses of TCPA

by the-banker

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

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

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

1. What does TCPA do?

2. What does AMIBIOS have to do with TCPA?

3. What is the licensing structure?

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

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

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

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

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

TCPA adds a few elements to this security scheme:

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

2. A crypto-processor to speed key computations

3. Secure key storage on the system mainboard

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

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

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

The solutions support privacy principles in a number of ways:

1. The owner controls personalization.

2. The owner and user control the trust relationship.

3. Provides private object storage and digital signature capability.

4. Private personalization information is never exposed.

5. User keys are encrypted prior to transmission.

6. Supports multiple certificate authorities giving the user choice.

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

1. They are not global identifiers.

2. They are not personalized before user interaction.

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

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

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

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

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

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

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

18. Does the TCPA support open source systems?

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

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

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

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

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

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

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

2) Advantage

by TedCheshireAcad

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

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

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

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

You can break these down three major areas:

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

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

3. Support after the sale

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

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

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

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

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

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

3) Performance hit

by oliverthered

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

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

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

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

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

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

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

4) Why are BIOSes closed source?

by mcelrath

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

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

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

Just to get this out of the way:

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

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

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

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

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

There's three major components of any BIOS:

1. Core Routines

2. Silicon Support Routines

3. Board Specific Routines

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5) Technical Explanation of BIOS Settings

by doppleganger871

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

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

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

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

6) "Trusted" computer

by michael

A few related questions:

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

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

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

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

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

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

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

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

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

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

2. Say no

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

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

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

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

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

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

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

7) Hardware vendors

by cybermace5

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

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

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

8) Windows override

by Forkenhoppen

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

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

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

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

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

9) TCPA & Palladium

by ignipotentis

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

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

• Curtain Memory

• Control of Specification

• Intellectual Property (IP) Rights

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

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

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

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

10) What do you think about Linux BIOS?

by lanner

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

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

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

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

1. Cooperation with Microsoft, Novell & Linux

2. Perspective on LinuxBIOS

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

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

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

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

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

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

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

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

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

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

why-not-now asks: "Recently there's been a lot of talk about open source/free software that enables your PC to act as a DVR, all-purpose media player, DVD player, CD player, MP3 player, etc... not to mention the ability to play all sorts of video games (if you know where to look). The idea of the set top MAME console is nice, but with a little TV/Audio out, a little know how and the right software, are we currently able to put together a free version of the big convergence media center others are trying to do?"

buro9 writes "Last week on the WMTalk list a heated debate raged on the rights of a consumer to rip their DVD's locally for more convenient playback later. As the debate started to border on a flameware an anonymous user managed to give the most clear description of Palladium and its implications to us as both users and developers."

buro9 writes "Last week on the WMTalk list a heated debate raged on the rights of a consumer to rip their DVD's locally for more convenient playback later. As the debate started to border on a flameware an anonymous user managed to give the most clear description of Palladium and its implications to us as both users and developers."

T-Kir writes "Microsoft has finally released DirectX 9... although we'll have to wait until the games that fully exploit it are released, at least those with high end cards (aka Radeon 9700+) will be able to unlock more of the advanced features. Now all we have to wait for is OpenGL 2.0!"

mypenwry writes "Foundstone, a Mission Viejo, CA security services company, is reporting several vulnerabilities that would allow malicious code embedded in MP3 and WMA files to be executed via WinXP and WinAmp. WinAmp versions 2.81 and 3.0 are vulnerable to buffer overflows via certain long ID3v2 tags when MP3 files are loaded. More troubling is the WinXP vulnerability: A buffer overflow exists in Explorer's automatic reading of MP3 or WMA (Windows Media Audio) file attributes in Windows XP. An attacker could create a malicious MP3 or WMA file, that if placed in an accessed folder on a Windows XP system, would compromise the system and allow for remote code execution. The MP3 does not need to be played, it simply needs to be stored in a folder that is browsed to, such as an MP3 download folder, the desktop, or a NetBIOS share. This vulnerability is also exploitable via Internet Explorer by loading a malicious web site. Explorer automatically reads file attributes regardless of whether or not the user actually highlights, clicks on, reads, or opens the file. Windows XP's Explorer will overflow if corrupted attributes exist within the MP3 or WMA file. Microsoft has issued a fix for this vulnerability. Nullsoft has posted fixed version of WinAmp 2.81 and 3.0 on their web site."

lastberserker writes "Call them all you want - generics, parametrized types, thingamagic mumbojumbo - but (tada!) Java gets templates in 1.5 release. Nice landing after 5+ years of dancing around a bush. Competition is good, pardon my pun."

I've heard a lot of people describe Richard Stallman as "unreasonable." I find Stallman instead to be one of the most persistently, relentlessly reasonable people whose thoughts I've ever encountered. Stallman may be a dogmatist, but the dogma is sincere and his own, not borrowed. A new book from the GNU Press called Free Software, Free Society collects several of his essays (and some other material) into one slim book. Stallman's essays document what his actions (as a programmer and through projects like GNU) have demonstrated concretely -- that the software future can be one primarily of rigorously open and freely, explicitly shareable code: a nightmare of control is not the only option. Free software enthusiasts might find little actually new: Those readers are probably already aware that control exercised through hidden, inaccessible bits is becoming more odious, more ubiquitous and more invisible. This makes the book worth reading especially to people who are currently not interested in the distribution and disclosure of software's source code. Unless you can completely disentangle the future of society from the future of software, this should concern you. Free Software, Free Society author Richard Stallman pages 220 publisher GNU Press rating 9 reviewer timothy ISBN 18822114981 summary Philosophy and practicality don't have to clash; this book makes the case that software can be open, and why it should be.

What's between the covers Free Software, Free Society is divided into four sections:

• One: The GNU Project and Free Software (10 chapters)
• Two: Copyright, Copyleft, and Patents (6 chapters)
• Three: Freedom, Society and Software (5 chapters)
• Four: The Licenses

Despite the division into chapters, the book's content does not conform to a single straight line, so I will deal with the chapters I mention out of the order in which they appear.

The book starts off on a good note. Key to understanding nearly everything in the book is a basic understanding of what source code is. Since Stallman's usual audiences don't need to have this explained, Richard E. Buckman and book editor Joshua Gay provide a three-page introduction ("A Note on Software") which is as good and concise an explanation as I've ever seen of the meaning of "source code," "compiler," "assembler," "machine code" and "operating system." Without quibbling over details that space has made them gloss over, this section is a good mental boot camp for anyone reading the book with no programming knowledge at all.

This note is followed by a topic guide which walks a prospective reader through the contents of the book better than a table of contents can, pointing out what concepts are dealt with in the book's chapters, a sort of micro-index. (And in a book this brief, it helps make up for the lack of a more thorough index.)

Lawrence Lessig's introduction largely repeats what Lessig has said in the past about the openness of software. One paragraph in particular sums up one of my favorite analogies when it comes to Free software, and one which I think translates well to those familiar with other fields, like art and architecture:

"... Law firms have enough incentive to produce great briefs even though the stuff they build can be taken and copied by someone else. The lawyer is a craftsman; his or her product is public. Yet the crafting is not charity. Lawyers get paid; the public doesn't demand such work without price. Instead this economy flourishes, with later work added to the earlier."

Old hat, new hat.

Those familiar with Richard Stallman will no doubt recognize at least some of these essays, or at least their cores, because of the persistence with which Stallman has spread the word of the origins and underlying philosophies of the GNU project and the Free Software Foundation. The first chapters of the book may bore readers who have heard dozens of times the story of Stallman's experiences with the Incompatible Timesharing System (ITS) in the MIT AI lab, the dissolution of the software-sharing society there, and how it directly led to his quest for a complete Free operating system. Stallman is an engaging writer, though, and I found myself enjoying it even though I have heard the story several times before.

The chapter in this section most likely to trouble those set in conventional thinking when it comes to software is Chapter 4, "Why Software Should Not Have Owners."

Despite the title, the book does not consist entirely of essays; it also includes a transcript of Stallman's speech at NYU in May of 2001, which shows how consistent Stallman's speaking is with his writing style. Some people have derided Stallman (and the FSF) as too academic, removed from the realities of normal computer users and the business world which right now implicitly favors non-Free software, so it's interesting to note the context of that speech -- it was a direct, welcome reaction to the prodding of Microsoft Vice President Craig Mundie's speech on the same campus earlier the same month, in which Mundie casually referred to the "viral aspect" of the GPL, and declared that Free software "puts at risk the continued vitality of the independent software sector."

There's also Stallman's short story "The Right to Read" and even (Chapter 10) the text and score of the Free Software Song. 'The Right to Read" may be the part of the book most appropriate for reprinting in tract form to leave around public libraries: this is a story, not quite hypothetical enough, about a future where every time a book is read, it must be unlocked with a password and authorized by those who hold the strings of copyright -- and sharing books is prohibited. Replace "books" with "e-books" and the story becomes less an allegory as a description of current reality.

Just as current are Chapters 12 ("Misinterpreting Copyright -- A Series of Errors") and 16 ("The Danger of Software Patents"). Stallman's arguments here, despite his protests that practicality is secondary to ethical interests, are eminently practical and should be read by everyone whose work touches either copyright or patents. And contrary to disparagement sometimes heaped on the Free software movement, he does not dismiss either of these in toto -- he simply points out forcefully ways in which these protections can be dangerously perverted.

Some of Free Software, Free Society's contents may strike readers (whatever their level of interest) as needlessly pedantic. I'm thinking here specifically of Chapter 21, "Words to Avoid," which lists 14 words and phrases Stallman discourages in the context of Free software as he defines it. On second glance, I think even this chapter is well suited to the book, since the reasoning presented for his objections to each word on this list (a paragraph or two apiece) will be most informative to people not already steeped in the lore and leanings of the Free Software movement. Some of these (I'll tease by saying that the entry for "content" is my favorite) squeeze in some humor as well.

Stallman's philosophy is what drives his attachment to Free software, but this book is not just a collection of harangues -- there's a great deal of practical advice as well.

Chapter 8, "Selling Free Software" is an essay found in earlier form on the GNU website, which in a few hundred words obliterates a persistent myth about Free software -- that it can't be sold or can't make its sellers a profit. Stallman emphasizes the differences that the GPL has on distribution terms, but lays out the terms clearly:

"Except for one special situation*, The GNU General Public License (GNU GPL) has no requirements about how much you can charge for distributing a copy of free software. You can charge nothing, a penny, a dollar, or a billion dollars. It's up to you, and the marketplace, so don't complain to us if nobody wants to pay a billion dollars for a copy."

Helpfully, that older chapter is preceded by one written earlier this year, "Releasing Free Software if You Work at a University." This is a particularly short chapter -- it takes up only two pages -- but the brevity is to Stallman's credit. I would like to see many more case studies beyond the single example presented (a GNU Ada compiler developed at NYU with Air Force funding, with a contract that specified its source code would be donated to the FSF) but these would probably be better in a book with a narrower scope. By not dwelling on unneeded specifics, Stallman has saved space to explain arguments and tactics which may be useful in persuading your school to endorse a Free software license. I also learned in this chapter that "The University of Texas has a policy that, by default, all software developed there is released as free software under the GNU General Public License." (Can anyone tell me more schools where this is true?)

The practical upshot of a philosophical book. Free Software, Free Society is not a book for casual reading, and has no thrills, cliffhangers or suspense -- unless you apply the thoughts within to current, real situations, in which case you can probably find more excitement than you might care for. When Stallman wrote "The Right to Read," no one had yet been arrested for making eBooks accessible or copyable. This book is intentionally didactic and persuasive.

Your library (local or school) should carry a copy of this book because it is distillation of ideas that are philosophically important but by no means abstract. And if the libraries available to you don't carry it, I suggest filling out a book request form -- which you may be able to do right from your computer. (Here are two online examples from Yale and New York City's branch libraries.) Likewise for (as appropriate) your school's computer science department, law school and business school. It would also make a nice gift to your Congressional representatives, since many of them seem to have forgotten that preserving a free society supposed to be their highest aim.

This is a book worth buying, reading, and passing on.

* That exception is when source code is not physically included with binaries; the source code must then be available upon request from the binaries' provider.

You can purchase Free Software, Free Society directly from the GNU Press site. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

tusixoh writes "In the case of Sun Microsystems anti-trust suit against Microsoft (who claims Sun just wants a free ride on their OS), U.S. District Judge J. Frederick Motz, who is hearing the case, has suggested that forcing them to include Sun's Java software in the Windows operating systems posed as an "attractive" solution. Microsoft had previously dropped Java when Windows XP was released, but reversed their decision and claimed they would start including Java in a Windows XP update until 2004. CNN has the article." Update: 12/04 04:57 GMT by T : Read below for a more complete summary of the Sun vs. Microsoft Java dispute.

torre writes "Well, there at it again. Sun has now begun its private litigation against Microsoft charging some pretty serious stuff. As we all know it has been widely reported that Sun looks to seek to force Microsoft bundle its java plug-in with their OS.

For a quick recap Sun sued Microsoft to stop shipping java since they had violated their licensing agreement. Sun won, got some money, and Microsoft got upto 7 years to continue shipping their outdated version. Microsoft recently decided that in XP they shouldn't ship their mangled version of java and Sun cried fowl demanding that they ship their plugin.

Now, what hasn't been reported in detail is the allegations that Sun has charged against Microsoft. In brief, they charge that
1) Microsoft has a monopoly in the OS, Web browser, and Office productivity markets
2) Is engaged in illegally tying

a. IE to windows
b. Their workgroup software to their OS
c. IIS to their workgroup server
d. .net to their OS's
e. Active directory to both OS and workgroup OS and to Exchange
f. Exchange server to Office

3) Entering into illegal exclusive deals
4) Unreasonably restrained trade
5) Infringement on copyright
6) Engaged in unfair competition

In their settlement they look for and I'll quote " Preliminary injunctions prior to trial requiring Microsoft to:

Distribute Sun's current, binary implementation of Java Plug-in as part of Windows XP and Internet Explorer.
Stop the unlicensed distribution of Microsoft's Virtual Machine Java through separate web downloads, instead of incorporating within Windows XP and Internet Explorer, in accordance with Jan. 23, 2001 settlement agreement.

The preliminary injunction hearing is scheduled for December 3 - 5, 2002 at the U.S. District Court for the District of Maryland in Baltimore, Maryland. Permanent injunction requiring Microsoft to:

Distribute Sun's current Java Plug-In
Stop unlicensed distribution of Sun's Java code
Disclose and license proprietary interfaces, protocols and formats.
Unbundle tied products like Internet Explorer, IIS, Active Directory, Exchange, Windows server and .NET framework"

All of this claiming that they've harmed java, the Java programming community and intimately Sun's shareholders. Now as the court battle begins its seems that sun has to prove that they are not looking unfair advantage. This seems to be a big issue as it would seem that they could achieve the same level of distribution by merely dropping four million with OEMs..."

Biedermann writes "This is not exactly hot news, just a quick reminder to count the last days: A table in this article tells us that MS-DOS (as well as Windows 3.x, Windows 95 and NT 3.5x) reach their "End of Life" (as defined by Microsoft) on December 31, 2002. Come on, even if you loathed them, they were good for jokes at least."

SunPin asks: "I'm a writer that is 99% dependent, due to fine-motor disabilities, on voice dictation. I've been a dictation user since 1990. My preference is 'discrete' speech because of very low resource consumption and its effectively infinite flexibility. Over the years, my computer use has de-evolved to programming, FTP, email (Mozilla), word processing (OpenOffice) and Ricochet. Drop the game and there's nothing that I shouldn't be allowed to do on the go. The problem is that I can't. Back in 1990, the requirements for IBM VoiceType were: DOS, 8MB RAM, 10MB of drive space with one of those new-fangled scorching 386-16MHz processors... not exactly demanding by today's standards and, unless I'm outright wrong, not demanding by today's PDA standards. Why hasn't it occurred yet?"

"In the disability offices of the hundreds of universities across the US, such software would be a major money saver because not all students need a high-powered laptop. While natural speech is great from a marketing perspective, it is simply impractical for general use and cannot adapt to mildly noisy environments. IBM, L & H and Microsoft have all given me the run-around. IBM refused to entertain the possibility. L & H is on life support, in a deep coma. Only Microsoft had a remotely positive response saying that they were testing natural recognition in Mandarin Chinese in their Beijing research office. Does anyone believe in keeping it simple, anymore?"

DrEspenA writes "Salon has an interesting article on the competition for the mobile phone browser market. Ostensibly the article is about Microsoft's efforts to dominate the market, but the key protagonist is really Opera Software, which may be gaining the (initial) upper hand simply because they are not Microsoft. Good discussion of whether standards and familiarity really is necessary in the mobile browser market."

BenBenBen writes "According to a whitepaper found on "a fairly insecure server", UNIX not only is more reliable and easier to maintain than Windows (2000 in this case), it's cheaper too. These shock results are reported on both The Register and (the source) Security Office."

gmuslera writes "Not was enough that recent vulnerability in IE that can run any program in an unpatched windows system. Now there is another related to an ActiveX control that can make IE and IIS to run any code in the system. The Microsoft solution? kill the related ActiveX control and replace it with a safe one. The Microsoft problem? As this control is Microsoft signed, any site can require it, upload it and replace the "good" one with the vulnerable one. The final recomendation from Microsoft? Don't trust/run ActiveX controls signed by Microsoft." Gimble points to the appropriate locations on Microsoft's website: "Another buffer overrun (that allows arbitrary code to be run) has been admitted to by MS, and it affects IIS and IE on clients (but not on XP), and they have a patch available here Security Hotfix for Q329414. The kicker is that a patched system can be rendered vulnerable again by a hostile web site or HTML email. The 'solution' from MS in Microsoft Security Bulletin MS02-065 recommends that you remove MS from the list of Trusted Publishers."

gmuslera writes "Not was enough that recent vulnerability in IE that can run any program in an unpatched windows system. Now there is another related to an ActiveX control that can make IE and IIS to run any code in the system. The Microsoft solution? kill the related ActiveX control and replace it with a safe one. The Microsoft problem? As this control is Microsoft signed, any site can require it, upload it and replace the "good" one with the vulnerable one. The final recomendation from Microsoft? Don't trust/run ActiveX controls signed by Microsoft." Gimble points to the appropriate locations on Microsoft's website: "Another buffer overrun (that allows arbitrary code to be run) has been admitted to by MS, and it affects IIS and IE on clients (but not on XP), and they have a patch available here Security Hotfix for Q329414. The kicker is that a patched system can be rendered vulnerable again by a hostile web site or HTML email. The 'solution' from MS in Microsoft Security Bulletin MS02-065 recommends that you remove MS from the list of Trusted Publishers."

abhikhurana writes " Internetnews is reporting that Microsoft has launched Xbox Live broadband gaming service. To access Microsoft's service, Xbox gamers have to buy a $49.99 starter kit, which includes 12 month's worth of access to the Xbox Live service and a headset kit for voice communications. Microsoft said that about 16 games with online play capabilities will be available by the end of the year. So has anyone already tried it? If so, what do you think about it?"

Albanach writes "The BBC News are reporting in this story that Microsoft's Home Entertainment Division has filed a submission to the Securities and Exchange Commission reporting a loss of $177 million for the three months to 30 September 2002. The loss comes on revenues of $505m for the division that manufactures the Xbox games console. Microsoft are said to be prepared to spend $2 billion funding Xbox live over the next five years, suggesting it will be some time before the home entertainment division break into the black."

Slashback with more unintentionally odd clip art in Microsoft work for fire, Las Vegas monorail progress, the resolution of SonicBlue and TiVo's legal dispute, and more. Read on for the details.

Well, while we were switching things around here at the ad agency ... An anonymous reader writes "While looking around on Microsoft's site checking out the new Tablet PCs I noticed something very out of Place. In one of their Flash Demos for the Tablet PC there is an Apple Powerbook 1400! To see it for yourself, the flash is located here (then "Tablet PC Overview Demo," then "Tablet PC," then "Powerful") The first computer is really that Powerbook! Pic here."

What about to the legal brothels? Sacarino writes "Back in April, Slashdot ran a story about the Monorail project Las Vegas was embarking upon. It would appear that things are progressing nicely. "It's ugly" critics will be put to shame, the designers did a great job of making it non-obtrusive. (if that's possible in Vegas) Soon you too will pile off the airplane, trudge onto the monorail, then run into the casino to spend that money....ahh, Vegas."

Out of court, out of mind. Enry writes "SONICblue and TiVo have dropped the patent infringement lawsuits they filed against each other. The press release reads: "We believe our energies are better spent expanding the market for Digital Video Recorders (DVRs) rather than fighting each other. Both sides believe in the merits of their respective positions, but the overall success of the DVR category is what is most important to the companies at this time." Take that, AdAge!"

Sounds like a nice way to watch movies. For those intrigued by a 640x480, QWERTY-keyboard color, clamshell-case PDA as embodied by the Zaurus 5600, patrickoehlinger writes "Just found news and pictures about the new Sharp Zaurus SL-C700 released in Japan. With a 640 x 480 pixel display, a small design and a great keyboard! Golem.de has a article with pictures, but it's in German."

Would the BBC spy on you? An anonymous reader writes "The previous discussion on RedSheriff on slashdot was extremely confusing as well as mostly off-topic. The fact is, the BBC is downloading spyware to your machine when you surf their site. Very disappointing and surprising. I suggest e-mailing them to let them know what you think. The problem and remedies are covered in Google groups: "

An anonymous reader submits: "On the heels of several other releases, the W3C has released XForms as a Candidate Recommendation. Coverage here and here. XForms is the way-better version of HTML forms -- it's XML-based and includes built-in client-side validation and calculations, without scripting. It is expected to replace old-fashioned HTML forms in XHTML 2.0. It's also being viewed by many as the standards-based alternative to Microsoft's XDocs. Now's your chance to try it out and submit your comments, before the official Recommendation comes out in a few months."

Steve G Swine writes "That mammoth ECMA standards implementation project now builds on Mac OS X 10.2. The license is a little corporate, but actually seems clearer and less strident than some other licenses. Go, build, learn, have fun!"

Steve G Swine writes "That mammoth ECMA standards implementation project now builds on Mac OS X 10.2. The license is a little corporate, but actually seems clearer and less strident than some other licenses. Go, build, learn, have fun!"

nileshch asks: "A very important development in recent times with regards to website users' privacy has happened with the W3C introducing the Platform for Privacy Preferences(P3P). P3P allows websites to create and maintain XML-based privacy policies for the entire website or sub sections of the site. These machine readable policies document what information is collected from users and how it is going to be used. Today, a few browsers like Mozilla/Netscape & Internet Explorer are committed to giving support for P3P (Mozilla here, IE here) . Although that support seems only skin-deep. I also find very few big sites adopting P3P seriously. Isn't it like the classic chicken-and-egg situation? Websites wait for full P3P support on browsers, browsers go slow on development because there isn't much feature demand happening on this front. Do you have P3P policies for your website? If not, what stops you from creating one? We all create hoopla over tiny privacy issues, user profiling and doubleclick.net . Then why isn't there much enthusiasm for P3P support in browsers?"