I’ve written on here before about major bugs in the PGP platform for whole disk encryption. Fairly recently it was discovered that there exists a bug with the latest version of PGP Desktop (specifically, whole disk encryption), with machines that are running the new Intel Sandy Bridge architecture with certain hard drives. On the new 2011 Macbook Pro’s this manifests itself after the drive is instrumented and encryption started. If you happen to reboot the machine (even after a full encrypt) you can get past the boot guard, only to be faced with a hung system at the Apple logo. Decrypting the drive (using target disk mode) does not resolve the issue, and running fsck shows the catalog file to be corrupted and unrecoverable.
Initially we thought this issue to be specific to the Mac platform, however further testing has shown this to be a problem with ANY platform running Sandy Bridge. Specifically, I’ve seen this issue on Macbook Pro 8,2 models with the 750GB hard drives as well as with SSD’s as well as with new Dell laptops running Sandy Bridge and equipped with SSD’s.
For the Mac side of the house, a solid week of testing has allowed me to find two workarounds. It would appear that forcing the OS to boot into 32 bit mode (perpetually), then installing PGP and encrypting, resolves the issue. Unfortunately you also lose the benefit of running in native 64 bit mode. This is less than ideal. For Mac’s that are running with the Apple provided SSD’s you can also resolve this by placing a jumper on the left two jumper pins on the right side of the rear of the drive (there are four pins, they should be obvious), then doing a fresh install of the OS. At the moment I do not know specifically what that jumper configuration does (I can’t get a straight answer out of Toshiba), but I do know that it fixes the issue and allows for encryption to work. I’ve been running this configuration in my Sandy Bridge MBP 15″ for a few days now, fully encrypted, without any issues.
To date I do not have a workaround for the Dells. This is a major issue and Symantec has not made a widespread announcement on their encryption blog warning consumers. I have been in contact with Symantec regarding this issue (including working with one of their developers to perform testing and help narrow down where the problem exists), but as of yet have not heard a definitive answer as to what the cause is.
I will post updated information as it becomes available.











