Sata port disabled by BIOS gets initialized by ata_piix drive
PATCH 1/1 Sata port disabled by BIOS gets initialized by ata_piix drive
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 renamed from ata_piix.c.orig +1 -1
@@ -990,7 +990,7 @@ static void __devinit piix_init_pcs(strupci_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);
--
This message was sent on behalf of [email protected] at openSubscriber.com
http://www.opensubscriber.com/messages/[email protected]/topic.html
Quoted 6 lines · [email protected] 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_piixdriver 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?
Quoted 4 lines
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_piixdriver. 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.
Signature · 1 line
tejun
Re: Re: [PROBLEM + PATCH] Sata port disabled by BIOS gets initialized
Quoted 8 lines
Quoted 6 lines
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_piixdriver 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.
Quoted 9 lines
Quoted 4 lines
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_piixdriver. 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_piixout 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 [email protected] at openSubscriber.com
http://www.opensubscriber.com/message/[email protected]/6886790.html
Re: [PROBLEM + PATCH] Sata port disabled by BIOS gets initialized
Hello,
Quoted 4 lines · [email protected] wrote:
Quoted 1 line
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.
Quoted 4 lines
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.
Quoted 9 lines
Quoted 5 lines
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_piixout 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.
Signature · 1 line
tejun
Re: [PROBLEM + PATCH] Sata port disabled by BIOS gets initialized
Quoted 11 lines · Tejun Heo
Hello,
Quoted 4 lines
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)
Signature · 2 lines
Matt Sealey <[email protected]> Genesi, Manager, Developer Relations
Re: [PROBLEM + PATCH] Sata port disabled by BIOS gets initialized
Hello,
Quoted 4 lines · Matt Sealey
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.
Quoted 5 lines
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.
Signature · 1 line
tejun