[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2] livepatch: account for patch offset when applying NOP patch
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Wed, 30 Mar 2022 16:19:30 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.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=1vz7X0ovNdPoy6DasZte3c/fXEnJEYSs+oV9r1hVhM8=; b=EukQ7ROE18Y52lZK6HiLzA9b/6dlqzdipGb5c5TNEpUgn1GZpR0bqr701Z7nAykXxqTKsXefyqJ/T/qzwLU5A2DvoeiiZcMa22STOX3mvfcasb5cguWWuRD30GVTjebAnoowRnPbbPKxMpOoJER+uV8OQWtXBCLRFA0w1qkmV5eQqsteRRvjU8zoa0Z5OpXE7MaFK4058sdkZYs1zELAGlBeS0f9GT4DLprGQRBRG1ZIVWhK8xcMzpnCov3l4e8ya+p+mdzmc6ULXejkbwBvfhZwI8AB5XnTxyDtGiNGkXSWF0rSilkxUKbVoYIc4qr/5HZNBYEb+4e106LObxNwuQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=j2T2lFXR9xptOy6RVK88YfskQuXgUkHR/0jfIvDupWbgY4m9Ber8FD+4oGR9qTbymMTlTb3i3UVWqi8bghm0WNYgkQPBGBa+gEFiN2QvpQ/okJ/B2dGTf5Eu/5cA5egj2C9FyskmvuQ9u+XiL5IpxlXDI3gbS7DDwSq+MTiKoaFDRJN4hYNQjhviBts6lBJygInLZja1K4gqyNUZ8qjawM2wOmGlGyU8Gel0w6LCXB3YBa+KGZ2u4NlS22zzjm58NuvpxQPOuYp5xSR3rT1G+zLpjo0USXYHeGGRTZYq1+u59qrGDof5Mgu2hOh3LCiauHSNW69mWkPii+qaUG52wg==
- Authentication-results: esa3.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>, Konrad Wilk <konrad.wilk@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Bjoern Doebel <doebel@xxxxxxxxx>
- Delivery-date: Wed, 30 Mar 2022 14:20:01 +0000
- Ironport-data: A9a23:zbJuK6liWBkRURxBQPyduJro5gy/JkRdPkR7XQ2eYbSJt1+Wr1Gzt xJNWGmCP/aLZjakeotzO9y29E1U6pLUm4VmSAJt+S0zHyMWpZLJC+rCIxarNUt+DCFioGGLT Sk6QoOdRCzhZiaE/n9BCpC48T8kk/vgqoPUUIYoAAgoLeNfYHpn2EoLd9IR2NYy24DiWFvV4 7senuWEULOb828sWo4rw/rrRCNH5JwebxtB4zTSzdgS1LPvvyF94KA3fMldHFOhKmVgJcaoR v6r8V2M1jixEyHBqD+Suu2TnkUiGtY+NOUV45Zcc/DKbhNq/kTe3kunXRa1hIg+ZzihxrhMJ NtxWZOYcQFuE7CTm+cnaTZSDzwgJK5d/ub3Li3q2SCT5xWun3rExvxvCAc9PJEC+/YxCmZLn RAaAGlTNFbZ3bvwme/lDLk37iggBJCD0Ic3oHZvwCufFf87aZvCX7/L9ZlT2zJYasVmQ6mDO 5tIOWEHgBLoR0cfYmsGI54Fh72Khlz1XxZ+q2+tnP9ii4TU5FMoi+W8WDbPQfSVQe1Fk0Deo XjJl0z1BRwQOdi3wD+M4HWqwOPC9Qv4X4QIHbH+6f9ug3WU3GUYDBBQXly+ydG7gEOjX9NUK 2QP5zEj66M18SSDXtT7GhG1vnOAlhodQMZLVf037hmXzajZ6BrfAXILJgOtc/R/6pVwH2Zzk AbUwZW5XlSDrYF5V1ql8PC5sGyxOhIvAmUeeHEdThADuuns9dRbYg30cv5vF6u8j9vQED72w iyXoCVWu4j/nfLnxI3gowmZ3mvESozhC1dsu16JBj7NAhZRPtbNWmC+1bTMAR+sxq69R0LJg nULktP2AAsmXcDUz3zlrAng8diUCxe53N/03AYH83oJrW3FF5ufkWZ4umsWyKBBaJtsRNMRS BWP0T69HbcKVJdQUYd5YpiqF+MhxrX6GNLuW5j8N4QSMsUhLlbdpHs2OSZ8OlwBdmB2y8nT3 r/BLK6R4YsyU/w7nFJauc9DuVPU+szO7TyKHs2qp/hW+bGfeGSUWd843KimNYgEAFe/iFyNq b53bpLSoz0GCbGWSnSHoOY7cAFRRVBmVM+eliCiXrPaSuaQMDp6UKG5LHJIU9ENopm5Yc+Vp ynkARUJkQCXaL+uAVziV02PoYjHBP5XhXk6ITYtLRCv3X0iapyo96ARa908erxPyQCp5acco yUtEylYPslydw==
- Ironport-hdrordr: A9a23:0cxXz66/Q3v8MSvYXwPXwSSBI+orL9Y04lQ7vn2ZFiY7TiXIra yTdaoguCMc6AxxZJkh8erwX5VoZUmsj6KdgLNhRotKOTOJhILGFvAB0WKP+UyEJ8S6zJ8h6U 4CSdkBNDSTNykCsS+S2mDReLxBsbq6GeKT9J/jJh9WPH5XgspbnmFE42igYylLrF4sP+tEKH PQ3LsPmxOQPVAsKuirDHgMWObO4/XNiZLdeBYDQzoq8hOHgz+E4KPzV0Hw5GZUbxp/hZMZtU TVmQ3w4auu99m91x/nzmfWq7BbgsHoxNdvDNGFzuIVNjLvoAC1Y5kJYczLgBkF5MWUrHo6mt jFpBkte+x19nPqZ2mw5SDg3gHxuQxen0PK+Bu9uz/OsMb5TDU1B45qnoRCaCbU7EImoZVVzL 9L93jxjesaMTrw2ADGo/TYXRBjkUS55VA4l/QIsnBZWYwCLJdMsI0k+l9PGptoJlO21GkeKp ghMCjg3ocWTbvDBEqp/lWHgebcFEjbJy32DXTr4aeuontrdHMQ9Tps+CVQpAZDyHsHceg12w 31CNUYqFhwdL5kUUtcPpZ3fSLlMB26ffrzWFjiU2gPUpt3fk7wlw==
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Wed, Mar 30, 2022 at 01:05:31PM +0200, Jan Beulich wrote:
> While not triggered by the trivial xen_nop in-tree patch on
> staging/master, that patch exposes a problem on the stable trees, where
> all functions have ENDBR inserted. When NOP-ing out a range, we need to
> account for this. Handle this right in livepatch_insn_len().
>
> This requires livepatch_insn_len() to be called _after_ ->patch_offset
> was set. Note however that the earlier call cannot be deleted. In fact
> its result should have been used to guard the is_endbr64() /
> is_endbr64_poison() invocations - add the missing check now. While
> making that adjustment, also use the local variable "old_ptr"
> consistently.
>
> Fixes: 6974c75180f1 ("xen/x86: Livepatch: support patching CET-enhanced
> functions")
I have to admit I'm confused as to why that commit carries a Tested-by
from Arm. Did Arm test the commit on x86 hardware? Because that
commit only touches x86 specific code.
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
FWIW, on the original implementation, I think it would have been
clearer to advance old_ptr and adjust the length?
> ---
> v2: Re-issue livepatch_insn_len(). Fix buffer overrun.
> ---
> Only build tested, as I don't have a live patching environment available.
>
> For Arm this assumes that the patch_offset field starts out as zero; I
> think we can make such an assumption, yet otoh on x86 explicit
> initialization was added by the cited commit.
>
> Note that the other use of is_endbr64() / is_endbr64_poison() in
> arch_livepatch_verify_func() would need the extra check only for
> cosmetic reasons, because ARCH_PATCH_INSN_SIZE > ENDBR64_LEN (5 > 4).
> Hence I'm not altering the code there.
>
> --- a/xen/arch/x86/livepatch.c
> +++ b/xen/arch/x86/livepatch.c
> @@ -157,9 +157,15 @@ void noinline arch_livepatch_apply(struc
> * loaded hotpatch (to avoid racing against other fixups adding/removing
> * ENDBR64 or similar instructions).
> */
> - if ( is_endbr64(old_ptr) || is_endbr64_poison(func->old_addr) )
> + if ( len >= ENDBR64_LEN &&
> + (is_endbr64(old_ptr) || is_endbr64_poison(old_ptr)) )
> func->patch_offset += ENDBR64_LEN;
>
> + /* This call must be re-issued once ->patch_offset has its final value.
> */
> + len = livepatch_insn_len(func);
> + if ( !len )
> + return;
> +
> memcpy(func->opaque, old_ptr + func->patch_offset, len);
> if ( func->new_addr )
> {
> --- a/xen/include/xen/livepatch.h
> +++ b/xen/include/xen/livepatch.h
> @@ -90,7 +90,7 @@ static inline
> unsigned int livepatch_insn_len(const struct livepatch_func *func)
> {
> if ( !func->new_addr )
> - return func->new_size;
> + return func->new_size - func->patch_offset;
Seeing as func->patch_offset is explicitly initialized in
arch_livepatch_apply for x86, do we also need to do the same on Arm
now that the field will be used by common code?
Maybe the initialization done in arch_livepatch_apply for x86 is not
strictly required.
Thanks, Roger.
|