Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.

[Olivier Galibert <galibert@pobox.com>]

On Sat, Feb 04, 2006 at 01:49:44AM +0100, Pavel Machek wrote:
> > Why don't you try to design the system so that the progress bar can't
> > fuck up the suspend unless they really, really want to?  Instead of
> > one where a forgotten open(O_CREAT) in a corner of graphics code can
> > randomly trash the filesystem through metadata corruption?
> 
> Even if I only put chrome code to userspace, open() would still be
> deadly. I could do something fancy with disallowing syscalls,

Nah, simply chroot to an empty virtual filesystem (a tmpfs with max
size=0 will do) and they can't do any fs-related fuckup anymore.  Just
give them a fd through which request some specific resources
(framebuffer mmap essentially I would say) and exchange messages with
the suspend system (status, cancel, etc) and maybe log stderr for
debugging purposes and that's it.  They can't do damage by mistake
anymore.  They can always send signals to random pids, but that's not
called a mistake at that point.

Even better, you can run _multiple_ processes that way, some for
compression/encryption, some for chrome, etc.


> but it
> is probably easier to just read the chrome code to be used... It
> should be as simple as memcpy(framebuffer, prepared image).

I guess I just can't trust chrome code.  I've have seen too much of it
to be able to.  Especially since once you open the gates a simple
animated-gif equivalent won't be considered enough, and userland code
does not go through the same kind of filters kernel code does.

Anybody and his dog will be able to take your userland suspend code,
add their neogeo emulator to play while it's suspending, and then
point at you when their fs got eaten after the tenth reboot.  And
distribs will pick it up because it's cool.

  OG.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/