Wiki code for objfs

Hide Line numbers
1: == The System Object Filesystem ==
2: 
3: The system object filesystem (objfs), is mounted at {{code}}/system/object{{/code}} on every Solaris system.  Its purpose is to expose the symbol table and CTF data for all objects currently loaded in the kernel, with the primary consumer being [[libdtrace>>http://cvs.opensolaris.org/source/xref/usr/src/lib/libdtrace]].  Why is this so important for DTrace?  to quote from the original ARC case:
4: 
5: > The dtrace_kernel privilege was created to allow uprivileged users to trace
6: > kernel activity with DTrace.  Unfortunately, DTrace still has to use /dev/kmem
7: > to get type and symbol information.  This has the side effect of requiring all
8: > privileges, so a user with the dtrace_kernel privilege cannot use D scripts that
9: > rely on CTF data or kernel symbols.  This also prevents a 32-bit DTrace consumer
10: > from running on a 64-bit system, and is one of the barriers to DTrace in a local
11: > zone (since we can’t include /dev/kmem in a local zone for obvious reasons).
12: 
13: Now that DTrace uses /system/object, the {{code}}dtrace_kernel{{/code}} privilege actually behaves like it’s supposed to, and you have the added benefit of being able to run your favorite ELF tools (nm(1), elfdump(1), etc) on the resulting files.
14: 
15: === Finding the source ===
16: 
17: The source is located at [[usr/src/uts/common/fs/objfs>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/objfs]]. The following table provides a brief description of each file:
18: 
19: |=File    |=Description  
20: | [[usr/src/uts/common/fs/objfs/objfs_vfs.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/objfs/objfs_vfs.c]] | VFS and kernel module interfaces |
21: | [[usr/src/uts/common/fs/objfs/objfs_root.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/objfs/objfs_root.c]] | The root directory |
22: | [[usr/src/uts/common/fs/objfs/objfs_odir.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/objfs/objfs_odir.c]] | Per-object directory |
23: | [[usr/src/uts/common/fs/objfs/objfs_data.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/objfs/objfs_data.c]] | The ’object’ data file |
24: | [[usr/src/uts/common/fs/objfs/objfs_common.c>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/objfs/objfs_common.c]] | Miscellaneous shared routines |
25: 
26: === Understanding the source ===
27: 
28: The object filesystem is built on top of [[gfs>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/gfs.c]], a framework for constructing pseudo filesystems.  See David Powell’s [[blog post>>http://blogs.sun.com/roller/page/dep?entry=simplified_psuedo_filesystem_implementation]] for a description of GFS, why it was developed, and how it’s used.
29: 
30: At the heart of objfs is the ’object’ data file.  The rest of the source code exists solely to present this data in the appropriate manner.  The first question you might ask is: why have ’/system/object/module/object’, with nothing else in the directory?  Isn’t that redundant?  The reason is simple extensibility.  When /proc was first developed, there was a single file for each process, which quickly wore out its welcome.  We think there may be other uses for this filesystem out there, and we don’t want to rule any future enhancements.
31: 
32: The choice of ELF files follows a similar trend.  The primary reason is that the existing tools (most notably [[libctf>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libctf]]) already have existing interfaces to interact with ELF files.  On top of that, the ELF format is by nature extensible, so we can add information within the ELF object file, in addition to creating new entries in the per-object directory.  You might notice there is no text or data associated with the object file.  The data
33: is self explanatory: exposing it is a clear security risk.  The choice to export text is more subtle.  But module text is modified after being loaded, so if we chose to export it would be revealing privileged information (such as which DTrace probes were enabled).
34: 
35: The source code is laid out around the [[data_sections>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/objfs/objfs_data#141]] table, which describes how to construct each section.  The seemingly endless set of macros expand into a structure that the sect_*() family of functions can then access.  The bulk processing is done in [[objfs_data_read()>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/objfs/objfs_data#objfs_data_read]]. We check the following in order: the ELF header, the section headers, and finally the section data itself.
36: 
37: === Using the filesystem ===
38: 
39: The /system/object interface is not public, nor is it a stable interface.  If you find yourself needing to use the filesystem, let us know so that we can determine whether it makes sense to stabilize the interface.  The best ways to examine the data is through standard libraries, such as [[libelf(3LIB)>>http://docs.sun.com/app/docs/doc/816-5173/6mbb8adto?a=view#indexterm-126]] or [[libctf>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libctf]].
OpenSolaris

Top Menu

Wiki code for objfs

Search

Collectives

Community Group

Project

User Group

Subsites

Community Group observability Pages
