Dear Doug,
In message CAD=FV=Ui2Zww2bGT+QSjTg=K0v9BGGSAxShrTsXOQyPbA9XRSg@mail.gmail.com you wrote:
...I'm still awaiting Wolfgang's suggestion for which of the following he'd like me to submit instead of this series:
- A stripped down version of the change to use malloc with the caveat
that it's up to the user not to overrun any hardcoded limits in the kernel (I'm pretty sure that the kernel already has code to truncate--at least on most platforms).
- A version of the change to add a platform-specific
COMMAND_LINE_SIZE to u-boot (keeping in sync with the kernel) with a fix in u-boot to never buffer overrun (changing behavior to truncate).
I have to admit that I have no clear opinion here yet.
The existing code is from a time when all architectures had a pretty low limit on the command line size - IIRC even PPC had only 256 bytes by then, hard coded.
I think we have two options:
1) Try not to exceed any limits imposed by the Linux kernel. Advantage: we can catch situations where the user overflows the limits and print an error message (IIRC this needs to be added), so the user gets aware of the pronlem. Disadvantage: we need to add architecture specific definitions for the command line size, and keep these in sync with any related changes to the Linux kernel. We know in advance that this will not work really well.
2) We just make sure not to overwrite array bounds in U-Boot, and allow passing arbitrary sized buffers to the Linux kernel. Advantage: the code in U-Boot can be simple and clean Disadvantage: the resulting behaviour is not exactly user-friendly, as a silent truncation in the Linux kernel is probably hard to spot.
Hm...
I agree that the old code needs fixing. I think it would be nice if we could adapt U-Boot behaviour, but I fear that actually it cannot work at all, as we don't know which Linux kernel version the user will use, and what their limits might be.
So in the end 2) is probably the most sensible approach here.
Best regards,
Wolfgang Denk