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

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


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 22 Apr 2024 12:57:55 +0200
  • 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: Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 22 Apr 2024 10:58:01 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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?

> So when st_value == __init_begin check if the name matches
> "__init_begin" or "__2M_init_start" or "_sinittext", and fail
> resolution, otherwise allow it?

Kind of, but that's not enough. For one, as said, the first symbol in
the first .init.* section would also have this same address, and would
also want rejecting. And then the same would be needed for __init_end.

>> Worse (but contrived) would be cases of "constructed" symbols derived from
>> ones ahead of __init_begin, with an offset large enough to actually point
>> into .init.*. Such are _still_ valid to be used in calculations, as long
>> as no deref occurs for anything at or past __init_begin.
> 
> But one would have to craft such a symbol specifically, at which point
> I consider this out of the scope of what this patch is attempting to
> protect against.  The aim is not to prevent malicious livepatches, and
> there are far easier ways to trigger a page-fault from a livepatch.

I understand the latter is the case, but I'm afraid I then don't see what
the goal of this change is.

Jan



 


Rackspace

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