I have an IOKit-based kernel extension on Mac OS X, a subclass of IOService. When this service loads i need to publish additional specific runtime information from it and i need it to be accessible from user space without making some specific IOUserClient requests. The information in question is basically field\value pairs and it's format is shared between the KEXT and it's user-space wrapper library. The contents will change over time on some specific events inside the service when it is active.
On Linux i would have accomplished this with a file in the /proc file system. Can you advise a similar strategy on OS X? Maybe something related to IORegistry?
Thank you.
Well this turned out to be pretty easy.
Your IOKit service is (eventially) inherited from IOService class, which in turn is inherited from IORegistryEntry, which represents an instance of your service's entry in IORegistry and provides a family of setProperty\getProperty methods to add\change\remove your own fields in IORegistry entry for your service.
The IORegistry in an in-memory database that is of course programmatically accessible from user space where you search it for you service's entry and read information published by it.
Related
I'm wondering if it's possible to get the name of a driver from the device that it created. Let's say I have a symbolic link that points to a device, \.\RTF64 -> \Device\RTF64. Is there any way to get the driver name (.sys) using just this information. Either I have to use some undocumented functions exported by ntdll.dll or write a driver which retrieves the information I want. Is it even possible to do?.
I've looked trough various functions exported by ntdll.dll but have not found anything yet.
In user mode you can use SetupDi* functions to enumerate all the devices and interfaces then use SetupDiGetDeviceInterfaceDetail to get the device path.
Then use something like SetupDiGetDriverInfoDetail to get details about the driver.
Edit: As mentioned in the comments it only works if the driver registered an interface for the device object, which is not possible in some cases (control device objects)
Great information on interrogating mounted drives via IOKit in this question. But is there a way to determine which of the devices returned by IOIteratorNext() is the boot drive? Or better yet, might there be a way to get just the boot drive in the iterator returned by IOServiceGetMatchingServices()?
Booting is done from media, not a device per se. Devices have media, media have volumes. I don't believe that volumes are represented in IOKit.
This is probably easiest using Disk Arbitration. Use DADiskCreateFromVolumePath() with the CFURL for /. Then call DADiskCopyDescription() to get the description dictionary. That will include properties of the volume, the media, the device, and even the bus, including IOKit paths if you need them. There's a good chance the information you're looking for is directly in the description dictionary, though.
The NVRAM information cited by Mark Setchell is available from IOKit, too, at path IOService:/AppleACPIPlatformExpert/AppleEFIRuntime/AppleEFINVRAM. There's a property efi-boot-device. Its value is a property list including a service matching dictionary. As you can see, it looks for an entry with provider class of IOMedia whose UUID property is a certain UUID.
You can use this:
nvram efi-boot-device
efi-boot-device <array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>78025031-4C42-4FDE-8DD1-A515A2BF6032</string></dict></dict><key>BLLastBSDName</key><string>disk0s3</string></dict></array>%00
I am trying to port Wine 1.7.13 to modern Cocoa. I am considering running Windows binaries in an XPC service’s process, for security isolation and crash-proofing. However, there is one problem: To the best of my knowledge, XPC services are singletons. Only one XPC service process is allowed to be running at a time. This is a problem because, if I use threads to enable multiple Windows binaries to run at once, a segfault or other hard crash in one Windows binary would cause all the other binaries to crash with it.
As mentioned here, it is generally understood that the above assertion is true. If that is so, it would seem that I cannot implement this sort of isolation within a single XPC service process.
My other alternative is to use sandbox inheritance (having the GUI application fork and using more traditional IPC to have the Windows processes talk to each other) instead of an XPC service. What are the pros and cons of using that instead of an XPC service? I understand that processes that inherit their parent’s sandbox does not get to have its own entitlements. What other drawbacks are there?
I also understand that Apple discourages the use of sandbox inheritance in favor of XPC, but it is still an available design decision. They must have kept it around for a reason. Would a sandboxed Mac App Store app be able to use sandbox inheritance in this fashion?
I am going through the same decision. I had my heart set on XPC services, but upon discovering that there would be a single XPC Service with multiple connections, I cannot use them (my XPC Service will use plug-ins provided by third-parties so I want to keep them apart, and also the XPC Service will use libraries that might not clean-up properly, so I want to be able to dispose of them while keeping the UI stable - well I shouldn't have to justify this - I want one-process-per-job and that's that).
I am considering the normal sub-process model using posix_spawn() (I think this behaves better than fork() WRT to Sandboxing), CocoaAsyncSocket for the comms. I am going to see if I can replace the use of TCP/IP in CocoaAsynSocket with UNIX sockets to speed-up up comms (with the intent of contributing it back to the project if this works out). (UPDATE: this has already been done, some time ago by github user #jdiehl. See his socketUN branch and the discussion in issue #88 of the upstream repo).
For data marshalling I will use Google Protocol Buffers (UPDATE #2: Nope; not worth the hassle when NSKeyedArchiver and NSKeyedUnarchiver provide everything required out-of-the box. They may not provide data as packed as Google Protocol Buffers, but they 1) Don't require writing and maintaining, 2) Allow any class to participate by implementing the NSCoding protocol, and 3) Don't have to solve the issue of cross-platform data exchange.
The only possible disadvantage I can see is I don't know if file bookmarks can be passed to the subprocess and used (i.e. the UI opens a file or has a file dragged to it and wants to give access to the file to the worker process). I will update this answer with whatever I learn. (FINAL UPDATE: Passing the URL bookmark across the UNIX domain socket works fine, and the bookmark doesn't even need to be a security-scoped bookmark for this to work. There are no more impediments to this alternative to XPC).
Your assertion is incorrect about sub-processes not having their own entitlements; they do and are embedded into the executable and it must have "inherits sandbox" set for the sub-process to work correctly.
And the end-of-the-day the one-xpc-service-per-app is a show stopper so you have no choice but to find an alternative.
As I saw Sandboxie makes a virtual space on hard disk and there are allowed the programs to write.
This how can be implemented as software?
Which windows (kernel,shell ?) functions needed to be overriden?
Software like Sandboxie basically provide a virtual execution environment for (sandboxed) applications. They do this by virualizing file system and Registry (read/write/delete/exec operations) among other things. They are also called feather-weight virtual machines, as they provide a virtual machine like environment for individual applications. You can refer to these pages for more info:
http://sourceforge.net/projects/fvm-rni/ (open source app)
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.74.1367&rep=rep1&type=pdf (paper)
http://www.ecsl.cs.sunysb.edu/tr/TR224.pdf (paper)
I don't know how Sandboxie does it, but the usual way is through File System Filter Drivers:
A file system filter driver intercepts
requests targeted at a file system or
another file system filter driver. By
intercepting the request before it
reaches its intended target, the
filter driver can extend or replace
functionality provided by the original
target of the request.
I want to store some information in the EPROCESS structure of the process in windows NT kernel. My aim is that when winlogon is called I want to assign a unique value to the next process based on which user logs in. But I do not know where to store this unique ID. I have tried and succeeded in modifying some information (like the tokens) in the EPROCESS block of a process by the method of Direct kernel object modification and I wonder if there is any structure in this EPROCESS block where some other information can be stored.
p.s. For modifying the EPROCESS block I used a device driver.
The EPROCESS structure is opaque and undocumented, meaning you shouldn't be messing with its internals. Doing so requires you, among other things, to test on every OS version and service pack you plan on supporting.
Do not modify EPROCESS. It will bring you great sorrow.
Furthermore, if you do, do not install it on anyone elses machine. It is absolutely wrong to impose such a profoundly damaging, system destabilizing change on another persons computer. How would like it if I gave you tuberculosis?