linux-kernel - Re: [PATCH] x86: add 'runtime constant' infrastructure

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]

Message-ID: <CAMj1kXHyhv=J0v9eZKOgLd0xySrZmvnzmD=Oz398C5KS2=48Kw@mail.gmail.com>
Date: Mon, 10 Jun 2024 14:10:59 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>, 
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, linux-arch <linux-arch@...r.kernel.org>, 
	Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] x86: add 'runtime constant' infrastructure

On Sun, 9 Jun 2024 at 05:11, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Sat, 8 Jun 2024 at 13:55, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> >
> > Think of this patch mostly as a "look, adding another architecture
> > isn't *that* hard - even if the constant value is spread out in the
> > instructions".
>
> .. and here's a version that actually works. It wasn't that bad.
>
> Or rather, it wouldn't have been that bad had I not spent *ages*
> debugging a stupid cut-and-paste error where I instead of writing
> words 0..3 of the 64-bit large constant generation, wrote words 0..2
> and then overwrote word 2 (again) with the data that should have gone
> into word 3. Causing the top 32 bits to be all wonky. Oops. Literally.
>
> That stupid typo caused like two hours of wasted time.
>
> But anyway, this patch actually works for me. It still doesn't do any
> I$/D$ flushing, because it's not needed in practice, but it *should*
> probably do that.
>

arm64 already has so-called 'callback' alternatives that allow the
patching logic for a particular alternative sequence to be implemented
by the user of the API.

A callback implementation to patch a movz/movk sequence already
exists, in arch/arm64/kvm/va_layout.c, used by
kvm_get_kimage_voffset() and kvm_compute_final_ctr_el0().

>From inline asm, it gets called like this

static inline size_t __invalidate_icache_max_range(void)
{
  u8 iminline;
  u64 ctr;

  asm(ALTERNATIVE_CB("movz %0, #0\n"
                     "movk %0, #0, lsl #16\n"
                     "movk %0, #0, lsl #32\n"
                     "movk %0, #0, lsl #48\n",
                     ARM64_ALWAYS_SYSTEM,
                     kvm_compute_final_ctr_el0)
      : "=r" (ctr));

  iminline = SYS_FIELD_GET(CTR_EL0, IminLine, ctr) + 2;
  return MAX_DVM_OPS << iminline;
}

This one gets patched after SMP bringup, but they can be updated
earlier if needed.

Doing the same for the immediate field in a single ALU instruction
should be straight-forward, although this particular example doesn't
even bother, and just masks and shifts the result of the movz/movk
sequence.