Other EFI, IEEE1667 etc. for external drive

[YuryG]

I've bought an external portable USB3 HDD drive which claims to support IEEE 1667 and has this partitioning from the manufacturer:

# gpart show /dev/da0
=>        34  7814037100  da0  GPT  (3.6T)
          34           6       - free -  (3.0K)
          40      409600    1  efi  (200M)
      409640        2008       - free -  (1.0M)
      411648  7813623808    2  ms-basic-data  (3.6T)
  7814035456        1678       - free -  (839K)

So, some questions emerged on the occasion.
1) Is there need for that EFI partition (and I do not see FreeBSD shows some access to it). I do not plan to boot from the drive.
2) If not, I should gpart it new, shouldn't I? I've planned two partitions on it: FAT32 and UFS2 (for compatibility and for productivity and robustness).
3) Is there any support (or needed support) for IEEE 1667 from FreeBSD, since Windows shows some "Control" device when the disc attached and the disc icon is with a lock sign in Windows' file manager. But no specific messages concerning this IEEE 1667 in FreeBSD's dmesg.

 

[SirDice]

Is there need for that EFI partition (and I do not see FreeBSD shows some access to it). I do not plan to boot from the drive.

Then no, it's not needed. It's only a requirement to EFI boot the disk.

If not, I should gpart it new, shouldn't I?

You can use gpart destroy to completely remove the existing partitioning scheme and create a new, fresh one or gpart delete and remove each of the existing partitions. It doesn't matter which route you take.

 

[Mjölnir]

I would leave the EFI partition. It's only 0.005% of the total size. Maybe some time in the future you want to boot from it, or sell it, or or or...

 

[YuryG]

And anything about IEEE 1667?

 

[olli@]

FreeBSD does not support IEEE 1667. But you don’t need it if you don’t plan to encrypt the drive.

PS: When I buy a new drive, I usually ignore everything supplied by the manufacturer and create partitions from scratch.

 

[Mjölnir]

I did not find anything related in the sources ( grep -Rl '1667' /usr/src, same for /src/13-CUR/). Just plug it in, it should be detected & accessible/usable. EDIT I guess olli@ means encryption by the method provided by the drive's firmware. You can still use your OS's method to encrypt the data on the drive. 2nd, I'd suggest ZFS not UFS. It's compatible, too, at least Linux can access it. For Windows I do not know, you'll have to search yourself.

 

[olli@]

I guess olli@ means encryption by the method provided by the drive's firmware.

Well, yes, I meant encryption through IEEE 1667 because that’s what he was asking for. He may enable it using Windows’ “eDrive” feature. But FreeBSD does not provide support for that.

(Edit: This is also the reason why there is an EFI partition. It’s required to support IEEE 1667.)

 

[YuryG]

FreeBSD does not support IEEE 1667. But you don’t need it if you don’t plan to encrypt the drive.

PS: When I buy a new drive, I usually ignore everything supplied by the manufacturer and create partitions from scratch.

At places it is written that it is «internal transparent encryption as a part of a device» (for one could not use the magnetic/SSD disc inside of a device without its interface microchips??? where one can see the security? only that if encryption microchip dies the disc becomes unrecoverable because all written is so strangely encrypted), and there was no mentioning of this feature in any product description I saw before the buy, only when I plugged the disc into a Windows machine. (Although someone could add a layer of password-encryption above all that internal nonsensical (in my opinion) encryption, somehow.)
(Is it me, or devices become too «smart» to have possibilities and do things that its' users do not aware about.)

 

[Mjölnir]

(Is it me, or devices become too «smart» to have possibilities and do things that its' users do not aware about.)

Maybe you're getting old Try to find out how to disable that. Windows disk device manager might offer that. Not the cheap one, right click Windows menu, there's another one, IIRC.

 

[olli@]

At places it is written that it is «internal transparent encryption as a part of a device» (for one could not use the magnetic/SSD disc inside of a device without its interface microchips??? where one can see the security? only that if encryption microchip dies the disc becomes unrecoverable because all written is so strangely encrypted), and there was no mentioning of this feature in any product description I saw before the buy, only when I plugged the disc into a Windows machine. (Although someone could add a layer of password-encryption above all that internal nonsensical (in my opinion) encryption, somehow.)
(Is it me, or devices become too «smart» to have possibilities and do things that its' users do not aware about.)

Maybe you mean SED (self encrypting drive)? That’s something different. SED works transparently for the OS (and the user). One of its advantages is the “secure erase” function, which simply makes the drive regenerate the internal encryption key, so all the data stored so far cannot be decrypted anymore. This is fast and efficient. If the drive didn’t support SED, a secure erase has to overwrite the whole storage (including any spare sectors, unmapped sectors, and sectors that have been taken out of service because of errors) – obviously this takes a long time and increases wear on SSDs.

For drive-assisted encryption there are quite a lot of standards. The most popular ones are probably TCG Opal and IEEE 1667. Windows uses these for its “eDrive” feature, for example. All of this is quite complex, it cannot be thoroughly explained in a forum article. If you’re interested in these kind of things, I invite you to search the web for the names mentioned above. Wikipedia might be a good start.

 

[YuryG]

Maybe you mean SED (self encrypting drive)? That’s something different. SED works transparently for the OS (and the user). One of its advantages is the “secure erase” function, which simply makes the drive regenerate the internal encryption key, so all the data stored so far cannot be decrypted anymore. This is fast and efficient. If the drive didn’t support SED, a secure erase has to overwrite the whole storage (including any spare sectors, unmapped sectors, and sectors that have been taken out of service because of errors) – obviously this takes a long time and increases wear on SSDs.

For drive-assisted encryption there are quite a lot of standards. The most popular ones are probably TCG Opal and IEEE 1667. Windows uses these for its “eDrive” feature, for example. All of this is quite complex, it cannot be thoroughly explained in a forum article. If you’re interested in these kind of things, I invite you to search the web for the names mentioned above. Wikipedia might be a good start.

IEEE 1667 and SED (somehow they are closely connected), and I cannot turn it off from (my version of) Windows, only from manufacturer's software (SeaTools), as far as I can see it now.

 

[olli@]

IEEE 1667 and SED (somehow they are closely connected)

No, basically you can have one without the other. In practice, I think all drives supporting IEEE 1667 are also SED drives (not vice versa!), but that’s probably just because SED technology is much older than IEEE 1667 or TCG Opal. Again, I invite you to look for the details on the web.

and I cannot turn it off from (my version of) Windows, only from manufacturer's software (SeaTools), as far as I can see it now.

There is no need to turn SED off. Why would you want to?

And as far as IEEE 1667 is concerned: All drives that I know are shipped with IEEE 1667 turned off. So you have to turn it on yourself in the first place. Once you have turned it on, it is indeed somewhat difficult to turn it off again, and you’ll lose all of the data on it, but that’s intentional because otherwise it wouldn’t really be secure.