[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 00/65] x86: Support for CET Indirect Branch Tracking
- To: Andrew Cooper <amc96@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Fri, 26 Nov 2021 14:22:21 +0100
- 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=FfjdDBwDMPHBrBZZWErItRoUqmgu4pOq+aqdGmATT7o=; b=jm1yfG2iRyYnFAArfb5wrseNIM06HQYHXFdW3/P2Gte/DgM4PAZQKyNFVDM22A66ZM9XBGcNnxQ9/DMfY1uxRi918LY6RTbtxjQvb5y4sQpgR0nmhIXFIIX1zwNYn24ZCTFbS5BSnWseQFgPcc1jkCvFlQW89xfEFqV9jCUXwwDENP6tIgDq41MGt5RTuSuuEckcral1kPWdPgoeE5VLxL8bzDj1aWKOCLFKWyEzNENNNAjUkBpvGPDYsQMoatgOg6miuN2FH4dYTbKThzPvDnfEVlmss+Oxs0sPbuIsc9EbztAklT8Fkagc0uGUrBcUjzFmquzqIBLNOnqwcj2nnw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Tnz4Ms3L8qZc688Z6PAZ9dvnA1DxXQ370s8+K3KL07SHJuRnMUkFX2P5FTIzS3iJq0P5Zz4hW0vHx+EcnOOTh7OzvUiJpVAtgK4/itGz3mGC73ypCqiMUN2DJDLCeLaMASkOIim3cw7w6J5dytPiO4aDC1clOxM2Ob1VQA8Bcgh3OZL72eVHz4Ufs3VDgM0KfWf/0I8KKksNGB9FgEbyq3fEp3iqOUFm08rBXkuTEUaj+bGbCS3S1yL+3P6yS4etvk8TtR5SYGeGxv3wSawwvJZNGKLrN9Ganv1Hz5zAnTLiucINaAIwN1u7mXMVEq885sX2h8P3BwZatPORWTQFTw==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Daniel Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx>, Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Fri, 26 Nov 2021 13:22:29 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 26.11.2021 14:13, Andrew Cooper wrote:
> On 26/11/2021 12:48, Jan Beulich wrote:
>> On 26.11.2021 13:33, Andrew Cooper wrote:
>>> * I have not checked for misaligned endbr64's, and I'm not sure there is
>>> anything useful we could do upon discovering that there were any.
>>> Naively, there is a 1 in 2^32 chance (endbr64 being 4 bytes long), but
>>> this doesn't account for the structure of x86 code, which is most
>>> certainly not a uniform random distribution of bytes.
>> Do you really mean "misaligned" here? The 2nd sentence rather might suggest
>> that you mean byte sequences resembling ENDBR, despite actually being part
>> of other insns. If so, checking might not allow to prove anything, as e.g.
>> displacements change with about every build.
>
> I do mean "any sequence of bytes resembling ENDBR", because that is
> ultimately how the CPU instruction decode will behave.
>
> And yes - you certainly can hide it in a 4-byte disp/imm, but it's an
> incredibly rare imm32 to find (except for tasks such as in patch 64).
A disp alone won't do in general, as the top byte will only ever be 0x00
or 0xFF (as long as our binary image doesn't go beyond 16Mb). But a
ModR/M or SIB byte could start such a sequence, with only two or three
of the (lower) disp bytes used to complete the pattern.
> You can also hide it in an disp/imm8 followed by a specific nopl, but
> I'm not sure if we'd ever emit 0F 1E FA as a nopl by default.
We don't, and the tool chain doesn't either. Only canonical NOPs (opcode
0x1F) are to be used there, as all others may gain a meaning beyond
plain NOP.
Jan
|
