Hi Tixy,
On 27/03/15 10:42, Jon Medhurst (Tixy) wrote:
> On Thu, 2015-03-26 at 22:19 +0000, Marc Zyngier wrote:
>> On Thu, 26 Mar 2015 22:03:23 +0000
>> Will Deacon <will.deacon@xxxxxxx> wrote:
>>
>>> On Thu, Mar 19, 2015 at 01:59:33PM +0000, Marc Zyngier wrote:
>>>> Since all immediate branches are PC-relative on Aarch64, these
>>>> instructions cannot be used as an alternative with the simplistic
>>>> approach we currently have (the immediate has been computed from
>>>> the .altinstr_replacement section, and end-up being completely off
>>>> if we insert it directly).
>>>>
>>>> This patch handles the b and bl instructions in a different way,
>>>> using the insn framework to recompute the immediate, and generate
>>>> the right displacement.
>>>>
>>>> Reviewed-by: Andre Przywara <andre.przywara@xxxxxxx>
>>>> Signed-off-by: Marc Zyngier <marc.zyngier@xxxxxxx>
>>>> ---
>>>> arch/arm64/kernel/alternative.c | 55 +++++++++++++++++++++++++++++++++++++++--
>>>> 1 file changed, 53 insertions(+), 2 deletions(-)
>>>
>>> [...]
>>>
>>>> static int __apply_alternatives(void *alt_region)
>>>> {
>>>> struct alt_instr *alt;
>>>> @@ -40,16 +83,24 @@ static int __apply_alternatives(void *alt_region)
>>>> u8 *origptr, *replptr;
>>>>
>>>> for (alt = region->begin; alt < region->end; alt++) {
>>>> + u32 insn;
>>>> + int i;
>>>> +
>>>> if (!cpus_have_cap(alt->cpufeature))
>>>> continue;
>>>>
>>>> - BUG_ON(alt->alt_len > alt->orig_len);
>>>> + BUG_ON(alt->alt_len != alt->orig_len);
>>>>
>>>> pr_info_once("patching kernel code\n");
>>>>
>>>> origptr = (u8 *)&alt->orig_offset + alt->orig_offset;
>>>> replptr = (u8 *)&alt->alt_offset + alt->alt_offset;
>>>> - memcpy(origptr, replptr, alt->alt_len);
>>>> +
>>>> + for (i = 0; i < alt->alt_len; i += sizeof(insn)) {
>>>> + insn = get_alt_insn(origptr + i, replptr + i);
>>>> + *(u32 *)(origptr + i) = insn;
>>>
>>> My brain's not firing on all cylinders right now, but do you need a
>>> cpu_to_le32 here?
>>
>> I'm not 100% awake myself (probably some acute form of firmwaritis),
>> but I suspect you're quite right (get_alt_insn calls aarch64_insn_read,
>> which does a le32_to_cpu). Obviously, we need to revert the conversion
>> when writing the instruction back.
>
> Isn't aarch64_insn_write the inverse of aarch64_insn_read and more
> correct than using cpu_to_le32?
You're perfectly right, and you've actually uncovered a bug: if we have
CONFIG_DEBUG_SET_MODULE_RONX or CONFIG_DEBUG_RODATA, we'd end up trying
to patch the read-only mapping, with disastrous results,
aarch64_insn_write does the right thing, so we might as well use that.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
