Keystone Build System Update

173 views
Skip to first unread message

Gregor Haas

unread,
Sep 11, 2023, 5:30:07 PM9/11/23
to Keystone Enclave Forum
Hi all,

As part of a broader effort to clean up our codebase, we've developed a new top-level build system for Keystone. This change takes advantage of our earlier efforts to move to a monorepo model for Keystone sources, and will enable better platform integration and CI as Keystone continues to evolve. While this change has a lot of benefits, it may also have a good change of being a breaking change for some workflows. Most notably, we are moving away from CMake as the top-level build system and instead using a small Makefile wrapper around Buildroot, which will now coordinate building all Keystone subprojects and generating a bootable rootfs. Much of the rationale behind this change is described in the PR, and we have also created a migration guide in order to assist users in moving to the new infrastructure.

We expect to land this change in main by the end of this week. For any questions, comments, or concerns, please feel free to raise Github issues, reach out on the Keystone slack/mailing list, or to me directly at gregorhaas1997 AT gmail.com.

Thank you,
Gregor Haas

Gregor Haas

unread,
Sep 15, 2023, 4:59:00 PM9/15/23
to Keystone Enclave Forum
Hi all,

We have just merged the PR described above into main.

Thank you,
Gregor Haas
> --
> You received this message because you are subscribed to a topic in the Google Groups "Keystone Enclave Forum" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/keystone-enclave-forum/G0X-kG4IosA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to keystone-enclave-...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/keystone-enclave-forum/236fd448-b9c7-4d7a-9342-cbe959f3588fn%40googlegroups.com.

Konrad-Felix Krentz

unread,
Sep 19, 2023, 3:57:29 AM9/19/23
to Keystone Enclave Forum
Hello Gregor,

The build system became much cleaner and I am looking forward to get support for my Icicle.

Currently, I am rebasing my filtering proxy. While it compiles, I soon get errors of this kind at runtime: "[runtime] page fault at 0x531c on 0x3ffdfff0 (scause: 0xf)". Kindly let me know if you recall any changes to the runtime or sdk that might be the cause.

Kind regards,

Konrad

Gregor Haas

unread,
Sep 19, 2023, 4:41:26 PM9/19/23
to Konrad-Felix Krentz, keystone-en...@googlegroups.com
Hi Konrad,

Thanks for reaching out and for the feedback on the build system!

While I don’t know exactly what may be causing the issue here, I do see the following in runtime/include/mm/vm_defs.h. This file sets the EYRIE_USER_STACK_START to 0x40000000, and the EYRIE_USER_STACK_SIZE to 0x20000. Your faulting address is exactly 0x40000000 - 0x20010, which looks to me like a stack overflow.

Maybe the toolchain/libc changes, along with bumps to any libraries you consume in your filtering proxy, result in deeper call stacks in the eapp? I would try to bump this stack size, relevantly dirclean your build folder as described in the migration guide (probably BUILDROOT_TARGET=keystone-runtime-dirclean make), and rebuild to see if this fixes things.

Thank you,
Gregor Haas
> To view this discussion on the web visit https://groups.google.com/d/msgid/keystone-enclave-forum/dadcc405-ce43-4c19-a66a-c00514ac7888n%40googlegroups.com.

Konrad-Felix Krentz

unread,
Oct 20, 2023, 12:58:14 PM10/20/23
to Keystone Enclave Forum

Thank you for the hint, Gregor. I eventually got my filtering proxy to work. Increasing the stack size did not do the trick. A first page fault was caused by sdk/src/app/tiny-malloc.c. When running out of memory, malloc does not return NULL, but crashes with a page fault. This occurs with the older version of Keystone, too. After some unsuccessful fiddling with the app.lds and tiny-malloc.c, I switched to static allocation. Then, I thought that I could remove the app.lds since the examples also live without it as far as I can see. If I do so, my eapp crashes immediately, even with the fix in #356 or when going back to the older version of Keystone. So, I retained the app.lds, but still encountered a page fault at the first invocation of memset(). By contrast, previous ocall() invocations work fine and both ocall and memset are contained in KEYSTONE_LIB_EAPP. Despite this, I had to insert “$ENV{KEYSTONE_SDK}/src/app/string.c” into the source file list of my eapp.

Kind regards,

Konrad

Reply all
Reply to author
Forward
0 new messages