|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 07/16] livepatch/arm/x86: Check payload for for unwelcomed symbols.
>>> On 19.09.16 at 16:13, <julien.grall@xxxxxxx> wrote:
>
> On 19/09/2016 16:11, Jan Beulich wrote:
>>>>> On 19.09.16 at 15:33, <julien.grall@xxxxxxx> wrote:
>>> On 19/09/2016 11:27, Jan Beulich wrote:
>>>>>>> On 16.09.16 at 18:38, <konrad.wilk@xxxxxxxxxx> wrote:
>>>>> --- a/xen/arch/arm/livepatch.c
>>>>> +++ b/xen/arch/arm/livepatch.c
>>>>> @@ -117,6 +117,20 @@ bool arch_livepatch_symbol_ok(const struct
>>>>> livepatch_elf
>>> *elf,
>>>>> return true;
>>>>> }
>>>>>
>>>>> +bool arch_livepatch_symbol_deny(const struct livepatch_elf *elf,
>>>>> + const struct livepatch_elf_sym *sym)
>>>>> +{
>>>>> +#ifdef CONFIG_ARM_32
>>>>> + /*
>>>>> + * Xen does not use Thumb instructions - and we should not see any of
>>>>> + * them. If we do, abort.
>>>>> + */
>>>>> + if ( sym->name && *sym->name == '$' && sym->name[1] == 't' )
>>>
>>> Please use sym->name[0] for readability. Also, you may want to check the
>>> length of the symbol before checking the second character.
>>
>> Why would the length check be needed? If the first character is $,
>> then looking at the second one is always valid (and it being nul will
>> be properly dealt with by the expression above).
>
> Because you may have a payload which is not valid? Or maybe you consider
> that all the payload are trusted.
If all symbols' names are inside their string tables and the string
tables are both contained inside the image and have a zero byte
at their end (all of which gets verified afair), nothing bad can
happen I think.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |