From: Andrew Cooper <andrew.cooper3@citrix.com>
To: "Jason Andryuk" <jason.andryuk@amd.com>,
"Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>,
xen-devel@lists.xenproject.org
Cc: Anthony PERARD <anthony.perard@vates.tech>
Subject: Re: [PATCH] tools/xl: don't crash on NULL command line
Date: Tue, 29 Jul 2025 07:55:25 +0100 [thread overview]
Message-ID: <feb8a172-e304-4f35-ad6f-cd8ca3b8dac5@citrix.com> (raw)
In-Reply-To: <55d8f784-4ad5-4a20-bfb4-ad6219415288@amd.com>
On 29/07/2025 1:29 am, Jason Andryuk wrote:
> On 2025-07-28 06:45, Andrew Cooper wrote:
>> On 28/07/2025 11:24 am, Marek Marczykowski-Górecki wrote:
>>> When running xl in a domU, it doesn't have access to the Xen command
>>> line. Before the non-truncating xc_xenver_cmdline(), it was always set
>>> with strdup, possibly of an empty string. Now it's NULL. Treat it the
>>> same as empty cmdline, as it was before. Autoballoon isn't relevant for
>>> xl devd in a domU anyway.
>>>
>>> Fixes: 75f91607621c ("tools: Introduce a non-truncating
>>> xc_xenver_cmdline()")
>>> Signed-off-by: Marek Marczykowski-Górecki
>>> <marmarek@invisiblethingslab.com>
>>> ---
>>> So, apparently the "No API/ABI change" was a lie... it changed "empty
>>> string" to NULL in libxl_version_info->commandline. Quick search didn't
>>> spot any other (in-tree) place that could trip on NULL there. IMO NULL
>>> value in this case makes more sense. Buf maybe for the API stability
>>> reasons the old behavior should be restored?
>>
>> Hmm, I didn't intend to change things, but I also didn't anticipate
>> libxl__strdup()'s behaviour, or for something to depend on that.
>
> I think it isn't strdup()'s behaviour, but rather the old code:
>
> - xc_version(ctx->xch, XENVER_commandline, &u.xen_commandline);
> - info->commandline = libxl__strdup(NOGC, u.xen_commandline);
> + info->commandline = xc_xenver_commandline(ctx->xch);
>
> No error checking on xc_version(), so strdup() is duplicating whatever
> (stale?) data may be in the union.
Even better...
xc_version(XENVER_commandline) for better or worse couldn't fail in Xen
for anything other than -EFAULT (writing a 1k block of memory), but a
systematic failing with the old ABIs was that nothing caused Xen to
explicitly NUL-terminate the string.
Notice how XENVER_commandline operates on ARRAY_SIZE(saved_cmdline) and
not strlen().
I'll give you 0 guesses what happens when the bootloader passed a
cmdline of >1k, and also 0 guesses for how we stumbled onto this mess.
~Andrew
next prev parent reply other threads:[~2025-07-29 6:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-28 10:24 [PATCH] tools/xl: don't crash on NULL command line Marek Marczykowski-Górecki
2025-07-28 10:45 ` Andrew Cooper
2025-07-28 10:50 ` Frediano Ziglio
2025-07-28 10:54 ` Jan Beulich
2025-07-29 0:29 ` Jason Andryuk
2025-07-29 6:55 ` Andrew Cooper [this message]
2025-07-28 12:11 ` Roger Pau Monné
2025-07-31 9:45 ` Anthony PERARD
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=feb8a172-e304-4f35-ad6f-cd8ca3b8dac5@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=anthony.perard@vates.tech \
--cc=jason.andryuk@amd.com \
--cc=marmarek@invisiblethingslab.com \
--cc=xen-devel@lists.xenproject.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.