> OK, so we're looking for the buffer_head for block 101 and the first
> buffer_head which is attached to the page represents block 100. So the
> next buffer_head _should_ represent block 101. Please print it out:
Not quite the same, but simelar:
Feb 23 14:50:24 localhost kernel: __find_get_block_slow() failed. block=102,
b_blocknr=128, next=129
Feb 23 14:50:24 localhost kernel: b_state=0x00000013, b_size=2048
Feb 23 14:50:24 localhost kernel: device blocksize: 2048
Feb 23 14:50:24 localhost kernel: ------------[ cut here ]------------
> Could be UFS. But what does "transparent block encryption and sector
> shuffling" mean? How is the sector shuffling implemented?
GDBE is a block level encrypter. It encrypts the actual sectors
transparently via the GEOM API (corresponds to the devicemapper api in linux).
GBDE assigns a key for each block, thereby introducing keysectors.
Furthermore the sectors are remapped so that one can not guess where e.g.
metadata is located on the physical disk. It is a rather simple remap:
Taken from GDBE:
/*
* Convert an unencrypted side offset to offsets on the encrypted side.
*
* Security objective: Make it harder to identify what sectors contain what
* on a "cold" disk image.
*
* We do this by adding the "keyoffset" from the lock to the physical sector
* number modulus the available number of sectors. Since all physical sectors
* presumably look the same cold, this will do.
*
* As part of the mapping we have to skip the lock sectors which we know
* the physical address off. We also truncate the work packet, respecting
* zone boundaries and lock sectors, so that we end up with a sequence of
* sectors which are physically contiguous.
*
* Shuffling things further is an option, but the incremental frustration is
* not currently deemed worth the run-time performance hit resulting from the
* increased number of disk arm movements it would incur.
*
* This function offers nothing but a trivial diversion for an attacker able
* to do "the cleaning lady attack" in its current static mapping form.
*/"
Further reading:
http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf
Regards Thomas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
