This isn't exactly on topic, but I thought it was interesting nonetheless. So with a mobo that would support this BIOS, could we still pop out the Phoenix BIOS and pop in a LinuxBIOS or FreeBIOS?
http://www.extremetech.com/article2/0,3973,1237519,00.asp
BIOS maker Phoenix Technologies said it is currently shopping a digital-rights-enabled BIOS system to top PC OEMs, the most aggressive use of DRM technology to date.
Phoenix executives said Wednesday that they've developed a prototype version of its Core Management Environment (cME) using DRM technology in conjunction with Orbid Corp., a DRM technology provider. The software was designed to assist content providers to authenticate and track software moving from PC to PC.
On Thu, Sep 04, 2003 at 08:16:13AM -0700, Dale Harris wrote:
This isn't exactly on topic, but I thought it was interesting nonetheless. So with a mobo that would support this BIOS, could we still pop out the Phoenix BIOS and pop in a LinuxBIOS or FreeBIOS? http://www.extremetech.com/article2/0,3973,1237519,00.asp
(cut)
Not a chance in hell I guess. I was lucky to be able to join a talk about the upcoming new and improved secure windows with an extra vertical separation between left and right, where right is the old kernel space, with on top the old user space. Basicly they stop trusting kernel space.
basic services | old user ------------------------------------- NEXUS | old kernel
The nexus would be some micro kernel with supposedly code that is open to peer review (no word about the license).
All circuits on board would be encrypted, all the way to the graphics card (eg. to securely display sensitive information, no word about attacks which use the radiation of the screen as the basis though :)
The BIOS will check the Nexus and its signature and then load it, the nexus then fires the operating system (only windows up till now I guess).
MS was having active connections with mobo manufacturers, but of course they need time for anything like this (imagine the changes required to the hardware ...). My guess is that this is one of the prime reasons for the delay of Longhorn to 2005. It will be presented as the saviour of the content industry. I wouldn't be surprised if lobbying towards people only being allowed to use trusted PCs would start at around the same time. This is all speculation though.
Not sure if the Phoenix DRM BIOS fits into this picture.
v
Vincent Touquet wrote:
Not sure if the Phoenix DRM BIOS fits into this picture.
I suspect the Xbox is your clue... MS has had plenty of practice on encrypting the bios and locking out foreign app sw, and the xboxlinux group has been the test foil (although in the short run they are on top right now).
-Steve
Steve Gehlbach steve@nexpath.com writes:
Vincent Touquet wrote:
Not sure if the Phoenix DRM BIOS fits into this picture.
I suspect the Xbox is your clue... MS has had plenty of practice on encrypting the bios and locking out foreign app sw, and the xboxlinux group has been the test foil (although in the short run they are on top right now).
Boards don't sell if people won't buy them.
Eric
Eric W. Biederman wrote:
Steve Gehlbach steve@nexpath.com writes:
Vincent Touquet wrote:
Not sure if the Phoenix DRM BIOS fits into this picture.
I suspect the Xbox is your clue... MS has had plenty of practice on encrypting the bios and locking out foreign app sw, and the xboxlinux group has been the test foil (although in the short run they are on top right now).
Boards don't sell if people won't buy them.
Eric
I think people will buy if them if they are cheap enough. Imagine a mobo that only runs Win2k and sells (in a system) for cost, like the Xbox, where the revenue stream is the license fees for software, shared by the mfr and distributor.
The implications for linuxbios is that any reverse engineering to determine chip function is a violation of DMCA (because of the encryption), with stiff penalties. The reverse engineering exception may apply, but this DMCA exeception does not allow public dissemination of the information that is discovered (see Judge Kaplan's opinion in the DeCSS case). Via is already making it hard enough without encryption.
My worry is that this is prong two of a two prong aproach to slowing Linux down by MS. The other being the SCO license FUD.
-Steve
OK, it is true, there is an issue.
Consider this, however. There are now several vendors actively supporting LinuxBIOS: AMD, Tyan, ASUS, and a few I can name in another few days. There's money in LinuxBIOS.
Market forces are starting to sway our way. So don't worry too much.
ron
ron minnich wrote:
OK, it is true, there is an issue.
Consider this, however. There are now several vendors actively supporting LinuxBIOS: AMD, Tyan, ASUS, and a few I can name in another few days. There's money in LinuxBIOS.
Market forces are starting to sway our way. So don't worry too much.
Cool, love to see the name "Via" in that list someday.
-Steve
On Thu, 4 Sep 2003, Steve Gehlbach wrote:
Cool, love to see the name "Via" in that list someday.
VIA was extremely helpful with the EIPA issues, from what I understand.
We're getting there.
Also, be aware that the much of the world is less than happy with the idea of any one vendor controlling their software, much less their PC architecture. Anything that pushes to unity of control (such as DRM in the BIOS) will probably be poorly received.
ron
ron minnich wrote:
On Thu, 4 Sep 2003, Steve Gehlbach wrote:
Cool, love to see the name "Via" in that list someday.
VIA was extremely helpful with the EIPA issues, from what I understand.
Well actually, my beef is about not releasing datasheets. AFAIK we still do not have the direct register VGA working for EPIA-800, due to some hidden enable of some kind or another. And in this case, we have the datasheet, so it probably undocumented. But the other EPIAs, with the CLE266, the datasheet is not available to my knowledge.
-Steve
On Thu, 4 Sep 2003, Steve Gehlbach wrote:
Well actually, my beef is about not releasing datasheets. AFAIK we still do not have the direct register VGA working for EPIA-800, due to some hidden enable of some kind or another. And in this case, we have the datasheet, so it probably undocumented. But the other EPIAs, with the CLE266, the datasheet is not available to my knowledge.
as of today, David Hendriks built a BIOS for EPIA with SONE's freebios source tree, and the VGA is working fine. I think there's literally one bit left to find.
We are now trying to see why our latest CVS does not work, but we're very close with this. It's going to turn into a diff -r.
Hang in there.
ron p.s. Next we try to get via-rhine to boot the node in less than 3 minutes ...
ron minnich wrote:
as of today, David Hendriks built a BIOS for EPIA with SONE's freebios source tree, and the VGA is working fine. I think there's literally one bit left to find.
I'd love to know which bit; but of course that is typical VGA, one bit off or 100 bits off, same result, black screen. I'll admit I never gave it a really hard effort, I just didn't have the time right now.
-Steve
On Thu, Sep 04, 2003 at 09:32:04PM -0700, Steve Gehlbach wrote:
ron minnich wrote:
as of today, David Hendriks built a BIOS for EPIA with SONE's freebios source tree, and the VGA is working fine. I think there's literally one bit left to find.
Good to hear that.
I'd love to know which bit; but of course that is typical VGA, one bit off or 100 bits off, same result, black screen. I'll admit I never gave it a really hard effort, I just didn't have the time right now.
To clarify, what I've done is merely enabling VGA by executing the mfr's proprietary VGABIOS. Perhaps Steve is talking about enabling the device without such binary-only code, but by directly programming the (poorly documented) registers with outb()'s, etc. Of cource I too would like to have such an open sourced code.
SONE Takeshi wrote:
To clarify, what I've done is merely enabling VGA by executing the mfr's proprietary VGABIOS. Perhaps Steve is talking about enabling the device without such binary-only code, but by directly programming the (poorly documented) registers with outb()'s, etc. Of cource I too would like to have such an open sourced code.
Yes, I am talking about direct register programming. The BIOS approach is very useful, but I want to do it directly. Just a personal thing, like Linus' comment in setup.S, "we don't need no steenking BIOS anyway".
I did see one VGA legacy register in the vt8601 datasheet, copied below, that looks a little funny. I thought it defaulted to a useable default state, but maybe not. But this "read 3C6 four times to enable" is the kind of thing where if you do not have the datasheet you are up a creek.
-Steve
Port 3C6 – VGA RAMDAC Command........................... RW This register is a non-standard VGA register (“extension register”) located at the same port address as the VGA RAMDAC Pixel Mask register. In order to maintain compatibility with standard VGA operations, access to this register is restricted: access is enabled by performing four successive accesses to the Pixel Mask register at 3C6 (i.e., read 3C6 four times).
7-4 Color Mode Select 0000 Pseudo-Color Mode ................................default 0001 Hi-Color Mode (15-bit direct interface) 0010 Muxed Pseudo-Color Mode (16-bit pixel bus) 0011 XGA Color Mode (16-bit direct interface) 01xx -reserved- 10xx -reserved- 1100 -reserved- 1101 True Color Mode (24-bit direct interface) 111x -reserved- 3 Reserved ......................................... always reads 0 2 DAC Disable 0 DAC On (if SR20[0] = 1) .......................default 1 DAC Off 1 Reserved ......................................... always reads 0 0 RAMDAC Enable 0 Disable (Bypass) RAMDAC ..................default 1 Enable RAMDAC
On Fri, 5 Sep 2003, SONE Takeshi wrote:
To clarify, what I've done is merely enabling VGA by executing the mfr's proprietary VGABIOS. Perhaps Steve is talking about enabling the device without such binary-only code, but by directly programming the (poorly documented) registers with outb()'s, etc. Of cource I too would like to have such an open sourced code.
there is some difference. When he built from CVS, it did not work; when he built from your tree, it worked.
ron
Yeah, that whole via-rhine (Or via_rhine, more like) issue is somewhat bizarre, but is an issue for another thread :)
On Thu, 4 Sep 2003, Steve Gehlbach wrote:
Well actually, my beef is about not releasing datasheets. AFAIK we still do not have the direct register VGA working for EPIA-800, due to some hidden enable of some kind or another. And in this case, we have the datasheet, so it probably undocumented. But the other EPIAs, with the CLE266, the datasheet is not available to my knowledge.
as of today, David Hendriks built a BIOS for EPIA with SONE's freebios source tree, and the VGA is working fine. I think there's literally one bit left to find.
We are now trying to see why our latest CVS does not work, but we're very close with this. It's going to turn into a diff -r.
Hang in there.
ron p.s. Next we try to get via-rhine to boot the node in less than 3 minutes ...
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
I suspect the Xbox is your clue... MS has had plenty of practice on
encrypting
the bios and locking out foreign app sw, and the xboxlinux group has
been the
test foil (although in the short run they are on top right now).
Boards don't sell if people won't buy them.
I am afraid they will buy it when they have no or very few choice. When the majority of the boards on the market are DRM enabled or most of the digital information requires DRM to be accessed, pepole will buy these products. I don't know how it is in the U.S., but here in Taiwan, MS is using the recent SoBig/Blaster virus as a "sales point" for its "Trusted Computing" hype.
Ollie
On Fri, Sep 05, 2003 at 11:48:39AM +0800, ??? elucidated:
I am afraid they will buy it when they have no or very few choice. When the majority of the boards on the market are DRM enabled or most of the digital information requires DRM to be accessed, pepole will buy these products. I don't know how it is in the U.S., but here in Taiwan, MS is using the recent SoBig/Blaster virus as a "sales point" for its "Trusted Computing" hype.
Heh, a virus that is possible because of their crappy software... the irony.
Dale
On Fri, 5 Sep 2003, ??? wrote:
I am afraid they will buy it when they have no or very few choice. When the majority of the boards on the market are DRM enabled or most of the digital information requires DRM to be accessed, pepole will buy these products. I don't know how it is in the U.S., but here in Taiwan, MS is using the recent SoBig/Blaster virus as a "sales point" for its "Trusted Computing" hype.
that's quite funny. First, M$ builds insecure software, then pushes DRM as a fix for their own software?
hmm.
ron
On Friday 05 September 2003 4:05 pm, ron minnich wrote:
On Fri, 5 Sep 2003, ??? wrote:
I am afraid they will buy it when they have no or very few choice. When the majority of the boards on the market are DRM enabled or most of the digital information requires DRM to be accessed, pepole will buy these products. I don't know how it is in the U.S., but here in Taiwan, MS is using the recent SoBig/Blaster virus as a "sales point" for its "Trusted Computing" hype.
that's quite funny. First, M$ builds insecure software, then pushes DRM as a fix for their own software?
Not so new, I think. For years they've been buildig insecure software, then pushing the next version of Windows as "the most reliable and most secure version of Windows ever" (by "ever" of course, they mean "so far").
Antony.
ron minnich wrote:
that's quite funny. First, M$ builds insecure software, then pushes DRM as a fix for their own software?
Who was it that said, "No one ever went broke underestimating the stupidity of the American public" ? P.T. Barnum I think.
-Steve
On Fri, 5 Sep 2003, ??? wrote:
I am afraid they will buy it when they have no or very few choice. When the majority of the boards on the market are DRM enabled or most of the digital information requires DRM to be accessed, pepole will buy these products. I don't know how it is in the U.S., but here in Taiwan, MS is using the recent SoBig/Blaster virus as a "sales point" for its "Trusted Computing" hype.
that's quite funny. First, M$ builds insecure software, then pushes DRM as a fix for their own software?
Yea, that is their old trick. Sell something borken first and sell another thing to fix it.
Ollie
-
??? -
Antony Stone -
Dale Harris -
David Hendricks -
ebiederman＠lnxi.com -
ron minnich -
SONE Takeshi -
Steve Gehlbach -
Vincent Touquet