All right, thanks for pointing out the details and the procedure, seems legit secfreeze is issued by default.
On Thu, 2021-06-10 at 07:08 -0700, Bryan Linton wrote: > On 2021-06-10 11:49:59, Xavier Sanchez <xavie...@mailoo.org> wrote: > > > > Read somewhere that issuing a security erase could also help. So I > > tried issuing the following: > > > > # atactl sd0c secsetpass user high > > User password: > > Retype user password: > > atactl: ATA device returned error register 0 > > > > But any sec* command returned: > > atactl: ATA device returned error register 0 > > > > even after a coldboot ( non-frozen ), despite the devices supports > > the > > Security Mode feature set > > > > - Am I attempting to issue the security erase the wrong way ? > > > > This is not possible on OpenBSD. It's actually a feature, not a > bug. OpenBSD issues the secfreeze command at the driver level > when disks attach. > > From atactl(8): > > secfreeze > Prevents changes to passwords until a following power > cycle. > The purpose of this command is to prevent password > setting > attacks on the security system. After command > completion any > other commands that update the device lock mode will be > aborted. > > > You can see in src/sys/dev/ata/atascsi.c:408 and > src/sys/dev/ata/wd.c:305 that the same command is issued to all > sd(4) and wd(4) drives as a security measure. > > You're going to need to boot from a live CD/USB in order to set a > password on the drive. > > You should also double-check that your BIOS doesn't have a setting > to disable this too. I've heard that some BIOSes have a toggle > for this to help mitigate the above-mentioned password setting > attacks. > > Also, another poster mentioned that these are SMR drives. If > that's the case, then the "stuttering" speeds you described is > normal for them. SMR drives are good for storing infrequently > accessed files. They're big and they're cheap, but they're not > always very fast. > > Like the old saying goes when it comes to hard drives, "Pick any > two: cheap, fast, big". SMR drives write data in "stripes". If > you change even one bit of one byte anywhere in that stripe, the > drive has to read the entire stripe into memory, change what was > changed, then re-write the entire stripe. > > This is a limitation of the technology they use. It allows very > high density drives, but has the drawback of slowing things down a > lot whenever the drive has to re-write a stripe of data. > > > I've personally found that SMR drives are good enough for my use > case, but I wouldn't recommend them for a live database where > latency is much more critical. > > It seems like the new hierarchy is now: > > SSD >> PMR > SMR > > when it comes to speed. The inverse is true when it comes to > capacity. > > So to summarize, your drive may be working exactly as intended. >
