XPDDS19: Secure Unikraft Applications with Solo5 - Haibo Xu, ARM
•Download as PPTX, PDF•
0 likes•230 views
As the number of contributions grow, reviewer bandwidth becomes a bottleneck; and maintainers are always asking for more help. However, ultimately maintainers must at least Ack every patch that goes in; so if you're not a maintainer, how can you contribute? Why should anyone care about your opinion? This talk will try to lay out some advice and guidelines for non-maintainers, for how they can do code review in a way which will effectively reduce the load on maintainers when they do come to review a patch.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to XPDDS19: Secure Unikraft Applications with Solo5 - Haibo Xu, ARM
Similar to XPDDS19: Secure Unikraft Applications with Solo5 - Haibo Xu, ARM (20)
More from The Linux Foundation
More from The Linux Foundation (20)
Recently uploaded
Recently uploaded (20)
XPDDS19: Secure Unikraft Applications with Solo5 - Haibo Xu, ARM
- 1. Secure unikraft application with solo5 Haibo Xu, Software Engineer, ARM
- 2. Agenda • Overview • Solo5 • Unikraft • Running Unikraft on Solo5 • Things to hack on
- 3. Overview: Solo5 Solo5 is a sandboxed execution environment suitable for running applications built using various unikernels, targeting different sandboxing technologies on diverse host operating systems and hypervisors. – About Solo5 It is essentially a piece of “middleware” interfacing unikernel-style applications with their host systems, and can not be an standalone product as such.
- 4. Overview: Solo5 Features: minimalist API and monitor • reduced attack surface • fast boot time(~10 ms) • management public guest facing APIs • easy to port existing and future unikernels app • easy to port to different sandboxing or host environment live and post debugging of unikernel no SMP • scale out by running multiple instance no interrupts or scheduling does not run on bare metal limited APIs to application, currently 13 Limited system calls, as few as 7 on spt tender
- 5. Overview: Unikraft Unikraft, introduced by NEC Laboratories Europe, is a development model – SDK for unikernels. evolution Web Service Unikernel Block Device Library Net Device Library Filesystem Library Network Stack Library Python Runtime Library Web Service Application • Minimalistic • Single address space • Collection of required libraries • Deployed with minimal dependency
- 7. Running Unikraft on Solo5 • ~1000 LOC • New LIBSOLO5PLAT added • Implemented LIBSOLO5PLAT APIs with Solo5 bindings(include/uk/plat/) • External platform library is added to include solo5 source code(unikraft/libs/) • unikraft/apps/helloworld is verified on both x86_64 and arm64 machine with solo5 hvt and spt tenders
- 8. Running Unikraft on Solo5
- 9. Things to hack on • Solo5 doesn’t support interrupts network/block device I/O support – event driven? spinlock APIs thread context switch APIs irq register/save/restore APIs?
Editor's Notes
- Solo5 originally started as a project by Dan Williams at IBM Research to port MirageOS to run on the Linux/KVM hypervisor. Since then, it has grown into a more general sandboxed execution environment, suitable for running applications built using various unikernels, targeting different sandboxing technologies on diverse host operating systems and hypervisors.
- The products of building a Solo5 unikernel are two artifacts: (1) an ELF binary containing the built unikernel, (2) a specialized tender by convention currently built as solo5-hvt alongside the unikernel binary(~130KB). It turns out that simplifying this interface has the following desirable properties: (1) removal of interrupts implies more deterministic behavior of applications, allowing for efficient record/replay and debugging, (2) fast "boot" times, comparable to loading a standard user process, suitable for "function as a service" use-cases, (3) ease of porting existing and future unikernels to run on top of the Solo5 interface.
- Here is the basic Unikernels concept. (As Simon have introduced it this morning I think we can skip it.) We regard Unikraft as an evolution of Unikernels. This project's goal was to design a totally new development model or we can call it as an SDK, to reduce the effort of converting existed applications to Unikernels. It has three important improvements of Unikernel development: 1: it’s Easy to Reuse existing researches and developments; 2: it’s Easy to Configure the Unikernel application; 3: it’s the most important one: Porting effort requires no rewriting code, in the best case, you just need To recompile the application code with Unikraft toolchain. In the worst case, you may need some small changes to the actual application code. Using recompiling instead of rewriting is the biggest improvement.
- The main idea behind Unikraft is depicted in this figure and consists of two basic components: library pools containing libraries that the user of Unikraft can select from to create the unikernel; a build tool and menu allowing users to pick and choose from those libraries to build images tailored to specific applications.
- As mentioned in previous slides, Solo5 can provide a general sandboxed execution environment which is very suitable for running application build using various unikernels. And unikraft is an automated system for building specialized unikernel based applications. So to run the Unikraft based application in Solo5 environment is possible and straightforward.
- As mentioned in previous slides, Solo5 doesn’t support interrupt and schedule, so we have to figure out how to implement these APIs in solo5 platform. As far as I can see, we can use the event to drive the network and block device I/O operations. But we have no idea for the remain APIs. Please feel free to ping us if you have any ideas or are interested in this new platform.