[PROBLEM + PATCH] Sata port disabled by BIOS gets initialized by ata_piix drive

[PROBLEM + PATCH] Sata port disabled by BIOS gets initialized by ata_piix drive

[shyam_iyer]

Problem
Sata disks are connected to onboard sata ports of PowerEdge 1900 (ESB2 southbridge chipset). If one of the port is disabled in the bios then they get enabled again by the ata_piix driver because of a default port map being written to the Port control and status register(0x91-93). 
Instead the driver should preserve the bios setting by way of a fix like this.

Fix:
The BIOS configured PCS value must be anded logically with the default port map for the chipset. This way the BIOS information will not be lost by the reinitialization of the config space by the ata_piix driver. The below patch is against 2.6.21 kernel.

--- ata_piix.c.orig	2007-06-08 02:38:03.000000000 +0530
+++ ata_piix.c	2007-06-08 02:39:45.000000000 +0530
@@ -990,7 +990,7 @@ static void __devinit piix_init_pcs(stru
 
 	pci_read_config_word(pdev, ICH5_PCS, &pcs);
 
-	new_pcs = pcs | map_db->port_enable;
+	new_pcs = pcs & map_db->port_enable;
 
 	if (new_pcs != pcs) {
 		DPRINTK("updating PCS from 0x%x to 0x%x\n", pcs, new_pcs);

Signed-off-by: Shyam Iyer <shyam_iyer@dell.com>



--
This message was sent on behalf of shyam_iyer@dell.com at openSubscriber.com
http://www.opensubscriber.com/messages/linux-ide@vger.kernel.org/topic.html

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

[Tejun Heo]

shyam_iyer@dell.com wrote:
> Problem Sata disks are connected to onboard sata ports of PowerEdge
> 1900 (ESB2 southbridge chipset). If one of the port is disabled in
> the bios then they get enabled again by the ata_piix driver because
> of a default port map being written to the Port control and status
> register(0x91-93). Instead the driver should preserve the bios
> setting by way of a fix like this.

What happens if the port is enabled by the kernel?

> Fix: The BIOS configured PCS value must be anded logically with the
> default port map for the chipset. This way the BIOS information will
> not be lost by the reinitialization of the config space by the
> ata_piix driver. The below patch is against 2.6.21 kernel.

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.

-- 
tejun

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

[shyam_iyer]

>> Problem Sata disks are connected to onboard sata ports of PowerEdge  
>> 1900 (ESB2 southbridge chipset). If one of the port is disabled in  
>> the bios then they get enabled again by the ata_piix driver because  
>> of a default port map being written to the Port control and status  
>> register(0x91-93). Instead the driver should preserve the bios  
>> setting by way of a fix like this.  
 
>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.

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.
 
>> Fix: The BIOS configured PCS value must be anded logically with the  
>> default port map for the chipset. This way the BIOS information will  
>> not be lost by the reinitialization of the config space by the  
>> ata_piix driver. The below patch is against 2.6.21 kernel.  
 
>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.
 
--
Shyam

--
This message was sent on behalf of shyam_iyer@dell.com at openSubscriber.com
http://www.opensubscriber.com/message/linux-ide@vger.kernel.org/6886790.html

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

[Tejun Heo]

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

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

[Matt Sealey]

Tejun Heo wrote:
> Hello,
>
>> 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.

Isn't there a case for speeding up boot and not wasting resources by
respecting BIOS settings in this regard? If you have an 8-port
controller on a board and one disk, forcing all of them enabled
regardless of BIOS settings is just 7 redundant port scans.

It should at least be an option - the default being to open up all
gunports, an option to respect BIOS settings and only use the ones
requested and enabled.. (I can see an edge case where a user disables
a disk in the BIOS to stop another OS from looking at/for it, but
wants the Linux system to boot from it)

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

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

[Tejun Heo]

Hello,

Matt Sealey wrote:
> Isn't there a case for speeding up boot and not wasting resources by
> respecting BIOS settings in this regard? If you have an 8-port
> controller on a board and one disk, forcing all of them enabled
> regardless of BIOS settings is just 7 redundant port scans.

Ports can be populated later with hotplug.

> It should at least be an option - the default being to open up all
> gunports, an option to respect BIOS settings and only use the ones
> requested and enabled.. (I can see an edge case where a user disables
> a disk in the BIOS to stop another OS from looking at/for it, but
> wants the Linux system to boot from it)

There hasn't been any actual need for such an option.  Yes, there are
situations where such option might help theoretically but how much?  If
you have an actual strong case for such option, I'm all ears.

-- 
tejun