Hi,
On Monday 06 February 2006 00:02, Nigel Cunningham wrote:
> On Saturday 04 February 2006 23:51, Rafael J. Wysocki wrote:
> > On Saturday 04 February 2006 02:23, Pavel Machek wrote:
> > > On So 04-02-06 02:08:33, Olivier Galibert wrote:
> > > > 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.
> > >
> > > No, I do not want to deal with multiple processes. Chrome code is not
> > > *as* evil as you paint it... But yes, chroot is a nice idea. Doing
> > > chroot into nowhere after freezing system will prevent most stupid
> > > mistakes. Rest of userland is frozen, so it can not do anything really
> > > wrong (at most you deadlock), if you kill someone -- well, that's only
> > > as dangerous as any other code running as root.
> >
> > I like the chroot idea too.
>
> You're making this too complicated. Just require that the userspace program
> does all it's file opening etc prior to telling kernelspace to do
> anything. Then clearly document the requirement. If someone breaks the
> rule, it is their problem, and their testing should show their
> foolishness. We have done a similar thing in the Suspend2 userspace user
> interface code, and it works fine.
Unfortunately I'd like to open at least one device file after freeze, for a
technical reason that probably does not exist in suspend2, so I need a
temporary filesystem anyway. Chrooting to it is just a cake.
[BTW, we have the list [email protected] we'd like
to be a place for discussing the userspace suspend issues. If you could
subscribe to it, we'd be able to move the discussion there.]
Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
