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-next>] [day] [month] [year] [list]
Message-ID: <CAP045ApiMSvP--f2E0=VdMbjE8oibvy921m8JASf4kaCCuU2RA@mail.gmail.com>
Date:   Sat, 21 May 2022 13:07:14 -0700
From:   Kyle Huey <me@...ehuey.com>
To:     open list <linux-kernel@...r.kernel.org>
Cc:     "moderated list:ARM PORT" <linux-arm-kernel@...ts.infradead.org>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
        yyc1992@...il.com, Keno Fischer <keno@...iacomputing.com>,
        "Robert O'Callahan" <robert@...llahan.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Borislav Petkov <bp@...en8.de>, Marc Zyngier <maz@...nel.org>,
        Suzuki K Poulose <suzuki.poulose@....com>,
        Will Deacon <will.deacon@....com>
Subject: arm64 equivalents of PR_SET_TSC/ARCH_SET_CPUID

There is ongoing work by Yichao Yu to make rr, a userspace record and
replay debugger[0], production quality on arm64[1]. One of the bigger
remaining issues is the kernel's emulation of accesses to certain
system registers[2] that reflect timing and CPU capabilities and are
either non-deterministic or can vary from processor to processor. We
would like to add the ability to tell the kernel to decline to emulate
these instructions for a given task and pass that responsibility onto
the supervising rr ptracer. There are analogous processor features and
disabling mechanisms on x86. The RDTSC instruction is controlled by
prctl(PR_SET_TSC) and the CPUID instruction is controlled (when the
hardware allows) by arch_prctl(ARCH_SET_CPUID).

The questions I'd like to raise are:

1. Is it appropriate to reuse PR_SET_TSC for roughly equivalent
functionality on AArch64? (even if the AArch64 feature is not actually
named Time Stamp Counter).
2. Likewise for ARCH_SET_CPUID
3. Since arch_prctl is x86-only, does it make more sense to add
arch_prctl to arm64 or to duplicate ARCH_SET_CPUID into the prctl
world? (e.g. a PR_SET_CPUID that works on both x86/arm64)

- Kyle

[0] https://rr-project.org/
[1] https://github.com/rr-debugger/rr/issues/3234
[2] e.g. CNTVCT_EL0 and MIDR_EL1, among others

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ