Hello, shyam_iyer@xxxxxxxx wrote: >> What happens if the port is enabled by the kernel? > The BIOS tests for the device will not be performed for the port > since it is disabled by the BIOS, and there is a potential security > problem here if they get reenabled in the kernel. You're trying to protect security by making OS not initialize PCS bits? I'm sorry but there are millions of ways to breach that once one has root access to the OS (e.g. two liner script with setpci and echo to scsi scan sysfs node) or physical access to the machine (connect the drive to a different port or host). If the user doesn't have either, OS security mechanisms work pretty well and are much more flexible and useful. Security-by-preserving-PCS just doesn't fly. Please use Security Mode feature set for that. > If the user decides to disable the port through the BIOS, the driver > needs to respect the user's wish to not use the port and carry on. > Here the end result is a forceful reinitialization of the port by the > driver against the user's wishes. Well, currently, the Linux driver policy is to exploit the hardware capability to the maximum - e.g. we unlock HPA unconditionally and force multi-mode controllers into its best possible mode. We try hard to ignore BIOS imposed settings/limits. >> I'm not sure whether this is a good idea and it has potential to >> break a lot of other configurations. That part of code is used for >> *all* ata_piix out there, so we need a really really good reason to >> change that. So, please explain what you're trying to fix better. >> > If the fix has a potential to break other things then there could be > a module parameter that would let the driver accept the bios > configuration for the pcs register and not modify the config space > through the driver. If reprogramming PCS does break specific cases, I'm willing to modify the driver such that it detects the condition and preserves PCS setting which is far better than requiring the user to enter some kernel parameter but you need to give me much better reason if we're gonna go that way. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
