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
| ||
|
Date: Thu, 04 Sep 2008 02:09:59 +0200 From: Tejun Heo <tj@...nel.org> To: "Eric W. Biederman" <ebiederm@...ssion.com> CC: Miklos Szeredi <miklos@...redi.hu>, serue@...ibm.com, greg@...ah.com, fuse-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org Subject: Re: [PATCH 5/7] FUSE: implement ioctl support Eric W. Biederman wrote: > Maintenance. What happens if I go 128bit, if I have some processes > that are big endian and some that are little endian. Or if I have > some processes that are running a completely different instruction > set with a completely different ABI than other processes. Or > perhaps different perhaps the processes is in a different network > namespace than your filesystem and so it's arguments refer > to something different entirely. Is it a userspace bug if userspace > does not anticipate how the kernel will change in the future? What I don't see is how anything becomes different whether that part is implemented in kernel or not. For ioctls, only the implementing code knows what the data structure should look like that's why we can't handle 64/32 bit problems generically and has ->compat_ioctl hook. To me, splitting it to two pieces looks like more maintenance overhead than the other way around. > If we don't look at ioctl as a set of system calls that should > be put into an appropriate format for a filesystem we have > a maintenance problem. > > If we don't have an interface clean enough we can push data > out to a server on a remote machine have it processes the > arguments and send the data back. We actually have failed > to properly abstract the interface. I don't think that's a possible goal in generic manner. We can't even do that for read/writes. At least not at FUSE's level. We need higher abstraction for that. e.g. /dev/oss via CUSE, ioctl specified machine endian 16bit format. Supporting that in the way you described would require a lot of logic in the kernel and I don't really see any benefit over, say, forward the sound via pulseaudio after getting it to userland. I don't think the problem can or should be solved at FUSE interface level. >> Well, kernel stub kind of beats a lot of benefits of FUSE - no >> specific kernel dependencies, easy development and distribution, >> etc... > > Of course FUSE has specific kernel dependencies. It depends > on the implementation of fusefs in the kernel to talk to it. > The reason you don't need a specific kernel today is that > the kernel dependencies are well defined. You are talking > about using a very poorly defined interface to talk to the > filesystem. At which point it would be better to open > a separate channel and talk to the filsystem directly. The difference is that FUSE servers depend on FUSE and each server doesn't require separate new pieces to get working and ioctl is poorly defined by nature. > Being able to add a kernel system call (ioctl) with no review is a > total maintenance disaster. It is impossible to maintain because > there is not a process to even discover what is going on. How about adding whole FSes w/o a review? That's the whole point of FUSE. Seriously, there are infinite number of ways to break the regular defined filesystem semantics using FUSE. FUSE should provide mechanism and protects against certain fundamental things. It can't enforce correct semantics on everything. > We have to have a kernel stub to support other system calls > and I don't see why individual ioctls should be different. > > If you want to support forwards compatibility reserving > some ioctl numbers and saying these numbers will always > be parsed this way. Which would allow you to write > a common stub that can be implemented before the ioctls > are implemented. ioctls is most likely to be used to emulate legacy or proprietary devices. If you're worried about filesystems abusing it, maybe the solution is to only allow CUSE to use ioctls but I really don't see what the problem is here. If the userland FS server wants to shoot itself in the foot, it's not really the kernel's problem. > If you really don't want new kernel dependencies you can hook up to > the process via ptrace and intercept the ioctls before they even get > to the kernel. If you can open /proc/<pid>/mem you have the rights > to ptrace the process. Aieee.. The same goes for the whole FUSE. Thanks. -- tejun -- 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/
Powered by blists - more mailing lists