Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1660324pxu; Tue, 24 Nov 2020 06:06:33 -0800 (PST) X-Google-Smtp-Source: ABdhPJwc5KR2C/8SiqyNx+boJZPFSWAbiWSP7hgtOm+esFczjDjX7CpvO4hOeAmLYXzzykGbRSkC X-Received: by 2002:a05:6402:170e:: with SMTP id y14mr4115885edu.115.1606226793033; Tue, 24 Nov 2020 06:06:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606226793; cv=none; d=google.com; s=arc-20160816; b=Y7+t6bqWO6fcX0QBDdAlPVRtDGrZGH/S9BC7f8lY8EsP0DuFaC3R+tCvO3KAcW6cEI WyiAJZFAO39HzTx99wxU+w9BR0wXT/efTGiYBEZTBFwATlDN4Kw/NZQJ/+0BOKSYuXAB FsXUXFcmKYOitZojcORJsChlxJWBxYnDoNg/6doE8yZQcYppuVek/OJdWOMs1W7p3pCZ DnBu34IT/N2ou4ZV++qTm0uurph7SC6SB7ass76ovY6VsAXK9rwmSctrKD3P4ZiskK0h gZBO/RqGvQMi3bH53Ht0LZC825NcV/4jfBs4W+oo2MTdBn7Gz3mmhrfUTI2O1Bf7BgRP WvRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=p0T3iiqlMjR/rXBSPiAuHFco27jxRuu0dNWWo6glmpQ=; b=ZR1rE/ZEl77EWSi2MITeR8gN5X3rB3iLQ15Zj2N7iJRBfrt0WRatJm+fwe3ck8fEXl MqzjfwnJeoZCGRblmvGr6Ik2dvRksuEMNP9jbIt6yVp82ieqJSBh1CloNc5J5jfwc7ET xy6nW2mHW1I/UibHf8GwjpBBPK7D3Px+KChXv09X5tS/f7vLB+Z4p4gNkktjgz9wlTzx aOrlylFvqvNJYAHeDXFWCXlgrlnt3a0gcBKxR+8NRRHBoF+lGdT/C8pqYEpyXdNmzwwP A7EIHmnV/p2AkDYQyTdy18T3OCTMDq3wHlcbe+JahS/Gq1zzgClIrDrUegE1/ZhoSzSN o5aw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=vC8sTOzZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l15si9043273edq.356.2020.11.24.06.06.05; Tue, 24 Nov 2020 06:06:33 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=vC8sTOzZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729662AbgKXOCr (ORCPT + 99 others); Tue, 24 Nov 2020 09:02:47 -0500 Received: from mail.kernel.org ([198.145.29.99]:47226 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729608AbgKXOCj (ORCPT ); Tue, 24 Nov 2020 09:02:39 -0500 Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 590D72076E for ; Tue, 24 Nov 2020 14:02:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1606226558; bh=ueZAeL04uckNDd28QddIVeKofdi8RG1oj0UX85IE2CE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=vC8sTOzZZNhg0Eut1OB3+3j1fYyVtJB/BwkJLsmoZE8soWwi8EV/YlziB2z6SQt1r GRglbic3RmwEJsk8SNqziyObNRJhQz4wjwM7ap7M1iYtqXH3L+7E8J39UySaZUYoOw jDRC9hUL4e+pr0/QoqMVAgvvOSr7q4VutMoHwAxk= Received: by mail-ot1-f51.google.com with SMTP id n11so19398821ota.2 for ; Tue, 24 Nov 2020 06:02:38 -0800 (PST) X-Gm-Message-State: AOAM532llU/iNZZXOUbNUK6F9VAxykdmbQhV/A752MCanXuMZGXrf+nY GeWo7v+zW+x3nIsSSWuGMnWVOviSj3TqEOPaALM= X-Received: by 2002:a9d:62c1:: with SMTP id z1mr3359853otk.108.1606226557554; Tue, 24 Nov 2020 06:02:37 -0800 (PST) MIME-Version: 1.0 References: <20201119162543.78001-1-dbrazdil@google.com> <20201119162543.78001-4-dbrazdil@google.com> In-Reply-To: <20201119162543.78001-4-dbrazdil@google.com> From: Ard Biesheuvel Date: Tue, 24 Nov 2020 15:02:26 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 3/6] kvm: arm64: Fix up RELR relocation in hyp code/data To: David Brazdil Cc: kvmarm , Linux ARM , Linux Kernel Mailing List , Marc Zyngier , James Morse , Julien Thierry , Suzuki K Poulose , Catalin Marinas , Will Deacon , Mark Rutland , Andrew Scull , Android Kernel Team Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 19 Nov 2020 at 17:25, David Brazdil wrote: > > The arm64 kernel also supports packing of relocation data using the RELR > format. Implement a parser of RELR data and fixup the relocations using > the same infra as RELA relocs. > > Signed-off-by: David Brazdil > --- > arch/arm64/kvm/va_layout.c | 41 ++++++++++++++++++++++++++++++++++++++ > 1 file changed, 41 insertions(+) > > diff --git a/arch/arm64/kvm/va_layout.c b/arch/arm64/kvm/va_layout.c > index b80fab974896..7f45a98eacfd 100644 > --- a/arch/arm64/kvm/va_layout.c > +++ b/arch/arm64/kvm/va_layout.c > @@ -145,6 +145,43 @@ static void __fixup_hyp_rela(void) > __fixup_hyp_rel(rel[i].r_offset); > } > > +#ifdef CONFIG_RELR Please prefer IS_ENABLED() [below] if the code in question can compile (but perhaps not link) correctly when the symbol is not set. > +static void __fixup_hyp_relr(void) __init ? > +{ > + u64 *rel, *end; > + > + rel = (u64*)(kimage_vaddr + __load_elf_u64(__relr_offset)); > + end = rel + (__load_elf_u64(__relr_size) / sizeof(*rel)); > + The reason for this little dance with the offset and size exists because the initial relocation routine runs from the ID mapping, but the relocation fixups are performed via the kernel's VA mapping, as the ID mapping does not cover the entire image. So simple adrp/add pairs aren't suitable there. In this case (as well as in the previous patch, btw), that problem does not exist, and so I think we should be able to simply define start and end markers inside the .rela sections, and reference them here as symbols with external linkage (which ensures that they are referenced relatively, although you could add in a __attribute__((visibility("hidden"))) for good measure) > + while (rel < end) { > + unsigned n; > + u64 addr = *(rel++); Parens are redundant here (and below) > + > + /* Address must not have the LSB set. */ > + BUG_ON(addr & BIT(0)); > + > + /* Fix up the first address of the chain. */ > + __fixup_hyp_rel(addr); > + > + /* > + * Loop over bitmaps, i.e. as long as words' LSB is 1. > + * Each bit (ordered from LSB to MSB) represents one word from > + * the last full address (exclusive). If the corresponding bit > + * is 1, there is a relative relocation on that word. > + */ > + for (n = 0; rel < end && (*rel & BIT(0)); n++) { > + unsigned i; > + u64 bitmap = *(rel++); > + > + for (i = 1; i < 64; ++i) { > + if ((bitmap & BIT(i))) > + __fixup_hyp_rel(addr + 8 * (63 * n + i)); > + } > + } > + } > +} > +#endif > + > /* > * The kernel relocated pointers to kernel VA. Iterate over relocations in > * the hypervisor ELF sections and convert them to hyp VA. This avoids the > @@ -156,6 +193,10 @@ __init void kvm_fixup_hyp_relocations(void) > return; > > __fixup_hyp_rela(); > + > +#ifdef CONFIG_RELR > + __fixup_hyp_relr(); > +#endif > } > > static u32 compute_instruction(int n, u32 rd, u32 rn) > -- > 2.29.2.299.gdc1121823c-goog >