Moving to OpenSBI #212
Assignees
Comments
|
I was able to make it work in a single-core machine, but it ended up having a bunch of interface changes. Currently, our IPI does not properly work, thus we need to fix in order to run on multi-core machines. |
|
Note: OpenSBI v0.7 (or higher) requires Linux v5.7-rc1 (or higher) in order to support SMP. |
Why is branch dev-firemarshal removed? |
|
@yintianyu because it was merged #208 |
|
Hi @dayeol, if I want to test keystone with opensbi, which branch should I use? |
|
Hi Huaqi,
Sorry for the late reply, I've been busy last week.
We're still working on a few more bug fixes, so it's not testable with the
public branch.
However, if you really want to try it out ahead of time, you can run on
single-core machine with this version of OpenSBI:
https://github.com/keystone-enclave/opensbi/tree/ab417a8b2c41aa388a8871c8255655b499bbf5a7
You need to update a few things in your keystone repo:
(1) Build linux image with `make`, not `make vmlinux`. I'd modify
CMakeListst.txt to omit vmlinux from the Linux build commands.
This is because bbl was using vmlinux image, whereas OpenSBI uses the raw
kernel image as a payload.
(2) In the fork of openSBI, you can find the SM submodule under
lib/utils/experimental/keystone.
The submodule itself is in https://github.com/keystone-enclave/sm
Compile OpenSBI with the following commands:
make O=build PLATFORM=generic CROSS_COMPILE=riscv64-unknown-elf-
FW_PAYLOAD_PATH=/home/ubuntu/keystone/build/linux.build/arch/riscv/boot/Image
-j4
and you will find the image in
build/platform/generic/firmware/fw_payload.elf
Replace QEMU's -kernel with that image. (Modify <build
directory>/scripts/run-qemu.sh)
(3)
Finally, change the Linux driver to dev-opensbi branch (
https://github.com/keystone-enclave/linux-keystone-driver/tree/dev-opensbi)
These three will let you boot OpenSBI firmware with Keystone security
monitor, and your updated driver will call correct SBIs compatible with the
OpenSBI spec.
Let me know if face any problem!
Thanks
Dayeol
…On Thu, Dec 3, 2020 at 6:03 PM Huaqi Fang ***@***.***> wrote:
Hi @dayeol <https://github.com/dayeol>, if I want to test keystone with
opensbi, which branch should I use?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#212 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAPWYJ6DRKGWTLTH35UVRATSTA7PVANCNFSM4SHZOLDA>
.
|
|
Thank you @dayeol for your detailed information, I will take a try later. |
|
Hi @dayeol , I tried with opensbi + sm, but I met an issue here, as below: I didn't met with this issue using the bbl version, I am wondering whether there is something I missed. BTW, wish you a happy new year in 2021. Thanks |
|
I am not sure, but did you use dev-opensbi branch for linux-keystone-driver? |
|
Yes, I am using that branch, it seems that the bug is happening in keystone-runtime executing. |
|
Hi @dayeol, which keystone-sdk branch and keystone-runtime branch should I use? |
|
Hi Huaqi,
SDK's dev-opensbi branch will contain the right runtime branch in its
CMakeLists.txt.
Please refer to the latest commit of SDK's `dev-opensbi` branch:
keystone-enclave/keystone-sdk@eded0e0
Let me know if that branch doesn't work.
If you checkout the new SDK, you'll need to reinstall it by running `make
install` in the sdk's build directory.
Also, if you're testing with QEMU, you need to run `make image` to rebuild
the disk image, because the old image will contain the enclave binaries
built with older SDK.
Hopefully, I'll finish testing this OpenSBI version and publish the working
version shortly.
We are currently incorporating a few changes
<http://patchwork.ozlabs.org/project/opensbi/list/?series=222283> in
OpenSBI for the security monitor.
I'll let you know when it's done.
…On Tue, Jan 5, 2021 at 12:34 AM Huaqi Fang ***@***.***> wrote:
Hi @dayeol <https://github.com/dayeol>, which keystone-sdk branch and
keystone-runtime branch should I use?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#212 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAPWYJYLVKLKV54U4HKISTDSYLFKLANCNFSM4SHZOLDA>
.
|
|
Ok, thank you for your information. @dayeol |
|
FYI, I'm deprecating riscv-pk with this PR |
|
Hi @dayeol , I am able to reproduce the result, but when I integrated it into our SDK using riscv gnu toolchain(gcc 9.2, glibc 2.29), I faced issue show above. Do you have any changes to gcc toolchain? Thanks |
|
Hi @dayeol , I tried to use the same toolchain base you used in keystone, and rebuilt toolchain, and intergrated it in our SDK with keystone, and I am able to run keystone tests, and it works well, but when I changed to gcc 9.2, it didn't work. Any compatiable issue in different glibc library? |
|
I do remember that there was a compatibility issue that we needed to fix. (it was buildroot that causes some error as far as i remember) |
|
Hi @dayeol , I am using this commit in our own repo: https://github.com/riscv-mcu/riscv-gnu-toolchain/tree/8c13bb4f538863f9ddb545aa1c5ec9d0be65cb44 |
|
I find the fault caused running |
|
Could you try unmodified version of riscv-gnu-toolchain with gcc 9.2 to see if the same thing happens? |
|
Hi, we didn't do any modification related to glibc library, but BTW I will take a try. |
|
Hi @dayeol , I have tested with riscv gcc 9.2, glibc 2.29, the same error happened. |
|
Hi, I have done a few more tests, I build riscv toolchain with gcc 9.2, but using glibc 2.26, it works well for me, is there any incompatiable issue with glibc 2.26 and glibc 2.29 which might cause above issue. Here is a full run log |
|
Failed with glibc 2.27, see |
|
Thanks a lot for the detailed log. I am trying to reproduce this. |
|
I just tried with keystone master branch using gcc 9.20 + glibc 2.29, and run with sifive qemu, repeated the same issue. $ git diff conf/
diff --git a/conf/qemu_riscv64_virt_defconfig b/conf/qemu_riscv64_virt_defconfig
index 5478a5e..11c4508 100644
--- a/conf/qemu_riscv64_virt_defconfig
+++ b/conf/qemu_riscv64_virt_defconfig
@@ -8,8 +8,8 @@ BR2_GCC_TARGET_ABI="lp64d"
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_PATH="$(RISCV)"
BR2_TOOLCHAIN_EXTERNAL_CUSTOM_PREFIX="$(ARCH)-unknown-linux-gnu"
-BR2_TOOLCHAIN_EXTERNAL_GCC_7=y
-BR2_TOOLCHAIN_EXTERNAL_HEADERS_4_13=y
+BR2_TOOLCHAIN_EXTERNAL_GCC_9=y
+BR2_TOOLCHAIN_EXTERNAL_HEADERS_5_0=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM_GLIBC=y
BR2_TOOLCHAIN_EXTERNAL_INET_RPC=y
BR2_TOOLCHAIN_EXTERNAL_CXX=yRun log: |
|
I was able to reproduce the issue and it seems that this is a duplicate of keystone-enclave/keystone-sdk#48. Please follow up in that thread! |
dayeol
added a commit
that referenced
this issue
Feb 10, 2021
* Moving to OpenSBI, deprecate BBL (riscv-pk) * Bump latest riscv-gnu-toolchain (2021.01) * Bump buildroot (2020.11) * Remove all newly-introduced compiler errors * Test and fix RV32 (ilp32d/rv32gc) dtb was not aligned, which results in system hang at boot. align dtb in both bootrom and QEMU. * Better scripting for RV32 (always use fast-setup.sh) * Buildroot configs for the new toolchain (glibc) * Linux config mcmodel to medany (to be consistent) * CI changes for the latest toolchain * CI changes for RV32 test * Remove unused patches * Switch CI from Travis to CircleCI (Travis is no longer free for OSS) Issues resolved: - #212 - #195 - #127 - #147 - #148 - keystone-enclave/keystone-sdk#48 - keystone-enclave/keystone-runtime#46
|
Resolved |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We're moving the security monitor to OpenSBI (https://github.com/riscv/opensbi) so that it's much easier to integrate Keystone with the latest RISC-V platforms.
This will also resolve a lot of IPI-related issues (#127) and device tree bugs (#147, #148), and so on.
The text was updated successfully, but these errors were encountered: