linux-kernel - Re: [PATCH 1/2] Documentation/x86: Add the AMX enabling example

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 16 Jun 2022 15:45:37 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     "Chang S. Bae" <chang.seok.bae@...el.com>, len.brown@...el.com,
        tony.luck@...el.com, rafael.j.wysocki@...el.com,
        reinette.chatre@...el.com, dan.j.williams@...el.com
Cc:     corbet@....net, pbonzini@...hat.com, kvm@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] Documentation/x86: Add the AMX enabling example

> +  1. **Check the feature availability**. AMX_TILE is enumerated in CPUID
> +     leaf 7, sub-leaf 0, bit 24 of EDX. If available, ``/proc/cpuinfo``
> +     shows ``amx_tile`` in the flag entry of the CPUs.  Given that, the
> +     kernel may have set XSTATE component 18 in the XCR0 register. But a
> +     user needs to ensure the kernel support via the ARCH_GET_XCOMP_SUPP
> +     option::

Why did you bother mentioning the XCR0 and CPUID specifics?  We don't
want applications doing that, right?

> +        #include <asm/prctl.h>
> +        #include <sys/syscall.h>
> +	#include <stdio.h>
> +        #include <unistd.h>

^ Just from the appearance here there looks to be some spaces vs. tabs
inconsistency.

> +        #define ARCH_GET_XCOMP_SUPP  0x1021
> +
> +        #define XFEATURE_XTILECFG    17
> +        #define XFEATURE_XTILEDATA   18
> +        #define XFEATURE_MASK_XTILE ((1 << XFEATURE_XTILECFG) | (1 << XFEATURE_XFILEDATA))
> +
> +        unsigned long features;
> +        long rc;
> +
> +        ...
> +
> +        rc = syscall(SYS_arch_prctl, ARCH_GET_XCOMP_SUPP, &features);
> +
> +        if (!rc && features & XFEATURE_MASK_XTILE == XFEATURE_MASK_XTILE)
> +            printf("AMX is available.\n");
> +
> +  2. **Request permission**. Now it is found that the kernel supports the
> +     feature. But the permission is not automatically given. A user needs
> +     to explicitly request it via the ARCH_REQ_XCOMP_PERM option::

That phrasing is a bit awkward.  How about:

	After determining support for AMX, an application must
	explicitly ask permission to use it:
	...

> +        #define ARCH_REQ_XCOMP_PERM  0x1023
> +
> +        ...
> +
> +        rc = syscall(SYS_arch_prctl, ARCH_REQ_XCOMP_PERM, XFEATURE_XTILEDATA);
> +
> +        if (!rc)
> +            printf("AMX is ready for use.\n");
> +
> +Note this example does not include the sigaltstack preparation.
> +
>  Dynamic features in signal frames
>  ---------------------------------
>