如何将用户设置传递给驱动程序扩展名（MACOS）？
我正在写一个驱动程序扩展程序，其目标是阻止某些类别的USB设备，例如Flash驱动器。驱动程序应阻止（匹配）相关设备类的任何设备，除了白色的设备类别（基于其供应商和产品ID）。白名单可以由应用程序的用户动态设置。
问题是，如何将这些数据传递给驱动程序，因为从文件中读取或诸如Windows注册表之类的内容在驱动程序中不可用。棘手的部分是，驱动程序需要白名单数据 匹配设备。
据我了解，通过从start（）方法返回错误并过早地返回的错误来拒绝设备。我有一个想法是在驱动程序运行此功能时发送数据，但是这是不可能的，因为直到启动方法返回之前，通过Iouserclass的通信才可用。
这有点可行吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
start（）方法与用户空间应用进行通信。如您所说，iouserClient是用于用户空间通信的机制，直到启动和注册该服务之前，这些机制才可用。您可以将驱动程序匹配ioresources/iouserresources始终加载，但是每个匹配的服务启动了您的dext的唯一过程，我不知道一个直接在这些实例之间进行交流的方法。如果我正确理解您，您正在尝试阻止其他驱动程序获取设备。我认为您想到的解决方案不会为您提供帮助。如果您从start（）返回成功， 您的 dext将驱动设备。如果您返回失败，则为设备加载了 no 驱动程序，因为匹配已经结束。因此，无论该设备是在您的允许列表还是拒绝列表上，其他驱动程序将永远不会有机会。osmappedfile/a>。我可以想象，驱动程序沙盒将对dext可以打开哪些文件有话要说，但这似乎值得探索您是否可以通过这种方式打开配置文件。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 matchIOResources/IOUserResourcesso 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 fromStart(), 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.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.