All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Kleikamp <dave.kleikamp@oracle.com>
To: sparclinux@vger.kernel.org
Subject: Re: [PATCH] sparc64: use COMMAND_LINE_SIZE for boot string
Date: Tue, 07 Oct 2014 18:49:37 +0000	[thread overview]
Message-ID: <543435C1.8030103@oracle.com> (raw)
In-Reply-To: <5432BE03.10405@oracle.com>



On 10/07/2014 01:38 PM, Kjetil Oftedal wrote:
> On 07/10/2014, Dave Kleikamp <dave.kleikamp@oracle.com> wrote:
>> Even though I just sent a new patch...
>>
>> On 10/06/2014 11:23 PM, David Miller wrote:
>>> From: Dave Kleikamp <dave.kleikamp@oracle.com>
>>> Date: Mon, 06 Oct 2014 11:06:27 -0500
>>>
>>>> sparc64 defines COMMAND_LINE_SIZE to be 2048, but the boot string is
>>>> hard-coded to be 256 bytes long.
>>>>
>>>> based on a patch by Bob Picco
>>>>
>>>> Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
>>>
>>> I think we might be limited by the size of barg_out[] in the SILO
>>> bootloader, which is 1024 bytes.
>>>
>>> SILO massages the command line into barg_out[] then does:
>>>
>>> 		if (architecture = sun4u)
>>> 		    kernel_params = (char *)((hdrs->bootstr_info_ptr_low - 0x400000) +
>>> 				(image_base - 0x4000));
>>>  ...
>>> 	if (kernel_params) {
>>>     	    extern char barg_out[];
>>>     	    int len = *(unsigned int *)kernel_params;
>>>
>>>     	    strncpy (kernel_params + 8, barg_out, len);
>>>     	    kernel_params [8 + len - 1] = 0;
>>>     	    *(unsigned int *)(kernel_params + 4) = 1;
>>> 	}
>>>
>>> So it blindly copies however many bytes you tell it to in that
>>> bootstr_info area :-/
>>
>> strncpy will still stop at the first null character, so the only way it
>> will copy more than 1024 bytes would be if it has already overflowed
>> barg_out in constructing the command line. Writing the final null
>> terminator into kernel_params is not a problem.
>>
> 
> Just a note from the strncpy manpage:
> "If  the  length of src is less than n, strncpy() writes additional null
>  bytes to dest to ensure that a total of n bytes are written."
> 
> So strncpy always writes len bytes, regardless of the presence of a null char.
> (Unless silo strncpy is different ?)

I never realized that, but that's really not a problem since the
destination will have the space. The original patch shouldn't be
problematic, although it may make the string longer than it practically
needs to be. I'll let davem make the call which version he likes better.
Maybe the comment in the second patch can be improved.

Dave

  parent reply	other threads:[~2014-10-07 18:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-06 16:06 [PATCH] sparc64: use COMMAND_LINE_SIZE for boot string Dave Kleikamp
2014-10-07  4:23 ` David Miller
2014-10-07 12:44 ` Dave Kleikamp
2014-10-07 13:23 ` Dave Kleikamp
2014-10-07 18:38 ` Kjetil Oftedal
2014-10-07 18:49 ` Dave Kleikamp [this message]
2014-10-07 18:54 ` David Miller
2014-10-07 19:03 ` David Miller
2014-10-07 19:19 ` Dave Kleikamp
2014-10-07 19:23 ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=543435C1.8030103@oracle.com \
    --to=dave.kleikamp@oracle.com \
    --cc=sparclinux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.