SG Enterprise encryption - Bad Sectors survey

Hi MawfTech,

you wrote:

Reading on though, your method used is a very VERY BAD IDEA! Using that method, I now have no way of knowing impending surface failure on a drive without running a long diagnotic test. You should be aware that small drives IDE/SATA have no controller head avoidance built in so that new surface defects discovered after factory release have to be recorded by the overlying format itself. If a surface becomes scratched or pitted, the heads will still continue to pass over bad sectors and eventually rub off portions of the heads eventually causing catastrophic disk failures. SCSI/SAS drives have built-in avoidance algorythms such that a bad sector are recorded by the on-board controller and avoided by the heads and therefore can cope quite adequately with small failures for many years. By writing the kerneal area as bad sectors, you're now removing the ability for us guys to spot impending failures early. Yes, I'm aware that I can use tools like spinrite to fully analyse surfaces, but when was the last time you managed to wrench a machine away from a user for hours just to run diagnostics every 'n' weeks. A simple chkdsk (with no switches) is an excelent tool to show up impending issues and can be kicked off remotely in the backround while the user continues to work.

It would be significantly better for the Kernel to be placed in hidden portions of the disk or format (which is well documented and well used by pretty much every machine manufacturer) and not written as bad sectors. Even writing the area as system-protected like the paging file or hyberfil would be better so that it won't get moved by e.g. defrag or similar tools. Bad sectors tells me the Utimaco team don't really understand hard drive architecture and that is most worrying!

Your idea regarding pagefile.sys and hiberfil.sys will not work. You forgot that they are on an encrypted partition. It is a hen and egg problem if you store the pre-boot code in normal sectors of the encrypted drive: You simply would not be able to boot, the sectors are encrypted. Additionally it is extremely risky to store the pre-boot code in a file which can be seen in the OS. If somebody is able to manipulate or delete the file, you cannot access the keys any longer (it does not matter for pagefile and hiberfil, because the OS can re-create them; but the pre-boot code and its keys will be gone).

It is common practice for hard disk encryption products to hide pre-boot code in “false” bad sectors. Only a few products don’’’’t use bad sectors, e.g. requiring an extra partition. This is more cumbersome and would require partition changes before installing a hard disk encryption product – which increases roll-out time.

There are only those two ways: separate partition or bad sectors. Bad sectors are, as I said, used throughout the industry for more than a decade and this is state-of-the-art technology. It does not interfere with SCSI algorithms. And if you use chkdsk, please reduce 96MB for a system encrypted with SafeGuard Enterprise to calculate the actual number of bad sectors.

PS: Even SafeGuard Easy 4.x used bad sector handling to hide its pre-boot code.

With compliments,

Hi MawfTech,

you wrote:

Reading on though, your method used is a very VERY BAD IDEA! Using that method, I now have no way of knowing impending surface failure on a drive without running a long diagnotic test. You should be aware that small drives IDE/SATA have no controller head avoidance built in so that new surface defects discovered after factory release have to be recorded by the overlying format itself. If a surface becomes scratched or pitted, the heads will still continue to pass over bad sectors and eventually rub off portions of the heads eventually causing catastrophic disk failures. SCSI/SAS drives have built-in avoidance algorythms such that a bad sector are recorded by the on-board controller and avoided by the heads and therefore can cope quite adequately with small failures for many years. By writing the kerneal area as bad sectors, you're now removing the ability for us guys to spot impending failures early. Yes, I'm aware that I can use tools like spinrite to fully analyse surfaces, but when was the last time you managed to wrench a machine away from a user for hours just to run diagnostics every 'n' weeks. A simple chkdsk (with no switches) is an excelent tool to show up impending issues and can be kicked off remotely in the backround while the user continues to work.

It would be significantly better for the Kernel to be placed in hidden portions of the disk or format (which is well documented and well used by pretty much every machine manufacturer) and not written as bad sectors. Even writing the area as system-protected like the paging file or hyberfil would be better so that it won't get moved by e.g. defrag or similar tools. Bad sectors tells me the Utimaco team don't really understand hard drive architecture and that is most worrying!

Your idea regarding pagefile.sys and hiberfil.sys will not work. You forgot that they are on an encrypted partition. It is a hen and egg problem if you store the pre-boot code in normal sectors of the encrypted drive: You simply would not be able to boot, the sectors are encrypted. Additionally it is extremely risky to store the pre-boot code in a file which can be seen in the OS. If somebody is able to manipulate or delete the file, you cannot access the keys any longer (it does not matter for pagefile and hiberfil, because the OS can re-create them; but the pre-boot code and its keys will be gone).

It is common practice for hard disk encryption products to hide pre-boot code in “false” bad sectors. Only a few products don’’’’t use bad sectors, e.g. requiring an extra partition. This is more cumbersome and would require partition changes before installing a hard disk encryption product – which increases roll-out time.

There are only those two ways: separate partition or bad sectors. Bad sectors are, as I said, used throughout the industry for more than a decade and this is state-of-the-art technology. It does not interfere with SCSI algorithms. And if you use chkdsk, please reduce 96MB for a system encrypted with SafeGuard Enterprise to calculate the actual number of bad sectors.

PS: Even SafeGuard Easy 4.x used bad sector handling to hide its pre-boot code.

With compliments,