(re-send with all HTML stripped for vger.k.o): On Mon, Dec 28, 2015, at 10:35, Philipp Kern wrote: > I wrote a kernel module that allows access to BIOS options on Lenovo machines using the WMI interface originally intended for Windows and documented on https://support.lenovo.com/us/en/documents/ht100612. In theory this applies to both laptops and desktops of the Think series, however at this point I only care about and tested it on multiple laptops. > > Now I have a few questions where I'd need some guidance: > > * Should this live as a part of thinkpad_acpi.c, or should this be a separate module? If so, should it live as lenovo-wmi.c, even though it is unclear if non-Think-branded products can make use of it? Module autoload could be keyed off the WMI interface, but then the generic name might hurt again… IMHO, it could live as a separate module, and you could name it something like tp-bioswmi or lenovo-bioswmi, or even a mix of the two (lenovo-tpbioswmi?). Autoloading will do its job, so it should be mostly transparent to users anyway, and we don't need to care that much if the module has an awkward name, as long as it is not *confusing* :p > * I wrote it so that individual BIOS options are (currrently) exposed as /sys/devices/virtual/lenovowmi/<Option>/value. <Option> is taken literally from Lenovo's list in WMI. Reading that file will give you the literal value, which is fine. However writing is - as > documented - a bit awkward if you have a BIOS password set, as you will need to pass it with the value. Is this even an appropriate interface? What would be one, that does not resort to ioctl? Should I let the user store the BIOS password information in a separate file and store the blob within the module, applying it on every set? Be careful if you're taking "option" directly from the firmware. IME, you will eventually hit a UEFI with crap in there, and injecting it into the sysfs attribute name can cause all sort of insanity. Always pipe it through a sanitizing function that is *whitelist* based, and either reject weird entries, or fix them. Also, you may hit name uniqueness issues. It shouldn't happen, but that doesn't mean it won't happen. There are several ways to implement the BIOS password thing. I'd suggest you go with a well-designed, safer one instead of something that looks easy at first glace. Maybe a kernel keyrings can be used to store the credential? Whatever you do, ensure you either require authorization for each transaction (which means something other than sysfs for sure!), or that you do it process-based. If you use a model where you "authorize" the entire system (echo the password to sysfs node XXX, change parameters using sysfs, echo nothing to the password node to clear the passsword"), you will create a window where undesired accesses can happen. > * The interface for setting a new BIOS password or setting the asset tag data is different from the BIOS option interface. If I do the above I do not really have a namespace to expose these interfaces anywhere. How would I do this? Maybe if you place everything on subdirs instead of directly on your main attribute tree it would work better?. E.g. store the options in "options/<sanitized_option>".. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
