Re: [flashrom] [PATCH] revamp the warning of failing to set BIOS write enable in enable_flash_ich
and if we are at it... shouldn't we tell the user, that writes will most probably fail in cases where we could not enable bios writes?
e.g. the dell optiplex in the "It is hard to report a bug...."-thread: BIOS Lock Enable: enabled, BIOS Write Enable: disabled, BIOS_CNTL is 0x2 tried to set 0xdc to 0x3 on ICH8/ICH8R failed (WARNING ONLY)
as far as i understand this, an SMI is triggered and in this case the SMM prohibits us from setting the BIOS WE bit, but this may not be always the case. is there a way around it? i don't know enough about SMM to be sure if that's correct.
in any case we won't be able to erase/write if the WE bit is not set and we should indicate this clearly to the user imho. what do you think?
Am 20.06.2011 15:15 schrieb Stefan Tauner:
and if we are at it... shouldn't we tell the user, that writes will most probably fail in cases where we could not enable bios writes?
Ah, you assume that this is an interface similar to SPI where commands exist. That is not the case. Parallel/LPC/FWH flash uses normal reads/writes as commands, and the state machine inside the flash chip decides whether a write is indeed a write of the flash chip or rather a command sent to the flash chip. Due to that, a Parallel/LPC/FWH programmer with disabled write can't even probe because the probe function uses writes which are treated as commands by the chip. If you want an appropriate warning, it should be something like this: "Could not enable full flash access on chipset FOO. flashrom may be unable to find the flash chip and/or write to it."
e.g. the dell optiplex in the "It is hard to report a bug...."-thread: BIOS Lock Enable: enabled, BIOS Write Enable: disabled, BIOS_CNTL is 0x2 tried to set 0xdc to 0x3 on ICH8/ICH8R failed (WARNING ONLY)
as far as i understand this, an SMI is triggered and in this case the SMM prohibits us from setting the BIOS WE bit, but this may not be always the case. is there a way around it? i don't know enough about SMM to be sure if that's correct.
in any case we won't be able to erase/write if the WE bit is not set and we should indicate this clearly to the user imho. what do you think?
Sure, warning the user is good. But please consider the problems outlined above.
Regards, Carl-Daniel
On Wed, 14 Sep 2011 00:27:47 +0200 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Am 20.06.2011 15:15 schrieb Stefan Tauner:
and if we are at it... shouldn't we tell the user, that writes will most probably fail in cases where we could not enable bios writes?
Ah, you assume that this is an interface similar to SPI where commands exist. That is not the case. Parallel/LPC/FWH flash uses normal reads/writes as commands, and the state machine inside the flash chip decides whether a write is indeed a write of the flash chip or rather a command sent to the flash chip. Due to that, a Parallel/LPC/FWH programmer with disabled write can't even probe because the probe function uses writes which are treated as commands by the chip. If you want an appropriate warning, it should be something like this: "Could not enable full flash access on chipset FOO. flashrom may be unable to find the flash chip and/or write to it."
e.g. the dell optiplex in the "It is hard to report a bug...."-thread: BIOS Lock Enable: enabled, BIOS Write Enable: disabled, BIOS_CNTL is 0x2 tried to set 0xdc to 0x3 on ICH8/ICH8R failed (WARNING ONLY)
as far as i understand this, an SMI is triggered and in this case the SMM prohibits us from setting the BIOS WE bit, but this may not be always the case. is there a way around it? i don't know enough about SMM to be sure if that's correct.
in any case we won't be able to erase/write if the WE bit is not set and we should indicate this clearly to the user imho. what do you think?
Sure, warning the user is good. But please consider the problems outlined above.
after a quick recheck on IRC the real problem is this: we always try to set the BIOS write enable bit in enable_flash_ich and warn it this fails even though it may not be necessary for accessing the attached flash chip (because we think SPI is not affected).
a patch for this problem would need to know which bus we want to access. this is (more or less) derivable from the chipset's boot straps in GCS. the best option is probably to not call enable_flash_ich at all if the motherboard is strapped to spi (or pci), rename enable_flash_ich to enable_flash_ich_lpc (or so) and to add a warning to it like the one mentioned by carldani above.
does that sound like a plan?
I checked with some boards with different Intel chipsets (some ICHx and Tunnel Creeks), and the bios write enable bit does affect the SPI bus. It will quite likely be ignored for PCI accesses, but everything that goes through the chipset is affected by this bit. So if this bit is not set, write accesses to the bios flash will not be clocked to the SPI bus.
And there is really nothing we can do about the SMM-based locking mechanism if it is enabled. SMIs cannot be prevented, and the code from SMM mode cannot be changed (except through some tricky code injection on faulty S3 resumes, but that is something we should leave to the black hats :-) ).
Besides, if I remember correctly, I think the Computrace OS modules can also restore their corresponding bios modules as long as at least one of their protection parts (bios, bootloader, OS, etc) survives. So at least in this case we don't really gain anything by trying to find a new way to break into SMM mode.
Best regards, Ingo
Es gelten unsere Allgemeinen Leistungsbedingungen die unter http://www.msc-ge.com/alb abrufbar sind.
Our standard terms and conditions apply which are available under http://www.msc-ge.com/alb .
MSC Vertriebs GmbH
Sitz der Gesellschaft: Industriestrasse 16, 76297 Stutensee Handelsregister: Mannheim, HRB Nr. 10 3631 Geschäftsführung: Manfred Schwarztrauber, Lothar Kümmerlin, Rüdiger Kuhn, Silvano Geissler Umsatzsteuer ID Nr.: DE 143 585 507 WEEE Reg. Nr. : DE 31011852
Gleichmann & Co. Electronics GmbH
Sitz der Gesellschaft: Schraderstrasse 44, 67227 Frankenthal Handelsregister: Ludwigshafen, HRB Nr. 21305 Geschäftsführung: Manfred Schwarztrauber, Thomas Klein Umsatzsteuer ID Nr. : DE 148 421 329 WEEE Reg. Nr.: DE 72277043
Diese E-Mail enthält vertrauliche und/ oder rechtlich geschützte Informationen. Wenn Sie nicht der beabsichtigte Empfänger sind, informieren Sie bitte sofort den Absender und löschen Sie diese E-Mail.
The information contained in this message is confidential and/ or protected by law. If you are not the intended recipient, please contact the sender and delete this message.
-----Ursprüngliche Nachricht----- Von: flashrom-bounces+ifel=msc-ge.com@flashrom.org [mailto:flashrom-bounces+ifel=msc-ge.com@flashrom.org] Im Auftrag von Stefan Tauner Gesendet: Mittwoch, 14. September 2011 01:05 An: Carl-Daniel Hailfinger Cc: flashrom@flashrom.org Betreff: [SPAM?]Re: [flashrom] [PATCH] revamp the warning of failing to set BIOS write enable in enable_flash_ich
On Wed, 14 Sep 2011 00:27:47 +0200 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Am 20.06.2011 15:15 schrieb Stefan Tauner:
and if we are at it... shouldn't we tell the user, that writes will most probably fail in cases where we could not enable bios writes?
Ah, you assume that this is an interface similar to SPI where commands exist. That is not the case. Parallel/LPC/FWH flash uses normal reads/writes as commands, and the state machine inside the flash chip decides whether a write is indeed a write of the flash chip or rather a command sent to the flash chip. Due to that, a Parallel/LPC/FWH programmer with disabled write can't even probe because the probe function uses writes which are treated as commands by the chip. If you want an appropriate warning, it should be something like this: "Could not enable full flash access on chipset FOO. flashrom may be unable to find the flash chip and/or write to it."
e.g. the dell optiplex in the "It is hard to report a bug...."-thread: BIOS Lock Enable: enabled, BIOS Write Enable: disabled, BIOS_CNTL is 0x2 tried to set 0xdc to 0x3 on ICH8/ICH8R failed (WARNING ONLY)
as far as i understand this, an SMI is triggered and in this case the SMM prohibits us from setting the BIOS WE bit, but this may not be always the case. is there a way around it? i don't know enough about SMM to be sure if that's correct.
in any case we won't be able to erase/write if the WE bit is not set and we should indicate this clearly to the user imho. what do you think?
Sure, warning the user is good. But please consider the problems outlined above.
after a quick recheck on IRC the real problem is this: we always try to set the BIOS write enable bit in enable_flash_ich and warn it this fails even though it may not be necessary for accessing the attached flash chip (because we think SPI is not affected).
a patch for this problem would need to know which bus we want to access. this is (more or less) derivable from the chipset's boot straps in GCS. the best option is probably to not call enable_flash_ich at all if the motherboard is strapped to spi (or pci), rename enable_flash_ich to enable_flash_ich_lpc (or so) and to add a warning to it like the one mentioned by carldani above.
does that sound like a plan?
On Wed, 14 Sep 2011 13:51:04 +0200 "Feldschmid, Ingo" ifel@msc-ge.com wrote:
I checked with some boards with different Intel chipsets (some ICHx and Tunnel Creeks), and the bios write enable bit does affect the SPI bus. It will quite likely be ignored for PCI accesses, but everything that goes through the chipset is affected by this bit. So if this bit is not set, write accesses to the bios flash will not be clocked to the SPI bus.
what have you "checked" exactly? did you try clearing the bit, issuing SPI commands and looked at the physical bus? it's a pity that the public data sheets do not provide a clear statement regarding this bit.
I changed my local copy of the flashrom trunk to never set the write-enable-bit. Then, on the target machine, I double-checked with lspci that the bit isn't set. Next, I called "flashrom -w bios.bin" to let it try & write to the flash chip.
As a result, I got flashrom errors, telling me that it couldn't erase the chip:
Erasing and writing flash chip contents... Transaction error! spi_block_erase_20 failed during command execution at address 0xe3000 ... spi_block_erase_52 failed during command execution at address 0xe3000 ... spi_block_erase_d8 failed during command execution at address 0xe0000 ... spi_block_erase_60 failed during command execution ... spi_block_erase_c7 failed during command execution ... FAILED! Uh oh. Erase/write failed. Checking if anything changed. Good. It seems nothing was changed. Writing to the flash chip apparently didn't do anything.
Furthermore, a colleague told that they actually once have read the SPI accesses with a osci, and that no write / erase cycles have been executed without this bit set (sry don't have proof for that right now).
Es gelten unsere Allgemeinen Leistungsbedingungen die unter http://www.msc-ge.com/alb abrufbar sind.
Our standard terms and conditions apply which are available under http://www.msc-ge.com/alb .
MSC Vertriebs GmbH
Sitz der Gesellschaft: Industriestrasse 16, 76297 Stutensee Handelsregister: Mannheim, HRB Nr. 10 3631 Geschäftsführung: Manfred Schwarztrauber, Lothar Kümmerlin, Rüdiger Kuhn, Silvano Geissler Umsatzsteuer ID Nr.: DE 143 585 507 WEEE Reg. Nr. : DE 31011852
Gleichmann & Co. Electronics GmbH
Sitz der Gesellschaft: Schraderstrasse 44, 67227 Frankenthal Handelsregister: Ludwigshafen, HRB Nr. 21305 Geschäftsführung: Manfred Schwarztrauber, Thomas Klein Umsatzsteuer ID Nr. : DE 148 421 329 WEEE Reg. Nr.: DE 72277043
Diese E-Mail enthält vertrauliche und/ oder rechtlich geschützte Informationen. Wenn Sie nicht der beabsichtigte Empfänger sind, informieren Sie bitte sofort den Absender und löschen Sie diese E-Mail.
The information contained in this message is confidential and/ or protected by law. If you are not the intended recipient, please contact the sender and delete this message.
-----Ursprüngliche Nachricht----- Von: Stefan Tauner [mailto:stefan.tauner@student.tuwien.ac.at] Gesendet: Mittwoch, 14. September 2011 14:03 An: Feldschmid, Ingo Cc: flashrom@flashrom.org Betreff: [SPAM?]Re: [flashrom] [PATCH] revamp the warning of failing to set BIOS write enable in enable_flash_ich
On Wed, 14 Sep 2011 13:51:04 +0200 "Feldschmid, Ingo" ifel@msc-ge.com wrote:
I checked with some boards with different Intel chipsets (some ICHx and Tunnel Creeks), and the bios write enable bit does affect the SPI bus. It will quite likely be ignored for PCI accesses, but everything that goes through the chipset is affected by this bit. So if this bit is not set, write accesses to the bios flash will not be clocked to the SPI bus.
what have you "checked" exactly? did you try clearing the bit, issuing SPI commands and looked at the physical bus? it's a pity that the public data sheets do not provide a clear statement regarding this bit.
Hi Ingo,
thanks a lot for taking the time to investigate and for sharing your results with us!
Am 14.09.2011 15:09 schrieb Feldschmid, Ingo:
I changed my local copy of the flashrom trunk to never set the write-enable-bit. Then, on the target machine, I double-checked with lspci that the bit isn't set. Next, I called "flashrom -w bios.bin" to let it try & write to the flash chip.
As a result, I got flashrom errors, telling me that it couldn't erase the chip:
Erasing and writing flash chip contents... Transaction error! spi_block_erase_20 failed during command execution at address 0xe3000 ... spi_block_erase_52 failed during command execution at address 0xe3000 ... spi_block_erase_d8 failed during command execution at address 0xe0000 ... spi_block_erase_60 failed during command execution ... spi_block_erase_c7 failed during command execution ... FAILED! Uh oh. Erase/write failed. Checking if anything changed. Good. It seems nothing was changed. Writing to the flash chip apparently didn't do anything.
Furthermore, a colleague told that they actually once have read the SPI accesses with a osci, and that no write / erase cycles have been executed without this bit set (sry don't have proof for that right now).
That's proof enough.
Now the interesting question is whether we can trick the chipset into thinking that we're not writing...
Regards, Carl-Daniel
-
Carl-Daniel Hailfinger -
Feldschmid, Ingo -
Stefan Tauner