IMHO people who really care should find the BIOS option and disable it there.
Having Linux take responsibility seems a little weird. If we do go that route it should be early in setup_arch() before any callbacks to other subsystems to avoid and endless games of whack-a-mole. I also wonder about the level of outrage this time around. The feature has been sitting there for three full generations: Ivybridge (tick), Haswell (tock) and another tick for Broadwell. Do privacy folks not read each new SDM from cover to cover? Sent from my iPhone > On Nov 23, 2016, at 09:29, Henrique de Moraes Holschuh <h...@hmh.eng.br> > wrote: > >> On Wed, 23 Nov 2016, Borislav Petkov wrote: >>> On Wed, Nov 23, 2016 at 11:29:51AM -0200, Henrique de Moraes Holschuh wrote: >>> 1. Assuming we can do it, always lock it when it is found to be unlocked >>> at kernel boot. >> >> Because...? > > Privacy, and the fact that /dev/cpu/msr exists and is enabled on > almost all general-use distros. > >>> 2. Not attempt to change its state from disabled to enabled *unless* >>> given a command line parameter authorizing it. A kconfig-based >>> solution for default+command line override would also work well IMHO, >>> if it makes more sense. >> >> You can't reenable it: > > Yeah, I just found the description for that thing in the IA32 manual. > > It can be disabled + unlocked, disabled + locked, or enabled + unlocked. > Once locked, it will stay disabled until the next reboot. > > However, the manual makes it clear we are _not_ supposed to leave it > enabled + unlocked. Apparently, we're supposed to do our business and > disable+lock it (i.e. enable, read and store/process, disable+lock). > > Looks like it is supposed to be used in a way that protects privacy by > making it very hard for general use software to depend on it existing > and being enabled. > > -- > Henrique Holschuh
