jitterentropy-rngd woes on armel

[Christoph Biedl]

[ jitterentropy-rngd maintainer Cc'ed ]

Hello,

can please somebody check the armel jitterentropy-rngd package in
testing and unstable (1.2.1-2) on various arm platforms? Things look
really weird and I have no idea how to proceed.

Initial observation: On an old Seagate Dockstar (Feroceon 88FR131, armv5tel
CPU) running Debian bullseye (buster is fine), jitterentropy-rngd ("je-r")
fails to start:

# jitterentropy-rngd
Floating point exception

Using gdb:

Program received signal SIGFPE, Arithmetic exception.
0xb6fb6810 in raise () from /lib/arm-linux-gnueabi/libpthread.so.0
(gdb) bt
#0 0xb6fb6810 in raise () from /lib/arm-linux-gnueabi/libpthread.so.0
#1 0x00404968 in __aeabi_ldiv0 ()
#2 0x00402664 in sha3_update (ctx=0xbefff55c, in=0x404b50 <msg_256> "^", <incomplete sequence \326>,
inlen=3) at jitterentropy-base.c:567
#3 0x00402d48 in sha3_tester () at jitterentropy-base.c:658
#4 0x004038dc in jent_entropy_init () at jitterentropy-base.c:1387
#5 0x00400ffc in alloc () at jitterentropy-rngd.c:666
#6 main (argc=1, argv=0xbefff914) at jitterentropy-rngd.c:794

So this is most likely caused by

size_t partial = ctx->msg_len % ctx->r;


Surprise however: In an armel bullseye chroot on both a Cubietruck
(armhf) and Raspberry Pi 4 (arm64), je-r just runs fine.

And running a rebuilt je-r on the Dockstar yields a completely different
message:

jitterentropy-rngd - Error: The initialization of CPU Jitter RNG failed with error code 11

Adding some debug print statements reveals this is caused from a fail in
sha3_tester, and indeed the computed hash is different. But the line
that initially caused trouble is passed.


Possibly unrelated, the gcc warnings (line number are a bit off)

jitterentropy-base.c: In function ‘sha3_tester’:
jitterentropy-base.c:311:25: warning: cast increases required alignment of target type [-Wcast-align]
311 | struct sha_ctx *name = (struct sha_ctx *) name ## _ctx_buf
| ^
jitterentropy-base.c:649:2: note: in expansion of macro ‘HASH_CTX_ON_STACK’
649 | HASH_CTX_ON_STACK(ctx);
| ^~~~~~~~~~~~~~~~~

don't look good but I fail to understand the root cause behind this.
Applying some #pragma pack made the warnings go away, the issue
remained, though.

Any idea?

Christoph

[Adrian Bunk]

Post by Christoph Biedl
...
can please somebody check the armel jitterentropy-rngd package in
testing and unstable (1.2.1-2) on various arm platforms? Things look
really weird and I have no idea how to proceed.
Initial observation: On an old Seagate Dockstar (Feroceon 88FR131, armv5tel
CPU) running Debian bullseye (buster is fine), jitterentropy-rngd ("je-r")
# jitterentropy-rngd
Floating point exception
Program received signal SIGFPE, Arithmetic exception.
0xb6fb6810 in raise () from /lib/arm-linux-gnueabi/libpthread.so.0
(gdb) bt
#0 0xb6fb6810 in raise () from /lib/arm-linux-gnueabi/libpthread.so.0
#1 0x00404968 in __aeabi_ldiv0 ()
#2 0x00402664 in sha3_update (ctx=0xbefff55c, in=0x404b50 <msg_256> "^", <incomplete sequence \326>,
inlen=3) at jitterentropy-base.c:567
#3 0x00402d48 in sha3_tester () at jitterentropy-base.c:658
#4 0x004038dc in jent_entropy_init () at jitterentropy-base.c:1387
#5 0x00400ffc in alloc () at jitterentropy-rngd.c:666
#6 main (argc=1, argv=0xbefff914) at jitterentropy-rngd.c:794
So this is most likely caused by
size_t partial = ctx->msg_len % ctx->r;
Surprise however: In an armel bullseye chroot on both a Cubietruck
(armhf) and Raspberry Pi 4 (arm64), je-r just runs fine.
And running a rebuilt je-r on the Dockstar yields a completely different
jitterentropy-rngd - Error: The initialization of CPU Jitter RNG failed with error code 11
Adding some debug print statements reveals this is caused from a fail in
sha3_tester, and indeed the computed hash is different. But the line
that initially caused trouble is passed.
Possibly unrelated, the gcc warnings (line number are a bit off)
jitterentropy-base.c:311:25: warning: cast increases required alignment of target type [-Wcast-align]
311 | struct sha_ctx *name = (struct sha_ctx *) name ## _ctx_buf
| ^
jitterentropy-base.c:649:2: note: in expansion of macro ‘HASH_CTX_ON_STACK’
649 | HASH_CTX_ON_STACK(ctx);
| ^~~~~~~~~~~~~~~~~
don't look good but I fail to understand the root cause behind this.
Applying some #pragma pack made the warnings go away, the issue
remained, though.
Any idea?

This sounds similar to other problems reported on armv5tel:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975977#44
https://bugs.debian.org/987566

I've added Bernhard to Cc, who has done most of the investigation
work on these bugs.

Post by Christoph Biedl
Christoph

cu
Adrian

[Bernhard Übelacker]

Hello everyone,

Post by Adrian Bunk

Post by Christoph Biedl
...
can please somebody check the armel jitterentropy-rngd package in
testing and unstable (1.2.1-2) on various arm platforms? Things look
really weird and I have no idea how to proceed.
Initial observation: On an old Seagate Dockstar (Feroceon 88FR131, armv5tel
CPU) running Debian bullseye (buster is fine), jitterentropy-rngd ("je-r")
# jitterentropy-rngd
Floating point exception
Program received signal SIGFPE, Arithmetic exception.
0xb6fb6810 in raise () from /lib/arm-linux-gnueabi/libpthread.so.0
(gdb) bt
#0 0xb6fb6810 in raise () from /lib/arm-linux-gnueabi/libpthread.so.0
#1 0x00404968 in __aeabi_ldiv0 ()
#2 0x00402664 in sha3_update (ctx=0xbefff55c, in=0x404b50 <msg_256> "^", <incomplete sequence \326>,
inlen=3) at jitterentropy-base.c:567
#3 0x00402d48 in sha3_tester () at jitterentropy-base.c:658
#4 0x004038dc in jent_entropy_init () at jitterentropy-base.c:1387
#5 0x00400ffc in alloc () at jitterentropy-rngd.c:666
#6 main (argc=1, argv=0xbefff914) at jitterentropy-rngd.c:794
So this is most likely caused by
size_t partial = ctx->msg_len % ctx->r;
Surprise however: In an armel bullseye chroot on both a Cubietruck
(armhf) and Raspberry Pi 4 (arm64), je-r just runs fine.
And running a rebuilt je-r on the Dockstar yields a completely different
jitterentropy-rngd - Error: The initialization of CPU Jitter RNG failed with error code 11
Adding some debug print statements reveals this is caused from a fail in
sha3_tester, and indeed the computed hash is different. But the line
that initially caused trouble is passed.
Possibly unrelated, the gcc warnings (line number are a bit off)
jitterentropy-base.c:311:25: warning: cast increases required alignment of target type [-Wcast-align]
311 | struct sha_ctx *name = (struct sha_ctx *) name ## _ctx_buf
| ^
jitterentropy-base.c:649:2: note: in expansion of macro ‘HASH_CTX_ON_STACK’
649 | HASH_CTX_ON_STACK(ctx);
| ^~~~~~~~~~~~~~~~~
don't look good but I fail to understand the root cause behind this.
Applying some #pragma pack made the warnings go away, the issue
remained, though.
Any idea?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975977#44
https://bugs.debian.org/987566
I've added Bernhard to Cc, who has done most of the investigation
work on these bugs.

Post by Christoph Biedl
Christoph

cu
Adrian

I tried to do some side by side comparision.
Once with a Bullseye chroot on top of a Buster kernel (due to size limitations of my qnap device).
And the other side one old android device with the same chroot,
but unfortunately running an android kernel, but I guess
the result might still be valid.

As far as I see the issue is with the "ldrd" instruction at sha3_update+4.
On the failing device afterwards register r5 contains 0.
On the good device the register contains the value of ctx->r.

Because of that the modulus receives a zero as divisor
and therefore raises the exception.

So if I interpret the situation right, the ldrd instruction
tries to load 8 bytes into register r4 and r5.

Is here the fault that the address to load from is not 8 byte aligned?

At least a package built with an alignment hint
like in the diff below (similar to the change from #975977),
the address to load from is now 8 byte aligned,
the register receives the expected value
and the crash did not happen.

When building the unmodified package inside the
bullseye chroot I don't get the warning you mention,
and it is also not visible in the armel build log.

Kind regards,
Bernhard




Bad: Architecture: armv5tel, Model name: Feroceon 88FR131 | Good: Architecture: armv7l, Model name: Krait
|
(gdb) print &ctx->msg_len | (gdb) print &ctx->msg_len
$3 = (size_t *) 0xbefffae4 | $3 = (size_t *) 0xbefffb24
|
0x00402640 567 size_t partial = ctx->msg_len % ctx->r; | 0x7f557640 567 size_t partial = ctx->msg_len % ctx->r;
1: x/i $pc | 1: x/i $pc
=> 0x402640 <sha3_update+4>: ldrd r4, [r0, #200] ; 0xc8 | => 0x7f557640 <sha3_update+4>: ldrd r4, [r0, #200] ; 0xc8
2: /x $r0 = 0xbefffa1c | 2: /x $r0 = 0xbefffa5c
4: /x $r4 = 0xbefff9fc | 4: /x $r4 = 0xbefffa3c
5: /x $r5 = 0x404a90 | 5: /x $r5 = 0x7f559a90
(gdb) stepi | (gdb) stepi
0x00402644 566 { | 0x7f557644 566 {
1: x/i $pc | 1: x/i $pc
=> 0x402644 <sha3_update+8>: sub sp, sp, #20 | => 0x7f557644 <sha3_update+8>: sub sp, sp, #20
2: /x $r0 = 0xbefffa1c | 2: /x $r0 = 0xbefffa5c
4: /x $r4 = 0x0 | 4: /x $r4 = 0x0
5: /x $r5 = 0x0 <<<<<<<<<<<<< | 5: /x $r5 = 0x88 <<<<<<<<<<<<<





--- jitterentropy-rngd-1.2.1.orig/jitterentropy-base.c
+++ jitterentropy-rngd-1.2.1/jitterentropy-base.c
@@ -306,7 +306,7 @@ struct sha_ctx {
/* CTX size allows any hash type up to SHA3-224 */
#define SHA_MAX_CTX_SIZE 368
#define HASH_CTX_ON_STACK(name) \
- uint8_t name ## _ctx_buf[SHA_MAX_CTX_SIZE]; \
+ uint8_t __attribute__((aligned(8))) name ## _ctx_buf[SHA_MAX_CTX_SIZE]; \
struct sha_ctx *name = (struct sha_ctx *) name ## _ctx_buf

/*