Anatoly Parshintsev via llvm-dev
2020-Oct-20 06:09 UTC
[llvm-dev] HWASAN support for RISCV
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 <https://github.com/riscv/riscv-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 <https://lists.nongnu.org/archive/html/qemu-riscv/2020-10/msg00173.html>. 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201020/37263268/attachment.html>
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
The policy and mechanism for Clang to support experimental/unratified extensions in RISCV has already been established, see https://reviews.llvm.org/D73891 (as well as https://reviews.llvm.org/D69987 https://reviews.llvm.org/D81188 implementing the experimental V extension). As long as you follow the same model for the experimental "J" extension, there should be no issue with this. On Tue, Oct 20, 2020 at 2:09 AM 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 > <https://github.com/riscv/riscv-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 > <https://lists.nongnu.org/archive/html/qemu-riscv/2020-10/msg00173.html>. > > > 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. > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201020/614a2a62/attachment.html>