2019-06-03 13:44:50 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2017-12-04 01:36:55 +08:00
|
|
|
/*
|
|
|
|
|
* Copyright (C) 2017 ARM Ltd.
|
|
|
|
|
* Author: Marc Zyngier <marc.zyngier@arm.com>
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <linux/kvm_host.h>
|
arm64: KVM: Introduce EL2 VA randomisation
The main idea behind randomising the EL2 VA is that we usually have
a few spare bits between the most significant bit of the VA mask
and the most significant bit of the linear mapping.
Those bits could be a bunch of zeroes, and could be useful
to move things around a bit. Of course, the more memory you have,
the less randomisation you get...
Alternatively, these bits could be the result of KASLR, in which
case they are already random. But it would be nice to have a
*different* randomization, just to make the job of a potential
attacker a bit more difficult.
Inserting these random bits is a bit involved. We don't have a spare
register (short of rewriting all the kern_hyp_va call sites), and
the immediate we want to insert is too random to be used with the
ORR instruction. The best option I could come up with is the following
sequence:
and x0, x0, #va_mask
ror x0, x0, #first_random_bit
add x0, x0, #(random & 0xfff)
add x0, x0, #(random >> 12), lsl #12
ror x0, x0, #(63 - first_random_bit)
making it a fairly long sequence, but one that a decent CPU should
be able to execute without breaking a sweat. It is of course NOPed
out on VHE. The last 4 instructions can also be turned into NOPs
if it appears that there is no free bits to use.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: James Morse <james.morse@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-12-04 02:22:49 +08:00
|
|
|
#include <linux/random.h>
|
|
|
|
|
#include <linux/memblock.h>
|
2017-12-04 01:36:55 +08:00
|
|
|
#include <asm/alternative.h>
|
|
|
|
|
#include <asm/debug-monitors.h>
|
|
|
|
|
#include <asm/insn.h>
|
|
|
|
|
#include <asm/kvm_mmu.h>
|
2020-10-22 03:48:02 +08:00
|
|
|
#include <asm/memory.h>
|
2017-12-04 01:36:55 +08:00
|
|
|
|
arm64: KVM: Introduce EL2 VA randomisation
The main idea behind randomising the EL2 VA is that we usually have
a few spare bits between the most significant bit of the VA mask
and the most significant bit of the linear mapping.
Those bits could be a bunch of zeroes, and could be useful
to move things around a bit. Of course, the more memory you have,
the less randomisation you get...
Alternatively, these bits could be the result of KASLR, in which
case they are already random. But it would be nice to have a
*different* randomization, just to make the job of a potential
attacker a bit more difficult.
Inserting these random bits is a bit involved. We don't have a spare
register (short of rewriting all the kern_hyp_va call sites), and
the immediate we want to insert is too random to be used with the
ORR instruction. The best option I could come up with is the following
sequence:
and x0, x0, #va_mask
ror x0, x0, #first_random_bit
add x0, x0, #(random & 0xfff)
add x0, x0, #(random >> 12), lsl #12
ror x0, x0, #(63 - first_random_bit)
making it a fairly long sequence, but one that a decent CPU should
be able to execute without breaking a sweat. It is of course NOPed
out on VHE. The last 4 instructions can also be turned into NOPs
if it appears that there is no free bits to use.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: James Morse <james.morse@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-12-04 02:22:49 +08:00
|
|
|
/*
|
2019-12-28 19:57:14 +08:00
|
|
|
* The LSB of the HYP VA tag
|
arm64: KVM: Introduce EL2 VA randomisation
The main idea behind randomising the EL2 VA is that we usually have
a few spare bits between the most significant bit of the VA mask
and the most significant bit of the linear mapping.
Those bits could be a bunch of zeroes, and could be useful
to move things around a bit. Of course, the more memory you have,
the less randomisation you get...
Alternatively, these bits could be the result of KASLR, in which
case they are already random. But it would be nice to have a
*different* randomization, just to make the job of a potential
attacker a bit more difficult.
Inserting these random bits is a bit involved. We don't have a spare
register (short of rewriting all the kern_hyp_va call sites), and
the immediate we want to insert is too random to be used with the
ORR instruction. The best option I could come up with is the following
sequence:
and x0, x0, #va_mask
ror x0, x0, #first_random_bit
add x0, x0, #(random & 0xfff)
add x0, x0, #(random >> 12), lsl #12
ror x0, x0, #(63 - first_random_bit)
making it a fairly long sequence, but one that a decent CPU should
be able to execute without breaking a sweat. It is of course NOPed
out on VHE. The last 4 instructions can also be turned into NOPs
if it appears that there is no free bits to use.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: James Morse <james.morse@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-12-04 02:22:49 +08:00
|
|
|
*/
|
|
|
|
|
static u8 tag_lsb;
|
|
|
|
|
/*
|
2019-12-28 19:57:14 +08:00
|
|
|
* The HYP VA tag value with the region bit
|
arm64: KVM: Introduce EL2 VA randomisation
The main idea behind randomising the EL2 VA is that we usually have
a few spare bits between the most significant bit of the VA mask
and the most significant bit of the linear mapping.
Those bits could be a bunch of zeroes, and could be useful
to move things around a bit. Of course, the more memory you have,
the less randomisation you get...
Alternatively, these bits could be the result of KASLR, in which
case they are already random. But it would be nice to have a
*different* randomization, just to make the job of a potential
attacker a bit more difficult.
Inserting these random bits is a bit involved. We don't have a spare
register (short of rewriting all the kern_hyp_va call sites), and
the immediate we want to insert is too random to be used with the
ORR instruction. The best option I could come up with is the following
sequence:
and x0, x0, #va_mask
ror x0, x0, #first_random_bit
add x0, x0, #(random & 0xfff)
add x0, x0, #(random >> 12), lsl #12
ror x0, x0, #(63 - first_random_bit)
making it a fairly long sequence, but one that a decent CPU should
be able to execute without breaking a sweat. It is of course NOPed
out on VHE. The last 4 instructions can also be turned into NOPs
if it appears that there is no free bits to use.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: James Morse <james.morse@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-12-04 02:22:49 +08:00
|
|
|
*/
|
|
|
|
|
static u64 tag_val;
|
2017-12-04 01:36:55 +08:00
|
|
|
static u64 va_mask;
|
|
|
|
|
|
2019-12-28 19:57:14 +08:00
|
|
|
/*
|
|
|
|
|
* We want to generate a hyp VA with the following format (with V ==
|
|
|
|
|
* vabits_actual):
|
|
|
|
|
*
|
|
|
|
|
* 63 ... V | V-1 | V-2 .. tag_lsb | tag_lsb - 1 .. 0
|
|
|
|
|
* ---------------------------------------------------------
|
|
|
|
|
* | 0000000 | hyp_va_msb | random tag | kern linear VA |
|
|
|
|
|
* |--------- tag_val -----------|----- va_mask ---|
|
|
|
|
|
*
|
|
|
|
|
* which does not conflict with the idmap regions.
|
|
|
|
|
*/
|
2019-11-29 03:58:05 +08:00
|
|
|
__init void kvm_compute_layout(void)
|
2017-12-04 01:36:55 +08:00
|
|
|
{
|
|
|
|
|
phys_addr_t idmap_addr = __pa_symbol(__hyp_idmap_text_start);
|
2017-12-08 22:18:27 +08:00
|
|
|
u64 hyp_va_msb;
|
2017-12-04 01:36:55 +08:00
|
|
|
|
2017-12-08 22:18:27 +08:00
|
|
|
/* Where is my RAM region? */
|
2019-08-07 23:55:18 +08:00
|
|
|
hyp_va_msb = idmap_addr & BIT(vabits_actual - 1);
|
|
|
|
|
hyp_va_msb ^= BIT(vabits_actual - 1);
|
2017-12-04 01:36:55 +08:00
|
|
|
|
2019-12-28 19:57:14 +08:00
|
|
|
tag_lsb = fls64((u64)phys_to_virt(memblock_start_of_DRAM()) ^
|
arm64: KVM: Introduce EL2 VA randomisation
The main idea behind randomising the EL2 VA is that we usually have
a few spare bits between the most significant bit of the VA mask
and the most significant bit of the linear mapping.
Those bits could be a bunch of zeroes, and could be useful
to move things around a bit. Of course, the more memory you have,
the less randomisation you get...
Alternatively, these bits could be the result of KASLR, in which
case they are already random. But it would be nice to have a
*different* randomization, just to make the job of a potential
attacker a bit more difficult.
Inserting these random bits is a bit involved. We don't have a spare
register (short of rewriting all the kern_hyp_va call sites), and
the immediate we want to insert is too random to be used with the
ORR instruction. The best option I could come up with is the following
sequence:
and x0, x0, #va_mask
ror x0, x0, #first_random_bit
add x0, x0, #(random & 0xfff)
add x0, x0, #(random >> 12), lsl #12
ror x0, x0, #(63 - first_random_bit)
making it a fairly long sequence, but one that a decent CPU should
be able to execute without breaking a sweat. It is of course NOPed
out on VHE. The last 4 instructions can also be turned into NOPs
if it appears that there is no free bits to use.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: James Morse <james.morse@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-12-04 02:22:49 +08:00
|
|
|
(u64)(high_memory - 1));
|
|
|
|
|
|
2019-12-28 19:57:14 +08:00
|
|
|
va_mask = GENMASK_ULL(tag_lsb - 1, 0);
|
|
|
|
|
tag_val = hyp_va_msb;
|
|
|
|
|
|
2020-07-21 17:44:44 +08:00
|
|
|
if (IS_ENABLED(CONFIG_RANDOMIZE_BASE) && tag_lsb != (vabits_actual - 1)) {
|
2019-12-28 19:57:14 +08:00
|
|
|
/* We have some free bits to insert a random tag. */
|
|
|
|
|
tag_val |= get_random_long() & GENMASK_ULL(vabits_actual - 2, tag_lsb);
|
arm64: KVM: Introduce EL2 VA randomisation
The main idea behind randomising the EL2 VA is that we usually have
a few spare bits between the most significant bit of the VA mask
and the most significant bit of the linear mapping.
Those bits could be a bunch of zeroes, and could be useful
to move things around a bit. Of course, the more memory you have,
the less randomisation you get...
Alternatively, these bits could be the result of KASLR, in which
case they are already random. But it would be nice to have a
*different* randomization, just to make the job of a potential
attacker a bit more difficult.
Inserting these random bits is a bit involved. We don't have a spare
register (short of rewriting all the kern_hyp_va call sites), and
the immediate we want to insert is too random to be used with the
ORR instruction. The best option I could come up with is the following
sequence:
and x0, x0, #va_mask
ror x0, x0, #first_random_bit
add x0, x0, #(random & 0xfff)
add x0, x0, #(random >> 12), lsl #12
ror x0, x0, #(63 - first_random_bit)
making it a fairly long sequence, but one that a decent CPU should
be able to execute without breaking a sweat. It is of course NOPed
out on VHE. The last 4 instructions can also be turned into NOPs
if it appears that there is no free bits to use.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: James Morse <james.morse@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-12-04 02:22:49 +08:00
|
|
|
}
|
2019-12-28 19:57:14 +08:00
|
|
|
tag_val >>= tag_lsb;
|
2017-12-04 01:36:55 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static u32 compute_instruction(int n, u32 rd, u32 rn)
|
|
|
|
|
{
|
|
|
|
|
u32 insn = AARCH64_BREAK_FAULT;
|
|
|
|
|
|
|
|
|
|
switch (n) {
|
|
|
|
|
case 0:
|
|
|
|
|
insn = aarch64_insn_gen_logical_immediate(AARCH64_INSN_LOGIC_AND,
|
|
|
|
|
AARCH64_INSN_VARIANT_64BIT,
|
|
|
|
|
rn, rd, va_mask);
|
|
|
|
|
break;
|
arm64: KVM: Introduce EL2 VA randomisation
The main idea behind randomising the EL2 VA is that we usually have
a few spare bits between the most significant bit of the VA mask
and the most significant bit of the linear mapping.
Those bits could be a bunch of zeroes, and could be useful
to move things around a bit. Of course, the more memory you have,
the less randomisation you get...
Alternatively, these bits could be the result of KASLR, in which
case they are already random. But it would be nice to have a
*different* randomization, just to make the job of a potential
attacker a bit more difficult.
Inserting these random bits is a bit involved. We don't have a spare
register (short of rewriting all the kern_hyp_va call sites), and
the immediate we want to insert is too random to be used with the
ORR instruction. The best option I could come up with is the following
sequence:
and x0, x0, #va_mask
ror x0, x0, #first_random_bit
add x0, x0, #(random & 0xfff)
add x0, x0, #(random >> 12), lsl #12
ror x0, x0, #(63 - first_random_bit)
making it a fairly long sequence, but one that a decent CPU should
be able to execute without breaking a sweat. It is of course NOPed
out on VHE. The last 4 instructions can also be turned into NOPs
if it appears that there is no free bits to use.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: James Morse <james.morse@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-12-04 02:22:49 +08:00
|
|
|
|
|
|
|
|
case 1:
|
|
|
|
|
/* ROR is a variant of EXTR with Rm = Rn */
|
|
|
|
|
insn = aarch64_insn_gen_extr(AARCH64_INSN_VARIANT_64BIT,
|
|
|
|
|
rn, rn, rd,
|
|
|
|
|
tag_lsb);
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case 2:
|
|
|
|
|
insn = aarch64_insn_gen_add_sub_imm(rd, rn,
|
|
|
|
|
tag_val & GENMASK(11, 0),
|
|
|
|
|
AARCH64_INSN_VARIANT_64BIT,
|
|
|
|
|
AARCH64_INSN_ADSB_ADD);
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case 3:
|
|
|
|
|
insn = aarch64_insn_gen_add_sub_imm(rd, rn,
|
|
|
|
|
tag_val & GENMASK(23, 12),
|
|
|
|
|
AARCH64_INSN_VARIANT_64BIT,
|
|
|
|
|
AARCH64_INSN_ADSB_ADD);
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case 4:
|
|
|
|
|
/* ROR is a variant of EXTR with Rm = Rn */
|
|
|
|
|
insn = aarch64_insn_gen_extr(AARCH64_INSN_VARIANT_64BIT,
|
|
|
|
|
rn, rn, rd, 64 - tag_lsb);
|
|
|
|
|
break;
|
2017-12-04 01:36:55 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return insn;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void __init kvm_update_va_mask(struct alt_instr *alt,
|
|
|
|
|
__le32 *origptr, __le32 *updptr, int nr_inst)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
|
arm64: KVM: Introduce EL2 VA randomisation
The main idea behind randomising the EL2 VA is that we usually have
a few spare bits between the most significant bit of the VA mask
and the most significant bit of the linear mapping.
Those bits could be a bunch of zeroes, and could be useful
to move things around a bit. Of course, the more memory you have,
the less randomisation you get...
Alternatively, these bits could be the result of KASLR, in which
case they are already random. But it would be nice to have a
*different* randomization, just to make the job of a potential
attacker a bit more difficult.
Inserting these random bits is a bit involved. We don't have a spare
register (short of rewriting all the kern_hyp_va call sites), and
the immediate we want to insert is too random to be used with the
ORR instruction. The best option I could come up with is the following
sequence:
and x0, x0, #va_mask
ror x0, x0, #first_random_bit
add x0, x0, #(random & 0xfff)
add x0, x0, #(random >> 12), lsl #12
ror x0, x0, #(63 - first_random_bit)
making it a fairly long sequence, but one that a decent CPU should
be able to execute without breaking a sweat. It is of course NOPed
out on VHE. The last 4 instructions can also be turned into NOPs
if it appears that there is no free bits to use.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: James Morse <james.morse@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-12-04 02:22:49 +08:00
|
|
|
BUG_ON(nr_inst != 5);
|
2017-12-04 01:36:55 +08:00
|
|
|
|
|
|
|
|
for (i = 0; i < nr_inst; i++) {
|
|
|
|
|
u32 rd, rn, insn, oinsn;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* VHE doesn't need any address translation, let's NOP
|
|
|
|
|
* everything.
|
arm64: KVM: Introduce EL2 VA randomisation
The main idea behind randomising the EL2 VA is that we usually have
a few spare bits between the most significant bit of the VA mask
and the most significant bit of the linear mapping.
Those bits could be a bunch of zeroes, and could be useful
to move things around a bit. Of course, the more memory you have,
the less randomisation you get...
Alternatively, these bits could be the result of KASLR, in which
case they are already random. But it would be nice to have a
*different* randomization, just to make the job of a potential
attacker a bit more difficult.
Inserting these random bits is a bit involved. We don't have a spare
register (short of rewriting all the kern_hyp_va call sites), and
the immediate we want to insert is too random to be used with the
ORR instruction. The best option I could come up with is the following
sequence:
and x0, x0, #va_mask
ror x0, x0, #first_random_bit
add x0, x0, #(random & 0xfff)
add x0, x0, #(random >> 12), lsl #12
ror x0, x0, #(63 - first_random_bit)
making it a fairly long sequence, but one that a decent CPU should
be able to execute without breaking a sweat. It is of course NOPed
out on VHE. The last 4 instructions can also be turned into NOPs
if it appears that there is no free bits to use.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: James Morse <james.morse@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-12-04 02:22:49 +08:00
|
|
|
*
|
2019-12-28 19:57:14 +08:00
|
|
|
* Alternatively, if the tag is zero (because the layout
|
|
|
|
|
* dictates it and we don't have any spare bits in the
|
|
|
|
|
* address), NOP everything after masking the kernel VA.
|
2017-12-04 01:36:55 +08:00
|
|
|
*/
|
2019-12-28 19:57:14 +08:00
|
|
|
if (has_vhe() || (!tag_val && i > 0)) {
|
2017-12-04 01:36:55 +08:00
|
|
|
updptr[i] = cpu_to_le32(aarch64_insn_gen_nop());
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
oinsn = le32_to_cpu(origptr[i]);
|
|
|
|
|
rd = aarch64_insn_decode_register(AARCH64_INSN_REGTYPE_RD, oinsn);
|
|
|
|
|
rn = aarch64_insn_decode_register(AARCH64_INSN_REGTYPE_RN, oinsn);
|
|
|
|
|
|
|
|
|
|
insn = compute_instruction(i, rd, rn);
|
|
|
|
|
BUG_ON(insn == AARCH64_BREAK_FAULT);
|
|
|
|
|
|
|
|
|
|
updptr[i] = cpu_to_le32(insn);
|
|
|
|
|
}
|
|
|
|
|
}
|
2018-02-28 01:38:08 +08:00
|
|
|
|
2018-02-15 19:47:14 +08:00
|
|
|
void *__kvm_bp_vect_base;
|
|
|
|
|
int __kvm_harden_el2_vector_slot;
|
|
|
|
|
|
2018-02-28 01:38:08 +08:00
|
|
|
void kvm_patch_vector_branch(struct alt_instr *alt,
|
|
|
|
|
__le32 *origptr, __le32 *updptr, int nr_inst)
|
|
|
|
|
{
|
|
|
|
|
u64 addr;
|
|
|
|
|
u32 insn;
|
|
|
|
|
|
|
|
|
|
BUG_ON(nr_inst != 5);
|
|
|
|
|
|
|
|
|
|
if (has_vhe() || !cpus_have_const_cap(ARM64_HARDEN_EL2_VECTORS)) {
|
|
|
|
|
WARN_ON_ONCE(cpus_have_const_cap(ARM64_HARDEN_EL2_VECTORS));
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Compute HYP VA by using the same computation as kern_hyp_va()
|
|
|
|
|
*/
|
|
|
|
|
addr = (uintptr_t)kvm_ksym_ref(__kvm_hyp_vector);
|
|
|
|
|
addr &= va_mask;
|
|
|
|
|
addr |= tag_val << tag_lsb;
|
|
|
|
|
|
|
|
|
|
/* Use PC[10:7] to branch to the same vector in KVM */
|
|
|
|
|
addr |= ((u64)origptr & GENMASK_ULL(10, 7));
|
|
|
|
|
|
|
|
|
|
/*
|
2019-06-18 23:17:34 +08:00
|
|
|
* Branch over the preamble in order to avoid the initial store on
|
|
|
|
|
* the stack (which we already perform in the hardening vectors).
|
2018-02-28 01:38:08 +08:00
|
|
|
*/
|
2019-06-18 23:17:34 +08:00
|
|
|
addr += KVM_VECTOR_PREAMBLE;
|
2018-02-28 01:38:08 +08:00
|
|
|
|
|
|
|
|
/* stp x0, x1, [sp, #-16]! */
|
|
|
|
|
insn = aarch64_insn_gen_load_store_pair(AARCH64_INSN_REG_0,
|
|
|
|
|
AARCH64_INSN_REG_1,
|
|
|
|
|
AARCH64_INSN_REG_SP,
|
|
|
|
|
-16,
|
|
|
|
|
AARCH64_INSN_VARIANT_64BIT,
|
|
|
|
|
AARCH64_INSN_LDST_STORE_PAIR_PRE_INDEX);
|
|
|
|
|
*updptr++ = cpu_to_le32(insn);
|
|
|
|
|
|
|
|
|
|
/* movz x0, #(addr & 0xffff) */
|
|
|
|
|
insn = aarch64_insn_gen_movewide(AARCH64_INSN_REG_0,
|
|
|
|
|
(u16)addr,
|
|
|
|
|
0,
|
|
|
|
|
AARCH64_INSN_VARIANT_64BIT,
|
|
|
|
|
AARCH64_INSN_MOVEWIDE_ZERO);
|
|
|
|
|
*updptr++ = cpu_to_le32(insn);
|
|
|
|
|
|
|
|
|
|
/* movk x0, #((addr >> 16) & 0xffff), lsl #16 */
|
|
|
|
|
insn = aarch64_insn_gen_movewide(AARCH64_INSN_REG_0,
|
|
|
|
|
(u16)(addr >> 16),
|
|
|
|
|
16,
|
|
|
|
|
AARCH64_INSN_VARIANT_64BIT,
|
|
|
|
|
AARCH64_INSN_MOVEWIDE_KEEP);
|
|
|
|
|
*updptr++ = cpu_to_le32(insn);
|
|
|
|
|
|
|
|
|
|
/* movk x0, #((addr >> 32) & 0xffff), lsl #32 */
|
|
|
|
|
insn = aarch64_insn_gen_movewide(AARCH64_INSN_REG_0,
|
|
|
|
|
(u16)(addr >> 32),
|
|
|
|
|
32,
|
|
|
|
|
AARCH64_INSN_VARIANT_64BIT,
|
|
|
|
|
AARCH64_INSN_MOVEWIDE_KEEP);
|
|
|
|
|
*updptr++ = cpu_to_le32(insn);
|
|
|
|
|
|
|
|
|
|
/* br x0 */
|
|
|
|
|
insn = aarch64_insn_gen_branch_reg(AARCH64_INSN_REG_0,
|
|
|
|
|
AARCH64_INSN_BRANCH_NOLINK);
|
|
|
|
|
*updptr++ = cpu_to_le32(insn);
|
|
|
|
|
}
|
2020-10-22 03:48:02 +08:00
|
|
|
|
|
|
|
|
static void generate_mov_q(u64 val, __le32 *origptr, __le32 *updptr, int nr_inst)
|
|
|
|
|
{
|
|
|
|
|
u32 insn, oinsn, rd;
|
|
|
|
|
|
|
|
|
|
BUG_ON(nr_inst != 4);
|
|
|
|
|
|
|
|
|
|
/* Compute target register */
|
|
|
|
|
oinsn = le32_to_cpu(*origptr);
|
|
|
|
|
rd = aarch64_insn_decode_register(AARCH64_INSN_REGTYPE_RD, oinsn);
|
|
|
|
|
|
|
|
|
|
/* movz rd, #(val & 0xffff) */
|
|
|
|
|
insn = aarch64_insn_gen_movewide(rd,
|
|
|
|
|
(u16)val,
|
|
|
|
|
0,
|
|
|
|
|
AARCH64_INSN_VARIANT_64BIT,
|
|
|
|
|
AARCH64_INSN_MOVEWIDE_ZERO);
|
|
|
|
|
*updptr++ = cpu_to_le32(insn);
|
|
|
|
|
|
|
|
|
|
/* movk rd, #((val >> 16) & 0xffff), lsl #16 */
|
|
|
|
|
insn = aarch64_insn_gen_movewide(rd,
|
|
|
|
|
(u16)(val >> 16),
|
|
|
|
|
16,
|
|
|
|
|
AARCH64_INSN_VARIANT_64BIT,
|
|
|
|
|
AARCH64_INSN_MOVEWIDE_KEEP);
|
|
|
|
|
*updptr++ = cpu_to_le32(insn);
|
|
|
|
|
|
|
|
|
|
/* movk rd, #((val >> 32) & 0xffff), lsl #32 */
|
|
|
|
|
insn = aarch64_insn_gen_movewide(rd,
|
|
|
|
|
(u16)(val >> 32),
|
|
|
|
|
32,
|
|
|
|
|
AARCH64_INSN_VARIANT_64BIT,
|
|
|
|
|
AARCH64_INSN_MOVEWIDE_KEEP);
|
|
|
|
|
*updptr++ = cpu_to_le32(insn);
|
|
|
|
|
|
|
|
|
|
/* movk rd, #((val >> 48) & 0xffff), lsl #48 */
|
|
|
|
|
insn = aarch64_insn_gen_movewide(rd,
|
|
|
|
|
(u16)(val >> 48),
|
|
|
|
|
48,
|
|
|
|
|
AARCH64_INSN_VARIANT_64BIT,
|
|
|
|
|
AARCH64_INSN_MOVEWIDE_KEEP);
|
|
|
|
|
*updptr++ = cpu_to_le32(insn);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void kvm_update_kimg_phys_offset(struct alt_instr *alt,
|
|
|
|
|
__le32 *origptr, __le32 *updptr, int nr_inst)
|
|
|
|
|
{
|
|
|
|
|
generate_mov_q(kimage_voffset + PHYS_OFFSET, origptr, updptr, nr_inst);
|
|
|
|
|
}
|
2020-10-24 23:33:38 +08:00
|
|
|
|
|
|
|
|
void kvm_get_kimage_voffset(struct alt_instr *alt,
|
|
|
|
|
__le32 *origptr, __le32 *updptr, int nr_inst)
|
|
|
|
|
{
|
|
|
|
|
generate_mov_q(kimage_voffset, origptr, updptr, nr_inst);
|
|
|
|
|
}
|
