LRW/XTS + Via Padlock Bug in 2.6.24-rc7?

Thanks for the reply,

the patch doesn't work witch the patch utility, so I did it manually, hope this was rigth:

static void aes_crypt_copy(const u8 *in, u8 *out, u32 *key, struct cword *cword)

{
        u8 tmp[AES_BLOCK_SIZE * 2]
                __attribute__ ((__aligned__(PADLOCK_ALIGNMENT)));

        memcpy(tmp, in, AES_BLOCK_SIZE);
//      padlock_xcrypt(tmp, out, key, cword);
        padlock_xcrypt(tmp, tmp, key, cword);
        memcpy(out, tmp, AES_BLOCK_SIZE);
}

After rebuilding the kernel, I tried: cryptsetup -c aes-xts-plain -s 256 luksFormat /dev/raid/test

It does the same as before, dmesg says:

general protection fault: 0000 [#1] 
Modules linked in: xt_TCPMSS xt_tcpmss iptable_mangle ipt_MASQUERADE xt_tcpudp pppoe pppox xt_mark xt_state iptable_nat nf_nat nf_conntrack_ipv4 iptable_filter ip_tables x_tables af_packet ppp_generic slhc aes_i586 dm_crypt dm_mod

Pid: 4409, comm: kcryptd Not tainted (2.6.24-rc7 #2)
EIP: 0060:[<c03599cc>] EFLAGS: 00010282 CPU: 0
EIP is at aes_crypt_copy+0x2c/0x50
EAX: f62e1ff0 EBX: f60ab850 ECX: 00000001 EDX: f60ab830
ESI: f620dda8 EDI: f620dda8 EBP: f62e1ff0 ESP: f620dda8
DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
Process kcryptd (pid: 4409, ti=f620c000 task=f61f5030 task.ti=f620c000)

Stack: 638522f6 b587b135 a30487c5 d57aa809 f620de50 f620defc c02613e1 0000007b 
       f60ab850 f62e1ff0 f62e1ff0 f620de00 c0359ad6 f60ab830 f62e1ff0 f62e1ff0 
       00000010 c0267cfc f6edf6e0 f620de34 f620dea8 00000010 8f88b41a 3ba46549 
Call Trace:
 [<c02613e1>] blkcipher_walk_next+0x151/0x320
 [<c0359ad6>] aes_decrypt+0x56/0x60
 [<c0267cfc>] crypt+0xdc/0x110
 [<c0359a80>] aes_decrypt+0x0/0x60
 [<c0267e22>] decrypt+0x42/0x50
 [<c035a1c0>] aes_encrypt+0x0/0x60
 [<c0359a80>] aes_decrypt+0x0/0x60
 [<f886a7de>] crypt_convert_scatterlist+0x6e/0xe0 [dm_crypt]
 [<f886a9ea>] crypt_convert+0x19a/0x1c0 [dm_crypt]
 [<f886aa10>] kcryptd_do_crypt+0x0/0x260 [dm_crypt]
 [<f886aa59>] kcryptd_do_crypt+0x49/0x260 [dm_crypt]
 [<c011964a>] update_curr+0xfa/0x110
 [<f886aa10>] kcryptd_do_crypt+0x0/0x260 [dm_crypt]
 [<c012aeb6>] run_workqueue+0x66/0xe0
 [<c03f3339>] schedule+0x149/0x270
 [<c012b620>] worker_thread+0x0/0x100
 [<c012b6bd>] worker_thread+0x9d/0x100
 [<c012e4c0>] autoremove_wake_function+0x0/0x50
 [<c012b620>] worker_thread+0x0/0x100
 [<c012e182>] kthread+0x42/0x70
 [<c012e140>] kthread+0x0/0x70
 [<c0104acf>] kernel_thread_helper+0x7/0x18
 =======================
Code: ec 30 89 5c 24 20 89 cb 89 74 24 24 89 c6 89 7c 24 28 89 e7 89 6c 24 2c 89 d5 8b 54 24 34 a5 a5 a5 a5 b9 01 00 00 00 89 e6 89 e7 <f3> 0f a7 c8 89 ef 89 e6 a5 a5 a5 a5 8b 5c 24 20 8b 74 24 24 8b 
EIP: [<c03599cc>] aes_crypt_copy+0x2c/0x50 SS:ESP 0068:f620dda8
---[ end trace 927124c395b6378a ]---

note: kcryptd[4409] exited with preempt_count 1

One other strange thing ist, that after rebooting the entry:

name : xts(aes)
driver : xts(aes-padlock)
module : kernel
priority : 300
refcnt : 2
type : blkcipher
blocksize : 16
min keysize : 32
max keysize : 64
ivsize : 16

is not visible in /proc/crypt (and of course not useable with cryptsetup), till I use /etc/init.d/udev restart.

Sorry I don't no why this happens. I guess it is because of reloading the modules, these are my modules:

xt_TCPMSS               3840  1 
xt_tcpmss               2176  1 
iptable_mangle          2752  1 
ipt_MASQUERADE          3456  1 
xt_tcpudp               3136  6 
pppoe                  12800  2 
pppox                   3852  1 pppoe
xt_mark                 1792  1 
xt_state                2368  1 
iptable_nat             7236  1 
nf_nat                 17964  2 ipt_MASQUERADE,iptable_nat
nf_conntrack_ipv4       9988  3 iptable_nat
iptable_filter          2880  1 
ip_tables              12232  3 iptable_mangle,iptable_nat,iptable_filter
x_tables               14724  8 xt_TCPMSS,xt_tcpmss,ipt_MASQUERADE,xt_tcpudp,xt_mark,xt_state,iptable_nat,ip_tables
af_packet              21188  4 
ppp_generic            23700  6 pppoe,pppox
slhc                    6464  1 ppp_generic
aes_i586               33280  0 
dm_crypt               13956  1 
dm_mod                 54976  14 dm_crypt

grettings
Torben Viets

Oh I see. I misdiagnosed the problem. The problem is that for some reason gcc cannot guarantee 16-byte alignment for variables on the stack in the kernel. As you can see from ESI/EDI above the temporary buffer is unaligned.

Please try this patch instead.

Thanks,

Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--

index a337b69..5f7e718 100644
@@ -429,8 +429,8 @@ static inline void padlock_xcrypt(const u8 *input, u8 *output, void *key,
 
 static void aes_crypt_copy(const u8 *in, u8 *out, u32 *key, struct cword *cword)
 {
-	u8 tmp[AES_BLOCK_SIZE * 2]
-		__attribute__ ((__aligned__(PADLOCK_ALIGNMENT)));
+	u8 buf[AES_BLOCK_SIZE * 2 + PADLOCK_ALIGNMENT - 1];
+	u8 *tmp = PTR_ALIGN(&buf[0], PADLOCK_ALIGNMENT);
 
 	memcpy(tmp, in, AES_BLOCK_SIZE);
 	padlock_xcrypt(tmp, out, key, cword);

Woot,

it works, in XTS and LRW mode thanks, but I have one last question (it sounds like I'm columbo ;) )

Why I can't see both in /proc/crypto and of course not use in int cryptsetup, till I make a /etc/init.d/udev restart ist ths a kernel bug, or a ubuntu bug?

Thanks

Torben Viets

The algorithm xts(aes) is an instantiation of the xts template. As such you won't see it until someone tries to use it or you instantiate it explicitly (which isn't possible yet :)

Cheers,

Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt