Hi,
As per your suggestion, if I write a file with zero bits, it would
remap to other pages, and I might not zero the real pages. So is there
any other way that I can access the pages that a file is using?
On 7/9/06, Arjan van de Ven <[email protected]> wrote:
> On Sat, 2006-07-08 at 18:56 -0700, Avinash Ramanath wrote:
> > I am trying to zero data blocks whenever an unlink is invoked as part
> > of a secure delete filesystem.
> [
> Hi,
>
> just a question... how secure do you want to be?
> (just asking because zeros might not be the best pattern when protecting
> against government type use :)
I would be using zeroes multiple times followed by random bit patterns.
> > I tried to zero the file by writing a buffer (of file size) with
> > zeroes onto the file.
>
> that's not so nice since there is no guarantee that the filesystem or
> the disk won't remap the data blocks underneath you...
>
>
>
On Sat, 2006-08-05 at 00:55 -0700, Avinash Ramanath wrote:
> Hi,
>
> As per your suggestion, if I write a file with zero bits, it would
> remap to other pages, and I might not zero the real pages. So is there
> any other way that I can access the pages that a file is using?
there is an ioctl to find the blocks the file is in.. but still that's
only a snapshot, not a guarantee. What you really need/want is to do
this at the filesystem level, you can't reliably do it above that level.
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Hi,
I want to do this at the filesystem-level not in user-space.
I have a stackable-filesystem that runs as a layer on top of the
existing filesystem (with all the function pointers mapped to the
corresponding base filesystem function pointers, and other suitable
adjustments).
So yes I have access to the filesystem.
But the question is how can I access those particular data-blocks?
On 8/5/06, Arjan van de Ven <[email protected]> wrote:
> On Sat, 2006-08-05 at 00:55 -0700, Avinash Ramanath wrote:
> > Hi,
> >
> > As per your suggestion, if I write a file with zero bits, it would
> > remap to other pages, and I might not zero the real pages. So is there
> > any other way that I can access the pages that a file is using?
>
> there is an ioctl to find the blocks the file is in.. but still that's
> only a snapshot, not a guarantee. What you really need/want is to do
> this at the filesystem level, you can't reliably do it above that level.
>
> --
> if you want to mail me at work (you don't), use arjan (at) linux.intel.com
>
>
>
On Sat, 2006-08-05 at 10:13 -0700, Avinash Ramanath wrote:
> Hi,
>
> I want to do this at the filesystem-level not in user-space.
> I have a stackable-filesystem that runs as a layer on top of the
> existing filesystem (with all the function pointers mapped to the
> corresponding base filesystem function pointers, and other suitable
> adjustments).
> So yes I have access to the filesystem.
> But the question is how can I access those particular data-blocks?
I think you misunderstood: You need to do this in the filesystem layer
that allocates and tracks the blocks. You really can't do it outside
that...
Arjan van de Ven wrote:
> On Sat, 2006-08-05 at 10:13 -0700, Avinash Ramanath wrote:
>
>>Hi,
>>
>>I want to do this at the filesystem-level not in user-space.
>>I have a stackable-filesystem that runs as a layer on top of the
>>existing filesystem (with all the function pointers mapped to the
>>corresponding base filesystem function pointers, and other suitable
>>adjustments).
>>So yes I have access to the filesystem.
>>But the question is how can I access those particular data-blocks?
>
>
> I think you misunderstood: You need to do this in the filesystem layer
> that allocates and tracks the blocks. You really can't do it outside
> that...
On modern (>200 meg or so) disk drives, you can't do it at all without
drive-specific debug tools.
The problem is that the drive, if it detects a bad sector, may well
remap the track that the sector is on to a spare track. You then
simply cannot access the old track. The drive may or may not zero
it for you.
Any standard access will simply ignore the old copy of the track.
It may or may not be possible to retrieve/erase it with disk-drive
specific tools that the vendor won't give you anyway.
If you want to do this reliably - you need to encrypt the disk
(not with loopcrypt or dm-crypt in its current state) so you can
just throw it away.