RE: paging IO and 192-bit (or any non-aligned on page size) encryption

NTFSD
1

This behavior is FSD-dependent. FastFat, for example, will accept a
paging I/O write that extends beyond EOF but will round it up to the
next SECTOR size and will assume the buffer you passed in is at least
that large. Any slack space in your buffer between the byte count you
pass in and the next sector boundary will get written to disk. As far as
I can tell, on writes, it will NOT zero the slack space before writing
it out, but on reads, it will. But this behavior is CERTAINLY nothing to
depend on.

Sigurdur Asgeirsson wrote:

Hi Max,

you’re saying that the memory manager will pass you memory filled with
zeros past the file’s EOF to the paging write? I’m sure this is true,
but it’s more or less unrelated to my question, which may have been
poorly worded.
My question is this: what happens if your filter modifies the portion of
the page that sticks out past EOF, before passing the write down to the
FSD?
See, I’ve heard of encrypting filters that make use of the fact that -
at least some - FSDs write the entire page passed in to a paging write
to disk, irrespective of the write length (or at least up to the next
sector boundary), and trust that they’ll eventually read the (upto
BlockSize - 1) bytes *past* EOF back unmolested to reverse the
encryption.
If it’s safe to trust to this behaviour, that FSDs are Sector or Page
granular on paging reads and writes, then you can assume in your filter
that, irrespective of the file’s EOF (as long as it’s >0), you’ll have
access to no less than SectorSize bytes of storage.

Siggi

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Tuesday, July 08, 2003 11:53 PM
To: File Systems Developers
Subject: [ntfsd] RE: paging IO and 192-bit (or any non-aligned on page
size) encryption

>This does however beg a question for me: is it in general safe to

handle the last page of a

>file as a full page or sector, and encrypt it as such, irrespective

of the write length? I guess

The last page or sector in the file is always padded with zeroes.

Max

You are currently subscribed to ntfsd as: xxxxx@greenborder.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

You are currently subscribed to ntfsd as: xxxxx@nryan.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

–

  • Nick Ryan (MVP for DDK)
2

Of course, unless somebody with an evil filter driver sends down paging
I/O writes with its own data in the slack space. But now I see that the
read path is going to zero the corrupted slack space on the way back up
anyways, so even though the slack space can be dirtied, no reader is
ever going to see it. So much for evil filter drivers…

Maxim S. Shatskih wrote:

>I can tell, on writes, it will NOT zero the slack space before

writing

>it out, but on reads, it will.

So, a cache miss on the last page will result in slack space zeroed in
read path.
Then a lazy write of this same page (if it was dirtied) will write the
zeroed slack space.

The result is FASTFAT keeping slack space zeroed.

Max

You are currently subscribed to ntfsd as: xxxxx@nryan.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

–

  • Nick Ryan (MVP for DDK)