linux-kernel - Re: [PATCH 5/8] arm64: alternative: Add support for patching adrp instructions

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]

Date:   Tue, 23 Aug 2016 10:16:55 +0100
From:   Suzuki K Poulose <Suzuki.Poulose@....com>
To:     Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc:     "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Mark Rutland <mark.rutland@....com>,
        Marc Zyngier <marc.zyngier@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Andre Przywara <andre.przywara@....com>
Subject: Re: [PATCH 5/8] arm64: alternative: Add support for patching adrp
 instructions

On 22/08/16 12:45, Ard Biesheuvel wrote:
> On 18 August 2016 at 15:10, Suzuki K Poulose <suzuki.poulose@....com> wrote:
>> adrp uses PC-relative address offset to a page (of 4K size) of
>> a symbol. If it appears in an alternative code patched in, we
>> should adjust the offset to reflect the address where it will
>> be run from. This patch adds support for fixing the offset
>> for adrp instructions.
>>
>> Cc: Will Deacon <will.deacon@....com>
>> Cc: Marc Zyngier <marc.zyngier@....com>
>> Cc: Andre Przywara <andre.przywara@....com>
>> Cc: Mark Rutland <mark.rutland@....com>
>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@....com>
>> ---
>>  arch/arm64/kernel/alternative.c | 13 +++++++++++++
>>  1 file changed, 13 insertions(+)
>>
>> diff --git a/arch/arm64/kernel/alternative.c b/arch/arm64/kernel/alternative.c
>> index d2ee1b2..71c6962 100644
>> --- a/arch/arm64/kernel/alternative.c
>> +++ b/arch/arm64/kernel/alternative.c
>> @@ -80,6 +80,19 @@ static u32 get_alt_insn(struct alt_instr *alt, u32 *insnptr, u32 *altinsnptr)
>>                         offset = target - (unsigned long)insnptr;
>>                         insn = aarch64_set_branch_offset(insn, offset);
>>                 }
>> +       } else if (aarch64_insn_is_adrp(insn)) {
>> +               s32 orig_offset, new_offset;
>> +               unsigned long target;
>> +
>> +               /*
>> +                * If we're replacing an adrp instruction, which uses PC-relative
>> +                * immediate addressing, adjust the offset to reflect the new
>> +                * PC. adrp operates on 4K aligned addresses.
>> +                */
>> +               orig_offset  = aarch64_insn_adrp_get_offset(insn);
>> +               target = ((unsigned long)altinsnptr & ~0xfffUL) + orig_offset;
>> +               new_offset = target - ((unsigned long)insnptr & ~0xfffUL);
>> +               insn = aarch64_insn_adrp_set_offset(insn, new_offset);
>
> Are orig_offset and new_offset guaranteed to be equal modulo 4 KB?
> Otherwise, you will have to track down and patch the associated :lo12:
> add/ldr instruction as well.

We are modifying the alternative instruction to accommodate for the new PC,
where this instruction will be executed from, while the referenced symbol
remains the same. Hence the associated :lo12: doesn't change. Does that
address your concern ? Or did I miss something ?

Suzuki