All of lore.kernel.org
 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 \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.