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

Re: [PATCH] x86/extable: hide use of negative offset from array start


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 22 Feb 2023 12:26:19 +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=nGdPVvN+6sqr0QWyGpmV++DEXd8f/B8hU1wxly5arKM=; b=EHYEJV+7H224dOLEU0oP0rBmwSgwjBv6Ged6aMqp+5us6/H05zREPo17yoLfFQC4mZcDr9XWeujyZX21XF/xHEPzlqOlusNc45WNA0000wtLXV0hOoUDOB4+5nD5Xdax9LzBBmc2GxBYGLHaxvUX/OaOzoae0c0Dl4WlZ2HBSjpikePobfgZZ6QbBURZAvO0j01DU80/jqflGUtR/QFzmYXuFFm/OrvOneA0y3h2hs5taQgvrrhenHo3Rkkm9HsROvRIdkHqjqjvBB1TN1eD1TCEKQxrGCLjG86ABfiXEBAGt+IpRNXSbnQ8R4o4ru/DEwi6+99eV6CH2v80X5aItA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FOrmsWLKpyDOWPA162jOWemtnmWjtnEXMXHRTVytwKcHomSEN6vxR7nVZ7t/UwwuO4HSOyyIznTSR1BplBM5WAZuK5NxtDAgH1UtEea0porhtmOHDCi1qZuqmxQO1dqEKjiPwwJ8ndY/0Rydmz8rnBOYtFVPM+a+cswt1hBkZaaYd6I4khrYe/QxQmfB/bx2+XLkbD0BkfNv/OtDncZH7tYgcZGT+Ijoflha3XzmEq1O4+M8JhWQ+HttQG/TZy/pbfG7befML2G2+ZsWog2TO9ugyWEf0DUEn+/5F+MV9Zbr/GSdUWRbl2HAlTayzGIwL3nU3qB1L7zFSncw4IL1YQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 22 Feb 2023 11:26:37 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 22.02.2023 12:15, Andrew Cooper wrote:
> On 22/02/2023 10:22 am, Jan Beulich wrote:
>> In COVERAGE=y but DEBUG=n builds (observed by randconfig testing) gcc12
>> takes issue with the subtraction of 1 from __stop___pre_ex_table[],
>> considering this an out of bounds access. Not being able to know that
>> the symbol actually marks the end of an array, the compiler is kind of
>> right with this diagnosis. Move the subtraction into the function.
>>
>> Reported-by: Anthony PERARD <anthony.perard@xxxxxxxxxx>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>> To keep things simple, I'm merely calculating "last" as a local variable
>> now, rather than replacing its uses by suitable ones of "end". In the
>> longer run it may become necessary to actually go this 2nd step, as in
>> principle the compiler could inline the function and then still spot the
>> same issue. However, while the subtraction of 1 can likely be avoided by
>> suitable other adjustments, "last - first" cannot easily be. Yet that's
>> also an offense, in that it's calculating the difference between pointers
>> into distinct objects.
> 
> All of these bugs are ultimately because gcc doesn't know that these two
> labels are the bounds of a single array, and not separate objects.
> 
> There is no possible at all to get rid of the "last - first" calculation
> - this is a binary search through an array.  But it's also not going to
> actually stop working, because this is the common (and documented) way
> of getting linker symbols into C.

I disagree with the "impossible" aspect: Rather than surfacing start/end
symbols, a start/size pair would eliminate all such concerns. Recall my
attempt to make use of .startof. and .sizeof. assembly operators, which
sadly Clang doesn't support? (These aren't properly usable here, because
there's no separate .extable section in the final binary, so the remark
is merely to support the point I'm trying to make.)

I'm also unsure of that supposedly documented way actually covering
symbols at the end of objects. If that really was meant to be like that,
then why would Misra make an issue of it?

> For the patch, Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>  but

Thanks.

> if it were me, I'd have gone one step further and made
> search_one_extable() into a more normal looking binary search.

Well, I kind of inferred that from your reply on the original thread,
but I have to admit that it's not really clear to me why things would
end up "more normal looking" if the upper bound is exclusive rather
than inclusive.

Jan



 


Rackspace

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