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

Re: [PATCH v2 2/2] xen: Fix latent check-endbr.sh bug with 32bit build environments


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 18 Jul 2022 11:11:38 +0200
  • 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=JEEVgnAVgf0unhwcndHTceHBQIXvox7S5PPgOOD0iHs=; b=MRQxS+cPeHkx3bz+725HEzmHaSBVxYSEcT4H0GuMzxGmGkzjZU/8kTczlq67F7AA3ef/sLA7GfPTw3wS8OYfMAl/QOT2btCgpsMLs1pJP+y9N2EJIN9uTvweq+bQrxiFzWaTV/rVHCPsN0zxrQS7B6wzZd81JxDQ7dqbAfrvJ7A0kPh/CC/L1jY/ht1q/4E+B/EGvvSw693spMKfhEIW5Me74HJ5vHDjy1YpF/z1TMPVB5yDFgosxhyEWYTTVu5DNVWykaPpUhX9Lf0fWPL80COrSDwXNunK3mPjbgAZrpoE1k/azINjrJdiPoljgcGe6FPjoxNghFSWgB5puSLRGw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UKeZSm6Igia5t4k/foPy3hLJOLKqsL8sVyvJXX2HtxIphSNd0z951snGyRazldQV2YN0YEUUvvzPcYngBp3/29PzGbVVk/anQ+bDakqauCKh0k6q+jJZ5jq1ciFh3hvzVXL+RGVVjBd4bhuQJuBi/4x6wVKxJDbUy0EtSpop7JIHSer+dy2LnVHVBnj8wb49sI82a1jkcsTT6s034mtK83hWiQoQdICoZZVnFSgq0z+0LQaBsAJKPC1LNY5iJu+Owv3wW2ugMROlUyufHzlpGUTsbuMuwx2Et8kxbHLcFT2oSODblswRBAvDVcZbmzR7tePjb88V8qDa6UgOG1JK8Q==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Luca Fancellu <Luca.Fancellu@xxxxxxx>, Mathieu Tarral <mathieu.tarral@xxxxxxxxxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 18 Jul 2022 09:11:51 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 15.07.2022 15:26, Andrew Cooper wrote:
> While Xen's current VMA means it works, the mawk fix (i.e. using $((0xN)) in
> the shell) isn't portable in 32bit shells.  See the code comment for the fix.
> 
> The fix found a second latent bug.  Recombining $vma_hi/lo should have used
> printf "%s%08x" and only worked previously because $vma_lo had bits set in
> it's top nibble.  Combining with the main fix, %08x becomes %07x.
> 
> Fixes: $XXX patch 1
> Reported-by: Jan Beulich <JBeulich@xxxxxxxx>
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
with, I guess, ...

> --- a/xen/tools/check-endbr.sh
> +++ b/xen/tools/check-endbr.sh
> @@ -61,19 +61,36 @@ ${OBJDUMP} -j .text $1 -d -w | grep '     endbr64 *$' | 
> cut -f 1 -d ':' > $VALID &
>  #    the lower bits, rounding integers to the nearest 4k.
>  #
>  #    Instead, use the fact that Xen's .text is within a 1G aligned region, 
> and
> -#    split the VMA in half so AWK's numeric addition is only working on 32 
> bit
> -#    numbers, which don't lose precision.
> +#    split the VMA so AWK's numeric addition is only working on <32 bit
> +#    numbers, which don't lose precision.  (See point 5)
>  #
>  # 4) MAWK doesn't support plain hex constants (an optional part of the POSIX
>  #    spec), and GAWK and MAWK can't agree on how to work with hex constants 
> in
>  #    a string.  Use the shell to convert $vma_lo to decimal before passing to
>  #    AWK.
>  #
> +# 5) Point 4 isn't fully portable.  POSIX only requires that $((0xN)) be
> +#    evaluated as long, which in 32bit shells turns negative if bit 31 of the
> +#    VMA is set.  AWK then interprets this negative number as a double before
> +#    adding the offsets from the binary grep.
> +#
> +#    Instead of doing an 8/8 split with vma_hi/lo, do a 9/7 split.
> +#
> +#    The consequence of this is that for all offsets, $vma_lo + offset needs
> +#    to be less that 256M (i.e. 7 nibbles) so as to be successfully 
> recombined
> +#    with the 9 nibbles of $vma_hi.  This is fine; .text is at the start of a
> +#    1G aligned region, and Xen is far far smaller than 256M, but leave 
> safety
> +#    check nevertheless.
> +#
>  eval $(${OBJDUMP} -j .text $1 -h |
> -    $AWK '$2 == ".text" {printf "vma_hi=%s\nvma_lo=%s\n", substr($4, 1, 8), 
> substr($4, 9, 16)}')
> +    $AWK '$2 == ".text" {printf "vma_hi=%s\nvma_lo=%s\n", substr($4, 1, 9), 
> substr($4, 10, 16)}')
>  
>  ${OBJCOPY} -j .text $1 -O binary $TEXT_BIN
>  
> +bin_sz=$(stat -c '%s' $TEXT_BIN)
> +[ "$bin_sz" -ge $(((1 << 28) - $vma_lo)) ] &&
> +    { echo "$MSG_PFX Error: .text offsets can exceed 256M" >&2; exit 1; }

... s/can/cannot/ ?

Jan



 


Rackspace

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