Bug 57947 - incorporate loop-AES patch into Red Hat kernel?
incorporate loop-AES patch into Red Hat kernel?
Status: CLOSED DEFERRED
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
http://loop-aes.sourceforge.net/
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-01-02 17:55 EST by James Ralston
Modified: 2007-04-18 12:38 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-01-02 17:55:36 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description James Ralston 2002-01-02 17:55:31 EST
It would be very nice to have the loop-AES project patches integrated into
the Red Hat kernel (or, even better, the official kernel).

Currently, it doesn't seem to be possible to have loopback encryption. 
With these RPMs:

    kernel-2.4.9-13
    losetup-2.11g-5
    mount-2.11g-5

...the "-e DES" option to losetup does not appear to work:

    # losetup /dev/loop0 /var/tmp/loop-zQhvvY
    # losetup -d /dev/loop0
    # losetup -e DES /dev/loop0 /var/tmp/loop-zQhvvY
    Password: ********
    Init (up to 16 hex digits): ****************
    ioctl: LOOP_SET_STATUS: Invalid argument

Anyway, if you already have something other/better than loop-AES in mind,
I'm all ears.  But otherwise, it'd be really nice to have it included by
default.
Comment 1 Arjan van de Ven 2002-01-09 08:29:41 EST
Sorry for the delay in answering.
I've checked with legal for the situation re crypto vs US exports and that seems
ok so I've put "crypto loop" on the list of things I'm going to look at for the
next version of Red Hat Linux. Personally I like the idea of being able to have
encrypted filesystems; I'll check the implementation (to see if it's in a
mergable state) shortly.

I'm changing the state of this bug as "deferred" as the patch isn't merged yet
but hopefully will be soon.
Comment 2 James Ralston 2002-01-29 16:54:16 EST
Thanks for looking into this.

These are the only "gotchas" I could find:

1.  I suspect the optional DES package has never been added to Red Hat kernels
(which is why I could never get "losetup -e DES" to work).  However, if I'm
incorrect, and "-e DES" *is* actually supported, then the loop-AES patch will
break the DES support.

2.  The mount and losetup programs (and their man pages, of course) will need to
be updated as well.  (The loop-AES patch contains the necessary patches.)

Again, thanks for looking into this.  Hopefully the loop-AES will be integrated
in the kernel of the next version of Red Hat...
Comment 3 James Ralston 2002-06-24 22:13:43 EDT
Well, obviously this didn't make it into 7.3.

Any word on this?

Since I've been forced to build by own kernel RPMs (to get support for
my new motherboard's VIA vt8233a southbridge), I'm going to go ahead
and try integrating the AES loopback support myself.  If it works,
I'll come back and attach a patch against 2.4.18-5...
Comment 4 James Ralston 2002-07-16 16:11:03 EDT
Ack.

There's no way to integrate the AES loopback support.  Essentially, both Red Hat
and the loop-AES project patch the hell out of drivers/block/loop.c. 
Reintegrating the changes every time either Red Hat or the loop-AES guys updates
its patches would be a nightmare.

The only way I can see this working is if at least one of you manages to get
your patches put into the official kernel source.  That way, the patch
integration would only have to be done once.

Thanks to U.S. export issues, I don't have much faith that the loop-AES project
can be integrated into the official kernel distribution.  So, is there any
chance that Red Hat would submit its drivers/block/loop.c patches back to Linus?
 (And is there any chance he would accept them?)

Note You need to log in before you can comment on or make changes to this bug.