> -----Original Message-----
> From: Xen-devel <xen-devel-boun...@lists.xenproject.org> On Behalf Of
> Jiamei Xie
> Sent: 2022年3月17日 17:17
> To: Ross Lagerwall <ross.lagerw...@citrix.com>; Bjoern Doebel
> <doe...@amazon.de>; xen-devel@lists.xenproject.org
> Cc: Michael Kurth <m...@amazon.de>; Martin Pohlack
> <mpohl...@amazon.de>; Roger Pau Monne <roger....@citrix.com>;
> Andrew Cooper <andrew.coop...@citrix.com>; Konrad Rzeszutek Wilk
> <konrad.w...@oracle.com>
> Subject: RE: [PATCH v5 2/2] xen/x86: Livepatch: support patching CET-
> enhanced functions
>
> Hi Bjoern,
>
> > -----Original Message-----
> > From: Xen-devel <xen-devel-boun...@lists.xenproject.org> On Behalf Of
> > Ross Lagerwall
> > Sent: 2022年3月10日 1:12
> > To: Bjoern Doebel <doe...@amazon.de>; xen-devel@lists.xenproject.org
> > Cc: Michael Kurth <m...@amazon.de>; Martin Pohlack
> > <mpohl...@amazon.de>; Roger Pau Monne <roger....@citrix.com>;
> > Andrew Cooper <andrew.coop...@citrix.com>; Konrad Rzeszutek Wilk
> > <konrad.w...@oracle.com>
> > Subject: Re: [PATCH v5 2/2] xen/x86: Livepatch: support patching CET-
> > enhanced functions
> >
> > > From: Bjoern Doebel <doe...@amazon.de>
> > > Sent: Wednesday, March 9, 2022 2:53 PM
> > > To: xen-devel@lists.xenproject.org <xen-devel@lists.xenproject.org>
> > > Cc: Michael Kurth <m...@amazon.de>; Martin Pohlack
> > <mpohl...@amazon.de>; Roger Pau Monne <roger....@citrix.com>;
> > Andrew Cooper <andrew.coop...@citrix.com>; Bjoern Doebel
> > <doe...@amazon.de>; Konrad Rzeszutek Wilk <konrad.w...@oracle.com>;
> > Ross Lagerwall <ross.lagerw...@citrix.com>
> > > Subject: [PATCH v5 2/2] xen/x86: Livepatch: support patching CET-
> > enhanced functions
> > >
> > > Xen enabled CET for supporting architectures. The control flow aspect of
> > > CET expects functions that can be called indirectly (i.e., via function
> > > pointers) to start with an ENDBR64 instruction. Otherwise a control flow
> > > exception is raised.
> > >
> > > This expectation breaks livepatching flows because we patch functions by
> > > overwriting their first 5 bytes with a JMP + <offset>, thus breaking the
> > > ENDBR64. We fix this by checking the start of a patched function for
> > > being ENDBR64. In the positive case we move the livepatch JMP to start
> > > behind the ENDBR64 instruction.
> > >
> > > To avoid having to guess the ENDBR64 offset again on patch reversal
> > > (which might race with other mechanisms adding/removing ENDBR
> > > dynamically), use the livepatch metadata to store the computed offset
> > > along with the saved bytes of the overwritten function.
> > >
> > > Signed-off-by: Bjoern Doebel <doe...@amazon.de>
> > > Acked-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
> > > CC: Ross Lagerwall <ross.lagerw...@citrix.com>
> >
> > Reviewed-by: Ross Lagerwall <ross.lagerw...@citrix.com>
>
> Tested-by: Jiamei xie <jiamei....@arm.com>
>
> Cheers,
> Jiamei
Sorry I forgot to add the scope I tested in last email. I tested it on armv8a.
It worked fine and didn't break arm.
Tested-by: Jiamei xie <jiamei....@arm.com>
> Cheers,
> Jiamei
