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

[PATCH v3] livepatch: account for patch offset when applying NOP patch


  • To: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 31 Mar 2022 08:49:46 +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=YGmDYJFRqVoX7TqiRs6LvG2xNPugw+qDMYWQQY9WFIk=; b=hmS8AgoHXHbxS//M+sAxLta4WMgdsxMCwCK0HEVIhWrj9uu/HPmu8qdrN5zaXpp9vfHQWFPXL3WFwyztgz6oFV1xEAxoSSgVO691hx1TER5W8UBQ6Lskac31o4Cky9hAf4aEwmFQXpTrOZGnqqXECGMassguk/mmYIKXF0vzdmVVZglqqoDKvgxAJozVabMyujX1Ttvpdfd+cO1kpWCbTpmR0/pQAufUxgs3/AgGvgOX+pl8s7bX9dCeONyc3DypUeL6DQzzZtQIEqzX2RKIM1MiuICHrwC/kLbWaZg0H0TCzbsByUNSclbpUSrZh229JLD/3hn2irQQ8gB6K+QuwQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T0lNIi00SSD7KLAihSuPtC56hey3IHS9ybT56qvcjegUdhcEl0Xn2GBktLWYySVpmVkYoVfNQlXeGq/Hh4ZvnMrddF1ap+zS+Hg2DqkgS3pXZmzae9j5+9Fqwailm3gNFIkKDtArs66/S8tKE9eBQp0e8dUVGMDreRi8fdvNgmIyvcj+RN1xTxUlfIz9BAik26ZzwiA+W51KCBwJC6+3NRKYTAcmmewNrV8jTVRetL/+QDGu4RdsQTvayURNKmxB0u27k3YNLZIiTAVyKYjyhPG23GoDuZWcxrko8jZ7uDBCC0D98e1XXKM8UlD3msbXCjXJ1zwUkM8rLAet4Jju5Q==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>, Konrad Wilk <konrad.wilk@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Bjoern Doebel <doebel@xxxxxxxxx>
  • Delivery-date: Thu, 31 Mar 2022 06:50:06 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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.

Fixes: 6974c75180f1 ("xen/x86: Livepatch: support patching CET-enhanced 
functions")
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
---
v3: Drop 1st livepatch_insn_len(). Drop buffer overrun fix.
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.

I think there's more fallout from the cited commit, but that'll need to
wait.

--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -145,9 +145,6 @@ void noinline arch_livepatch_apply(struc
 
     func->patch_offset = 0;
     old_ptr = func->old_addr;
-    len = livepatch_insn_len(func);
-    if ( !len )
-        return;
 
     /*
      * CET hotpatching support: We may have functions starting with an ENDBR64
@@ -160,6 +157,11 @@ void noinline arch_livepatch_apply(struc
     if ( is_endbr64(old_ptr) || is_endbr64_poison(func->old_addr) )
         func->patch_offset += ENDBR64_LEN;
 
+    /* This call must be done with ->patch_offset already set. */
+    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;
 
     return ARCH_PATCH_INSN_SIZE;
 }




 


Rackspace

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