[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-arm] [Qemu-devel] [PATCH 1/3] target/arm: fix AArch64 virtual
Re: [Qemu-arm] [Qemu-devel] [PATCH 1/3] target/arm: fix AArch64 virtual address space size
Sat, 26 Jan 2019 12:00:38 -0800
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
On 1/25/19 10:36 PM, Rémi Denis-Courmont wrote:
> Le lauantaina 26. tammikuuta 2019, 1.29.27 EET Richard Henderson a écrit :
>> On 1/25/19 1:49 PM, Rémi Denis-Courmont wrote:
>>> From: Remi Denis-Courmont <address@hidden>
>>> Since QEMU does not support the ARMv8.2-LVA, Large Virtual Address,
>>> extension (yet), the VA address space is signed 48-bits. User mode can
>>> only handle the positive half of the address space, so that makes a
>>> limit of 47 bits.
>>> (With LVA, it would be 52 and 51 bits respectively.)
>>> The incorrectly large address space conflicts with PAuth instructions,
>>> which bits 48-54 and 56-63 for the pointer authentication code. This
>>> also conflicts with (as yet unsupported by QEMU) data tagging and with
>>> the ARMv8.5-MTE extension.
>>> Signed-off-by: Remi Denis-Courmont <address@hidden>
>>> target/arm/cpu.h | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
>>> index ff81db420d..2ccd04b8f7 100644
>>> --- a/target/arm/cpu.h
>>> +++ b/target/arm/cpu.h
>>> @@ -2503,7 +2503,7 @@ bool write_cpustate_to_list(ARMCPU *cpu);
>>> #if defined(TARGET_AARCH64)
>>> # define TARGET_PHYS_ADDR_SPACE_BITS 48
>>> -# define TARGET_VIRT_ADDR_SPACE_BITS 64
>>> +# define TARGET_VIRT_ADDR_SPACE_BITS 47
>>> # define TARGET_PHYS_ADDR_SPACE_BITS 40
>>> # define TARGET_VIRT_ADDR_SPACE_BITS 32
>> This doesn't really conflict, as this doesn't affect much besides the sizing
>> of the PageDesc for page_find.
> Uh, that value controls the range of target virtual addresses user mode maps
> to host virtual addresses. Without this patch, AFAICT, there are no
> guarantees, only chance, that emulated system calls such as mmap() will not
> allocate architecturally invalid addresses.
Well, that's the theory, yes.
On the plus side, the host platform that virtually everyone uses, x86_64, also
uses a 48-bit virtual address space, so there's no chance of such an invalid
On the minus side, the code within target_mmap is not sufficient to ensure that
mmap will not produce invalid addresses.
See 76393642ae6, where I extended target/alpha TARGET_VIRT_ADDR_SPACE_BITS to
63 to work around exactly this problem. To wit: target_mmap loops forever
asking the kernel for an address below 2**40, which the kernel refused to
So changing this value for target/arm runs the risk of causing
aarch64-linux-user to fail on a ppc64/s390x/sparc64 host. For all of the tens
of people around the world that care about such a configuration.