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

Re: [RFC PATCH v1] arch/x86: Livepatch: fix overflow check when computing ELF relocations


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 8 Mar 2022 17:53:11 +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=n+2Ls0OgjiwbyRerevIP0KKIiPnSbGETld3+mPdUBRU=; b=B3Iey5BPDCJW40hsyF3DdLAZIbnq2b2o8HaQxm3szDY9jdoqsMNqhob1YPjdb7a7P/VKyjEMSn0BcAVZpsLDpWX6QV1GiBtz5eb5v40NDEMTDTrYkoTgNcFKs5M5/q4U1joSCLgAplb1/SHYjG7BZdGcLK4GGHUENRrccQPztKipnP3mIbG0rMxuf88JQSmzSs6BNhnpkesP0u3q2v6TQyDHlyWHDmvrOLqzC1LBrU/OJjWKXY5r7GRP7qc3J5Q/ksd0E34oFshFtWIjzTG1VP8IH7YYZzyNwWnb4X9CNq1VqNOctyn3Aw6U2Clb1ITeAt4BOUNhA7BH8mU4I5nGTA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ntuCSXI+b+C6Mp8vGGsUYBoQF4omQzJnz1fhHstYjKapppnzah9qp4QhEAnJd3bwOxGMDAPeLhpHuUm2iVIRVNzmu3e+fGP35BuFMz69HmzFbHUEmzixjqZeEQxSCrLxCJwPPXu0gJHd8qOY5NuEn8h92h8ITsJBd22tDr7x5BuusZ+6JSDewLqzl1WLPNyb2qmi+cEJJjuHun/2C5TbcFBIiERkm8oz3W6lVG/ShkWWC+NiXAXcXwqYv4Qke+PUadVcr4oYABrQuI8JfW4w4T9YxLlFrA9YgskxWPRuslwVI3cta0A+PTGB6VPaQMCwBfFy88U7aZvXPsmMQeSGiw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Michael Kurth <mku@xxxxxxxxx>, Martin Pohlack <mpohlack@xxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, Bjoern Doebel <doebel@xxxxxxxxx>
  • Delivery-date: Tue, 08 Mar 2022 16:53:18 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 08.03.2022 17:26, Roger Pau Monné wrote:
> On Tue, Mar 08, 2022 at 05:15:33PM +0100, Roger Pau Monné wrote:
>> On Tue, Mar 08, 2022 at 04:45:34PM +0100, Jan Beulich wrote:
>>> On 08.03.2022 16:36, Bjoern Doebel wrote:
>>>> --- a/xen/arch/x86/livepatch.c
>>>> +++ b/xen/arch/x86/livepatch.c
>>>> @@ -339,7 +339,7 @@ int arch_livepatch_perform_rela(struct livepatch_elf 
>>>> *elf,
>>>>  
>>>>              val -= (uint64_t)dest;
>>>>              *(int32_t *)dest = val;
>>>
>>> Afaict after this assignment ...
>>>
>>>> -            if ( (int64_t)val != *(int32_t *)dest )
>>>> +            if ( (int32_t)val != *(int32_t *)dest )
>>>
>>> ... this condition can never be false. The cast really wants to be
>>> to int64_t, and the overflow you saw being reported is quite likely
>>> for a different reason. But from the sole message you did quote
>>> it's not really possible to figure what else is wrong.
>>
>> It seems Linux has that check ifdef'ed [0], but there's no reference
>> as to why it's that way (I've tracked it back to the x86-64 import on
>> the historical tree, f3081f5b66a06175ff2dabfe885a53fb04e71076).
>>
>> It's a 64bit relocation using a 32bit value, but it's unclear to me
>> that modifying the top 32bits is not allowed/intended.
> 
> Urg, I've worded this very badly. It's a 64bit relocation using a
> 32bit value, but it's unclear to me that modifying the top 32bits is
> not allowed/intended and fine to be dropped.

I'm still confused: Afaics this is in the handling of R_X86_64_PC32,
which is a 32-bit relocation. Only a 32-bit field in memory is to be
modified, and the resulting value needs to fit such that when the
CPU fetches it and sign-extends it to 64 bits, the original value is
re-established. Hence the check, aiui.

Jan




 


Rackspace

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