On Thu, 2002-02-28 at 19:11, Jari Ruusu wrote: >> anyway, I can't help thinking that you're in the process of recreating >> the international kernel patch.... > Cryptoapi does not support _my_ kernel of choice. If you care to examine > headers of this message, you will notice that this message is sent using > ultra stable 2.2.20aa1. This box goes down only when UPS batteries are about > to run out of juice (and for maintenance... ZIP drive died yesterday, grrr). > All 2.4 kernel versions prior to 2.4.17 died under my simple non-evil stress > tests. And that was without any crypto. 2.4.17 was first 2.4 kernel that > showed some signs of stability. I guess we all remember, that the 2.4 series had quite a bad start... before 2.4.4 the loopback device wasn't even usable, and would lead to deadlocks... > Herbert, if you are not going to support all maintained stable kernels > (especially ultra stable ones and distro vendor versions), then I will > support them... and do that without cryptoapi bloat. well, 2.0 seems out of reach for the 'cryptoloop' filter; but 2.2 > > ps: ...are you aware of any data corruption problems with loop-AES in > > combination with XFS on SMP boxes under high IO load? if I get the time, > > I can try to recreate the issue with 2.4.18; it was present w/ 2.4.16 > > the last time I checked, and it affected both, loop-AES and patch-int... > I am not aware of any problems with loop-AES. Like I said above, kernels > prior to 2.4.17 were unstable in my tests. well ok, I'll try to reproduce the corruption; the only problem is, that I have to run a XFS-enabled kernel on my workstation, since the root partition is XFS... (that's also the reason why I haven't been able to do much work on 2.2 backporting, as I have no XFS for 2.2)... >> btw, that's a known problem (see this mailing lists archives for more >> details); when it was detected it was too late, thus left so, since it >> would have broken existing encrypted volumes... > I corrected the bug, but added a "bug-compatible" option so that existing > cryptoapi-mutated disk images can be mounted (also had to add RIPE-MD160 > password hash for 100% compatibility). btw, expect that future cryptoloop versions will use the non-'mutated' cipher mode by default, since some network applications need the correct variant... 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
Attachment:
signature.asc
Description: This is a digitally signed message part
