linux-kernel - Re: zero out blocks of freed user data for operation a virtual machine environment

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <87ab50p3ip.fsf@frosties.localdomain>
Date:	Tue, 26 May 2009 12:22:38 +0200
From:	Goswin von Brederlow <goswin-v-b@....de>
To:	Chris Worley <worleys@...il.com>
Cc:	Goswin von Brederlow <goswin-v-b@....de>,
	LKML <linux-kernel@...r.kernel.org>, linux-ext4@...r.kernel.org
Subject: Re: zero out blocks of freed user data for operation a virtual  machine environment

Chris Worley <worleys@...il.com> writes:

> On Mon, May 25, 2009 at 7:14 AM, Goswin von Brederlow <goswin-v-b@....de>
> wrote:
>
>
>                Thomas Glanzmann <thomas@...nzmann.de> writes:
>      
>      > Hello Ted,
>      >
>      >> Yes, it does, sb_issue_discard().  So if you wanted to hook into
>      this
>      >> routine with a function which issued calls to zero out blocks, it
>      >> would be easy to create a private patch.
>      >
>      > that sounds good because it wouldn't only target the most used
>      > filesystem but every other filesystem that uses the interface as
>      well.
>      > Do you think that a tunable or configurable patch has a chance to
>      hit
>      > upstream as well?
>      >
>      >         Thomas
>      
>      
>
>
>      I could imagine a device mapper target that eats TRIM commands and
>      writes out zeroes instead. That should be easy to maintain outside
>      or
>      inside the upstream kernel source.
>
>
> Why bother with a time-consuming performance-draining operation?  There are
> devices that already support TRIM/discard commands today, and once you discard
> a block, it's completely irretrievable (you'll just get back zeros if you try
> to read that block w/o writing it after the discard).
> Chris 

Because you have one of the billions of devices that don't.

Because, iirc, the specs say nothing about getting back zeros.

Because someone could read the raw data from disk and recover your
state secrets.

Because loopback don't support TRIM and compression of the image file
is much better with zeroes.

Because on a crypted device TRIM would show how much of the device is
in used while zeroing out (before crypting) would result in random
data.

Because it is fun?

So many reasons.

MfG
        Goswin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/