SG Enterprise encryption - Bad Sectors survey

I had a very similar problem on a laptop. I get a block of about 96MB's of bad sectors appear for no real reason on a brand new machine (less than a month old). I reset back to day one and bad sectors were no longer present. I then proceeded to encrypt again but within a few days, the same 96MB's were back.
 
Obviously when restoring the original image, the bad sector definitions were wiped out and it actually turned out to be a duff disk rather than anything SGN had introduced. Disk zeroing is likely to have done exactly the same thing to you, wiping out the bad sector tables then leaving the disk in a state where it has to re-discover them again. What I'd be inclined to do is a fresh wipe, and then run a chkdisk /r on an unencrypted disk which will do a much more intensive surface scan across all sectors rediscovering any bad sectors. If there are truly any bad ones there, they'll show up again and you should be able to determine if this is an SGN issue or simple hardware failure.

Matt

Hi Matt, thanks.  That is in line with my thought process.  I'm just hoping it does not happen too often (making Safeguard look too sensitive).  I affectionaly refer to Safeguard as the, "Truth serum" as it exposes underlying problems on the hard drive. 

96Mb of bad sectors you're seeing is Safeguard Enterprise kernel -- Utimaco installs its kernel (which is about 96Mb) and marks it as bad in NTFS so Windows is not accidentally writing any data to it. 96Mb of bad sectors is NOT an indicator of a bad drive. I suggest using SpinRite or HDD Regenerator to check the drive for errors.
Good luck!

Nope, in this instance, it was a faulty drive and it had 96MB's of bad sectors. As per my post, I ran chkdsk /r to look at the disk after reimaging and it had 96MB's of bad sectors without Utimaco/Sophos installed. Now that a new disk is fitted, the machine reports 0 bad sectors with SGN5.50 so I don't follow where you think Sophos is marking the area the kernel is installed in as bad. I can understand it marking it as a system area so that defrag won't touch it but it would be a very bad thing IMHO to mark it bad. Can you point to where you found your information?

Matt

Hi all,

thank you very much for bringing up this topic. Please let me add my two cents...

Actually the given explanation is correct. When installing SafeGuard Enterprise we write the so called Kernel to the drive. The kernel area is at 96MB and we mark this section as bad. This area is needed to store the Power on Authentication (POA) and the freeBSD to load the POA.

When running a chkdsk on a system that has SGN installed there will always be at least 96 MB of bad sectors showing up - which indeed is the kernel area. Actually it is true that these sectors are not really bad sectors (physically damaged) anyway the bad sector mark must not be removed.

As a result of this we highly recommend not to use chkdsk /r on a machine that has SafeGuard Enterprise installed - instead of this please use chkdsk /l /f /v /x

Also it is better to use an external tool to check the general health status of the drive.

Last but not least we recommend to check the drive before installing SafeGuard Enterprise using CHKDSK > at this point (and only here) chkdsk /r can be used if desired, however, we recommend to replace a drive rather than installing SafeGuard Enterprise if bad sectors are found beforehand.

I hope I could clarify things a little bit :smileyhappy:

Regards

Dan

Hi Dan,

I just checked a 5.50 install and yes, 98,xxxKB bad sectors. This isn't the same though as the 96MB's spotted previously on a disk I had without Utimaco installed. Please read my earlier post where I suggest chkdsk /r on a non encrypted - pre SGN install.

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!

Matt

Thanks again all for the feedback on this.  Fortunately we haven't detected any more bad sectors.  From a support perspective, bad sectors with SG is tricky as the problems seem to manifest in many different ways,making it hard to troubleshoot.  Big shops probably swap the machine out and move on.  We are a small company and do not have an armada of spares.  I'm beginning to wonder if we should schedule a monthly "chkdsk /l /f /v /x" (export results to a file) so we can monitor this.  Hopefully we can do this in a way that does not impact the users much.  JB

Hi JB,

I schedule a simple "chkdsk > c:\chklog.txt". I don't put any switches on expecially /f because you cannot do that in the background on the system drive anyway so it's pointless. In this very simple mode, it reports the state of the disk without fixing anything and is not particularly hard-hitting on the drive so the users don't really notice the task in the background (especially if we time the task correctly). We then have a job that runs on the server and checks the size of the log file on each machine it can see. If the log is larger than a specific size, we investigate further and If on further investigation we find bad sectors or other nasties, we schedule more vigorous maintenance on the machine therefore a considerably pro-active approach to disk maintenance. With SGN creating 'good' bad sectors, this becomes very difficult to establish what's good from what's bad. SGE never used to do this and we're just going with SGN now as we migrate to Win 7. My initial impressions are that SGN is not as well thought out as the competition. I have 50 seats of SGE mostly running 4.40 or 4.50 with a full SGN maitenance contract so I'm not a huge company by any means either.

Matt

Very helpful.  Thanks Matt!

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,