Re: [PROBLEM + PATCH] Sata port disabled by BIOS gets initialized

[Tejun Heo <htejun@gmail.com>]

Hello,

shyam_iyer@dell.com 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