linux-kernel - Re: [PATCH 5/7] FUSE: implement ioctl support

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]

Date:	Fri, 29 Aug 2008 09:32:18 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	hpa@...nel.org
CC:	miklos@...redi.hu, tj@...nel.org, fuse-devel@...ts.sourceforge.net,
	greg@...ah.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/7] FUSE: implement ioctl support

On Thu, 28 Aug 2008, H. Peter Anvin wrote:
> Miklos Szeredi wrote:
> > On Thu, 28 Aug 2008, H. Peter Anvin wrote:
> >> This is *hard* to get right, and we screw this up in the kernel with 
> >> painful regularity.  The throught of having user-space processes, which 
> >> don't have access to the kernel locking primitives and functions like 
> >> copy_from_user() dealing with this stuff scares me crazy.
> > 
> > What issues exactly are you thinking of?
> 
> Memory changing underneath you.  It can be dealt with by very careful 
> sequencing only.

That's just handwaving.  Apps don't normally change memory under
system call arguments.  Or if they do the only thing we ever guarantee
is that the thing won't blow up in a big fireball.

I don't see how getting the data from userspace is different from
doing the same in the kernel.  Care to explain?

> >> That is why I'm suggesting using an in-kernel linearizer.
> > 
> > Lots of complexity, ugh...  Even Tejun's current scheme is better IMO.
> 
> And then you get *no* privilege separation, for one thing, so why even 
> bother doing it in userspace?

And with ioctls (at least if the filesystem supplies the linearizer
instructions) you simply _cannot_ get proper privilege separation.
Generic ioctl support will always be a privileged thing.

Alternatively we can restrict ioctls.  Most ioctls conform to some
convention for encoding the format (size/in/out) in the command, no?

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/