linux-kernel - Re: malicious filesystems (was Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <E1I96eW-00059M-00@dorka.pomaz.szeredi.hu>
Date:	Thu, 12 Jul 2007 23:56:48 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	pavel@....cz
CC:	miklos@...redi.hu, oliver@...kum.org, paulus@...ba.org,
	stern@...land.harvard.edu, johannes@...solutions.net, rjw@...k.pl,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	mjg59@...f.ucam.org, benh@...nel.crashing.org
Subject: Re: malicious filesystems (was Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway)

> > Actually there's also a non-malicious case in which waiting for
> > requests to finish won't work: when one fuse filesystem is accessing
> > another.
> > 
> > Since we are blocking new fuse requests, that might block a fuse
> > daemon, which in turn makes it impossible to finish the pending
> > request.
> 
> Hmm, yes, this is ugly. But will it hurt? We'll just wait for number
> of active fuse requests to go down to 0 before proceeding.

I'm thinking of the following situation, immediately after we begin to
wait for fuse requests to subside:

  - task A is performing file operation O1
  - O1 is being served by task B
  - task B needs to perform O2 before finishing O1

Since we don't allow new requests, O2 will never start.  So O1 will
never finish.  So the number of fuse requests will never go to 0.

> It may still livelock on system with busy fused-s, but we'll detect
> that with timeout, and I believe it is 'don't do that' situation.

There are no busy fused's.  If we allowed O2 to go through, everything
would be nice and dandy.  But we cannot know that O2 needs to be let
through, and other fuse requests must not.

> > And this is not at all theoretical, I know that encfs is used over
> > various other fuse filesystems like sshfs or ntfs-3g.
> > 
> > Yeah, stacking userspace filesystems could be done entirely in
> > userspace, and I'm actually working on that (with fuse-2.7.0 already
> > supporting some basic stacking).
> 
> Great.
> 
> > But the point is, that the "wait for fuse to quiescence" hack would
> > not work in todays environment.
> 
> Ok, I'll just blame fuse here. 'You have to write to /sys
> files for SIGKILL to work' is not funny.

SIGKILL won't work on a stopped task.  Neither on a traced task.
Neither on a zombie (how many newbies are thoroughly confused about
that ;)

And it won't work on a task that is hanging on an NFS mount, when the
network broke.

Oh, and it won't work on a deadlocked fuse filesystem.  How many of
these have you met?  How many of the others?

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