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

Re: [PATCH 3/3] livepatch: correctly handle altinstruction sections


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 11 Mar 2022 09:18:31 +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=UFAvEK9VlK6CHPGYBUtNcbmWwHUOBj8Z9Dz/0FXC03A=; b=ZLE7JL7vv3Ge6yQoQO+H5eKvTUrG3LTBzOtig9u9kFHKTtV4wooQuFS/7vvLz/C6wdCXd8Ms5G/no2g2LNZY9NC4l5Ue5XKH+JFMiPpWWFJIjS/mbrZQxKnppAilYUgSs2/YprVTGblSUAsRfxo/kwCwAB5VmgKlMsRRCUHqqt6B3EMjVkbEp0UP4QG9qhNE3RuR8tEpZBkmZm9JxDaRgpiwwe1xbNLo3fxVeISwX3TjUElhD1+WPv5nYgtfg/+ZrbMmA2v8MmTU+dHX2vVTTysSrQD63qn03cKWdJdxzyN3ZhKlzNfDhMTq6912mkz5ejTPKZ2SF/mxYDSnw0WsOw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LH87ZTVCXBbA1XnRnC2aoRImnLn30WzurGQzdNJAuHedeaiue4/bGnY9qX8FupbadnNGyCvPFt2rivc5CbkkTYE/yvwgCyow5kuMpzMg7ypQzUQ9YGSzYni9HGESa/ZrIbj1b5H8CDpse1dQ0jyZtSvGDbU6+cv7MV2ESglDdPBcJZayJYqNPXleznb0kluI0rtuMmElj7VlfI2ZQuzsB29pyUDvz1WsCtX7/oGEUBr/GAn6VBQsWfp0Ct9K8VIxno6z/vEhNYpHCg+MK9Vk1XAYNLLEcyJqgMeGEmLdsSzAZh1AvzPzSnMfQ16jM9pGnQlPVKrJDQEjjuIE9ZDFLw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>, doebel@xxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 11 Mar 2022 08:18:51 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 11.03.2022 09:12, Roger Pau Monné wrote:
> On Fri, Mar 11, 2022 at 08:35:18AM +0100, Jan Beulich wrote:
>> On 10.03.2022 16:08, Roger Pau Monne wrote:
>>> --- a/common.c
>>> +++ b/common.c
>>> @@ -249,19 +249,22 @@ int is_text_section(struct section *sec)
>>>             (sec->sh.sh_flags & SHF_EXECINSTR));
>>>  }
>>>  
>>> +#define SEC_MATCH(n) !strncmp(sec->name, n, strlen(n) - 1)
>>>  int is_rodata_section(struct section *sec)
>>>  {
>>>     return sec->sh.sh_type == SHT_PROGBITS &&
>>>            !(sec->sh.sh_flags & (SHF_EXECINSTR | SHF_WRITE)) &&
>>> -          !strncmp(sec->name, ".rodata", 7);
>>> +          (SEC_MATCH(".rodata") || SEC_MATCH(".data.ro_after_init"));
>>>  }
>>>  
>>>  int is_init_section(struct section *sec)
>>>  {
>>>     return sec->sh.sh_type == SHT_PROGBITS &&
>>>            (sec->sh.sh_flags & SHF_ALLOC) &&
>>> -          !strncmp(sec->name, ".init", 5);
>>> +          (SEC_MATCH(".init") || SEC_MATCH(".text.startup") ||
>>> +           SEC_MATCH(".altinstr") || SEC_MATCH(".ctors"));
>>
>> Having dealt with this recently - what about .init_array? Modern gcc
>> prefers that over .ctors. Of course the question is whether either
>> really needs dealing with here - these sections, to my knowledge,
>> appear only with gcov support enabled. Not sure that's a case where
>> livepatching is actually expected to be used.
> 
> .init_array will match the .init comparison, and thus is already
> handled.

Oh, I guess I should have looked at what SEC_MATCH() actually does.

> Regarding .ctors, it's certainly an .init section, so it doesn't hurt
> to get added here in any case? (regardless of us only knowing it being
> used for code coverage so far)

It certainly doesn't hurt, sure.

Jan




 


Rackspace

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