Subject: Re: cgd and replay
To: Pawel Jakub Dawidek <pjd@FreeBSD.org>
From: Daniel Carosone <dan@geek.com.au>
List: tech-security
Date: 08/24/2005 06:45:14
--lCt7MkQCJDO5fc2F
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 23, 2005 at 07:26:19PM +0200, Pawel Jakub Dawidek wrote:
> On Tue, Aug 23, 2005 at 11:40:38AM +1000, Daniel Carosone wrote:
> +> You clarified that you instead had individual MACs per sub-block, and
> +> could maintain integrity assuming the underlying hardware was atomic
> +> at this resolution.
> +>=20
> +> However, at this point you've negated one of your previous tenets.  If
> +> the upper layer sees each MAC+data+MAC block as a single data block,
> +> you have to have transactional integrity *at that resolution*.  Your
> +> mechanism allows you to reproduce partial write results (with either
> +> old or new mac, per physical sector) to that upper layer - but only
> +> the full old or new 8k data value is valid to the filesystem.
>=20
> Let me explain it a bit more.
>=20
> da0.auth splits 8kB into sixteen, 512-bytes pieces and authenicate those
> pieces one by one. If new MAC check fails for one piece, it tries check
> it against old MAC. Every single sector from da0 is authenticated
> separately.

Yes, that is clear, but please read what I said again.=20

The filesystem on da0.auth has no use for an 8kb sector with partial
contents from old and new versions, regardless of whether those parts
are legitimate in isolation. No such combination represents a valid
8kb sector state.

A transaction must happen completely or not at all.

You're relying on an assumption that the equivalent of this problem
doesn't happen for the 512-byte sectors of the underlying disk, and
*introducing* exactly the same problem for your upper layers.  This is
precisely the reverse of the desired solution, which would provide
integrity even where the underlying disk doesn't have that property.

No thanks.

--
Dan.

--lCt7MkQCJDO5fc2F
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (NetBSD)

iD8DBQFDC4raEAVxvV4N66cRAgC9AJ0a1ElwsuUACVVwr3P34KUCW0DqXgCcD3KT
KXzfPBf5r0e0itZhnRMyT+Y=
=pXXn
-----END PGP SIGNATURE-----

--lCt7MkQCJDO5fc2F--