From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751846AbbL1OMP (ORCPT ); Mon, 28 Dec 2015 09:12:15 -0500 Received: from mout.kundenserver.de ([217.72.192.73]:59424 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750777AbbL1OMN (ORCPT ); Mon, 28 Dec 2015 09:12:13 -0500 From: Arnd Bergmann To: Ard Biesheuvel Cc: "linux-arm-kernel@lists.infradead.org" , kernel-hardening@lists.openwall.com, Will Deacon , Catalin Marinas , Mark Rutland , Leif Lindholm , Kees Cook , "linux-kernel@vger.kernel.org" , Sharma Bhupesh , Stuart Yoder Subject: Re: [RFC PATCH 01/10] arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region Date: Mon, 28 Dec 2015 15:11:25 +0100 Message-ID: <11016384.rorhLcDd8i@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: <1451301654-32019-1-git-send-email-ard.biesheuvel@linaro.org> <11539877.krH4qBJsp9@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:hcQ4hI2AmQpmborw+iL0PB8BBAW48dwRNx2wfPqYQtO/UAhvSTi TshN+VNUDES1J2cbgBhOp+uHy60ToQMqGk20QW0a7AzCc9K07V83/eSPKEpCZsjczDfrwid OwJkTE93ASnLFmyDRFlSxKPydrZUlyEbvEp/4NmoNb7jlGPabI8q6sGtwaoi33ykooPZbY8 sNonZU9lHZVeAQ58OvJAA== X-UI-Out-Filterresults: notjunk:1;V01:K0:01f8wlb8iSk=:8nXDFSYdFyUwMO1ukPKPIW rbNASF7JQQS6D9003CO08o3vsK/qrfNBmTxorFxqO6CJp2hOigMmlg9wr68LGldynsg5eTUsf 3maYKDG7c6zpY/Gr3bZ+lKjZxhlyXomqkPN4t7N6Bj6NKkvfoNRMpe6conSCXduu2Yp4UNzGI Z33wblM4bJ+EuSZKa4y5ZWyj4qffUYyR6rrKGrlm38iIBq0j0L9hb6mrcxUFe48wP7d85OAn4 TVlMDt9Ue0VMcPELtU5mfhaGNLIobjRM8BOmSU15KDV48vDYLz0tEBvScFbVJohViD5KjbE5o ygQsEetpLsTcGZsdyMOkf3P62umSWQ6G2qxy0BhduxIT4813hmRLXsmRmSWnCfFCkGPuU12Oq MUEiarXRj9KsSzgWRroD0ur/vFEDWr5Ufqeldfhmq5Cfmp45Qirg9eVTGsMvbFbdGpvMzVKOR sRaAwrs/Y5glzIF78YiZE9vHEf163hTuVJAG+NwDyKBXMgdnR4IS9CAmHnJ86LZ2gLKDa0Tbw 7S180+GdMjo3MwVAKNQ37xRFUf3HHAp8xhXb1OhC/AZ/SBVZWuvUDR7iN9QS/fH3if/T/tSO8 1fyVYH86cxElTjSLTQAxUxZOVmsYaYzdF/DQB8lZEC7S4rQX0b/kTFXTxXC++CMog1Go2+NIc mTFaXTukN+vBjZI+bGqN4p0RAU0zVmom5TCsz5HKwlwxXKKHb8nss+pQx/AadtOD7Kt3sD3hT 2D4zWRfQfTVeuWF9 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday 28 December 2015 13:07:44 Ard Biesheuvel wrote: > On 28 December 2015 at 12:50, Arnd Bergmann wrote: > > On Monday 28 December 2015 12:20:45 Ard Biesheuvel wrote: > > How about a different approach that keeps the relocatable kernel, but moves it in > > physical memory with the same random offset as the virtual address? That way, both > > would be random, and you can keep the simple virt_to_phys() function. > > > > I suppose the downside of that is that the number of random bits is then limited > > by the size of the first memblock, which is smaller than the vmalloc area. > > > > I don't see a reason to use the same virtual and physical offset > (other than the conditional). On arm64, it would be up to the > bootloader to decide where to put the Image in physical memory, and it > would be up to the kernel to decide whether or not to virtually remap > itself. I see. If we pull in the bootloader to the discussion, there are a couple of related points that are not directly required for your series but that we should keep in mind anyway: - We need to implement the randomization for each boot loader separately. This is probably easy enough for grub, as it can tap the same random number source that you use here, but a little harder for u-boot (requiring to implement access to hardware rng separately on each platform) and much harder to get done consistently in UEFI for direct kernel loading since there is no common upstream. - once we have a random number in the bootloader, we should also pass that through a DT property. This has been discussed multiple times in the past and I think we had reached consensus already but don't know if we had agreed on a specific DT property that contains the random number seed. - For machines that don't have strong hardware RNG, or where we don't trust that hardware enough, we may want to have a way to feed back a random seed into the bootloader during shutdown, the equivalent of /etc/random-seed. On real Open Firmware, we'd do this through a nvram variable that gets copied into a /chosen DT property, but we don't have a generic way to do the same with u-boot. On UEFI we could probably do it through efivars, but I'm not sure if that's accessible early enough in the kernel, so we might need help from grub again. Arnd