[lkml]   [2007]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: malicious filesystems (was Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway)
    On Sunday, 8 July 2007 09:21, Miklos Szeredi wrote:
    > > > > We can just wait for all fuse requests to be serviced before
    > > > > proceeding further with freeze, right?
    > > >
    > > > Right. Nice way to slow down or stop the suspend with an unprivileged
    > > > process. Avoiding that sort of DoS is one of the design goals of
    > > > fuse.
    > >
    > > So you want me to handle _malicious_ filesystems now?
    > What I'd like, is a suspend, that works reliably, regardless of the
    > state of any userspace filesystem, network servers and such.

    And then you also would like to have a consistent state of the system after
    the resume, but if the state were inconsistent before the suspend that
    would be difficult to get.

    > > That should be easy... :-). You already have nasty deadlocks in FUSE,
    > > and you solve them by "root can echo 1 > abort"... so allow me the
    > > same possibility.
    > >
    > > We can tell fused we are freezing, and if all the requests are not
    > > serviced within, say, 30 seconds, we call the filesystem malicious and
    > > do echo 1 > abort.
    > Arbitrary time limits, nice. Not.
    > This freezer is like an old house that's close to collapsing, and you
    > are basically just thinking of where to prop it up further. To
    > continute this brilliant analogy, Rafael's patch at least demolishes
    > the worst part of the house, where bricks are already falling on our
    > head ;)

    Actually, this isn't correct and I have some testing problems with this
    patch (as I expected, BTW), so it's not going anywhere. Alternative ideas
    will be appreciated. :-)

    > > Not ideal, but neither is allowing malicious filesystems in the first
    > > place...
    > Malicious programs are not something specific to fuse. A lot of the
    > multiuser/multitasking OS design is about isolating things, so such a
    > program is limited in the damage it can do.
    > > > Look at it this way: the task of the freezer is to stop new I/O
    > > > hitting the hardware. But it is totally indiscriminate about what it
    > > > stops, it tries to stop _everything_ even things which have nothing to
    > > > do with hardware.
    > > >
    > > > Not nice.
    > >
    > > Not nice, but we don't know any better for now. "Just fix all the
    > > drivers" basically means "just fix 90% of kernel".
    > And how much of that 90% currently has any power management?

    Well, you know why that actually started to be a real problem? Because
    sufficiently many people have started to use suspend/hibernation and it
    actually works for quite a lot of them. This makes people to try exotic
    combinations like suspend+FUSE and they find that doesn't work.


    "Premature optimization is the root of all evil." - Donald Knuth
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-07-08 16:03    [W:0.023 / U:16.800 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site