[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: Thu, 17 Mar 2022 12:07:31 +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=EXv4usRYqcaqAZxKX8YAvDHrpqxWLQOIIfxnj2uQt9k=; b=n+UcPUI3X6IQv9PnlHNYdocg9uk2hrsdUGHBl59rH667kNvF3m7bgteNU9CucrpMel8tAa0efCnQyu3xo1nIEzqQaXozemdhKaK8dF9gVW/51mWlOH3ft717eHd2Gj+FQpDnxTUfL5UQdGd8Y9vJ9QhfASllr6s6OhbSDZSO/Fn2yV54tK/URQAZBSepzTl/7IpYTtD1nzZHY3QIGLyPCQ0h/D6NWMMvb02LZ5n8QuUytEU77wvCCvOQFvjIWIqx9YnGr+TwOP28w9dH5gDlHHXIk3Tiui7J5PN1dZxq/148+h9E/mvAIB5Pxd6qUhe+mMxgcGH7Qk8Pc7QTE4Q9dA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V+Ww4V5+22+yXyoeRsmBflqH8u7mrhfu7bIQTAMGzHpFfxgkBY9TJcOXWDtSxCBSfqtrxL5cGpQN+xhLmn2pdTxr8vDzwTm/q0uev92brjW2iIiptuCzhtn0oCwW5aCKFhzKnk8Nb4nrr2SFs6vPVxSFKCqvOkMUmTO4W2c7aaJVkg1rIPctMwPISp2RdWArxi7ucJEhd18no4jc9J97/BgQcHPu/Wa/TPdg/gKCcZUYoSPCM1ahlBepz9qr4N3peZLqE47bxaDmf4S9LF3mLvOcN5RN0jCbb0BPBW882D94JfG/STFUekzNCqkG++PJK8yUniXA+5haKwz234rFJg==
  • 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: Thu, 17 Mar 2022 12:07:59 +0000
  • Ironport-data: A9a23:iA7l5KzcWo/zquqpvcR6t+f+xirEfRIJ4+MujC+fZmUNrF6WrkUHn WRLWj3Ta/nbZ2GnfN93Ptji9UxXsZLRyddgSQU4pCAxQypGp/SeCIXCJC8cHc8zwu4v7q5Dx 59DAjUVBJlsFhcwnj/0bv656yMUOZigHtIQMsadUsxKbVIiGX9JZS5LwbZj2NYz2IfhWWthh PupyyHhEA79s9JLGjp8B5Kr8HuDa9yr5Vv0FnRnDRx6lAe2e0s9VfrzFonoR5fMeaFGH/bSe gr25OrRElU1XfsaIojNfr7TKiXmS1NJVOSEoiI+t6OK2nCuqsGuu0qS2TV1hUp/0l20c95NJ NplvLC0Sh4YeaHwxOkZDEZfEy5TNr1DweqSSZS/mZT7I0zudnLtx7NlDV0sPJ1e8eFyaY1M3 aVGcnZXNEnF3r/ohuLgIgVvrp1LwM3DFYUToHx/ixreCu4rW8vrSKTW/95Imjw3g6iiGN6AO ZZJOGM0MXwsZTVgGmU2JrMwgN6xpVbEfx4Jq1+Mj/Y4tj27IAtZj+G2bYu9lsaxbcBWg26Ro 2vU+GK/DhxyHNmHzjqB+3mvrubKlDH8XsQeGdWQ5vNsxVGe2GEXIBkXTkeg5+m0jFakXNBSI FBS/TAhxYAw/kG2Stj2XzWjvWWJ+BUbXrJ4DOkS+AyLjK3O7G6xCm8JRDNFQNUjvd0xQ3om2 ze0c8jBXGI19ufPEDTEq+nS/Wja1TUpwXEqbAMAThI0pNXf/Iw30U3ITtlOG76wt4igcd3v+ AyioC87jrQVqMcE0aSn4FzK6w6RSoj1oh0dvVuOAD/8hu9tTMv8PtHztwCHhRpVBNzBJmRtq kTojCR3AAomKZiW3BKAT+wWdF1Cz6bUaWaM6bKD8nRIythMx5JBVd0IiN2dDB0wWirhRdMPS BWP0e+2zMUPVEZGlYctP+qM5z0ClMAM7+jNWPHOdcZpaZNsbgKB9ywGTRfOgz+xzRd1y/9nZ srznSOQ4ZAyU/gPIN2eHbt17FPW7npmmTO7qW7TknxLLoZylFbKEOxYYTNin8gy7b+eoRW9z jqsH5Di9vmra8WnOnO/2ddKdTgidCFnbbir+50/XrPSeWJORTB+Y8I9NJt8IuSJaYwOzbyWl px8M2cFoGfCaYrvclzbNCo8NOuxAf6SbxsTZEQRALph4FB6Ca6H56YDbZonO74h8e1o1/lvS PcZPc6HB5xypv7vpFzxsbGVQFReSSmW
  • Ironport-hdrordr: A9a23:/8qNeq4rPRYwP1rRtQPXwWiBI+orL9Y04lQ7vn2ZFiY6TiXIra +TdaoguSMc0AxhJE3Jmbi7Sc29qeu1z+863WBjB8bcYOCAghroEGgC1/qs/9SEIUzDH4FmpN 9dmsRFeb/N5B1B/LvHCWqDYpYdKbu8gduVbI7lph8HJ2wLGsJdBkVCe3ym+yVNNVN77PECZf 2hD7981kOdkAMsH6KG7xc+Lo3+juyOsKijTQ8NBhYh5gXLpyiv8qTGHx+R2Qpbey9TwJ85mF K10DDR1+GGibWW2xXc32jc49B9g9360OZOA8SKl4w8NijssAC1f45sMofy/gzd4dvfrWrCou O85CvIDP4DrU85uVvF+CcF7jOQlArGLUWSkWNwz0GT+vARDwhKdfapzbgpAycxrXBQ4e2UmZ g7rF5w/fBsfGP9tTW46N7SWx5wkE2o5XIkjO4IlnRaFZATcblLsOUkjQlo+bo7bWrHAbocYa JT5QDnlYFrWELfa2qcsnhkwdSqUHh2FhCaQlIassjQ1zRNhnh2w0YR2cRaxx47hd4AYogB4/ 6BPrVjlblIQMNTZaVhBP0ZSc/yDmDWWxrDPG+bPFyiHqAaPHDGrYLx/dwOlayXUY1NyIF3lI XKUVteu2J3c0XyCdeW1JkO6RzJSHXVZ0Wl9iif3ekOhlTRfsufDcTYciFdryKJmYRqPvHm
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHYOeYhM19FRsX4fEqZ0g9opW1q5KzDY8oAgAAXkYA=
  • Thread-topic: [PATCH] x86/cet: Use dedicated NOP4 for cf_clobber

On 17/03/2022 10:43, Jan Beulich wrote:
> On 17.03.2022 11:02, 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 extend
>> check-endbr.sh to look for it.
>>
>> The choice of nop has some complicated consequences.  nopw (%rax) has a ModRM
>> byte of 0, which the Bourne compatible shells unconditionally strip from
>> parameters, meaning that we can't pass it to `grep -aob`.
> Urgh. But as per my earlier comments I'm happier with ...
>
>> Therefore, use nopw (%rcx) so the ModRM byte becomes 1.
> ... a non-zero ModR/M byte anyway.
>
>> This then demonstrates another bug.  Under perl regexes, \1 thru \9 are
>> subpattern matches, and not octal escapes.  Switch the `grep -P` runes to use
>> hex escapes instead.
>>
>> The build time check then requires that the endbr64 poison have the same
>> treatment as endbr64 to avoid placing the byte pattern in immediate operands.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
>
>> Jan: As you had the buggy grep, can you please confirm that hex escapes work.
> (Build-)Tested-by: Jan Beulich <jbeulich@xxxxxxxx>

Thanks.

>
> When working out the workaround, I actually did test with hex, but
> then switched to octal to make easily visible that the two patterns
> actually match. I also did wonder about octal and sub-pattern
> matching conflicting, but the grep I used definitely didn't have
> an issue there. Hence I assume grep behavior changed at some point;
> I wonder how they mean to have octal expressed now.

$ LC_ALL=C grep -aobP '\363\17\36\372|\146\17\37\1' text.bin
grep: reference to non-existent subpattern

> https://perldoc.perl.org/perlre specifically outlines how the
> conflict is dealt with - assuming you have observed grep to misbehave,
> I wonder whether they've accumulated a bug. (The doc also makes clear
> that such references aren't limited to single digit numbers; you may
> want to adjust your description in this regard.)

That part of the doc does say that the dynamic interpretation is only
for \10 and higher, so I don't think this is a bug.  \1 use to
exclusively mean the first capture group, not an octal character, and
this behaviour remains.

> Depending on how exactly your grep behaves, switching to always-three-
> digit octal escapes may be an alternative to retain the property of
> making obvious the similarity between the two pattern representations.

\01 and \001 do both work properly, but the non-ambiguous forms are \o1
or \o001.

Overall, I think it's better to stay with the hex escapes, because
they're also non-ambiguous.  The mix of octal and hex is irritating, but
the comments are very clear about what we're searching for.


And on that note, I realise we can also scan for endbr32 in exactly the
same way for no extra cost.  I'll fold that in too, seeing as the
discussion has come up before, and post a v3.

~Andrew

 


Rackspace

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