On Mon, Feb 13, 2017 at 10:17 AM, Linda Knippers <[email protected]> wrote: > On 02/13/2017 12:28 PM, Dan Williams wrote: >> On Mon, Feb 13, 2017 at 8:27 AM, Linda Knippers <[email protected]> >> wrote: >>> As it is today, we can't enable or test new functions in firmware without >>> changing the kernel. >>> >>> With this patch we allow function 0 for the HPE DSM families, >>> as is already allowed with the MS family. We now only restrict >>> the functions to the currently documented set if the module parameter >>> "disable_vendor_specific" is set. Since the module parameter >>> description says "Limit commands to the publicly specified set", >>> this approach seems correct. >>> >> >> My concern is that this makes the kernel less strict by default. Given >> this is only a test capability lets add a module option to override >> the default dsm_mask. > > This part isn't strictly a test capability. It's also to allow older > kernels to be supported with newer NVDIMM hardware, firmware, and management > tools. > We shouldn't need a customer to update their production kernel just to support > an NVDIMM management tool. > > As for less secure by default, the default is to allow undocumented > functions of the "vendor specific" type. How is the really different? >
It's about pushing back on undocumented BIOS interfaces as much as possible. The kernel has the documented set enabled by default, including the documented vendor-specifc function code. There is the option to disable the vendor-specific tunnel to restrict the kernel to only allowing commands with publicly documented effects. With a new "default_dsm_mask" parameter the default kernel policy can be overridden by the system owner. _______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
