One Thousand Gnomes <gnomes@xxxxxxxxxxxxxxxxxxx> wrote: > > I thought that if I'm changing the module_param annotations anyway then it's > > probably worth bunging in an extra parameter that notes what the parameter > > modifies (ioport, iomem, etc.) for future reference, even if we don't store > > it. > > With a security hat on the security best practice and long standing > accepted rule is that you whitelist rather than blacklist, so there ought > to be a > > module_param_safe_array() > etc > > to mark parameters that are safe, not the reverse. Whilst that may be true, it's a lot more work. Mind you, that said, you can take the annotations I've made and script the inverse. > That debate aside I think the patch is exactly what is needed for this, > and is probably useful for more general hardening as well. Okay, I've done a preliminary patchset, labelling all the parameters that appear to be associated with hardware details and pushed them here: http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=efi-lock-down The patch that modifies the module parameter header is labelled: Lock down module params that specify hardware parameters (eg. ioport) and all the driver dir lockdown patches follow that. I still need to do a bit of commenting in that patch and add various maintainer cc's in the other patches. David -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
