linux-kernel - Re: [PATCH v5 0/4] KASAN for powerpc64 radix

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] [day] [month] [year] [list]

Message-ID: <87muagjewu.fsf@dja-thinkpad.axtens.net>
Date:   Wed, 22 Jan 2020 15:25:37 +1100
From:   Daniel Axtens <dja@...ens.net>
To:     Christophe Leroy <christophe.leroy@....fr>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        linuxppc-dev@...ts.ozlabs.org, kasan-dev@...glegroups.com,
        aneesh.kumar@...ux.ibm.com, bsingharora@...il.com
Subject: Re: [PATCH v5 0/4] KASAN for powerpc64 radix

Christophe Leroy <christophe.leroy@....fr> writes:

> Le 09/01/2020 à 08:08, Daniel Axtens a écrit :
>> Building on the work of Christophe, Aneesh and Balbir, I've ported
>> KASAN to 64-bit Book3S kernels running on the Radix MMU.
>> 
>> This provides full inline instrumentation on radix, but does require
>> that you be able to specify the amount of physically contiguous memory
>> on the system at compile time. More details in patch 4.
>
> This might be a stupid idea as I don't know ppc64 much. IIUC, PPC64 
> kernel can be relocated, there is no requirement to have it at address 
> 0. Therefore, would it be possible to put the KASAN shadow mem at the 
> begining of the physical memory, instead of putting it at the end ?
> That way, you wouldn't need to know the amount of memory at compile time 
> because KASAN shadow mem would always be at address 0.

Good question! I've had a look. Bearing in mind that I'm not an expert
in ppc64 early load, I think it would be possible, but a large chunk of
work.

One challenge is that - as I understand it - the early relocation code
in head_64.S currently allows the kernel to either:
 - run at the address it's loaded at by kexec/the bootloader, or
 - relocate the kernel to 0

As far as I can tell book3s 64bit doesn't have code to arbitrarily
relocate the kernel.

It's possible I'm wrong about this, in which case I'm happy to reasses!

If I'm right, I think we'd want to implement KASLR for book3s first,
along the lines of how book3e does it. That would allow the kernel to be
put at an arbitrary location at runtime. We could then leverage that.

Another challenge is that some of the interrupt vectors are not easy to
relocate, so we'd have to work around that. That's probably not too big
an issue and we'd pick that up in KASLR implementation.

So I think this is something we could come back to once we have KASLR.

Regards,
Daniel

>
> Christophe