[PATCH 2/5] arm64: alternative: Allow immediate branch as alternative instruction

[Marc Zyngier]

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 at arm.com> 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 at arm.com>
>>>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>>>> ---
>>>>  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...