wrong variable name for vla

[dvyukov]

It seems that the variable called vla come from:

static int crypto_xcbc_digest_setkey(struct crypto_shash *parent,
				     const u8 *inkey, unsigned int keylen)
{
....
	u8 key1[bs];

Need to say key1.

==================================================================
BUG: KMSAN: uninit-value in __arch_swab64 arch/x86/include/uapi/asm/swab.h:31 [inline]
BUG: KMSAN: uninit-value in __fswab64 include/uapi/linux/swab.h:68 [inline]
BUG: KMSAN: uninit-value in __swab64p include/uapi/linux/swab.h:192 [inline]
BUG: KMSAN: uninit-value in __be64_to_cpup include/uapi/linux/byteorder/little_endian.h:74 [inline]
BUG: KMSAN: uninit-value in get_unaligned_be64 include/linux/unaligned/access_ok.h:35 [inline]
BUG: KMSAN: uninit-value in camellia_setup128 arch/x86/crypto/camellia_glue.c:1006 [inline]
BUG: KMSAN: uninit-value in __camellia_setkey+0x150b/0x1880 arch/x86/crypto/camellia_glue.c:1261
CPU: 0 PID: 10172 Comm: syz-executor4 Not tainted 4.16.0+ #81
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:17 [inline]
 dump_stack+0x185/0x1d0 lib/dump_stack.c:53
 kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
 __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
 __arch_swab64 arch/x86/include/uapi/asm/swab.h:31 [inline]
 __fswab64 include/uapi/linux/swab.h:68 [inline]
 __swab64p include/uapi/linux/swab.h:192 [inline]
 __be64_to_cpup include/uapi/linux/byteorder/little_endian.h:74 [inline]
 get_unaligned_be64 include/linux/unaligned/access_ok.h:35 [inline]
 camellia_setup128 arch/x86/crypto/camellia_glue.c:1006 [inline]
 __camellia_setkey+0x150b/0x1880 arch/x86/crypto/camellia_glue.c:1261
 camellia_setkey+0x9a/0xb0 arch/x86/crypto/camellia_aesni_avx2_glue.c:200
 setkey+0x50f/0x5a0 crypto/cipher.c:60
 crypto_cipher_setkey include/linux/crypto.h:1552 [inline]
 crypto_xcbc_digest_setkey+0x4b7/0x570 crypto/xcbc.c:77
 crypto_shash_setkey crypto/shash.c:66 [inline]
 shash_async_setkey+0x337/0x4c0 crypto/shash.c:218
 crypto_ahash_setkey+0x31a/0x470 crypto/ahash.c:201
 hash_setkey+0x8b/0xa0 crypto/algif_hash.c:420
 alg_setkey crypto/af_alg.c:223 [inline]
 alg_setsockopt+0x6c5/0x740 crypto/af_alg.c:256
 SYSC_setsockopt+0x4b8/0x570 net/socket.c:1849
 SyS_setsockopt+0x76/0xa0 net/socket.c:1828
 do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x455259
RSP: 002b:00007f9d7bdd1c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 00007f9d7bdd26d4 RCX: 0000000000455259
RDX: 0000000000000001 RSI: 0000000000000117 RDI: 0000000000000013
RBP: 000000000072bea0 R08: 0000000000000010 R09: 0000000000000000
R10: 00000000200001c0 R11: 0000000000000246 R12: 00000000ffffffff
R13: 0000000000000510 R14: 00000000006faa20 R15: 0000000000000000

Local variable description: ----vla@crypto_xcbc_digest_setkey
Variable was created at:
 crypto_xcbc_digest_setkey+0x12e/0x570 crypto/xcbc.c:68
 crypto_shash_setkey crypto/shash.c:66 [inline]
 shash_async_setkey+0x337/0x4c0 crypto/shash.c:218
==================================================================

[dvyukov]

Also filed https://bugs.llvm.org/show_bug.cgi?id=37207 as it's msan bug.

[ramosian-glider]

Right now [K]MSan uses AllocaInst.getName() to obtain the local's name.
It's actually possible to query the LLVM metadata to get the exact name and declaration location for local vars.

Another idea we've just discussed is to associate the local var's DILocation with the corresponding __msan_poison_alloca() call.

[eugenis]

Querying metadata is a good idea, and it's not that hard to implement. It will only work with full debug info though, not -gmlt.

In your last sentence, are you saying that you want to describe __msan_poison_alloca call site as data in debug info?

[ramosian-glider]

In your last sentence, are you saying that you want to describe __msan_poison_alloca call site as data in debug info?
No, the idea was to make the call __msan_poison_alloca have the same file:line info as the local variable.

[eugenis]

Sure. Either that or __msan_set_alloca_origin4.

[ramosian-glider]

Another question is how do we represent the information about inlined variables.
E.g. in the following case:

static int bar(int index) {
  int buf[10];
  for (int i = 0; i < 10; i++) {
    buf[i] = (i > 1) ? buf[i-1] + buf[i-2] : 1;
  }
  return (index >= 0 && index < 10) ? buf[index] : 0;
}

static
int foo(int index) {
  return bar(index);
}

We could describe the inlined buf as one of the following options:

1. buf@foo (current version)
2. buf@bar (show only the original function)
3. buf@bar@foo (show all the inlining stack)

Version 3 is the most informative, but it'll create a lot of unnecessary global strings. Version 2 has only the deepest function in the inline stack, which may sometimes be obscure.

[dvyukov]

Uninit come from local variable buf created at:
    bar bar.c:11
    foo foo.c:22
    baz baz.c:33

[ramosian-glider]

Still reproducible with Clang 15.0.0.

[ramosian-glider]

On the other hand, VLAs are gone from the kernel, so keeping the bug around in LLVM should be enough: https://bugs.llvm.org/show_bug.cgi?id=37207