linux-kernel - Re: An idea .... with code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <200298.8282.qm@web33207.mail.mud.yahoo.com>
Date:	Wed, 27 Aug 2008 18:24:02 -0700 (PDT)
From:	jassi brar <jassi_singh_brar@...oo.com>
To:	Kasper Sandberg <lkml@...anurb.dk>,
	Andi Kleen <andi@...stfloor.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: An idea .... with code

--- On Wed, 8/27/08, Andi Kleen <andi@...stfloor.org> wrote:
> On Wed, Aug 27, 2008 at 04:49:35PM +0200, Kasper Sandberg
> wrote:
> > As far as cryptoloop goes, isnt that obsoleted anyway?
> 
> It's like saying: FAT -- isn't that obsolete by
> now? 
> As long as there are crypto loop files around it's not
> obsolete.

 Cryptoloop? No, my code isn't the 'same' as loop.c and hence can't provide for cryptoloop. I lose, you win :)
 Cryptoloop was designed so b'coz 'loop' feature was available, not the other way round. Had we not had '-o loop', developers would have devised mechanism for encrypting block devices rather than exploiting the -o loop hack. In retrospect, it seems Cryptoloop was a bad design based upon a hack.
 Encryption? Yes, my code does provide a way for it. It supports better dm-crypt/LUKS off the shelf.

 Loop.c sure provides more 'features' but the point is that we can make do without them, which only adds to the complexity. A simpler and more generic driver could do us equal good.

> > is there anyone
> > that doesent use dm-crypt by now?
> Wrong question. You lose.
 I see one mail from Andrew Morton suggesting removal of cryptoloop altogether in order to ramp up its obsoletion! I am only providing a more-transparent-way of using dm-crypt. 

I assume the concede Kasper's point on 'offset' feature of loop.c.

Anyways, seems we are moving from discussion to debate. You've got the whole picture and now its purely your call to approve of it or not.

 Better still, you could suggest how to make it better: we are for sure gonna drop cryptoloop for dm-crypt. What wud we do with the then-unnecessary crypt support of loop.c?

 Or maybe, for the time being, it would be better to modify Loop.c to allow for runtime alloc/free of as many resources as needed and provide for sysfs interface to add/remove 'loop' rather than ioctls?

I had an idea and i cooked up a code. I wanted to put it somewhere for someone to stumble upon the idea sometime. I am done.

Best Regards,
-Jassi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/