Windows vista and RF
Posted: Sun Dec 24, 2006 12:16 pm
Will Rf work on windows vista???
I came upon this today.
Below is a selection from a much longer article
Part of which is found here http://www.cs.auckland.ac.nz/~pgut001/p ... a_cost.txt
Elimination of Open-source Hardware Support
-------------------------------------------
In order to prevent the creation of hardware emulators of protected output
devices, Vista requires a Hardware Functionality Scan (HFS) that can be used
to uniquely fingerprint a hardware device to ensure that it's (probably)
genuine. In order to do this, the driver on the host PC performs an operation
in the hardware (for example rendering 3D content in a graphics card) that
produces a result that's unique to that device type.
In order for this to work, the spec requires that the operational details of
the device be kept confidential. Obviously anyone who knows enough about the
workings of a device to operate it and to write a third-party driver for it
(for example one for an open-source OS, or in general just any non-Windows OS)
will also know enough to fake the HFS process. The only way to protect the
HFS process therefore is to not release any technical details on the device
beyond a minimum required for web site reviews and comparison with other
products.
Elimination of Unified Drivers
------------------------------
The HFS process has another cost involved with it. Most hardware vendors have
(thankfully) moved to unified driver models instead of the plethora of
individual drivers that abounded some years ago. Since HFS requires unique
identification and handling of not just each device type (for example each
graphics chip) but each variant of each device type (for example each stepping
of each graphics chip) to handle the situation where a problem is found with
one variation of a device, it's no longer possible to create one-size-fits-all
drivers for an entire range of devices like the current
Catalyst/Detonator/ForceWare drivers. Every little variation of every device
type out there must now be individually accommodated in custom code in order
for the HFS process to be fully effective.
If a graphics chip is integrated directly into the motherboard and there's no
easy access to the device bus then the need for bus encryption (see
"Unnecessary CPU Resource Consumption" below) is removed. Because the
encryption requirement is so onerous, it's quite possible that this means of
providing graphics capabilities will suddenly become more popular after the
release of Vista. However, this leads to a problem: It's no longer possible
to tell if a graphics chip is situated on a plug-in card or attached to the
motherboard, since as far as the system is concerned they're both just devices
sitting on the AGP/PCIe bus. The solution to this problem is to make the two
deliberately incompatible, so that HFS can detect a chip on a plug-in card vs.
one on the motherboard. Again, this does nothing more than increase costs and
driver complexity.
Further problems occur with audio drivers. To the system, HDMI audio looks
like S/PDIF, a deliberate design decision to make handling of drivers easier.
In order to provide the ability to disable output, it's necessary to make HDMI
codecs deliberately incompatible with S/PDIF codecs, despite the fact that
they were specifically designed to appear identical in order to ease driver
support and reduce development costs.
Denial-of-Service via Driver Revocation
---------------------------------------
Once a weakness is found in a particular driver or device, that driver will
have its signature revoked by Microsoft, which means that it will cease to
function (details on this are a bit vague here, presumably some minimum
functionality like generic 640x480 VGA support will still be available in
order for the system to boot). This means that a report of a compromise of a
particular driver or device will cause all support for that device worldwide
to be turned off until a fix can be found. Again, details are sketchy, but if
it's a device problem then presumably the device turns into a paperweight once
it's revoked. If it's an older device for which the vendor isn't interested
in rewriting their drivers (and in the fast-moving hardware market most
devices enter "legacy" status within a year of two of their replacement models
becoming available), all devices of that type worldwide become permanently
unusable.
The threat of driver revocation is the ultimate nuclear option, the crack of
the commissars' pistols reminding the faithful of their duty [Note B]. The
exact details of the hammer that vendors will be hit with is buried in
confidential licensing agreements, but I've heard mention of multimillion
dollar fines and embargoes on further shipment of devices alongside the driver
revocation mentioned above.
Now where does this leave RF ? It looks to me like the end of the road unless we all go LINUX and even then will we be able to get the graphics cards that will work on Linux? or do we have to stick with what we have got and hope the cards do not break down.
__________________
I came upon this today.
Below is a selection from a much longer article
Part of which is found here http://www.cs.auckland.ac.nz/~pgut001/p ... a_cost.txt
Elimination of Open-source Hardware Support
-------------------------------------------
In order to prevent the creation of hardware emulators of protected output
devices, Vista requires a Hardware Functionality Scan (HFS) that can be used
to uniquely fingerprint a hardware device to ensure that it's (probably)
genuine. In order to do this, the driver on the host PC performs an operation
in the hardware (for example rendering 3D content in a graphics card) that
produces a result that's unique to that device type.
In order for this to work, the spec requires that the operational details of
the device be kept confidential. Obviously anyone who knows enough about the
workings of a device to operate it and to write a third-party driver for it
(for example one for an open-source OS, or in general just any non-Windows OS)
will also know enough to fake the HFS process. The only way to protect the
HFS process therefore is to not release any technical details on the device
beyond a minimum required for web site reviews and comparison with other
products.
Elimination of Unified Drivers
------------------------------
The HFS process has another cost involved with it. Most hardware vendors have
(thankfully) moved to unified driver models instead of the plethora of
individual drivers that abounded some years ago. Since HFS requires unique
identification and handling of not just each device type (for example each
graphics chip) but each variant of each device type (for example each stepping
of each graphics chip) to handle the situation where a problem is found with
one variation of a device, it's no longer possible to create one-size-fits-all
drivers for an entire range of devices like the current
Catalyst/Detonator/ForceWare drivers. Every little variation of every device
type out there must now be individually accommodated in custom code in order
for the HFS process to be fully effective.
If a graphics chip is integrated directly into the motherboard and there's no
easy access to the device bus then the need for bus encryption (see
"Unnecessary CPU Resource Consumption" below) is removed. Because the
encryption requirement is so onerous, it's quite possible that this means of
providing graphics capabilities will suddenly become more popular after the
release of Vista. However, this leads to a problem: It's no longer possible
to tell if a graphics chip is situated on a plug-in card or attached to the
motherboard, since as far as the system is concerned they're both just devices
sitting on the AGP/PCIe bus. The solution to this problem is to make the two
deliberately incompatible, so that HFS can detect a chip on a plug-in card vs.
one on the motherboard. Again, this does nothing more than increase costs and
driver complexity.
Further problems occur with audio drivers. To the system, HDMI audio looks
like S/PDIF, a deliberate design decision to make handling of drivers easier.
In order to provide the ability to disable output, it's necessary to make HDMI
codecs deliberately incompatible with S/PDIF codecs, despite the fact that
they were specifically designed to appear identical in order to ease driver
support and reduce development costs.
Denial-of-Service via Driver Revocation
---------------------------------------
Once a weakness is found in a particular driver or device, that driver will
have its signature revoked by Microsoft, which means that it will cease to
function (details on this are a bit vague here, presumably some minimum
functionality like generic 640x480 VGA support will still be available in
order for the system to boot). This means that a report of a compromise of a
particular driver or device will cause all support for that device worldwide
to be turned off until a fix can be found. Again, details are sketchy, but if
it's a device problem then presumably the device turns into a paperweight once
it's revoked. If it's an older device for which the vendor isn't interested
in rewriting their drivers (and in the fast-moving hardware market most
devices enter "legacy" status within a year of two of their replacement models
becoming available), all devices of that type worldwide become permanently
unusable.
The threat of driver revocation is the ultimate nuclear option, the crack of
the commissars' pistols reminding the faithful of their duty [Note B]. The
exact details of the hammer that vendors will be hit with is buried in
confidential licensing agreements, but I've heard mention of multimillion
dollar fines and embargoes on further shipment of devices alongside the driver
revocation mentioned above.
Now where does this leave RF ? It looks to me like the end of the road unless we all go LINUX and even then will we be able to get the graphics cards that will work on Linux? or do we have to stick with what we have got and hope the cards do not break down.
__________________