On 24/03/2021 14.33, Arnd Bergmann wrote:
On Tue, Mar 23, 2021 at 4:57 PM Rasmus Villemoes linux@rasmusvillemoes.dk wrote:
On 23/03/2021 14.04, Arnd Bergmann wrote:
if (securedisplay_cmd->status == TA_SECUREDISPLAY_STATUS__SUCCESS) {
int pos = 0; memset(i2c_output, 0, sizeof(i2c_output)); for (i = 0; i < TA_SECUREDISPLAY_I2C_BUFFER_SIZE; i++)
sprintf(i2c_output, "%s 0x%X", i2c_output,
pos += sprintf(i2c_output + pos, " 0x%X", securedisplay_cmd->securedisplay_out_message.send_roi_crc.i2c_buf[i]); dev_info(adev->dev, "SECUREDISPLAY: I2C buffer out put is :%s\n", i2c_output);Eh, why not get rid of the 256 byte stack allocation and just replace all of this by
dev_info(adev->dev, ""SECUREDISPLAY: I2C buffer out put is: %*ph\n", TA_SECUREDISPLAY_I2C_BUFFER_SIZE, securedisplay_cmd->securedisplay_out_message.send_roi_crc.i2c_buf);
That's much less code (both in #LOC and .text), and avoids adding yet another place that will be audited over and over for "hm, yeah, that sprintf() is actually not gonna overflow".
Yeah, it'll lose the 0x prefixes for each byte and use lowercase hex chars.
Ah, I didn't know the kernel's sprintf could do that, that's really nice.
If you're bored, you can "git grep -E -C4 '%[0.]2[xX]'" and find places that are inside a small loop, many can trivially be converted to %ph, though often with some small change in formatting. If you're lucky, you even get to fix real bugs when people pass a "char" to %02x and "know" that that will produce precisely two bytes of output, so they've sized their stack buffer accordingly - boom when "char" happens to be signed and one of the bytes have a value beyond ascii and %02x produces 0xffffffXX.
%ph has a hard-coded upper bound of 64 bytes, I think that's silly because people instead do these inefficient and very verbose loops instead, wasting stack, .text and runtime.
Rasmus