I need to retrieve the "Physical Device Object name" of a disk device from a user mode application on Windows, as seen in Device Manager.
I have a solution now that involves a kernel driver that gets loaded and interrogated through IOCTLs. Once in kernel land, I have no trouble getting to that name. If possible, I would like to avoid using a kernel module.
Any ideas?
You can get this using the Setup API functions. Specifically I believe you can get this via SetupDiGetDeviceRegistryProperty and SPDRP_PHYSICAL_DEVICE_OBJECT_NAME.
Related
I am writing a driverkit extension whose goal is to block some categories of USB devices, such as flash drives. The driver should block (match to) any device of the relevant device classes, except those, which are whitelisted (based on their vendor and product ID). The whitelist can be set dynamically by user of the application.
The question is, how to pass these data to the driver as reading from a file or something like Windows registry is not available in the DriverKit. The tricky part is that the driver requires the whitelist data before the device is matched.
From what I understood, rejection of device is possible by returning an error from Start() method and returning from it prematurely. I got an idea to send the data while the driver is running this function, however this is not possible as the communication via IOUserClass is not available until the Start method returns.
Is this somehow doable?
As far as I'm aware, communicating with user space apps from the initial Start() method is not possible from DriverKit extensions. As you say, IOUserClients are the mechanism to use for user space communication, and those aren't available until the service is started and registered. You can have your driver match IOResources/IOUserResources so it is always loaded, but each matched service starts up an independed process of your dext, and I'm not aware of a way to directly communicate between these instances.
If I understand you correctly, you're trying to block other drivers from acquiring the device. I don't think the solution you have in mind will help you with this. If you return success from Start(), your dext will drive the device. If you return failure, no driver is loaded for the device, because matching has already concluded. So other drivers would never get a chance anyway, regardless of whether the device is on your allow-list or deny-list.
It's new in DriverKit 21 (i.e. macOS Monterey), and I've not had a chance to try it yet, but there is an API for reading files, OSMappedFile. I would imagine that the DriverKit sandbox will have something to say about which files a dext can open, but this seems like an avenue worth exploring whether you can open configuration files this way.
Note that none of this will help you during early boot, as your dext will never be considered for matching at that time. And you may not be able to get required entitlements from Apple to build a dext which matches USB device classes rather than specific product/vendor ID patterns. (Apologies for repeating myself, but other users may come across this answer and not be aware of this issue.)
From definition of monolithic kernel, it says that it exists as single bin file in an address location, and it varies from micro-kernel in a sense that in micro-kernel, there are servers which run in kernel and user-space.
My question here is that shell interprets the user commands for the kernel, so does it mean shell exists in the user-space ?
If yes isn't the interaction between kernel and shell just like it happens in micro-kernel using message passing ?
So how does micro-kernel differ from monolithic kernel ?
http://en.wikipedia.org/wiki/Monolithic_kernel see the image it give you clear picture.
It is NOT about kernel and u-space application interaction.
In micro-k let say you are reading a file then file-system server comes into the picture. user send request to file system server but to read a file from device you need driver so file system server must have to communicate with device drivers server (message passing occurs between two core functionality of OS file system and device driver)
In case of Mono-kernel everything (like file system , device drivers so on) is part of kernel and it is single-flow no message between kernels subsystems like file systems and device drivers.
You can find other major difference in the link http://en.wikipedia.org/wiki/Microkernel
From a general standpoint, I am trying to figure out how to access a platform device from userspace. To be more specific, I have a EMIF controller on and SoC of which I have added to my device tree and I believe it is correctly bound to a pre-written EMIF platform device driver. Now I am trying to figure out how I can access this EMIF device from a userspace application. I have come accross a couple different topics that seem to have some connection to this issue but I cannot quite find out how they relate.
1) As I read it seems like most I/O is done through the use of device nodes which are created by mknod(), do I need to create a device node in order to access this device?
2) I have read a couple threads that talk about writting a Kernel module (Character?, Block?) that can interface with both userspace and the platform device driver, and use it as an intermediary.
3) I have read about the possibility of using mmap() to map the memory of my platform device into my virtual memory space. Is this possible?
4) It seems that when the EMIF driver is instantiated, it calls the probe() fucntion. What functions would a userpace application call in the driver?
It's not completely clear what you're needing to do (and I should caveat that I have no experience with EMIF or with "platform devices" specifically), but here's some overview to help you get started:
Yes, the usual way of providing access to a device is via a device node. Usually this access is provided by a character device driver unless there's some more specific way of providing it. Most of the time if an application is talking "directly" to your driver, it's a character device. Most other types of devices are used in interfacing with other kernel subsystems: for example, a block device is typically used to provide access from a file system driver (say) to an underlying disk drive; a network driver provides access to the network from the in-kernel TCP/IP stack, etc.
There are several char device methods or entry points that can be supported by your driver, but the most common are "read" (i.e. if a user-space program opens your device and does a read(2) from it), "write" (analogous for write(2)) and "ioctl" (often used for configuration/administrative tasks that don't fall naturally into either a read or write). Note that mknod(2) only creates the user-space side of the device. There needs to be a corresponding device driver in the kernel (the "major device number" given in the mknod call links the user-space node with the driver).
For actually creating the device node in the file system, this can be automated (i.e. the node will automatically show up in /dev) if you call the right kernel functions while setting up your device. There's a special daemon that gets notifications from the kernel and responds by executing the mknod(2) system call.
A kernel module is merely a dynamically loadable way of creating a driver or other kernel extension. It can create a character, block or network device (et al.), but then so can a statically linked module. There are some differences in capability mostly because not all kernel functions you might want to use are "exported" to (i.e. visible to) dynamically loaded modules.
It's possible to support mapping of the device memory into user virtual memory space. This would be implemented by yet another driver entry point (mmap). See struct file_operations for all the entry points a char driver can support.
This is pretty much up to you: it depends on what the application needs to be able to do. There are many drivers in the kernel that provide no direct function to user-space, only to other kernel code. As to "probe", there are many probe functions defined in various interfaces. In most cases, these are called by the kernel (or perhaps by a 'higher level "class" driver') to allow the specific driver to discover, identify and "claim" individual devices. They (probe functions) don't usually have anything directly to do with providing access from user-space but I might well be missing something in a particular interface.
You need to create a device node in order to access the device.
The probe function is called when the driver finds a matching device.
For information on platform device API, the following articles could be useful.
The platform device API
Platform devices and device trees
I'm writing method to get pci device, given vendor id, device id programmatically (just like pci_get_device from Linux kernel).
For that I need to get device object configuration. I read from here for the same: http://msdn.microsoft.com/en-us/library/windows/hardware/ff558707(v=vs.85).aspx
Now to test this, I made fake driver - service installation framework, which will install my I/O device driver and in that from DriverEntry I can test this PCI functionality.
But OS crashes with irql_not_less_or_equal, at
irp = IoBuildSynchronousFsdRequest(IRP_MJ_PNP,
targetObject,
NULL,
0,
NULL,
&event,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> &ioStatusBlock);
Can anyone tell me what's wrong with that, (I'm calling this from Driver Entry, and passing current installing driver's deviceObject.)
You don't have a valid PDO in DriverEntry(). DriverEntry roughly corresponds to main() in user space application and is called first thing after driver load into memory. DriverEntry main purpose is to register the driver with the OS and its code is independent of actual device(s). You can have a PDO only after the OS has called your initialization callback (after it has recognized your device) - and the callback will be called after DriverEntry completion (actually, the callback should be provided to the OS as part of the driver registration inside the DriverEntry()).
If a USB device driver is loaded, and at some time the device plugs in, then which part of the kernel will create struct device and register it?
When the driver is loaded, the system calls the function, which you assigned in module_init. You will want to call there usb_register(struct usb_driver skel_driver), where skel_driver is a struct with pointers to methods servicing the device, like the probe method.
The probe method is the one which is called, when a new usb device is introduced in to the system. In this place you can fill your struct (usb_skel) with what you will need in the future, initiate a char device or whatever you do, when the device is introduced.
The system mostly won't create anything by itself, it has to have most of the structs prepared and filled with device specific data.
Please see usb-skeleton in lxr for reference and learn to use it, besides read writing usb drivers from LDD.
Cheers