[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 3/6] xen/efi: Make efi-boot.h compile with -Wwrite-strings


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 22 Nov 2023 09:46:32 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3Ag/W+3cXpV5c6W32UxHMkxy+4hgfufiUKjIJ493JMk=; b=CiIgBEYah48Dy5tdMQfTkmTj8J3IPQLV1E+MSkGkGuUSSf3M+Yr+TygWhJsHuD99dZoscAmGrH72uwIeMWwMo3vX+E6OxJluG7B5P6p1U4Iz/KNuxDwDN1ZVm9Ti4RNwiYR8iNlqBKy8D+a1FlZ9E4zCAECmc0uXvxGZDw9ai+Ar1ks5Rps8i4JdcruD2d01a8vxq06e0qI5mcSm1nUmnoUYA6UAg44gU39/7V/iaVsy3CfbjiCn/YCkyMqM19hs971g/G4nKTh+JDQJJJtDgcFuhLqLnu5G2Hb1b/lWNbEOaBzHu60Cuwq2hAgH7JUTRvPPTuL9jOB5WH8WuaLgpQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HhE0H/wHbIXkgv/LpVmIH82FOYG2QlS0B+J8j40CiyHf/EKy9BSWH/F2S2UYr5h+spd5O1WzxDqS63n3gPYjnXoEfjo9QUKHFSgFqyYTcGvvEe87T47i0LeypobKKp03R3NkQgPhbisf5g+IZob+zbPUvPV/CTa48veiU1F4T+TWiwqTeBmTd/i0ERmWk/qx6WEg2Tqp39ZVbL+NimkWJbaEbCHun8HVqUdRYznfGAHL513VFqStnShQDysU8LwpCWigdJxaCLurEEd1RQP3K1c7vysvnhiEgmkspxgr8YD6nIbwSrM9c2RBgnpTlTrZhe+MrmFrkZePdH3M8iPFlQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Autocrypt: addr=jbeulich@xxxxxxxx; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Roberto Bagnara <roberto.bagnara@xxxxxxxxxxx>, Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 22 Nov 2023 08:46:45 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 21.11.2023 20:13, Andrew Cooper wrote:
> On 21/11/2023 6:03 pm, Andrew Cooper wrote:
>> On 21/11/2023 8:40 am, Jan Beulich wrote:
>>> On 20.11.2023 23:49, Andrew Cooper wrote:
>>>> GCC complains:
>>>>
>>>>   In file included from arch/arm/efi/boot.c:700:
>>>>   arch/arm/efi/efi-boot.h: In function 'efi_arch_handle_cmdline':
>>>>   arch/arm/efi/efi-boot.h:482:16: error: assignment discards 'const' 
>>>> qualifier from pointer target type [-Werror=discarded-qualifiers]
>>>>     482 |         name.s = "xen";
>>>>         |                ^
>>>>
>>>> There's no easy option.  .rodata is really read-only, so the fact Xen 
>>>> doesn't
>>>> crash means these strings aren't written to.
>>> And the consuming sites confirm this being the case. Hence ...
>>>
>>>> Lie to the compiler using a union.
>>> ... to at least slightly limit the lying, how about ...
>>>
>>>> --- a/xen/arch/arm/efi/efi-boot.h
>>>> +++ b/xen/arch/arm/efi/efi-boot.h
>>>> @@ -479,7 +479,7 @@ static void __init efi_arch_handle_cmdline(CHAR16 
>>>> *image_name,
>>>>          w2s(&name);
>>>>      }
>>>>      else
>>>> -        name.s = "xen";
>>>> +        name.cs = "xen"; /* TODO, find a better way of doing this. */
>>>>  
>>>>      prop_len = 0;
>>>>      prop_len += snprintf(buf + prop_len,
>>> ... you also switch to using name.cs down below here and ...
>>>
>>>> --- a/xen/arch/x86/efi/efi-boot.h
>>>> +++ b/xen/arch/x86/efi/efi-boot.h
>>>> @@ -324,7 +324,8 @@ static void __init efi_arch_handle_cmdline(CHAR16 
>>>> *image_name,
>>>>          w2s(&name);
>>>>      }
>>>>      else
>>>> -        name.s = "xen";
>>>> +        name.cs = "xen"; /* TODO, find a better way of doing this. */
>>>> +
>>>>      place_string(&mbi.cmdline, name.s);
>>> ... here?
>>>
>>> An alternative would be to introduce 'char xen[4] = "xen";' in both
>>> cases, and use them instead of plain string literals.
>> They'd have to be static, or dynamically allocated or they'll end up out
>> of scope, wont they?

No, place_string() copies into the target area. The input string then
isn't further used.

>> I have to admit I find this logic very hard to follow.
>>
>> Furthermore, I note:
>>
>> mbi.boot_loader_name = (long)"EFI";
>>
>> which is exactly the kind of pointer which is liable to end up being
>> edited via kextra in the other patch.
> 
> Hang on.  place_string()'ing here is just to prepend a piece of data we
> go to other lengths to strip and ignore later in boot.
> 
> On x86 we can just delete it and make our lives simpler.  I hope the
> same is true on ARM too.

Well, yes, the prepending is just to allow uniform handling later on.
Surely this can be done differently. Again - I'll go look at v2.

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.