Implementing ATA Secure Erase

[Knogle]

Hey, how are you doing.
I am currently gathering some random ideas in my head regarding the ATA secure erase method.
Currently i am starting with a stand alone C implementation, and if it works properly i will try to port it to nwipe.
How should it look like inside the GUI?

That's my current approach.

#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <errno.h>
#include <string.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <scsi/sg.h>
#include <linux/hdreg.h>

#define ATA_CMD_SECURITY_ERASE_PREPARE 0xF3
#define ATA_CMD_SECURITY_ERASE_UNIT 0xF4

int send_ata_command(int fd, unsigned char command, unsigned char *buffer, size_t buf_len, int is_write) {
    sg_io_hdr_t io_hdr;
    unsigned char cdb[16] = {0};
    unsigned char sense[32] = {0};

    // CDB for ATA PASS THROUGH (12 bytes)
    cdb[0] = 0xA1; // OPERATION CODE (ATA PASS THROUGH)
    cdb[1] = (is_write ? 0x06 : 0x04); // PROTOCOL (PIO Data-In/Out)
    cdb[2] = (1 << 3); // FLAGS
    cdb[3] = 0x0E; // FEATURES
    cdb[4] = command; // COMMAND
    cdb[5] = 0x00; // RESERVED
    cdb[6] = 0x01; // SECTOR COUNT
    cdb[7] = 0x00; // LBA LOW
    cdb[8] = 0x00; // LBA MID
    cdb[9] = 0x00; // LBA HIGH
    cdb[10] = 0x00; // DEVICE
    cdb[11] = 0x00; // RESERVED

    memset(&io_hdr, 0, sizeof(sg_io_hdr_t));
    io_hdr.interface_id = 'S';
    io_hdr.cmd_len = sizeof(cdb);
    io_hdr.mx_sb_len = sizeof(sense);
    io_hdr.dxfer_direction = is_write ? SG_DXFER_TO_DEV : SG_DXFER_FROM_DEV;
    io_hdr.dxfer_len = buf_len;
    io_hdr.dxferp = buffer;
    io_hdr.cmdp = cdb;
    io_hdr.sbp = sense;
    io_hdr.timeout = 20000; // 20 seconds

    if (ioctl(fd, SG_IO, &io_hdr) < 0) {
        perror("ioctl SG_IO failed");
        return -1;
    }

    return 0;
}

int main(int argc, char *argv[]) {
    int fd;

    if (argc < 2) {
        printf("Usage: %s <device>\n", argv[0]);
        return 1;
    }

    fd = open(argv[1], O_RDWR | O_NONBLOCK);
    if (fd < 0) {
        perror("Error opening device");
        return 1;
    }

    // Prepare the drive for erase
    if (send_ata_command(fd, ATA_CMD_SECURITY_ERASE_PREPARE, NULL, 0, 0) < 0) {
        printf("Failed to prepare drive for erase.\n");
        close(fd);
        return 1;
    }

    // Execute the erase
    if (send_ata_command(fd, ATA_CMD_SECURITY_ERASE_UNIT, NULL, 0, 0) < 0) {
        printf("Failed to erase drive.\n");
        close(fd);
        return 1;
    }

    printf("Drive %s erased successfully.\n", argv[1]);
    close(fd);
    return 0;
}

[PartialVolume]

As a new method would probably be a good start. The drive status in terms of whether it is frozen will need to be determined when the drives are enumerated and then a sequence initiated that sends the computer to sleep for 5 seconds and then wakes it which will unfreeze the drive so that the erase command can be issued. The interface will also need to cope with the selection of standard and enhanced ATA secure erase. Adding secure erase is a major bit of work that will involve working in every part of nwipe. It will need extensive testing.

re: aes-ctr prng
BTW the AES code is still not working properly. I've not reported on it yet as I need to write some additional code that debugs the AES code and provides additional data. I don't yet understand why you don't see the verification errors when you do a 24 disc loop drive test but maybe it has to do with the fact the writes to the loop drives will be sequential in nature as all the loop drives are on one disc. Where as a real world test on 16+ drives has writes occuring at the same time. I'll know more once I get round to looking at the actual data being produced by aes. If possible you may want to try testing on at least 16 drives of varying sizes on a server.

[PartialVolume]

Another consideration with secure erase is how progress is represented. We don't know how far the wipe has progressed. Depending on the drive it could take seconds to several hours to complete. It's not just SSDs that support secure erase. The drive does provide a estimate of how long it would take which we can use, but representing that as a percentage in my opinion would not be good as it might complete before it reaches 100% or after which would make our percentage progress look broken. I would prefer a T-value/T+value much like a countdown to rocket launch. The T- being estimated time to completion T-HH:MM:SS. If it tools over it goes T+00:00:01 etc. So the GUI would need to be aware of the estimated wipe time obtained from the drive and maintain that.

In terms of methods you could have a standard Secure Erase and a Enhanced secure erase. You would also want a third method that combined Secure erase, immediately followed by a prng wipe and maybe a fourth secure erase plus zero.

You also need to think about verification. You can't assume the drive secure erases with zeros, some erase with a pattern. The verification code would need to examine several hundred random blocks on the disc and determine what method the drive used. Was it all zeros, all ones or a pattern, does the pattern repeat in a consistent way. Is it random data in which case it can't be verified. Depending on the pattern or whether it's zeros or ones the verification pass would need to choose the correct verification to use. So I'm essence we would need a smart verification function, in addition to the existing random and zeros verification functions.

Because this delves into almost all parts of nwipe there is a large possibility of breaking existing code so you really need to understand how every part of nwipe works together so you don't break existing code.

If it was me and I had only just started working on the code I'd start with something smaller like adding a option to select either a zeros or ones blanking pass. You would need to look at all the methods, the GUI code for adding the ones blanking option and presumably you could utilize the existing write ones function. Why ones blanking pass? Some people prefer writing ones to a SSD than zeros. Personally for SSDs I prefer the secure erase followed by a prng pass as I like to makesure there are no stuck bits in data buses which might be missed by a all zeros or all ones pass.

[Knogle]

Oh I see! This will be a tough one. I was expecting, Secure Erase would always set all blocks to zero. But if there is no standardized method it will require quite a lot of work it seems. But I think we can do it :)

Regarding AES: Can you maybe try the variant in my aes-ctr-cpp-smartptr branch?
It should make any cleanup process obsolete.

I'm curretly trying to reproduce this issue. Unfortunately i only have 7 hard drives, maybe it only occurs with much more.

[mdcato]

Just to reinforce what @***@***.***> wrote, some SSDs have all-zeros and all-ones reserved sectors/blocks so that writing either merely changes the sector/block pointer to one of the reserved ones, meaning the original sector/block is untouched and still may contain sensitive data. Pointing all sectors/blocks to a reserved block may be what’s happening with the SSD’s built-in secure erase as it finishes in seconds. Nwipe’s purpose is to make sure all data is erased beyond recovery, so the PRNG methods should be used, and (again from previously reading white papers) the all-ones write as last pass may result in lower power consumption for the SSD. And, we cannot depend on any one model’s documentation as subsequent SSD firmware could change the behavior of reserved blocks and the built-in secure erase function. We have to assume any SSD’s firmware is using the quick “cheat” of repointing blocks to the reserved ones and therefore needs to have all blocks overwritten. From: PartialVolume ***@***.***> Sent: Sunday, March 31, 2024 21:43 To: martijnvanbrummelen/nwipe ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [martijnvanbrummelen/nwipe] Implementing ATA Secure Erase (Discussion #568) Another consideration with secure erase is how progress is represented. We don't know how far the wipe has progressed. Depending on the drive it could take seconds to several hours to complete. It's not just SSDs that support secure erase. The drive does provide a estimate of how long it would take which we can use, but representing that as a percentage in my opinion would not be good as it might complete before it reaches 100% or after which would make our percentage progress look broken. I would prefer a T-value/T+value much like a countdown to rocket launch. The T- being estimated time to completion T-HH:MM:SS. If it tools over it goes T+00:00:01 etc. So the GUI would need to be aware of the estimated wipe time obtained from the drive and maintain that. In terms of methods you could have a standard Secure Erase and a Enhanced secure erase. You would also want a third method that combined Secure erase, immediately followed by a prng wipe and maybe a fourth secure erase plus zero. You also need to think about verification. You can't assume the drive secure erases with zeros, some erase with a pattern. The verification code would need to examine several hundred random blocks on the disc and determine what method the drive used. Was it all zeros, all ones or a pattern, does the pattern repeat in a consistent way. Is it random data in which case it can't be verified. Depending on the pattern or whether it's zeros or ones the verification pass would need to choose the correct verification to use. So I'm essence we would need a smart verification function, in addition to the existing random and zeros verification functions. Because this delves into almost all parts of nwipe there is a large possibility of breaking existing code so you really need to understand how every part of nwipe works together so you don't break existing code. If it was me and I had only just started working on the code I'd start with something smaller like adding a option to select either a zeros or ones blanking pass. You would need to look at all the methods, the GUI code for adding the ones blanking option and presumably you could utilize the existing write ones function. Why ones blanking pass? Some people prefer writing ones to a SSD than zeros. Personally for SSDs I prefer the secure erase followed by a prng pass as I like to makesure there are no stuck bits in data buses which might be missed by a all zeros or all ones pass. — Reply to this email directly, view it on GitHub<#568 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ANGK2PQXSUZL37WEQ3IHKVLY3DCTLAVCNFSM6AAAAABFQYJJJKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DSNRYGU3DS>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>