[llvm-dev] HWASAN support for RISCV

[Alex Bradbury via llvm-dev]

On Tue, 20 Oct 2020 at 07:09, Anatoly Parshintsev via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> Hello there,
>
>
> We want to publish the port of HWASAN implementation for RISCV to llvm. And I'd like to understand the prerequisites for this functionality to be adopted by llvm
>
>
> The implementation is dependent on the J-extension (aka "Pointer Masking") to be available. At the present moment, the extension is not an official one, but the core concepts which are relevant to llvm are not expected to be changed. Currently, we are pushing the implementation of this extension to qemu. There is a set of patches on review.
>
>
> We already have an initial prototype of the HWASAN port for RISC-V based on this extension. And we'd like to push it to llvm mainline. I'd like to understand the prerequisites of such functionality to be adopted.
>
>
> 1. Is the availability of J-extension in qemu enough?
>
> 2. As is - the extension can be used in bare-metal applications right away. However, Linux may require some patches: for example, implementation of syscalls to enable Pointer Masking for the calling process (by the way - we have the initial implementation for that too).
>
>
> Could someone advise if we can begin to roll-out the relevant patches for such an experimental functionality? Or should we wait for, say, an "official" Linux support?
>
>
> Any suggestions and recommendations are very welcome.

Hi Anatoly,

It's great to hear about this work. A relevant thread to review might
be this RFC on the policy for merging support for yet-to-be-ratified
extensions <http://lists.llvm.org/pipermail/llvm-dev/2020-January/138364.html>.
That discussion was more focused on instructions in e.g. the proposed
B and V extensions, but I think has relevance here. I tried to
summarise the conclusion in the 11.0 release notes too
<https://releases.llvm.org/11.0.0/docs/ReleaseNotes.html#changes-to-the-risc-v-target>

It would seem consistent with that previous discussion to work to
accept this work upstream (to encourage collaboration on common
functionality rather than long-lived downstream forks) but to have the
functionality behind a -experimental-[something?] flag until support
for the extension it relies upon is ratified, or some other discussion
concludes the experimental flag should be removed (e.g. a group might
come forward to say they've produced hardware based on the
specification, which might change the parameters of the conversation).

How does the above sound to you?

Best,

Alex