File:  [NetBSD Developer Wiki] / wikisrc / puffs / kernel_file_systems_as_userspace_servers.mdwn
Revision 1.2: download - view: text, annotated - select for diffs
Fri Mar 15 22:02:32 2013 UTC (6 years, 11 months ago) by jdf
Branches: MAIN
CVS tags: HEAD
Make image links work.

    1: **Contents**
    2: 
    3: [[!toc levels=2]]
    4: 
    5: # Kernel File Systems as Userspace Servers
    6: 
    7: This chapter describes the symbiosis of background knowledge on them, see the 
    8: respective web pages.
    9: 
   10: ## On Kernel File System Servers
   11: 
   12: The integration of the [[puffs]] and [[rump]] technologies enables mounting 
   13: kernel file systems as userspace servers. Equivalent functionality to the 
   14: in-kernel option is maintained, and an application accessing files is unable to
   15: tell the difference between the two.
   16: 
   17: A useful scenario for mounting a kernel file system as a userspace server is 
   18: accessing untrusted media. As file system code is generally authored assuming a 
   19: trusted and correct file system image, a corrupt or deliberately modified image 
   20: can easily cause a kernel crash or security compromise. By using a userspace 
   21: server, the compromise is limited to the userspace server program, not the whole 
   22: system.
   23: 
   24: It also enables the mounting of kernel file systems which are not included as 
   25: part of the kernel and loading a module is not desired.  Additionally, using 
   26: kernel file systems from different operating system versions is possible, since 
   27: interfacing with the kernel is done through the puffs protocol, not the kernel 
   28: binary interface. This is desired for example when wanting to take advantage of 
   29: new functionality without upgrading the operating system or wanting to do a 
   30: partial rollback to avoid a regression in a newer version.
   31: 
   32: ![File System Access Comparison](/puffs/rump.png)  
   33: **File System Access Comparison**
   34: 
   35: ## Mounting and Use
   36: 
   37: The use of kernel file systems as userspace servers requires the support for 
   38: [[puffs]] in the kernel.
   39: 
   40: To mount the file system, the relevant `rump_fs` command must be run.  These 
   41: commands share the same suffix as the normal in-kernel `mount_fs` commands. For 
   42: instance, the equivalent of `mount_msdos` is `rump_msdos`.  The usage is also 
   43: equal, so the manual page of the mount equivalent should be consulted. The only 
   44: exception is that rump file systems do not require the use of
   45: [vnconfig(8)](http://netbsd.gw.com/cgi-bin/man-cgi?vnconfig+8+NetBSD-current+i386)
   46: to mount regular files. Rather, such images can be mounted directly by using the 
   47: image as the device file path.
   48: 
   49: To unmount, `umount` should be run as normal. While it is possible to violently 
   50: kill the server process, this does not give the file system an opportunity to 
   51: flush its caches and cleanly unmount and may result in data loss. In case the 
   52: server process is violently killed, puffs automatically performs a forced 
   53: unmount and no further action is necessary.
   54: 
   55: ### Examples
   56: 
   57: To mount a file system image as a read-only mount:
   58: 
   59:     # rump_ffs -o ro ~/img/ffs.img /mnt
   60: 
   61: or
   62: 
   63:     # mount -t ffs -o ro,rump ~/img/ffs.img /mnt
   64: 
   65: If you want to mount a disk device instead, the procedure is the same.  This 
   66: example also instructs the file system to use journalling. Note: for reasons 
   67: beyond the scope of this document, it is highly recommended you use the raw 
   68: device instead of the usual block device.
   69: 
   70:     # rump_ffs -o log /dev/rwd0e /mnt2
   71: 
   72: Mounting nfs works in a similar fashion. The command line flag `-p` makes sure a 
   73: non-root mount is succesful if the server allows them:
   74: 
   75:     # rump_nfs -p host:/export /mnt3
   76: 
   77: Finally, the option `rump` in fstab signals that the file system should be 
   78: mounted using rump instead of the kernel file service. The following example is 
   79: for specifying an nfs share mount from a laptop over wireless:
   80: 
   81:     server:/m/server    /m/server    nfs    rw,noauto,-r=8192,-w=8192,rump
   82: 
   83: After this the file system will show up on the mountlist and you can access it 
   84: through the mountpath like any other mounted file system.
   85: 
   86: ## Internals
   87: 
   88: Internally, kernel file systems are implemented against the kernel virtual file 
   89: system layer. This layer defines a protocol which kernel file systems convert to 
   90: their backend storage protocol to satisfy the operation. The result is then 
   91: converted back to a format the virtual file system layer understands and passed 
   92: back to caller (most likely an application, although it can be for example the 
   93: NFS server).
   94: 
   95: Analogously, puffs file systems must interpret and convert the puffs file system 
   96: interface protocol. While the puffs interface is very similar to the kernel 
   97: virtual file system interface, there are differences in some parameters. For 
   98: example, the virtual file system passes information about I/O as a reference to 
   99: `struct uiomove`. In contrast, puffs passes this as explicit parameters.
  100: 
  101: Since a userspace kernel file system server attaches itself as a puffs file 
  102: system, protocol conversion from puffs to the kernel virtual file system must 
  103: happen, if the whole protocol stack is to work. This conversion of protocols is 
  104: done by the p2k, or puffs-to-kernel, component. It is installed as `libp2k` and 
  105: linked with all kernel file system servers.
  106: 

CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb