On Sat, Jan 20, 2024 at 11:14 PM Alexey Baturo <baturo.ale...@gmail.com> wrote: > > Hi, > > Having the feature to run binaries with pointer masking on qemu-user is > really nice, but I see this patch series as an initial support. > Obviously there'll be more patches and fixes for pointer masking as soon as > arch tests are ready. > I suggest supporting qemu-user in the next patches, but make sure we do this > before claiming 100% support for pointer masking. > @Deepak Gupta what do you think?
I think that makes sense. Thanks. > > Thanks > > сб, 20 янв. 2024 г. в 10:37, Richard Henderson <richard.hender...@linaro.org>: >> >> On 1/19/24 09:40, Deepak Gupta wrote: >> > On Thu, Jan 18, 2024 at 12:50 PM Richard Henderson >> > <richard.hender...@linaro.org> wrote: >> >> At some point pointer masking will be in hardware, and the kernel will >> >> gain support for >> >> it, and there will likely be a prctl() added for it. At the point the >> >> kernel finalizes >> >> the API, you will be able to enable pointer masking for qemu-user. >> > >> > I am sure I am missing some important detail here, BUT... >> > >> > How is it different from aarch64 "top byte ignore". >> >> It is very similar, yes. >> >> > I think commit: 16c8497 enables top byte ignore for user pointers and >> > by default for qemu-user for aarch64 target. >> >> Not quite, no. >> >> commit 0e0c030c681730f3ec55ba3b223b608a8f3e8282 >> Author: Richard Henderson <richard.hender...@linaro.org> >> Date: Fri Feb 12 10:48:51 2021 -0800 >> >> linux-user/aarch64: Implement PR_TAGGED_ADDR_ENABLE >> >> is more relevant. >> >> > IIRC, user <--> kernel abi is only needed for pointers that are passed >> > to the kernel. >> >> It is also needed to *enable* pointer masking at all. >> >> For aarch64, TBI has been enabled for user-space since the beginning, but >> that is not true >> for riscv. Therefore there will be a need for a syscall to opt in and >> enable pointer masking. >> >> > And in the case of qemu-user, we are talking about the host kernel. >> >> No, we are not. We are always emulating the guest kernel. >> >> >> r~