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:   Fri, 26 Aug 2022 10:45:07 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Eric Biggers <ebiggers@...nel.org>
Cc:     x86@...nel.org, linux-arm-kernel@...ts.infradead.org,
        linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
        Adam Langley <agl@...gle.com>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Ard Biesheuvel <ardb@...nel.org>
Subject: Re: Should Linux set the new constant-time mode CPU flags?

On Fri, Aug 26, 2022 at 1:15 AM Eric Biggers <ebiggers@...nel.org> wrote:
>
> For arm64, it's not clear to me whether the DIT flag is privileged or not.  If
> privileged, I expect it would need to be set by the kernel just like the Intel
> flag.  If unprivileged, I expect there will still be work to do in the kernel,
> as the flag will need to be set when running any crypto code in the kernel.

7206dc93a58f ("arm64: Expose Arm v8.4 features") added the feature bit for
Armv8.4+ processors. From what I can tell from the documentation and the
kernel source, I see:

- if the feature is set in HWCAP (or /proc/cpuinfo), then the instruction DIT
  register is available in user space, and sensitive code can set or clear the
  constant-time mode for the local thread.
- On CPUs without the feature (almost all ARMv8 ones), the register should
  not be touched.
- The bit is context switched on kernel entry, so setting the bit in user space
  does not change the behavior inside of a syscall
- If we add a user space interface for setting the bit per thread on x86,
  the same interface could be supported to set the bit on arm64 to save
  user space implementations the trouble of checking the feature bits
- the in-kernel crypto code does not set the bit today but could be easily
  changed to do this for CPUs that support it, if we can decide on a policy
  for when to enable or disable it.

        Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ