This is the mail archive of the
mailing list for the binutils project.
Re: [committed, PATCH 1/3] x86: CET v2.0: Update NOTRACK prefix
On Tue, Jul 4, 2017 at 8:50 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 04.07.17 at 17:42, <email@example.com> wrote:
>> On Mon, Jul 3, 2017 at 12:18 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> On 21.06.17 at 17:35, <firstname.lastname@example.org> wrote:
>>>> Update NOTRACK prefix handling to support memory indirect branch for
>>>> CET v2.0:
>>> It is pretty hard to judge whether the changes here are correct
>>> without the doc being really precise on the obvious corner case:
>>> How does one correctly use a segment override and a notrack
>>> prefix on an indirect call/jmp with a memory operand? Most
>>> importantly, how does one use %ds: but not notrack, notrack
>>> but not %ds:, or %ds and notrack?
>> The spec has
>> No-track Prefix for Near Indirect Call/Jmp
>> Near indirect call and jmp instructions when prefixed with 3EH are
>> termed “non-tracked indirect control
>> transfer instructions” and do not modify the CET indirect branch
>> tracker. Far call and jmp are always tracked
>> and ignore the 3EH prefix. The NO_TRACK_EN control in the
>> IA32_U_CET/IA32_S_CET MSR enables this
>> no-track prefix treatment. When this control is 0, the near indirect
>> call and jmp are always tracked irrespec-
>> tive of the presence of the 3EH prefix.
>> In 64-bit mode, the 3EH prefix on an indirect call or jmp is
>> recognized as a no-track prefix when the following
>> conditions are satisfied.
>> 3EH must be the last legacy prefix of any group (except any REX).
>> There must not be a 64H/65H prefix on the instruction.
>> In legacy/compatibility mode, the 3EH prefix on an indirect call or
>> jmp is recognized as a no-track prefix
>> when it is the last group 2 prefix on the instruction.
>> That means you can't use the notrack pefix with a segment override
>> and you can't use %ds segment override on indirect branch.
> Well, what you derive from it is one possible meaning, but I don't
> think the only one. I continue to think that the text is ambiguous,
> and I also continue to think that disallowing segment overrides
> here is a bad idea.
Can you comment on it?