[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] x86/altcall: silence undue warning
- To: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
- Date: Tue, 1 Mar 2022 12:48:26 +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=oZo5lPjNxNbmBmBf/ntNRJMOZECLKTp51QAUaoMkA7w=; b=m/zfsJZVl6rEsmD6FLFVc9lLdsYqU/mIzLXD3YAh+6dONFhYfeGV4g8JkqZ6B+zM0aIuxtRodZZ9Ie0N25+rxAQPMdWzMvgdoLRD0Gsj9L70v6MeQd3FWqzonEmts48Brsv1khDAKk/c6LgHWPIlV3Om2Ui3zbSiJi95iqlxBv5rgz+17wM/Wj2mgwE83zBJz6d5DpUpNtGBA/y2cDAmXeHYVvlHbbSJI7OZKNYeIgDmk14aQYUss4vkMKy4ZqO3YlzS9oSdMFd79mWUrK9tjjg4sKtUNleQZp+Q1rHrdaC+lMm2XsK2GAQwgr7ONMUadMyeNTV/f2aX3B/ZGYjuqg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Epf6X6V+N/txvJx/Qo2uGlRYz+ITXPduccgIYaH5Jz8GcdAQb5VFmoq7XxLJQEwOjydDpIv83KR/zoULwreMsjrjNToZhnv40Rpaubfhb/l/Ki7OpLUIJl8e5Q3W4DEwTSMVL3TzOPR/ZwjHmnYUMXcHp5OjHZoYWONE1gP0Kn9pAqVZyBMDbgZTeFRAftbKYvJ7bJPB7b5qXfYmmTANb/tMRo41/8FbwcfOlAfegsZAAzGGai4QfkSaWwr/qwk5MWn+peijSUO7uHatqdC18yvAb1JbrbpcIUHmT4aEBB9srVjlNngZrw5+v/nkqrjNrjuTscD3En6dLh4zroiaWA==
- Authentication-results: esa4.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
- Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>
- Delivery-date: Tue, 01 Mar 2022 12:48:59 +0000
- Ironport-data: A9a23:XDDEy6jaLPgcvHr3yA8SOiQfX161fRAKZh0ujC45NGQN5FlHY01je htvXGHUbPmCZGDzftx/a4+x8U9V7JeDn9A1QVY4+Sw2QS8b9cadCdqndUqhZCn6wu8v7a5EA 2fyTvGacajYm1eF/k/F3oDJ9CU6jefSLlbFILas1hpZHGeIcw98z0M78wIFqtQw24LhWFvU4 YmaT/D3YzdJ5RYlagr41IrbwP9flKyaVOQw5wFWiVhj5TcyplFNZH4tDfjZw0jQG+G4KtWSV efbpIxVy0uCl/sb5nFJpZ6gGqECaua60QFjERO6UYD66vRJjnRaPqrWqJPwwKqY4tmEt4kZ9 TlDiXC/YT15ML/0vfo3aQdFOCZQL7xn2uHNO2fq5KR/z2WeG5ft6/BnDUVwNowE4OdnR2pJ8 JT0KhhUMErF3bjvhuvmFK883azPL+GyVG8bklhmwSvUErANRpfbTr+RzdRZwC0xloZFGvO2i 88xN2UyNEycPEYn1lE/KNFvueKvhybFLDB8tFeou4Qq5kz0w1kkuFTqGIWMIYHbLSlPpW6Ho krW8mK/BQsVXPSPxDzA/n+yi+vnmSLgRJlUBLC+7uRtglCY2ioUEhJ+fVmxrOS9i0W+c8lCM EFS8S0rxZXe72TyEIO7BUfh5ifZ4FhMALK8DtHW9im3mqTG2yOHLFIaUxVGRs43le1oTyY1g wrhc8zSORRjt7icSHS4/7iSrC+vNSV9EVLudRPoXiNevYC9/dhbYgbnC486TfXr1oGd9STYn mjSxBXSkYn/miLiO0+T2VncywyhqZHSJuLezlWGBzn1hu+ViWPMWmBJ1bQ5xasYRGp6ZgPY1 JThpyR4xLpWZX1qvHbQKNjh5Jnzu5643MT02DaD5aUJ+TW34GKEdotN+jx4L0oBGp9aJWGxP xSN5VoIvc470J6WgUlfOdnZ5yMCl/WIKDgYfqqMMoomjmZZLmdrAx2ClWbPhjuwwSDAYIk0O IuBcNbEMJrpIf8P8dZCfM9EieVD7nlnnQv7HMmnpzz6gev2TCPEEt8tbQrRBt3VGYvZ+W05B f4EbJDUo/ieOcWjChTqHXk7dghbfSBmXsmt86S6tIere2JbJY3oMNeIqZsJcI15haVF0ODO+ 3C2QEhDz1Tjw3bALG23hrpLNNsDgb4XQaoHABER
- Ironport-hdrordr: A9a23:IQYcTqslujTT3DRjDmRJpbmI7skC2IMji2hC6mlwRA09TyXGra +TdaUguSMc1gx9ZJh5o6H8BEGBKUmskKKceeEqTPiftXrdyReVxeZZnMXfKlzbamHDH4tmu5 uIHJIOceEYYWIK7voSpTPIaerIo+P3sZxA592ut0uFJDsCA8oLjmdE40SgYzZLrWF9dMEE/f Gnl656Tk+bCBIqh7OAdx44tob41r/2vaOjRSRDKw8s6QGIgz/twqX9CQKk0hAXVC4K6as+8E De+jaJppmLgrWe8FvxxmXT55NZlJ/K0d1YHvGBjcATN3HFlhuoXoJ8QLeP1QpF491HqWxa0u UkkS1Qe/ib2EmhOV1dZiGdnTUI5QxerkMKD2Xo2EcL7/aJHA7SQPAx+r6xOiGplXbI+usMip 6jlljpx6a+R3n77VXAzsmNWBdwmkWup30+1eYVknxESIMbLKRctIoF4SpuYdw99Q/Bmcka+d NVfYnhDTdtACenRmGcunMqzM2nX3w1EBvDSk8eutaN2zwTmHxi1UMXyMEWg39FrfsGOtR5zv WBNr4tmKBFT8cQY644DOAdQdGvAmiIRR7XKmqdLVnuCalCMXPQrJz85qkz+YiRCdY15Yp3nI 6EXEJTtGY0dU6rAcqS3IdT+hSIW2m5VSSF8LAp23G4gMyKeFPGC1zwdLl1qbrSnxw2OLyvZ8 qO
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHYLWCYr1nVwle0TEu9TqkN6fmfJ6yqeogA
- Thread-topic: [PATCH] x86/altcall: silence undue warning
On 01/03/2022 11:36, Jan Beulich wrote:
> Suitable compiler options are passed only when the actual feature
> (XEN_IBT) is enabled, not when merely the compiler capability was found
> to be available.
>
> Fixes: 12e3410e071e ("x86/altcall: Check and optimise altcall targets")
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
Hmm yes. This is fallout from separating CONFIG_HAS_CC_CET_IBT and
CONFIG_XEN_IBT.
Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> ---
> Furthermore, is "Optimised away ..." really appropriate in what
> 37ed5da851b8 ("x86/altcall: Optimise away endbr64 instruction where
> possible") added? If this really was an optimization (rather than
> hardening), shouldn't we purge ENDBR also when !cpu_has_xen_ibt, and
> then ideally all of them? Whereas if this is mainly about hardening,
> wouldn't the message better say "Purged" or "Clobbered"?
I did have an RFC about this. Turning ENDBR into NOP4 matters, on a
CET-IBT-active system, to restrict the available options an attacker has
when they have already managed to hijack a function pointer (i.e.
already got a partial write gadget).
From that point of view, it is hardening.
The first version of this logic was trying to use UD1 in the same way as
Linux does, to harden non-CET builds too, but that does depend on having
objtool so all direct branches can have their targets updated to miss
the UD1 instruction.
~Andrew
P.S. I'd still like to have "away %u of %u endbr64's". It occurs to me
that now we have check-endbr64.sh, we could `wc -l` the $VALID file and
re-link this back in, but then we couldn't check the final objects.
|
