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 <xavier.s@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.
>
No comments:
Post a Comment