Re: Niches for the Hurd: evaluation method; was: DRM musings, capabilities and stuff

[Michal Suchanek]

2008/12/8 Arne Babenhauserheide <arne_bab@web.de>:
> Am Freitag 05 Dezember 2008 12:40:32 schrieb Michal Suchanek:
[...]
>> For me firefox can cause my media player to skip. This is because
>> firefox eats all available CPU time from time to time, and the only
>> way to prevent it from interfering with the player would be to elevate
>> the player's sheduling priority. This can be done only as root, and
>> would prove disastrous if there was a bug in the player which caused
>> it to run in a tight loop.
>>
>> It's not like I have an ancient system or Firefox really needs all the
>> system resources to run - there just isn't any reasonable CPU time
>> accounting in Linux.
>
> Please don't jump from "it can be done without needing a DRM capable
> structure" towards Linux bashing.

I am not bashing Linux specifically here. The same can be said about
Windows (probably even worse), and most likely about BSD. Some less
well known systems might actually have useful schedulers.

>
> I know I'm also prone to jumping, but let's try to avoid it for this
> discussion.
>
> Firefox' resource usage can be controlled without the user having to give up
> access to its memory, and system servers started and controlled by root could
> just police themselves.

Sure, and you might also want control its memory usage, and that it
cannot access the memory of other processes (because it is no debugger
it has no business doing so).

And once you have access control that actually works you can turn it
into DRM by giving up some rights so some system service that
implements DRM.

>
>> > The admin gives the user a pool of system memory he can use for any task.
>>
>> So this is like DRM except you cannot turn DRM memory into non-DRM
>> memory and the other way around.
>> You just get a piece of plain memory and a piece of DRM memory.
>
> No.
>
> It isn't DRM memory, because the admin always has access to it.

If you replace the admin with a system service it is DRM.

[...]
>> > So the level of security is useless for most users, but the danger is
>> > furthering a DRM ridden society.
>> >
>> > (sorry if that sounds too hard - it's the trade I currently see).
>>
>> You are mixing up things. To make society DRM ridden you must
>> implement the verification that is required for adding "trust" to
>> otherwise untrusted relationships between computer systems.
>
> If you facilitate implementing that verification, you further a DRM ridden
> society.

Then you are just facilitating it. Since the Hurd is microkernel based
it has less code that is crucial for its security and if somebody
wanted to implement verification they would have an easier job on the
Hurd.

>
> That's called the "invisible hand". Many do small things, and since noone had
> the foresight to see where he was heading, there was Hiroshima in the end.
>
> DIfferent from those nuclear physics scientists, we see the thread today, and
> acting or not acting upon that knowledge is our responsibility.
>
[DRM]
>> useless until somebody shows an example where it adds any value but
>> that does not discard the utility of security.
>
> Value to whom?

To the user of such system. Either single user system or shared
(school, company, institution, etc) system.

>
>> > And why should I allow such a component in my free system.
>>
>> Then run Windows 95. They do not have any security whatsoever so they
>> will fulfill this desire of yours.
>
> You really suggest to me using Windows 95?
>
> I said "free system", and free is not proprietary and definitely not WIndows.

Then you are out of luck actually. Because "secure enough to implement
DRM" is less than "secure enough to prevent as many breakins as
possible".

In the DRM case you have to add an extension that does care about
securing only single part of the system - the DRM protected data. In
the later case you want any security that could be useful for the user
which is certainly a superset.

If they wanted to build DRM on top of Linux (perhaps with some
extension like SELinux) and hired a team of experts it might be
doable. It would be hard and the result somewhat uncertain because an
error in any part of the kernel might compromise the protection but it
might still be impenetrable for all practical purposes.

>
>> some security, and a third party that the DRM content provider trusts
>
> That's exactly what you say: You want others to be able to trust my computer.
> But then I can't trust my computer anymore to do what I tell it.

I do not want others to be able to trust your computer. But there are
people who would like to trust it not to allow you access to their
protected content unless they allow it, and yes you could not really
trust your computer in that case anymore.

I cannot force you to choose either way. But they might say "Unless we
can trust your computer you cannot access this."

And either you find "this" important enough and give up your computer
or you do not.

>
> I want to trust it, I don't want others to be able to trust it if they don't
> trust me.
>
>> > And once programmers start using that convenience layer, you're in the
>> > same position again, but now with a layer which is incompatible to most
>> > applications.
>>
>> So if something can be entered by the user it is a compatibility layer?
>
> As soon as you have to design a simplification layer, you have a kind of
> compatibility layer - only with the disadvantage that there aren't any
> compatible applications, yet.

So if the system can communicate with the user it's a simplification layer?

>
> Do you trust the designers of that system so much as to think that their
> design will do better than POSIX on the long run?
>

"Better than POSIX" is actually very low standard in my view. POSIX is
just a collection of things that just happen to be similar on most
UNIXes.

>> > I'm sure that POSIX has weaknesses. But how do you make sure that your
>> > convenience layer wouldn't have just as many weaknesses which only show
>> > later on?
>>
>> Then it can be changed. It's only an interface for the user to enter
>> something in a terminal.
>> You are speaking as if there was only single shell used throughout all
>> UNIX systems.
>
> No. I just take into account that many scripts will use your simplification
> layer,so it will become a kind of API, and more and more applications will
> depend on a certain version of it.

If those applications are written in shell scripting it is the choice
of the author. Such applications always depend on having the right
version of the right shell.

>
>> Not using separate processes gives very poor reliability. Never had
>> your browser crash because of a plugin?
>
> So we are now talking redesigning most applications.

Yes, most applications are unreliable, insecure, miss important
functionality, and have poor UI.

That's true whatever system they run on.

>
>> > But I do think that porting to the Hurd should prove quite a bit easier
>> > than porting to a system without POSIX layer.
>>
>> Why so? There's nothing stopping you from adding libposix into the
>> system that implements the posix interfaces commonly used by
>> applications that would be missing otherwise.
>
> Will you supply the libposix, or do I have to write it myself?

Of course, a system that wants non-trivial number of applications has
to include it.

>
> And if it's there, how many programs will just use that?

I do not care. For most applications it is good enough that they use
it. They will just get the impression that they run on an empty POSIX
system.

>> No, it's not easier.  It's just reinventing the wheel, all the way
>> from square wheel to semi-rounded one.
>
> Then why do so many people do it?

I have no idea. Perhaps they want their own special wheel shape with
their name written on it, or there is no usable library that
implements what they want.

>> > So what keeps him from just modifying that first process to give him
>> > power again?
>>
>> Nothing. However, if particular version of the system were verified
>> for use with DRM protected content modifying that process would void
>> that verification.
>
> And who keeps me from modifying the routinee h uses for checking the
> verification?

Put simply you cannot modify that, it's part of the platform hardware.

For more elaborate answer search for TPM discussions here or elsewhere.

[...]
>> > But for me it seems that the patching and porting would be far more work
>> > on a system without POSIX layer.
>>
>> Where does KDE deal with POSIX?
>
> To take the simplest example: User management.

I never used KDE for user management. Still you can just say that part
does not work, or port that single part if you are concerned. It would
not work perfectly on the Hurd either.

>
>> > The translators are transparent to the mail client, so I can still change
>> > my system layout with them even though the Mail program doesn't see them.
>> >
>> > So they still offer an advantage.
>>
>> There is no reason why the situation with capabilities should be different.
>>
>> However, from your answers it looks like you know little about
>> software and system management, let alone writing software so I
>> suggest you look into that before we continue the debate about
>> feasibility of porting software to one kind of system or another.
>
> I know less about coding than an experienced programmer (I only write programs
> for a bit more than a year now), and my system management is limited to about
> 5 years of experience with Gentoo and university courses which sum up to about
> 2/3rd of a bachlor in informatics (I'm studying physics, and I learned stuff
> like high performance cluster file systems simply because it interested me,
> not because I needed it).
>
> (there's a reason why I do web editing for the Hurd and not lowlevel
> programming)
>
> But I know that just the changes Gentoo ebuilds make to get programs running
> in the environment they are designed for can become quite mmuch work, and I
> get the impression of quite much pain when I think about porting nontrivial
> stuff to a pure capabilities system.

You experience pretty much the same pain porting stuff to the Hurd
which takes POSIX to the letter and does not implement certain
optional aids on which many POSIX programmers like to rely.

Thanks

Michal