linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andries Brouwer <aebr@win.tue.nl>
To: Hielke Christian Braun <hcb@unco.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.6.0-test1 cryptoloop & aes & xfs
Date: Mon, 21 Jul 2003 00:15:03 +0200	[thread overview]
Message-ID: <20030721001503.A11447@pclin040.win.tue.nl> (raw)
In-Reply-To: <20030720213803.GA777@jolla>; from hcb@unco.de on Sun, Jul 20, 2003 at 02:38:03PM -0700

On Sun, Jul 20, 2003 at 02:38:03PM -0700, Hielke Christian Braun wrote:

> Thanks for the tip. With util-linux-2.12 i can setup the device.
> 
> So the new cryptoloop in 2.6.0 is incompatible to the one in the
> international crypto patch?

I have not investigated. But at least the way to transmit the passphrase
is very different. These out-of-kernel patch sets also come with
patches for util-linux. Usually the resulting patched losetup uses
some cryptographically strong digest algorithm to transform the
passphrase into the byte array sent to the kernel.

But I left all crypto out of mount and losetup in util-linux 2.12.
On the one hand we already have crypto in the kernel - no need to
duplicate that. But on the other hand, the preparation of the passphrase
has also been left out. The only handle put into mount/losetup is the
ability to read from a specified file descriptor.
So, today, you would need something like

% get_passphrase | mount -o loop,encryption=aes -p0 dev dir

where get_passphrase is a separate, to be written, utility that reads
the passphrase and digestifies.

Maybe I'll make things a bit friendlier in 2.12a, for example with

% mount -o loop,encryption=aes,getpw=/usr/local/bin/get_passwd dev dir

where mount itself forks off a process that produces the password.
Comments (and code) are welcome.

> I could not access my old data. So i created a new one. But when 
> i copy some data onto it, i get: 
> 
> XFS mounting filesystem loop5
> Ending clean XFS mount for filesystem: loop5
> xfs_force_shutdown(loop5,0x8) called from line 1070 of file fs/xfs/xfs_trans.c. Return address = 0xc02071ab
> Filesystem "loop5": Corruption of in-memory data detected. Shutting down filesystem: loop5
> Please umount the filesystem, and rectify the problem(s)
>  
> To setup, i did this:
> 
> losetup -e aes /dev/loop5 /dev/hda4
> mkfs.xfs /dev/hda4

Wait! /dev/loop5 is your block device, and /dev/hda4 is the file it is setup on.
Now behind the back of loop you fiddle with /dev/hda4. No surprise that fails.

Andries


  reply	other threads:[~2003-07-20 22:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-20  0:57 2.6.0-test1 cryptoloop & aes Hielke Christian Braun
2003-07-20  8:38 ` Andries Brouwer
2003-07-20 21:38   ` 2.6.0-test1 cryptoloop & aes & xfs Hielke Christian Braun
2003-07-20 22:15     ` Andries Brouwer [this message]
2003-07-21 17:12     ` Jeff Sipek
2003-07-22  0:24       ` Hielke Christian Braun
2003-07-22 11:54         ` Jari Ruusu
2003-07-29 23:28   ` 2.6.0-test1 cryptoloop & aes Bill Davidsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030721001503.A11447@pclin040.win.tue.nl \
    --to=aebr@win.tue.nl \
    --cc=hcb@unco.de \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: 2.6.0-test1 cryptoloop & aes & xfs' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).