0

I'm attempting to modify this project to include a call to dd to wipe the LUKs header of a disk.

Here is what I have:

static void panic_time(struct usb_device *usb)
{
    int i;
    struct device *dev;
    char *dd_argv[] = {
        "/bin/bash",
        "-c",
        "/bin/dd if=/dev/urandom of=/dev/sda5 bs=512 count=4096",
        NULL
    };

    pr_info("shredding...\n");
    for (i = 0; remove_files[i] != NULL; ++i) {
        char *shred_argv[] = {
            "/usr/bin/shred",
            "-f", "-u", "-n",
            shredIterations,
            remove_files[i],
            NULL,
        };
        call_usermodehelper(shred_argv[0], shred_argv,
                    NULL, UMH_WAIT_EXEC);
    }

    pr_info("...done.\n");

    pr_info("deleting LUKs header...\n");

    call_usermodehelper(dd_argv[0], dd_argv, NULL, UMH_WAIT_PROC);

    pr_info("...done.\n");

    pr_info("Syncing & powering off.\n");
    for (dev = &usb->dev; dev; dev = dev->parent)
        mutex_unlock(&dev->mutex);
    kernel_power_off();
}

However this doesn't work. The system either fails to run the dd command or shuts down before the call is complete.

I am aware of other options given to call_usermodehelper with namely UMH_WAIT_EXEC - but I've used all 4 with to avail.

  1. How can I ensure that a kernel module has permission to run the dd command?
  2. How can I delay the shutdown to wait for the dd command to finish?
Agent Smith
  • 1

1 Answers1

0

i don't understand how you concluded the system shutdowns before dd run is complete. there is 0 error checking after the call, thus you can't tell what happened in the first place.

the entire module looks rather peculiar

if storage is to be scrapped anyway, i suspect there is a nice way to create a one-time key and store it in memory (thus rendering the point of scrapping the header moot).

also note that despite its claims the module does not scrap ram.

  • I said the system shuts down either before `dd` is complete or `dd` does not have the correct permissions to run. This is evident from the fact that the system is still bootable. Running the same command on the terminal before shutting down renders the system unbootable. [Related](https://stackoverflow.com/questions/40385836/why-does-call-usermodehelper-fail-most-of-the-times) – Agent Smith Aug 21 '17 at 11:59
  • I edited the code to return the result. `dd` error code is 0. Still not sure why that vs running on the command line is giving a different result. – Agent Smith Aug 21 '17 at 12:14
  • now this is getting quite weird. i don't see the problem off hand. my suggestion is to temporarily remove all the code in this "panic" func and just leave your dd invocation. if that fails, you have a much simpler starting point. you can even run a script which will log what it's doing. –  Aug 21 '17 at 21:11