Re: [PATCH v2 2/2] livepatch: refuse to resolve symbols that belong to init sections

[Jan Beulich <jbeulich@xxxxxxxx>]

On 22.04.2024 13:34, Roger Pau Monné wrote:
> On Mon, Apr 22, 2024 at 12:57:55PM +0200, Jan Beulich wrote:
>> On 22.04.2024 12:49, Roger Pau Monné wrote:
>>> On Mon, Apr 22, 2024 at 10:25:40AM +0200, Jan Beulich wrote:
>>>> On 22.04.2024 09:54, Roger Pau Monné wrote:
>>>>> On Fri, Apr 19, 2024 at 04:34:41PM +0200, Jan Beulich wrote:
>>>>>> On 19.04.2024 12:50, Roger Pau Monné wrote:
>>>>>>> On Fri, Apr 19, 2024 at 12:15:19PM +0200, Jan Beulich wrote:
>>>>>>>> On 19.04.2024 12:02, Roger Pau Monne wrote:
>>>>>>>>> Livepatch payloads containing symbols that belong to init sections 
>>>>>>>>> can only
>>>>>>>>> lead to page faults later on, as by the time the livepatch is loaded 
>>>>>>>>> init
>>>>>>>>> sections have already been freed.
>>>>>>>>>
>>>>>>>>> Refuse to resolve such symbols and return an error instead.
>>>>>>>>>
>>>>>>>>> Note such resolutions are only relevant for symbols that point to 
>>>>>>>>> undefined
>>>>>>>>> sections (SHN_UNDEF), as that implies the symbol is not in the 
>>>>>>>>> current payload
>>>>>>>>> and hence must either be a Xen or a different livepatch payload 
>>>>>>>>> symbol.
>>>>>>>>>
>>>>>>>>> Do not allow to resolve symbols that point to __init_begin, as that 
>>>>>>>>> address is
>>>>>>>>> also unmapped.  On the other hand, __init_end is not unmapped, and 
>>>>>>>>> hence allow
>>>>>>>>> resolutions against it.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
>>>>>>>>> ---
>>>>>>>>> Changes since v1:
>>>>>>>>>  - Fix off-by-one in range checking.
>>>>>>>>
>>>>>>>> Which means you addressed Andrew's comment while at the same time 
>>>>>>>> extending
>>>>>>>> the scope of ...
>>>>>>>>
>>>>>>>>> @@ -310,6 +311,21 @@ int livepatch_elf_resolve_symbols(struct 
>>>>>>>>> livepatch_elf *elf)
>>>>>>>>>                      break;
>>>>>>>>>                  }
>>>>>>>>>              }
>>>>>>>>> +
>>>>>>>>> +            /*
>>>>>>>>> +             * Ensure not an init symbol.  Only applicable to Xen 
>>>>>>>>> symbols, as
>>>>>>>>> +             * livepatch payloads don't have init sections or 
>>>>>>>>> equivalent.
>>>>>>>>> +             */
>>>>>>>>> +            else if ( st_value >= (uintptr_t)&__init_begin &&
>>>>>>>>> +                      st_value < (uintptr_t)&__init_end )
>>>>>>>>> +            {
>>>>>>>>> +                printk(XENLOG_ERR LIVEPATCH
>>>>>>>>> +                       "%s: symbol %s is in init section, not 
>>>>>>>>> resolving\n",
>>>>>>>>> +                       elf->name, elf->sym[i].name);
>>>>>>>>
>>>>>>>> ... what I raised concern about (and I had not seen any verbal reply 
>>>>>>>> to that,
>>>>>>>> I don't think).
>>>>>>>
>>>>>>> I've extended the commit message to explicitly mention the handling of
>>>>>>> bounds for __init_{begin,end} checks.  Let me know if you are not fine
>>>>>>> with it (or maybe you expected something else?).
>>>>>>
>>>>>> Well, you mention the two symbols you care about, but you don't mention
>>>>>> at all that these two may alias other symbols which might be legal to
>>>>>> reference from a livepatch.
>>>>>
>>>>> I'm having a hard time understanding why a livepatch would want to
>>>>> reference those, or any symbol in the .init sections for that matter.
>>>>> __init_{begin,end} are exclusively used to unmap the init region after
>>>>> boot.  What's the point in livepatch referencing data that's no
>>>>> longer there?  The only application I would think of is to calculate
>>>>> some kind of offsets, but that would better be done using other
>>>>> symbols instead.
>>>>>
>>>>> Please bear with me, it would be easier for me to understand if you
>>>>> could provide a concrete example.
>>>>
>>>> The issue is that you do comparison by address, not by name. Let's assume
>>>> that .rodata ends exactly where .init.* starts. Then &__init_begin ==
>>>> &_erodata == &__2M_rodata_end. Access to the latter two symbols wants to
>>>> be permitted; only __init_begin and whatever ends up being the very first
>>>> symbol in .init.* ought to not be referenced.
>>>
>>> Hm, I guess I could add comparison by name additionally, but it looks
>>> fragile to me.
>>
>> It looks fragile, yes. Thing is that you're trying to deal with this when
>> crucial information was lost already. Or wait - isn't the section number
>> still available in ->st_shndx?
> 
> But that's the section number of the to be resolved symbol?  In the
> livepatch payload it would for example appear as:
> 
> 0000000000000000       F *UND*        0000000000000000 .hidden 
> setup_boot_APIC_clock
> 
> With undefined section.
> 
> It's possible I'm not following, is there a way to get the section
> number of the current Xen symbols, and then correlate it with the
> .init section?

Hmm, yes, looks like I was forgetting that livepatch resolves symbols
using kallsyms data, not Xen's ELF symbol table.

Jan