From: Herbert Valerio Riedel <hvr@hvrlab.org>
To: Jari Ruusu <jari.ruusu@pp.inet.fi>
Cc: marcelo@conectiva.com.br, Andrea Arcangeli <andrea@suse.de>,
axboe@suse.de, linux-kernel@vger.kernel.org
Subject: Re: RFC(ry): breaking loop.c's IV calculation
Date: 04 Dec 2001 14:48:35 +0100 [thread overview]
Message-ID: <1007473716.3731.60.camel@janus.txd.hvrlab.org> (raw)
In-Reply-To: <3C0BFB3F.9111CD2C@pp.inet.fi>
In-Reply-To: <3C0A51B0.9AD14E74@pp.inet.fi> <Pine.LNX.4.33.0112021716001.2563-100000@janus.txd.hvrlab.org> <20011202234625.A3447@athlon.random> <1007388763.1674.37.camel@janus.txd.hvrlab.org> <3C0BFB3F.9111CD2C@pp.inet.fi>
hello!
On Mon, 2001-12-03 at 20:00, Jari Ruusu wrote:
> Herbert Valerio Riedel wrote:
>> well, I've put one patch together (it still needs (constructive)
>> auditing though! jari?) here it is (it's against 2.4.16's loop.[ch])
> 1) For 2.4 kernels, IV type must remain int, not loop_iv_t, ok?
> Make the type loop_iv_t for 2.5 kernels but not for 2.4.
no problem, the typedef can be changed to
typedef int loop_iv_t;
that way the API does not change; it just looks more consistent...
IMHO having a typedef in loop.h instead of hardcoding it to an 'int' is
more flexible and less error-prone...
> 2) Get rid of the loop_get_bs() crap.
btw, what's the motivation for it? I'd also like to know why it was used
in the first place at all... :-)
On Mon, 2001-12-03 at 23:22, Jari Ruusu wrote:
> I have attached my version of loop.c bug fixes. These are extracted from
> loop-AES and are well tested.
although I'm quite confident you patch is well tested, it goes well
beyond fixing only the IV calculation and as such represents a major
change to the loop.c driver -- I'm curious whether it will be accepted
for 2.4.x... :-) ; but don't get me wrong, I'll be quite happy if it
goes in nevertheless!
just a minor note regarding source 'aesthetics';
it would be more self-explaining IMNSHO if you used some macro constant
for the '9' shifting instead of hardcoding it...:
int IV = index * (PAGE_CACHE_SIZE >> 9) + (offset >> 9);
in your patch vs. in my patch:
/* loop.h */
#define LOOP_IV_SECTOR_BITS 9
#define LOOP_IV_SECTOR_SIZE (1 << LOOP_IV_SECTOR_BITS)
typedef int loop_iv_t;
/* loop.c */
const loop_iv_t IV =
(index << (PAGE_CACHE_SHIFT - LOOP_IV_SECTOR_BITS))
+ (offset >> LOOP_IV_SECTOR_BITS);
it makes also life easier for filters which include loop.h, cause you
can check for the presence of the #defines above, whether a fixed loop.c
is available or not; and we are also prepared for the (even if unlikely)
event that those constants are changed some time...
> - IV computed in 512 byte units.
> - Make device backed loop work with swap by pre-allocating pages.
btw, just as a side note; IMHO this is a neat feature, but encrypted
swap shouldn't be done on top of a loop device but more like the bsd
people do it, as it allows for more interesting IV & key management
schemes...
> - External encryption module locking bug fixed (from Ingo Rohloff).
> - Get rid of the loop_get_bs() crap.
> - grab_cache_page() return value handled properly, avoids Oops.
> - No more illegal messing with BH_Dirty flag.
> - No more illegal sleeping in generic_make_request().
> - Loops can be set-up properly when root partition is still mounted ro.
> - Default soft block size is set properly for file backed loops.
> - kmalloc() error case handled properly.
regards,
--
Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840
Email: hvr@hvrlab.org / Finger hvr@gnu.org for GnuPG Public Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F
4142
prev parent reply other threads:[~2001-12-04 14:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20011202234625.A3447@athlon.random>
[not found] ` <3C0A51B0.9AD14E74@pp.inet.fi>
[not found] ` <Pine.LNX.4.33.0112021716001.2563-100000@janus.txd.hvrlab.org>
2001-12-03 14:12 ` Herbert Valerio Riedel
2001-12-03 19:00 ` Jari Ruusu
2001-12-03 22:22 ` Jari Ruusu
2001-12-04 13:48 ` Herbert Valerio Riedel [this message]
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=1007473716.3731.60.camel@janus.txd.hvrlab.org \
--to=hvr@hvrlab.org \
--cc=andrea@suse.de \
--cc=axboe@suse.de \
--cc=jari.ruusu@pp.inet.fi \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@conectiva.com.br \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome