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

Re: [PATCH] x86/cet: Use dedicated NOP4 for cf_clobber


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
  • Date: Tue, 8 Mar 2022 15:19:52 +0000
  • Accept-language: en-GB, en-US
  • 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=Do0+seH8JmTPVuWVnszBvv4ewmPEufWMTIktRX6Fiiw=; b=eqf+Rv3JaYOKML4dVUmb0FNtHa8mHQQRVgPN+tAXnO+Q3TS8zzR7y0/3Vw/ggGlBRkrQCjoGE7+Y2Cf1rKmdiihGrdC1ZJyCI+CdGx4eweH58qz3p7gG6+kU/wpx0CuL1WNcjKCVi8Su0+9u7Dquo1VwcojGWddA5BWABLGYa/xm6H1GTVJ12un0C+0/kAqWL3G6IDQVOEz+HUVmBImU0xAR3cJn2efBGXlC0xEtOlD6QyFL7AMNDkt4hsOWRLUiDhFo03Sg002jHkaDEgBIbwSHYxeT9+dqzJdSj6LUey+uccAX5NIjeRw7BQHgtkoe5Wj2v3qYZmij8vUpZPkK1g==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kZTqRkde/NdkZCtwO2Fcdohn+AdnfNL1AQaLqhT9GQwTILfe99cDaBqi9XcYxwE8+F7slPys5rLH99NdfFiaU14JkSfGo7x/mQfsnexQRD87dhSr8cNCQ/+FvsZixG4zvn8QGQiQWTyOK26AkMXMosGpzI4/WmcM31geDh2+INlU1yoIDRFr/NWaTV0f8VdVpTZ2GBaGyIN9ZttOqSr9Im9mdZ7KPImfsILsK5oafD/Vh7zYtM8rqC8P98T/Qz7KRGZNULzrV7AyUOIrO/VRUUK4KkTJZi97rQoenasJHza8Zz+gpA0oasuW6X7s6v+vu3Sj22MHnk4N/pAbkgCXAA==
  • Authentication-results: esa3.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Roger Pau Monne <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, "Bjoern Doebel" <doebel@xxxxxxxxx>, Michael Kurth <mku@xxxxxxxxx>, Martin Pohlack <mpohlack@xxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 08 Mar 2022 15:20:07 +0000
  • Ironport-data: A9a23:zT91YKDFvZ85NhVW/+Hjw5YqxClBgxIJ4kV8jS/XYbTApDtzgmQOm jZMDTiEb/yLYzSjLtl1a4S090JQ6MWBnYNhQQY4rX1jcSlH+JHPbTi7wuYcHM8wwunrFh8PA xA2M4GYRCwMZiaA4E/raNANlFEkvU2ybuOU5NXsZ2YgHWeIdA970Ug5w7Vh0tYy6TSEK1jlV e3a8pW31GCNg1aYAkpMg05UgEoy1BhakGpwUm0WPZinjneH/5UmJMt3yZWKB2n5WuFp8tuSH I4v+l0bElTxpH/BAvv9+lryn9ZjrrT6ZWBigVIOM0Sub4QrSoXfHc/XOdJFAXq7hQllkPhfm Otzi6e+az0sEaz2x9w2dl4DCHthaPguFL/veRBTsOSWxkzCNXDt3+9vHAc9OohwFuRfWD8Us 6ZCcXZUM07F17neLLGTE4GAguwKKsXxMZxZkXZn1TzDVt4tQIzZQrWM7thdtNs1rp4TQq+FP JpFAdZpRA+DegNCGAxONKMBp+OvqVzcKx5hl2vA8MLb5ECMlVcsgdABKuH9f9+XbcxQl1Sfo CTK8gzRBwkdNNiWwjmt+3ellOjJ2y/2MKoCGbv9+vN0jVm7wm0IFAZQRVa9ueO+iEO1R5RYM UN80igkoLU29UerZsLgRBD+q3mB1jYDX/JAHut87xuCooLY5AuTC2wsRztIetsg8sM7LQHGz XfQwYmvX2Y29uTIFzTNrd94sA9eJwA7fVE8WxQKbzEAzNjZ/7kYq1WUVYx8RfvdYsLOJRn8x DWDrS4bjroVjNIW26jTwW0rkw5AtbCSEFdru1y/snaNq1ogOdX7P9DABU3zsK4YRLt1WGVtq 5TtdyK2yOkVRa+AmyWWKAnmNOH4vq3VWNEwbLMGInXAy9hP0yP7FWyzyGsnTKuMDiriUWWxC KM0kVkNjKK/xFPwMcdKj3uZUqzGN5TIG9X/TezzZdFTeJV3fwLv1HgwORDOgDCwyxF8zPpX1 XKnnSCEVy1y5UNPlmbeegvg+eVzmnBWKZ37H/gXMChLIZLBPSXIGN/pwXOFb/wj7bPsnekm2 403Cid+8D0GCLeWSnCOqeY7dAlWRVBmVcGeg5EGLYarf1s5cFzN/teMmNvNjaQ+xP8L/goJl 1ngMnJlJK3X2SWXeV/UOyo4NNsCn/9X9BoGAMDlBn7xs1ALaoez9qYPMZwxeLgs7ut4yvBoC fICfq297j5nE1wrJxx1gUHBkbFf
  • Ironport-hdrordr: A9a23:SJh/b6kzxPuamlB9i6fUzpbkpKfpDfOCimdD5ihNYBxZY6Wkfp +V88jzhCWZtN9OYhwdcIi7SdS9qXO1z+8R3WGIVY3SEzUOy1HYUL2KirGSjQEIeheOutK1sJ 0PT0EQMqyIMbEXt7eY3OD8Kadb/DDlytHouQ699QYUcegCUcgJhG0ZajpzUHcGPzWubaBJT6 Z0jfA3wwZIDE5nCPhTcUN1ONQryee79q7OUFojPVoK+QOOhTSn5PrRCB6DxCoTVDtJ3PML7X XFuxaR3NTij9iLjjvnk0PD5ZVfn9XsjvFZAtaXt8QTIjLwzi61eYVaXaGYtjxdmpDt1L9qqq iPn/4TBbU215rjRBDznfIr4Xin7N8a0Q6m9bZfuwq7nSW2fkNjNyMLv/MnTvKQ0TtfgDg76t MQ44vRjesmMfuL9h6NluTgRlVkkFG5rmEllvNWh3tDUZEGYLsUtoAH+lhJea1wVx4SxbpXWd WGNvusrMq+sGnqG0zxry1q2pihT34zFhCJTgwLvdGUySFfmDR8w1EDzMISk38c/NZlIqM0qt jsI+BtjvVDX8UWZaVyCKMIRta2EHXERVbJPHiJKVrqGakbMzbGqoLx4r8y+Oa2EaZ4hqcaid DEShdVpGQyc0XhBYmH24BK6AnERCGnUTHk2qhllu5EU33HNc3W2AG4OSITepGb0oYi6+XgKo OOBK4=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHYMvUk0XiHSYNleUqdwHU2YHv5TKy1jjMAgAALzQA=
  • Thread-topic: [PATCH] x86/cet: Use dedicated NOP4 for cf_clobber

On 08/03/2022 14:37, Jan Beulich wrote:
> On 08.03.2022 15:01, Andrew Cooper wrote:
>> For livepatching, we need to look at a potentially clobbered function and
>> determine whether it used to have an ENDBR64 instruction.
>>
>> Use a non-default 4-byte P6 long nop, not emitted by toolchains, and 
>> introduce
>> the was_endbr64() predicate.
> Did you consider using ENDBR32 for this purpose?

No, and no because that's very short sighted.  Even 4 non-nops would be
better than ENDBR32, because they wouldn't create actually-usable
codepaths in corner cases we care to exclude.

> I'm worried that
> the pattern you picked is still too close to what might be used
> (down the road) by a tool chain.

This is what Linux are doing too, but no - I'm not worried.  The
encoding isn't the only protection; toolchains also have no reason to
put a nop4 at the head of functions; nop5 is the common one to find.

> One neat thing about ENDBR32 would be that you wouldn't even
> need memcpy() - you'd merely flip the low main opcode bit.

Not relevant.  You're taking the SMC pipeline hit for any sized write,
and a single movl is far less cryptic.

>> Bjoern: For the livepatching code, I think you want:
>>
>>   if ( is_endbr64(...) || was_endbr64(...) )
>>       needed += ENDBR64_LEN;
> Looks like I didn't fully understand the problem then from your
> initial description. The adjustment here (and the one needed in
> Björn's patch) is to compensate for the advancing of the
> targets of altcalls past the ENDBR?

No.  Consider this scenario:

callee:
    endbr64
    ...

altcall:
    call *foo(%rip)

During boot, we rewrite altcall to be `call callee+4` and turn endbr64
into nops, so it now looks like:

callee:
    nop4
    ...

altcall:
    call callee+4

Then we want to livepatch callee to callee_new, so we get

callee_new:
    endbr64
    ...

in the livepatch itself.

Now, to actually patch, we need to memcpy(callee+4, "jmp callee_new", 5).

The livepatch logic calling is_endbr(callee) doesn't work because it's
now a nop4, which is why it needs a was_endbr64(callee) too.

>
>> --- a/xen/arch/x86/include/asm/endbr.h
>> +++ b/xen/arch/x86/include/asm/endbr.h
>> @@ -52,4 +52,16 @@ static inline void place_endbr64(void *ptr)
>>      *(uint32_t *)ptr = gen_endbr64();
>>  }
>>  
>> +/*
>> + * After clobbering ENDBR64, we may need to confirm that the site used to
>> + * contain an ENDBR64 instruction.  Use an encoding which isn't the default
>> + * P6_NOP4.
>> + */
>> +#define ENDBR64_POISON "\x66\x0f\x1f\x00" /* osp nopl (%rax) */
> In case this remains as is - did you mean "opsz" instead of "osp"?
> But this really is "nopw (%rax)" anyway.

Oh, osp is the nasm name.  I'll switch to nopw.

~Andrew

 


Rackspace

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