Storing data in Kernel mode driver - wdk

I have an array in my kernel mode driver. Is it possible for the driver to save the array data and on load restore the same?

Assuming your array is not incredibly large you can use the registry to store this type of information.
You can set your driver to open a specific registry location relative to your driver instance. If it's missing your driver should contain a default value (you can also set your INF file to put this value in the registry on install). Then, as your data changes and your device unloads rewrite the data to the registry to be looked up the next time your device loads.

Related

How does PnP manager determine the appropriate function driver?

I am learing the loading process of Windows Driver.
But I cannot understand a part of the following article.
https://learn.microsoft.com/ja-jp/windows-hardware/drivers/install/step-3--the-driver-for-the-device-is-installed
In this article, there is the following description.
"4. The PnP manager loads the appropriate function driver and any optional filter drivers for the device."
I have a question about above description.
How does the PnP manager determine the appropriate function driver?
For example,
when a USB memory is plugged into a Windows PC then PnP manager will load disk.sys after loading a driver relating USB.
In this case, I want to know why PnP manager could judge that the device corresponds to disk.sys.
(seeing somewhere in registry? sending some requests to bus driver? and so on.. )
when bus driver detect and report PDO device PnP manager send several IRP_MJ_PNP to PDO device. including IRP_MN_QUERY_ID for get Device Identification Strings
then formated registry key path in form
\REGISTRY\MACHINE\SYSTEM\CurrentControlSet\Enum\<BusQueryDeviceID>\<BusQueryInstanceID>
in place <BusQueryDeviceID> string returned by device for BusQueryDeviceID and in place <BusQueryInstanceID> string returned by device for BusQueryInstanceID (Parameters.QueryId.IdType)
this key opened or created. then was query for BusQueryHardwareIDs and BusQueryCompatibleIDs. result of this query saved in HardwareID and CompatibleIDs REG_MULTI_SZ values.
and then PnP manager look for Service REG_SZ value under this key - if it already exist - the driver ( \REGISTRY\MACHINE\SYSTEM\CurrentControlSet\Services\<Service>) loaded and it AddDevice called with this PDO. if this value yet not set - was search via installed inf files in system - for best match HardwareID and CompatibleIDs. if found driver - result saved under Service REG_SZ value, for not search next time

What's the proper storage location for a database for a cross platform command line program?

I wrote a simple note taking program that's nothing more than a dictionary mapping a key to a value. IE
$ hlp -key age -value 25
$ hlp age
25
and it just stores information in a json file hardcoded to ~/.hlp.json. But I was wondering if there's likely some standard location I should be putting this file. Is there a standard location for databases like this?
A useful resource here is the hier(7) man page. (http://linux.die.net/man)
Data that is only going to be used by you belongs in $HOME, traditionally hosted under /home.
For something that is used to support the system itself, you'd be using /var. For applications that are just hosted on the system, you'd use /var/opt.
If the application is something big that could be replicated or moved to another system, you'd create a separate filesystem with a mount point outside any of those listed in hier(7). This could be a filesystem mounted from a SAN or NAS, which whould help mobility of the application.
Once you actually need to access the data from different machines, you'd have to move it to a network accessable key/value store or sql database.

windows registry storage best practice

Background
I've recently been shunted into the world of windows programming and I'm still trying to find my way around the best practices and ways of doing things. So I was just hoping for some pointers on use of the registry
Not particularly relevant but the background is that I am creating an installer in Golang, a couple of points to get out the way on that:
I am aware MSI's would usually be best practice for an installer (I have my reasons for going custom exe)
I know there are more obvious language choices than golang, just go with it
Current registry use
As part of the install process, I store several pieces of data in the registry:
run once commands:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
I create a few entries here: to restart the process after a system reboot and to delete some temp files on reboot after uninstall
an uninstall entry:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Vendor
Product
Content here is the same as an MSI would create, I was careful not to create any additional custom fields here (all static data until uninstall)
an application entry:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Vendor\Product
I store some additional data about the installation here, some of which is needed for uninstall such as state info from before installation (again all static content)
a temporary entry:
Computer\HKEY_CURRENT_USER\SOFTWARE\Vendor\Product
I store some temporary data here which can include some sensitive user entered data (usernames/passwords). I run some symmetric encryption to obscure the data though my understanding is this is area of the registry is encrypted so only the user could access anyway (would like confirmation on that)
This data is used to resume after restart and then deleted
Questions
I'm looking for confirmation / corrections on my current use of the registry?
I now have need to pass some data between an application and a running service, this data would be updated every 1-2 minutes and would be a few bytes of JSON. Does the registry seem like a reasonable place to store variable data like this? If so is there a particular place that better for variable data - I was going to add it to:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Vendor\Product
HCKU isn't encrypted to my knowledge. It's stored in a file called NTUser.dat and could be loaded as a hive under HKEY_USERS and visible to other processes with sufficient rights to do so.
You would need to open up the rights to HKLM\SOFTWARE\Vendor\Product if you expect a user priv process to be able to write to it. If you want to pass data to a service you might want to use some sort of IPC pipe to do so. Not sure what's available in Golang for this.

How to configure spi in the driver file insted of giving configuration in the application

I want to write a test driver for mcspi and want to give all configuration in my driver file (instead of using user space application I want to use driver as a test driver and want to create .ko) and want to pass all configuration to the mcspi controller.
The configurations like chip_select, mode, speed, bits etc., Basically all these configurations I want to use for my test driver to check functionality of FIFO mode in the mcspi. I have already enabled FIFO in the mcspi but I want to check its functionality.
Can anyone please give me some suggestions?
I don't really know why cant you do something you want. I think you can pass the configuration by set up parameters using module_param
Adding on what #sunnyleevip suggested: another "standard" way to configure your driver would be to expose the params of interest via the /proc or the /sys filesystems.
You can find all the details in Linux Device Driver
Expanding on #sergico and #sunnyleevip, you could also use device tree to pass configuration data to the driver. The SPI bus master driver (since the 2.6.30s and all of the 3.x kernels) already are pretty devicetree supportive, so there might not be much more to do to get it to work.

What's the best way to (programatically) determine a file's network origin?

For an application I'm writing, i want to programatically find out what computer on the network a file came from. How can I best accomplish this?
Do I need to monitor network transactions or is this data stored somewhere in Windows?
When a file is copied to the local system Windows does not keep any record of where it was copied. So unless the application that created it saved such information in the file then it will be lost.
With file auditing file and directory operations can be tracked, but I don't think that will include the source path with file copies (just who created it and when).
Yes, it seems like you would either need to detect the file transfer based on interception of network traffic, or if you have the ability to alter the file in some way, use public key cryptography to sign files using a machine-specific key before they are transferred.
Create a service on either the destination computer, or on the file hosting computers which will add records to an Alternate Data Stream attached to each file, much the way that Windows handles ZoneInfo for files downloaded from the internet.
You can have a background process on machine A which "tags" each file as having been tagged by machine A on such-and-such a date and time. Then when machine B downloads the file, assuming we are using NTFS filesystems, it can see the tag from A. Or, if you can't have a process at the server, you can use NTFS streams on the "client" side via packet sniffing methods as others have described. The bonus here is that future file-copies will retain the data as long as it is between NTFS systems.
Alternative: create a requirement that all file transfers must be done through a Web portal (as opposed to network drag-and-drop). Built in logging. Or other type of file retrieval proxy. Do you have control over procedures such as this?

Resources