On 9/10/26 11:30, Maarten Brock wrote:
Hello Michal,
-----Original Message-----
From: Michal Simek <[email protected]>
Sent: Thursday 10 September 2026 9:59
On 9/10/26 09:56, Maarten Brock wrote:
Hello Sriram and Drew,
It seems to me that the limit of 50 for MAX_NAME_LENGTH is pretty arbitrary.
If you expect it to easily overflow, why not make that larger as well?
do you have a case where your board, carrier cards will require more then 50
chars? This has been designed for Kria SOM where you have name in board eeprom
and carrier card eeprom and it is never over 50 chars.
No, I do not. I was just following the logic in the patch comments.
-----Original Message-----
From: Michal Simek <[email protected]>
Sent: Thursday 10 September 2026 10:04
On 9/9/26 21:20, Sriram Sriram wrote:
From: Drew Kluemke <[email protected]>
board_name_decode() assembles the board name into a calloc'd buffer of
MAX_NAME_LENGTH (50) bytes using strcat(). It appends CONFIG_SYS_BOARD
and then, for every detected EEPROM descriptor, "-", desc->name (up to
16 characters), "-rev" and desc->revision (up to 8 characters).
The length check runs only after the loop, so it cannot prevent the
overflow it documents. Each descriptor contributes up to 29 characters,
so a base board plus a carrier card already exceeds the buffer, and the
data being concatenated comes from the EEPROM.
To me this indicates it is very easy to overflow the buffer.
I have not followed where the result of board_name_decode() goes
and whether 50 is a logical bound there. But since it is locally defined
without any comments it seems an arbitrary choice.
And if both these assumptions are true (expect overflow and arbitrary bound)
then it is probably a good idea to use a larger bound.
It is used for DTB reselection to described current board setup.
If you look at arch/arm/dts/zynqmp-binman-*
the maximum amount of chars used is 37. There is still 13 chars left.
Code is prepared for covering board, carrier cards but also extension cards like
FMCs by simply pointing via nvmem alias to whatever EEPROM in the system. I am
not saying we would need more space but as of today I am not aware about any
usecase which requires more. In any case if something hit that limit panic is
thrown and we can extend it but extending it just in case make little sense to me.
Thanks,
Michal
