On Sat, May 4, 2013 at 2:16 AM, Nicholas A. Bellinger
<n...@linux-iscsi.org> wrote:
>> BTW, there are serious issues with casting pointers to u32s to pointers to
>> u8s
>> for the last two output parameters of iscsit_do_crypto_hash_buf() (pad_bytes
>> and data_crc):
>> 1. It's not endian-safe,
>> 2. In many cases, the original u32 was not initialized at all, so the
>> other 24
>> bits contain garbage. This will cause 32-bit comparisons like
>>
>> if (checksum != data_crc)
>>
>> to fail in unpredictable ways.
Upon closer look, this issue is moot. But the code is confusing for the casual
reader, due to the casts
Changing the "u8 *pad_bytes" parameters to "const void *pad_bytes"
(which is what sg_init_one() takes anyway) should allow you to get rid of the
casts for pad_bytes.
For data_crc, the issue is that crypto_hash_final() takes a "u8 *out",
instead of a "void *out". Still, it's better to move the cast inside
iscsit_do_crypto_hash_buf(), so it's in one place only.
> Ugh, I can see how that would be problematic for BE..
>
> Changing these to use u8 data_crc[ISCSI_DIGEST_SIZE] and
> pad_bytes[ISCSI_PAD_LEN] now, and will post a patch soon.
That's another good idea.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
