bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Niches for the Hurd: evaluation method; was: DRM musings, capabiliti


From: Michal Suchanek
Subject: Re: Niches for the Hurd: evaluation method; was: DRM musings, capabilities and stuff
Date: Tue, 30 Dec 2008 16:55:33 +0100

On 30/12/2008, Arne Babenhauserheide <arne_bab@web.de> wrote:
> Am Dienstag 30 Dezember 2008 14:04:52 schrieb Michal Suchanek:
>
> > You need a special hardware to verify the integrity of the system, and
>  > I can imagine that in a modular system the hardware driver might work
>  > without modifications to the system  - think one of the initial
>  > servers loaded with the mach kernel.
>  >
>  > The driver itself need not be non-free, it would just reveal what
>  > version (or more precisely the exact bitwise checksum) of the system
>  > is running regardless of the actual version.
>
>
> If that driver is non-free and I can't replace it, then the system locks down
>  my software.
>
>  If that driver is free, I can just give it a list of checksums of my changed
>  software and checksums it should give for them instead.

You can make the driver return any data you want. However, if the data
it returns are checksums signed by the cryptography hardware vendor
key then they are the real checksums of the bios, boot loader, and the
system including the driver (unless there is a bug somewhere, of
course).

>
>
>  > However, for a general purpose system a random application
>  > malfunctioning cannot be blamed on the system. Otherwise no system
>  > would be allowed ;-)
>
>
> Malfunctioning as soon as an irrelevant bit in the system changes can be
>  blamed on the system, if the application gets the information that the bit
>  changd from the system.

The system does not really tell, it only relays data from some hardware device.

Thanks

Michal




reply via email to

[Prev in Thread] Current Thread [Next in Thread]