├── FAQ.md ├── README.md ├── gsoc-2022 ├── README.md ├── ideas.md └── work-product │ └── Maria-Sfiraiala-Shadow-Stack │ ├── Maria-Sfiraiala-Shadow-Stack.md │ └── images │ ├── unikraft-architecture.png │ └── unikraft-build-system.png ├── gsoc-2023 ├── README.md ├── ideas.md └── work-product │ ├── Md-Sahil-Enhancing-the-VSCode-Developer-Experience │ └── Md-Sahil-Enhancing-the-Vscode-Developer-Experience.md │ ├── Rares-Miculescu-Plat-Re-Arch │ └── Rares-Miculescu-plat-rearch.md │ └── Xingjian-Zhang-Arm-CCA-Support │ ├── Xingjian-Zhang-Arm-CCA-Support.md │ └── images │ └── cca-arch.png ├── gsoc-2024 ├── README.md ├── ideas.md └── work-product │ ├── Maria-Pana-Multiboot2-Support-in-Unikraft │ └── Maria-Pana-Multiboot2.md │ ├── Mihnea-Firoiu-Lxboot-Support-in-Unikraft │ └── Mihnea-Firoiu-Lxboot.md │ ├── Sriprad-Potukuchi-UEFI-GOP-Support │ ├── Sriprad-Potukuchi-UEFI-GOP-Support.md │ └── images │ │ └── uefi-gop-console.png │ └── Yang-Hu-Synchronization-Support-in-Internal-Libraries │ └── Yang-Hu-Synchronization-Support-in-Internal-Libraries.md ├── gsoc-2025 ├── README.md ├── ideas.md └── work-product │ └── .gitignore └── work-product-template.md /FAQ.md: -------------------------------------------------------------------------------- 1 | # GSoC: FAQ 2 | 3 | ## I want to know more about Unikraft. Where should I start? 4 | 5 | A good place to start is the [documentation website](https://unikraft.org/). 6 | You can also check out Unikraft's [`docs`](https://github.com/unikraft/docs) repo and build your own version of the site using the information from the [`README.md`](https://github.com/unikraft/docs#readme). 7 | 8 | We also recommend taking a look into the [Unikraft Summer of Code sessions](https://unikraft.org/community/hackathons/usoc22/). 9 | If you fancy some live demos, check out [Unikraft's Youtube channel](https://www.youtube.com/channel/UCP2-A06KLk0_qgGtKAla65A). 10 | 11 | You can even reach out to community members on [discord](https://discord.com/invite/RG5ZQGKxyW). 12 | There you can discuss your doubts as well as ask questions; the community is always ready and willing to help. 13 | 14 | ## What to expect from mentors during GSoC? 15 | 16 | Your mentors are the people you will interact with the most during your project; your guides and the ones that will solidify your integration into the organization. 17 | They are also the people that will pass/fail you, so communicating with them not only regarding your issues, but your success too, should be on your TODO list. 18 | 19 | ## What are the midterm evaluations? What about the final evaluations? 20 | 21 | They are key stages in your project.They require feedback from both the mentor and the mentee and they determine the status of your project; they also represent a great way for the mentor to decide whether your work will end successfully, therefore (potentially) integrating it. 22 | 23 | As stated earlier, both evaluations are a pass/fail from the mentors, so mark the dates in your calendar. 24 | They are important! 25 | 26 | ## What should I be doing during the community bonding period? 27 | 28 | As the name suggests, you should get to know the people you'll work with, the maintainers, the core, people that previously built the part of the Unikraft project you're working on. 29 | 30 | You should, also, (if you haven't already), get accustomed to building and running Unikraft images and come up with a roadmap for the 12+ weeks that you'll have for your idea. 31 | 32 | We strongly suggest you attend the Weekly Community Gatherings, formal and informal meetings where we discuss ideas, issues, PRs and other fun stuff. 33 | 34 | Shy to even attend? Read the [meeting notes](https://github.com/unikraft/meeting-notes) and get your courage up! 35 | 36 | ## Is making a contribution necessary in order to apply to Unikraft? 37 | 38 | Theoretically, you can apply without making a contribution, however, we believe that having even a small contribution proves that you are, indeed, not only ready, but willing to contribute to open source code. 39 | 40 | For ideas, visit the issue page for [core Unikraft](https://github.com/unikraft/unikraft/issues) and external libraries, such as [newlib](https://github.com/unikraft/lib-newlib/issues), [lwip](https://github.com/unikraft/lib-lwip/issues), or [musl](https://github.com/unikraft/lib-musl/issues). 41 | We've marked some items with the `good first issue` and `kind/hackathon` labels to make things easier for you. 42 | 43 | Take a look into the [docs repository](https://github.com/unikraft/docs/issues) as well, there's always work to be done when documenting a project of Unikraft's size. 44 | 45 | Feeling lucky? Try fixing some build warnings. There's plenty of them, waiting just for you! 46 | 47 | ## Can I propose my own idea for a project? 48 | 49 | If you have a project in mind, you are welcome to discuss it with the community members. 50 | However, the project needs to be approved by the maintainer members. 51 | 52 | ## How to perfectly kraft[^1] my proposal? 53 | 54 | 1. Start looking into the organization way before the Contributor Proposal Period, do not wait for the last week to start the investigation process. 55 | 56 | 2. Take a good look at the `ideas.md` file, choose a topic based on your current knowledge and begin browsing the web. 57 | 58 | 3. Join the [discord server](https://bit.ly/UnikraftDiscord) and ask questions! It's extremely important to be as active as possible. 59 | 60 | 4. Read the `README.md` for the year you are applying in. It contains critical information regarding the whole process, especially the proposal template. 61 | 62 | 5. Write your proposal. Get feedback from the community. 63 | 64 | [^1]: Pun intended, based on the (soonly) deprecated Unikraft building tool, [kraft](https://github.com/unikraft/kraft) 65 | 66 | 67 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Unikraft at Google Summer of Code 2 | 3 | This repository contains the official archive of the Unikraft GSoC projects over the years. 4 | 5 | ## File hierarchy 6 | 7 | Browse the files to investigate what work was done every year, expectations, ideas and more: 8 | 9 | ``` 10 | gsoc/ 11 | |---gsoc-year/ 12 | | |---ideas.md 13 | | |---README.md 14 | | |---work-product/ 15 | | | |---Name-Project/ 16 | |---README.md 17 | |---work-product-template.md 18 | ``` 19 | 20 | Let's take a tour of what every file in this hierarchy means: 21 | 22 | * For every year, we provided an updated list of ideas that should inspire you decide what you'd like to work on during summer, the `ideas.md` file. 23 | You can choose from there or you can come up with your own idea; nevertheless, get involved with the community and debate on your project. 24 | 25 | * The `README.md` inside the yearly directory contains information specific to the year we are participating in GSoC: general code of conduct, the proposal template and what is expected of you **before** being accepted as a contributor. 26 | 27 | * Now, onto the `work-product` directory: this is the place where we document what our contributors have worked on during the summer, their progress and more. 28 | It's also where you will post your work (if you are going to be accepted as a contributor) and it will be what your mentor will revise before giving their final feedback. 29 | 30 | * The main `README.md` is what you are reading now: fun stuff! 31 | 32 | * The last piece of the puzzle is the `work-product-template.md` file. 33 | It contains the skeleton that accepted contributors use for their final submission. 34 | 35 | ## Best practices 36 | 37 | First and foremost, read the `README.md` file for the year you are applying in. 38 | Follow the steps documented there as closly as possible: you (literally) get extra points. 39 | 40 | Inspect `ideas.md`. 41 | Get involved with the community regarding your project idea! 42 | 43 | Take a glance at the `work-product` directory: know what to expect after the summer ends, what previous mentees had to do and their involvement with Unikraft. 44 | 45 | Write your proposal, you'll find the template linked in the `README.md` for the year you are applying in. 46 | 47 | Submit your proposal and good luck! 48 | -------------------------------------------------------------------------------- /gsoc-2022/README.md: -------------------------------------------------------------------------------- 1 | # Unikraft at Google Summer of Code 2022 (GSoC'22) 2 | 3 | Make your way into open source developement with operating systems, cloud, virtualization and low-level topics. 4 | Apply to [GSoC22](https://summerofcode.withgoogle.com/) with [Unikraft](https://summerofcode.withgoogle.com/programs/2022/organizations/unikraft). 5 | 6 | [Google Summer of Code 2022](https://summerofcode.withgoogle.com/) (GSoC'22) is a global online program focused on bringing new contributors into open source software development. 7 | GSoC Contributors work with an open source organization, such as Unikraft, on a 12+ week programming project under the guidance of mentors. 8 | 9 | [Unikraft](https://unikraft.org/) is a fast, secure and open-source Unikernel Development Kit. 10 | By tailoring the operating system, libraries and configuration to the particular needs of your application, it vastly reduces virtual machine and container image sizes to a few KBs, provides blazing performance, and drastically cuts down your software stack’s attack surface. 11 | 12 | Before you apply, see the [GSoC contributor eligibility](https://summerofcode.withgoogle.com/get-started). 13 | 14 | ## How to Apply[^1] 15 | 16 | * Connect to the community 17 | * Get accustomed to the Unikraft development ecosystem 18 | * Make a small contribution 19 | * Decide on a GSoC project 20 | * Fill out an application 21 | 22 | ### Connect to the community 23 | 24 | First join our [Discord server](https://bit.ly/UnikraftDiscord). 25 | This is where all (text) discussion and (live video) meetings take place. 26 | You will find multiple channels, each for a particular topic of the Unikraft ecosystem. 27 | 28 | As a newcomer, start by presenting yourself (name, university / occupation, interest in Unikraft, current experience). 29 | It's best if you use a `Firstname Lastname` nickname to make it easy for others to get in touch with you. 30 | 31 | Ask any questions, worry not about anything, we're happy to assist you in feeling at home in the Unikraft community. 32 | In particular, use the `gsoc22` and the `support` channels. 33 | 34 | ### Get accustomed to the Unikraft development ecosystem 35 | 36 | Unikraft development happens on the [Unikaft GitHub organization](https://github.com/unikraft/). 37 | 38 | For starters, check the first 2 sessions in [Unikraft Summer of Code](https://usoc21.unikraft.org/docs/). 39 | These give you a very nice set of initial hands-on tasks to get you started with grabbing, configuring, building and running Unikraft. 40 | Optionally, look into sessions 3, 4 and 5 as well. 41 | 42 | ### Make a small contribution 43 | 44 | The best way to prepare your application is to make small contributions. 45 | 46 | First off, browse the [Unikraft Contribution Guidelines](https://unikraft.org/docs/contributing/). 47 | This gives you an overview of how we expect you to write your code, create commits and make contributions and GitHub pull requests (PRs). 48 | 49 | Then aim for small, easy to do contributions. 50 | Look for items such as: 51 | * Removing build warnings for any of the repositories in the [Unikraft GitHub organization](https://github.com/unikraft/). 52 | * Fixing inconsistencies or adding missing information in the [documentation](https://github.com/unikraft/docs) (rendered on the [main Unikraft website](https://unikraft.org/)). 53 | * Adding [tests](https://unikraft.org/docs/develop/writing-tests/) to Unikraft components. 54 | 55 | ### Decide on a GSoC project 56 | 57 | We put together a [list of project ideas](https://github.com/unikraft/gsoc22/blob/staging/content/en/ideas.md) that you can choose from. 58 | 59 | Note that this is not an exclusive list. 60 | You can suggest new project ideas to the Unikraft GSoC mentors on the `gsoc22` channel on [Discord](https://bit.ly/UnikraftDiscord). 61 | If your idea has been vetted by a mentor (or more) in the community, then you can submit it as part of your application. 62 | 63 | If you fancy a given project idea, ask about that on the `gsoc22` channel on [Discord](https://bit.ly/UnikraftDiscord). 64 | A mentor will reply and give you extra information. 65 | If that is indeed a project you want to work on, then you can submit it as part of your application. 66 | 67 | ### Fill out an application 68 | 69 | Once the application period has opened (in the April 4-19, 2022 period), you have to submit your application on the [Google Summer of Code website](https://summerofcode.withgoogle.com/). 70 | Your application must be written in English. 71 | It should contain a detailed description of your project proposal. 72 | 73 | The application is a document that you will submit and that summarizes your motivation and suitability for the project. 74 | We recommend you copy our [Google Document template](https://docs.google.com/document/d/1TjoRgWMTjB114QlRVc7N5rZ6rswUzEN-JS-G_gB0Bso/edit?usp=sharing) and make sure you answer all of the questions. 75 | 76 | ### Still have some doubts/questions? 77 | 78 | Ask away on [Discord](https://bit.ly/UnikraftDiscord), on the `gsoc22` channel. 79 | 80 | [^1]: Based on the excellent guide from [GNOME](https://gsoc.gnome.org/) 81 | -------------------------------------------------------------------------------- /gsoc-2022/ideas.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Google Summer of Code 2022 Ideas List 3 | --- 4 | 5 | 6 | 7 | ## Unikraft Project Ideas 8 | 9 | Thank you for your interest in participating in [Google Summer of Code 2022 (GSoC22)](https://summerofcode.withgoogle.com/programs/2022)! 10 | 11 | 12 | Unikernels are a novel Operating System (OS) model providing unprecedented optimization for software services. 13 | The technology offers a clean slate OS design which improves the efficiency of cloud services, IoT and embedded system applications by removing unnecessary software layers by specializing the OS image. 14 | One unikernel framework which provides minimal runtime footprint and fast (~35μs) boottimes is Unikraft, and aims as a means to reduce operating costs for all services that utilise it as a runtime mechanism. 15 | 16 | Unikraft is a Unikernel Development Kit and consists of an extensive build system in addition to core and external library ecosystem which facilitate the underlying functionality of a unikernel. 17 | 18 | ## Mentors of the projects 19 | 20 | Mentors will be assigned when the project is initiated. Please feel free to reach out beforehand to discuss the project. 21 | 22 | | Mentor | Email | 23 | |--------|-------| 24 | | [Razvan Deaconescu](https://github.com/razvand) | razvan.deaconescu@cs.pub.ro | 25 | | [Alexander Jung](https://github.com/nderjung) | a.jung@lancs.ac.uk | 26 | | [Simon Kuenzer](https://github.com/skuenzer) | simon.kuenzer@neclab.eu | 27 | | [Felipe Huici](https://github.com/felipehuici) | felipe.huici@neclab.eu | 28 | 29 | Below are a list of open projects for Unikraft which can be developed as part of GSoC22. 30 | 31 | 32 | --- 33 | 34 | ### Lightweight and Scalable VMMs 35 | 36 | | | | 37 | |-|-| 38 | | **Difficulty** | 4/5 | 39 | | **Project Size** | Variable (175 or 350 hours) | 40 | | **Maximum instances** | 1 | 41 | | **Constraints/requirements** | Programming skills in C and Rust. Familiarity with virtio drivers, virtualization, and basic networking concepts is a plus. | 42 | 43 | #### Description 44 | 45 | VMMs (Virtual Machine Monitors) are the software that interacts with the hypervisor to manage the virtual machines running on a host (e.g., QEMU, Firecracker, etc.). 46 | While Unikraft is able to build extremely efficient virtual machines that can boot in a few milliseconds and suspend/resume in the 10s of milliseconds, achieving such numbers partly depends on the efficiency of the VMM, and especially how it scales with an increasing number of Unikraft instances (think thousands on the same server!). 47 | 48 | The work entails adding support to Unikraft for modern, scalable VMMs such as Amazon’s Firecracker and Intel’s Cloud Hypervisor, including the ability to boot Unikraft, suspend/resume its instances and provide networking support when using those VMMs. 49 | In addition, the project would require measuring the performance of such VMMs when running an increasing number of Unikraft instances (e.g., what are their boot times, suspend/resume times, throughput, VMM memory consumption, etc.). 50 | The length of the project (175 vs. 350 hours) can be negotiated based on the number of VMMs supported and which drivers. 51 | 52 | #### Reading & Related Material 53 | 54 | * https://dl.acm.org/doi/10.1145/3447786.3456248 (in particular Figure 10) 55 | * https://firecracker-microvm.github.io/ 56 | * https://github.com/cloud-hypervisor/cloud-hypervisor/ 57 | 58 | 59 | --- 60 | 61 | ### POSIX & Application Support 62 | 63 | | | | 64 | |-|-| 65 | | **Difficulty** | 3/5 | 66 | | **Project Size** | Variable (175 or 350 hours) | 67 | | **Maximum instances** | 1 | 68 | | **Constraints/requirements** | Basic OS concepts, familiarity with POSIX and system calls, build systems and toolstacks. | 69 | 70 | #### Description 71 | 72 | One of the weak points of most unikernel projects has always been weak application support, often requiring that applications be ported to the target unikernel OS. 73 | With Unikraft we have been making a strong push towards POSIX compatibility so that applications can run unmodified on Unikraft. 74 | We have been doing this in two different ways: (1) by adding support to the musl libc library such that applications can be compiled against it, using their native build systems, and then linked into Unikraft and (2) through binary compatibility mode, where unmodified ELFs are directly executed in Unikraft and the resulting syscalls trapped and redirected to Unikraft code. 75 | 76 | This project may consist of, but is not limited to, any of the following items: improving Unikraft’s application support by (1) looking at the state of musl integration and analyzing to what extent unmodified application can be successfully linked and run with Unikraft; (2) conducting an equivalent analysis for binary compatibility mode and/or (3) implementation or extension of syscalls. 77 | The success of this project would provide an enormous boost, we think, to Unikraft adoption. The project length can be varied depending on which of these items are covered by the project. 78 | 79 | 80 | #### Reading & Related Material 81 | 82 | * https://www.musl-libc.org/ 83 | * https://unikraft.org/docs/features/posix-compatibility/ 84 | 85 | 86 | --- 87 | 88 | ### Unikraft & DevOps 89 | 90 | | | | 91 | |-|-| 92 | | **Difficulty** | 3/5 | 93 | | **Project Size** | Variable (175 or 350 hours) | 94 | | **Maximum instances** | 1 | 95 | | **Constraints/requirements** | Strong Linux command-line and tooling experience, Golang, Makefile & C programming skills. | 96 | 97 | #### Description 98 | 99 | With Unikraft, the core pillars of its development are found from its inherent performance, security benefits as well as its integrity. 100 | These properties can be facilitated with CI/CD systems which are designed for modern systems and provide the ability to run checks, tests, and audits for systems before they are deployed. 101 | Thanks to its modular architecture and multi-architecture and multi-platform capabilities, running tests on Unikraft results in many permutations of the same application – resulting in a large and complex CI/CD system. 102 | 103 | The current CI/CD system, based on Concourse, tests many applications against many target arch/plat combinations but only facilitates the construction and but not the execution/runtime of final unikernel images. 104 | This project follows additional implementation and improvements to this system, for example: handling running of unikernels instead of simple builds; static analysis of images to be delivered as reports to GitHub pull requests; regression checks on performance (delivered as % change from the current upstream version); building new tools and instrumentation for presenting, easing, accessing and monitoring the results of the CI/CD for unikernel images (e.g. delivering performance graphs or tables of tests results); code coverage; etc. 105 | 106 | The success of this project would provide an enormous boost, we think, to Unikraft adoption. The project length can be varied depending on which of these items are covered by the project. 107 | 108 | #### Reading & Related Material 109 | 110 | * https://concourse-ci.org/ 111 | * https://builds.unikraft.io/ 112 | * https://unikraft.org/docs/contributing/review-process/ 113 | * https://fosdem.org/2022/schedule/event/massive_unikernel_matrices_with_unikraft_concourse_and_more/ 114 | 115 | 116 | --- 117 | 118 | ### Embedded Devices & Driver Shim Layer 119 | 120 | | | | 121 | |-|-| 122 | | **Difficulty** | 4/5 | 123 | | **Project Size** | Variable (175 or 350 hours) | 124 | | **Maximum instances** | 1 | 125 | | **Constraints/requirements** | C programming skills, OS/driver concepts, familiarity with ARM64 architecture. Experience with ARM64 boards is a plus. | 126 | 127 | #### Description 128 | 129 | Thanks to its modularity, efficiency and support for ARM64, Unikraft is well suited for running on embedded/small devices (e.g., Raspberry Pis, Pine64s, etc). We have done preliminary work to have Unikraft boot on some of these devices, but more work is needed for it to be able to run mainstream applications, frameworks and cool demos. 130 | The main part of the work would consist of building a driver shim layer that would allow Unikraft to transparently re-use unmodified drivers from an existing project (e.g., FreeRTOS) in order to support basic functionality such as networking and sensors. 131 | Time permitting, the project could be extended to include support for other devices as well, and to measure the efficiency of running Unikraft on them versus using mainstream OSes (e.g., Linux). 132 | 133 | #### Reading & Related Material 134 | 135 | * https://ieeexplore.ieee.org/document/9244044 136 | * https://www.freertos.org/ 137 | 138 | 139 | --- 140 | 141 | ### Security Features 142 | 143 | | | | 144 | |-|-| 145 | | **Difficulty** | 4/5 | 146 | | **Project Size** | Variable (175 or 350 hours) | 147 | | **Maximum instances** | 1 | 148 | | **Constraints/requirements** | Good C skills, familiarity with security and hardening features, basic OS knowledge, basic x86 assembly knowledge is a plus. | 149 | 150 | #### Description 151 | 152 | Unikraft should provide the highest level of security to its users. 153 | In order to achieve this, the Unikraft project counts on a combination of unikernels' inherent security properties (minimal attack surface, strong cross-application isolation, safe languages), generic security features matching Linux (ASLR, stack protection, Write-or-Execute, etc.), and state-of-the-art, 154 | fine-grained intra-unikernel compartmentalization. 155 | 156 | As of Unikraft v0.8.0 (Enceladus), the Unikraft main tree features support for a limited range of security features present in Linux such as Stack Smashing Protection (SP), or Undefined Behavior Sanitization (UBSAN). 157 | Top priority planned or ongoing security features include ASLR, shadow stacks, or `FORTIFY_SOURCE`. 158 | Other targets include Intel Control-flow Enforcement Technology (CET), or ARM Speculation Barrier (SB). 159 | 160 | In this security-focused project, you will have the opportunity to contribute towards the implementation and testing efforts of planned security features. In parallel to this, Unikraft features out-of-tree support for intra-unikernel isolation with Intel MPK and EPT. 161 | Interested candidates could also work towards the implementation of additional isolation mechanisms such as Intel SGX or ARM TrustZone. 162 | Project length variable depending on selected features. 163 | 164 | #### Reading & Related Material 165 | 166 | * https://unikraft.org/docs/features/security/ 167 | * https://dl.acm.org/doi/abs/10.1145/3503222.3507759 168 | * https://github.com/a13xp0p0v/linux-kernel-defence-map 169 | 170 | 171 | --- 172 | 173 | ### SMP Synchronization 174 | 175 | | | | 176 | |-|-| 177 | | **Difficulty** | 3/5 | 178 | | **Project Size** | Variable (175 or 350 hours) | 179 | | **Maximum instances** | 1 | 180 | | **Constraints/requirements** | C programming skills, familiarity with typical OS synchronization primitives, understanding of hardware (caching, reordering, atomic instructions). | 181 | 182 | #### Description 183 | 184 | At the moment, Unikraft can leverage a single processor only. While there can be multiple threads (i.e., multiprogramming), no two activities actually run at the same time (i.e., multiprocessing). 185 | With version v0.9.0 Hyperion, Unikraft introduces support for symmetric multiprocessing (SMP), thereby allowing it to execute code on all processors and cores of a system concurrently. This creates new challenges for synchronizing access to shared resources. 186 | On a single-processor machine synchronization primitives like mutexes and semaphores can consider interrupts as the only source of parallel execution. 187 | It is thus sufficient to protect a critical section of code by temporarily disabling interrupts. With SMP, however, this is no longer sufficient as other processors may access shared resources at any time. 188 | 189 | In the first part of the project, you will make Unikraft fit for SMP by developing new SMP-safe synchronization primitives such as mutexes, semaphores, reader-writer locks, and condition variables. 190 | This will enable Unikraft to protect critical sections and lay the foundation for full SMP support of core Unkraft components. 191 | 192 | While locking is effective it is not always the most efficient solution. 193 | Sometimes, for example, when manipulating data structures it can be faster to operate on the data structures directly using atomic instructions. 194 | These lockless data structures can benefit SMP performance. 195 | In the second part of the project, you will therefore extend Unikraft's existing data structures with lockless variants and research alternatives to simple locking such as read-copy-update (RCU). 196 | 197 | 198 | #### Reading & Related Material 199 | 200 | * [Operating Systems: Three Easy Pieces](https://pages.cs.wisc.edu/~remzi/OSTEP/) (Chapter on Concurrency) 201 | * https://dl.acm.org/doi/abs/10.1145/2517349.2522714 202 | * https://wiki.osdev.org/Synchronization_Primitives 203 | * https://www.kernel.org/doc/html/latest/RCU/index.html 204 | 205 | 206 | --- 207 | 208 | ### MSI/MSI-X Interrupt Driver Support (x86, KVM) 209 | 210 | | | | 211 | |-|-| 212 | | **Difficulty** | 3/5 | 213 | | **Project Size** | Variable (175 or 350 hours) | 214 | | **Maximum instances** | 1 | 215 | | **Constraints/requirements** | C programming skills, OS/driver concepts, familiarity with x86 architecture. Experience with interrupt controllers, the PCI standard, and virtio is a plus. | 216 | 217 | #### Description 218 | 219 | Unikraft’s interrupt system on KVM/x86 is based on the legacy 8259 programmable interrupt controller (PIC) which is limited to 15 interrupt lines and programmed using slow port I/O. 220 | Because the interrupt vector space is so small, when having many devices, interrupt lines need to be shared. 221 | The operating system thus has to query multiple drivers to figure out which one is responsible for handling an interrupt on a shared line and which device caused the interruption. This entails reading many device registers, leading to high interrupt latency. 222 | However, in order to achieve high I/O performance, one key is to keep the software overhead of interrupt handlers minimal. 223 | Modern devices (including virtio) even reduce software processing time further by setting up multiple interrupt lines, like one for each I/O queue they provide. 224 | With having just 15 interrupt lines, line sharing happens even with only a few devices attached. 225 | Advanced programmable interrupt controllers (APICs) utilizing the MSI and MSI-X PCI standards overcome this problem by providing a much larger interrupt vector space (currently up to 2048). Interrupt line sharing is thus not required anymore. 226 | 227 | In this project, you will (1) develop a driver for interfacing a modern x86 I/O APIC and extend Unikraft’s libpci to support MSI/MSI-X, and (2) enable the existing virtio drivers to make use of these technologies. 228 | 229 | #### Reading & Related Material 230 | 231 | * [Intel 64 and IA-32 Architectures Software Developer's Manual](https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html) 232 | * https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.html 233 | * https://wiki.osdev.org/Interrupts 234 | * https://wiki.osdev.org/APIC 235 | * https://wiki.osdev.org/PCI#Message_Signaled_Interrupts 236 | * https://habr.com/en/post/501912/ 237 | 238 | 239 | --- 240 | 241 | ### Call-Tree Analysis Tool for confirming ISR property 242 | 243 | | | | 244 | |-|-| 245 | | **Difficulty** | 3/5 | 246 | | **Project Size** | Variable (175 or 350 hours) | 247 | | **Maximum instances** | 1 | 248 | | **Constraints/requirements** | C programming skills, familiarity with the GCC/Clang compiler toolchain, ELF object files, and Makefiles, basic knowledge of OS/drivers and CPU architectures. Programming skills of python and bash is a plus. | 249 | 250 | #### Description 251 | 252 | In Unikraft, we compile monolithic unikernel images. 253 | Since application logic and drivers share the same binary, we must take special care when combining code that can use all CPU features and code that is limited to a basic set of registers. 254 | For example, an interrupt handler must not touch any extended CPU units (e.g., floating point, vector registers) because they are not saved before an interrupt handler is executed and restored on its return, as this would be too costly. 255 | If they would anyway do so, the result would be a corrupted application state leading to undefined behavior or even a system crash. 256 | 257 | Unikraft provides interrupt-safe routines (ISR) for basic primitives and a minimal interrupt-safe libc variant (`lib/isrlib`) that should be used in interrupt-safe functions instead. 258 | Such functions are compiled with different compiler arguments that avoid the usage of extended CPU features. 259 | 260 | The result of this project is an analysis tool that can be integrated into Unikraft’s build system. 261 | Its purpose is to confirm that none of the interrupt-safe routines is ever calling a regular function that is not an ISR function. 262 | To assist developers, the tool should report which function violates this property at the end of or during a compilation. 263 | The project would start with a survey of already existing tools, libraries, or compiler support that could serve as a basis for a static analysis. 264 | In a second step, this static analysis would be implemented on the selected basis and integrated into the Unikraft build system. 265 | 266 | #### Reading & Related Material 267 | 268 | * http://docs.unikraft.org/developers-app.html#makefile-uk (especially isr variant) 269 | * https://github.com/unikraft/unikraft/blob/staging/arch/x86/x86_64/Makefile.uk (ISR_ARCHFLAGS) 270 | * https://github.com/unikraft/unikraft/tree/staging/lib/isrlib 271 | * https://github.com/chaudron/cally (as example for a potential base) 272 | -------------------------------------------------------------------------------- /gsoc-2022/work-product/Maria-Sfiraiala-Shadow-Stack/Maria-Sfiraiala-Shadow-Stack.md: -------------------------------------------------------------------------------- 1 | # Unikraft GSoC'22: Shadow Stack 2 | 3 | 4 | 5 | Software based shadow stacks protect the return value of the functions by comparing what’s pushed into them with what resides in the traditional stack, practically, functioning as a backup and check storage. 6 | 7 | The current implementation aims to bring the compiler based, LLVM `ShadowCallStack` to Unikraft apps. 8 | 9 | What makes this project so different from other approaches is the complexity of the platform it targets. 10 | Unikraft, a Unikernel Development Kit, provides applications that run in a single address space, which means that there is no separation between usermode and kernelmode. 11 | 12 | ![unikraft build system](images/unikraft-build-system.png) 13 | 14 | Thus, traditional means of using the compiler based `ShadowCallStack` can not be applied to Unikraft images. 15 | More exactly, providing a runtime (not yet supported by LLVM's `compiler-rt`) for this security mechanism can not follow the path of using, for instance, the `arch_prctl` syscall, very nicely documented [here](https://gist.github.com/moyix/f2e101348209ddeb7eba903147a867aa). 16 | 17 | Moreover, what's really so interesting about Unikraft is the ability of building images for a plethora of architectures and platforms, ergo, the initial goal of my GSoC project (Shadow Stack for `AArch64` based apps) could easily come to light while maintaining separation and modularity. 18 | 19 | ![unikraft architecture](images/unikraft-architecture.png) 20 | 21 | Following this idea, what had to be accomplished was modifying the bootstraping process (provided by the `ukboot` internal library), by inserting a constructor, whose sole purpose was to initialize the `x18` register with the protected stack. 22 | 23 | Nevertheless, for more complex apps, such as `SQLite`, `Redis` and `Nginx` (already ported to Unikraft), initializing `x18` means altering the scheduling implementation (found in the `uksched` and `ukschedcoop` internal libraries), as multithreading becomes the norm. 24 | 25 | ## GSoC contributor 26 | 27 | Name: Maria Sfiraiala 28 | 29 | Email: 30 | 31 | Github profile: [mariasfiraiala](https://github.com/mariasfiraiala) 32 | 33 | ## Mentors 34 | 35 | [Razvan Deaconescu](https://github.com/razvand) 36 | 37 | [Vlad Badoiu](https://github.com/vladandrew) 38 | 39 | ## Main Contributions 40 | 41 | The biggest part of my work went into crafting the **[Shadow Stack PR](https://github.com/unikraft/unikraft/pull/505)**, which should be upstream once the `0.12 Epimetheus` Unikraft release is out. 42 | 43 | This PR aims to bring Shadow Stack support to both single threaded and multithreading apps, even though work is still pending in order to fix some bugs regarding the multithreading Shadow Stack implementation. 44 | 45 | ## Sidequests 46 | 47 | Besides providing the aforementioned PR, critical to the full integration of my work was ensuring that the most used complex apps on the `AArch64` architecture were functional. 48 | 49 | This matrix, which can also be found [here](https://github.com/mariasfiraiala/scs-work/blob/master/unikraft-scs/unikraft-scs-for-complex-apps.md) 50 | 51 | 52 | | App\Compiler | gcc - x86 | gcc - aarch64 | clang - x86 | clang - aarch64 | clang with scs | gcc-12 with scs | 53 | |--------------|-----------|---------------|-------------|-----------------|----------------|-----------------| 54 | | SQLite | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :soon: | :soon: | 55 | | redis | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :soon: | :soon: | 56 | | nginx | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :soon: | :soon: | 57 | 58 | perfectly describes the efforts made into that direction. 59 | 60 | ### PRs opened by me 61 | 62 | * [Redis documentation PR](https://github.com/unikraft/app-redis/pull/6) 63 | 64 | * [Newlib PR](https://github.com/unikraft/lib-newlib/pull/21) 65 | 66 | * [Core Unikraft TLS PR](https://github.com/unikraft/unikraft/pull/513) 67 | 68 | * [Lwip PR](https://github.com/unikraft/lib-lwip/pull/18) 69 | 70 | 71 | ### PRs reviewed by me 72 | 73 | * [Core Unikraft alignment PR](https://github.com/unikraft/unikraft/pull/530) 74 | 75 | * [Compiler-rt PR](https://github.com/unikraft/lib-compiler-rt/pull/5) 76 | 77 | * [Redis PR](https://github.com/unikraft/lib-redis/pull/6) 78 | 79 | * [Python3 PR](https://github.com/unikraft/lib-python3/pull/6) 80 | 81 | * [Core Unikraft boot stack alignment PR](https://github.com/unikraft/unikraft/pull/533) 82 | 83 | ### Issues opened by me 84 | 85 | * [Newlib limits.h issue](https://github.com/unikraft/lib-newlib/issues/19) 86 | 87 | * [Newlib fcntl.h issue](https://github.com/unikraft/lib-newlib/issues/20) 88 | 89 | * [Core Unikraft TLS issue](https://github.com/unikraft/unikraft/issues/514) 90 | 91 | * [Core Unikraft virtio issue](https://github.com/unikraft/unikraft/issues/518) 92 | 93 | * [Core Unikraft nested macros issue](https://github.com/unikraft/unikraft/issues/532) 94 | 95 | ### Unikraft Summer of Code 2022 96 | 97 | [Unikraft Summer of Code](https://unikraft.org/community/hackathons/usoc22/) is a unikernel and library OS workshop held every summer by the Unikraft community. 98 | 99 | My contributions revolved around both reviewing and updating last year's content for the [Complex Applications session](https://unikraft.org/community/hackathons/usoc22/complex-applications/) and testing the content for the [Contributing to Unikraft session](https://unikraft.org/community/hackathons/usoc22/contributing-to-unikraft/). 100 | 101 | For a better grasp of the work that went into it, check these 2 PRs: 102 | 103 | * [Complex Applications PR](https://github.com/unikraft/docs/pull/102) 104 | 105 | * [Contributing to Unikraft PR](https://github.com/unikraft/docs/pull/96) 106 | 107 | ## Roadmap 108 | 109 | My journey for the second part of the GSoC mentorship was documented [here](https://github.com/mariasfiraiala/scs-work/blob/master/utils/roadmap-scs.md). 110 | 111 | For more detailed timestamps you can check our meeting notes in the Unikraft meeting notes [repo](https://github.com/unikraft/meeting-notes/tree/staging/discussions/gsoc); look for the files with the `ss` prefix (acronym for Shadow Stack). 112 | 113 | ## Blog posts 114 | 115 | During GSoC'22, I provided 3 blog posts which offer a comprehensive status quo for the 3 months that I was involved with Unikraft: 116 | 117 | * [first blog post](https://unikraft.org/blog/2022-07-05-unikraft-gsoc-shadow-stack/) 118 | 119 | * [second blog post](https://unikraft.org/blog/2022-07-20-unikraft-gsoc-shadow-stack/) 120 | 121 | * [third blog post](https://unikraft.org/blog/2022-08-19-unikraft-gsoc-shadow-stack/) 122 | 123 | ## Documentation 124 | 125 | Documenting each and every step I took this summer was also one of my favourite activities. 126 | 127 | The main 3 documents that highlight this passion are: 128 | 129 | * [Shadow Stack for ARM vs x86](https://github.com/mariasfiraiala/scs-work/blob/master/utils/doc-scs-arm-vs-x86.md) 130 | 131 | * [Shadow Stack for simple apps on Unikraft](https://github.com/mariasfiraiala/scs-work/blob/master/unikraft-scs/unikraft-scs-for-helloworld.md) 132 | 133 | * [Shadow Stack for complex apps on Unikraft](https://github.com/mariasfiraiala/scs-work/blob/master/unikraft-scs/unikraft-scs-for-complex-apps.md) 134 | 135 | ## Current status 136 | 137 | My project, even though it followed the initial proposal quite accurately, provides Shadow Stack support for apps without multithreading. 138 | 139 | To be more exact, already implemented Unikraft apps, such as `helloworld`, or any user imported programs that do not use what, in the Unikraft realm, is considered [multithreading](https://unikraft.org/blog/2022-06-27-unikraft-synchronization/#mutex) work with Shadow Stack support. 140 | 141 | As Proof of Concept, I relied on inspecting assembly code using `gdb`: 142 | 143 | 144 | ``` 145 | main (argc=1, argv=0x4013c3d0 ) 146 | at /home/maria/demo/02-hello-world-with-shadow-stack/apps/app-helloworld/main.c:27 147 | 27 { 148 | (gdb) x/i $pc 149 | => 0x40108590
: str x30, [x18], #8 150 | (gdb) si 151 | 0x0000000040108594 27 { 152 | (gdb) x/i $pc 153 | => 0x40108594 : stp x29, x30, [sp, #-48]! 154 | (gdb) x/x $x18 155 | 0x47fc0018: 0x00000000 156 | (gdb) x/x $x30 157 | 0x40113c78 : 0x7100001f 158 | (gdb) x/x 0x47fc0010 159 | 0x47fc0010: 0x40113c78 160 | ``` 161 | 162 | Notice how [`x18` - 8] stores pointer to `x30`, which at this point in time has the return address. 163 | 164 | ## Future work 165 | 166 | The first milestone to be achieved after GSoC'22 comes to an end is having multithreading Shadow Stack support. 167 | 168 | Beautifying and easing the `make build` system for apps for which Unikraft users would like to have Shadow Stack support is also a top priority. 169 | 170 | Reviewing current work done by the community towards modifying the [scheduling API](https://github.com/skuenzer/unikraft/tree/skuenzer/sched-refactor) and updating my implementation to fit these changes takes a big part in my planning for the future 2-3 months. 171 | 172 | Nevertheless, investigating other security mechanisms related to Shadow Stack (such as `CET` and `Safe Stack`) and providing proposals as to how they would be integrated into the Unikraft ecosystem seems to be critical to [Unikraft's security](https://unikraft.org/docs/features/security/), as it heavily relies on the isolation provided by running images in a virtualized medium, without any other significant security mechanisms being involved. 173 | 174 | As a part of my testing work, I also plan on continuing to test Unikraft apps on `AArch64` with various compilers. Some of these apps are: [`app-python3`](https://github.com/unikraft/app-python3), [`app-lua`](https://github.com/unikraft/app-lua), [`app-httpreply`](https://github.com/unikraft/app-httpreply). 175 | 176 | Another thing which should also be achieved is providing a series of patches for `newlib` in order to fix some `gcc`-isms that, for the time being, make the compilation of `AArch64` apps impossible using `clang`. 177 | 178 | ## Main takeaways 179 | 180 | ### Soft skills 181 | 182 | The achievement I am the proudest about is the easiness with which I, now, ask questions. Luckily, I've come to the conclusion that, mostly, people don't bite and having trouble and asking for help isn't such a sin. 183 | 184 | The other accomplishment with which I'm also very happy is the integration among the other members of the community. I am now accustomed with everyone's role in the organization, what are the current tasks carried out by the team, what work is being done at the moment, who to ask about a particular bug. In other words, I've found my place. 185 | 186 | ### Hard skills 187 | 188 | Technologies I got accustomed with: 189 | 190 |
191 | C  192 | AArch64  193 | SQLite  194 | Redis  195 | Nginx  196 | Git  197 | Docker  198 | Markdown  199 |
200 | 201 | ### Final thoughts 202 | 203 | My forever gratitude goes towards my mentors, [Razvan](https://github.com/razvand) and [Vlad](https://github.com/vladandrew) as they truly embodied what a mentor should be. Without them my project wouldn't have been as fun and as close to an end as it is now. 204 | 205 | Many thanks to the people that also looked after me, [Radu](https://github.com/RaduNichita), [Eduard](https://github.com/eduardvintila), [Stefan](https://github.com/StefanJum) and [Cezar](https://github.com/craciunoiuc). 206 | 207 | To the rest of the community I pestered with issues and stupid questions, [Michalis](https://github.com/michpappas), [Marc](https://github.com/marcrittinghaus), [Simon](https://github.com/skuenzer) and [Robert](https://github.com/kubanrob), my sincere apologies and thank you for your patience and willingness to help. -------------------------------------------------------------------------------- /gsoc-2022/work-product/Maria-Sfiraiala-Shadow-Stack/images/unikraft-architecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/unikraft/gsoc/4041e2b0b4e7c41935a983deeb412989e17ad0ab/gsoc-2022/work-product/Maria-Sfiraiala-Shadow-Stack/images/unikraft-architecture.png -------------------------------------------------------------------------------- /gsoc-2022/work-product/Maria-Sfiraiala-Shadow-Stack/images/unikraft-build-system.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/unikraft/gsoc/4041e2b0b4e7c41935a983deeb412989e17ad0ab/gsoc-2022/work-product/Maria-Sfiraiala-Shadow-Stack/images/unikraft-build-system.png -------------------------------------------------------------------------------- /gsoc-2023/README.md: -------------------------------------------------------------------------------- 1 | # Unikraft at Google Summer of Code 2023 (GSoC'23) 2 | 3 | Make your way into open source development with operating systems, cloud, virtualization and low-level topics. 4 | Apply to [GSoC23](https://summerofcode.withgoogle.com/) with [Unikraft](https://summerofcode.withgoogle.com/programs/2023/organizations/unikraft). 5 | 6 | [Google Summer of Code 2023](https://summerofcode.withgoogle.com/) (GSoC'23) is a global online program focused on bringing new contributors into open source software development. 7 | GSoC Contributors work with an open source organization, such as Unikraft, on a 12+ week programming project under the guidance of mentors. 8 | 9 | [Unikraft](https://unikraft.org/) is a fast, secure and open-source Unikernel Development Kit. 10 | By tailoring the operating system, libraries and configuration to the particular needs of your application, it vastly reduces virtual machine and container image sizes to a few KBs, provides blazing performance, and drastically cuts down your software stack’s attack surface. 11 | 12 | Before you apply, see the [GSoC contributor eligibility](https://summerofcode.withgoogle.com/get-started). 13 | 14 | ## How to Apply[^1] 15 | 16 | * Connect to the community 17 | * Get accustomed to the Unikraft development ecosystem 18 | * Make a small contribution 19 | * Decide on a GSoC project 20 | * Fill out an application 21 | 22 | ### Connect to the community 23 | 24 | First join our [Discord server](https://bit.ly/UnikraftDiscord). 25 | This is where all (text) discussion and (live video) meetings take place. 26 | You will find multiple channels, each for a particular topic of the Unikraft ecosystem. 27 | 28 | As a newcomer, start by presenting yourself (name, university / occupation, interest in Unikraft, current experience). 29 | It's best if you use a `Firstname Lastname` nickname to make it easy for others to get in touch with you. 30 | 31 | Ask any questions, worry not about anything, we're happy to assist you in feeling at home in the Unikraft community. 32 | In particular, use the `#gsoc` and the `#support` channels. 33 | 34 | ### Get accustomed to the Unikraft development ecosystem 35 | 36 | Unikraft development happens on the [Unikraft GitHub organization](https://github.com/unikraft/). 37 | 38 | For starters, check the first 2 sessions in [Unikraft Summer of Code](https://unikraft.org/community/hackathons/usoc22/). 39 | These give you a very nice set of initial hands-on tasks to get you started with grabbing, configuring, building and running Unikraft. 40 | Optionally, look into sessions 3, 4 and 5 as well. 41 | 42 | ### Make a small contribution 43 | 44 | The best way to prepare your application is to make small contributions. 45 | 46 | First off, browse the [Unikraft Contribution Guidelines](https://unikraft.org/docs/contributing/). 47 | This gives you an overview of how we expect you to write your code, create commits and make contributions and GitHub pull requests (PRs). 48 | 49 | Then aim for small, easy to do contributions. 50 | Look for items such as: 51 | 52 | * Removing build warnings for any of the repositories in the [Unikraft GitHub organization](https://github.com/unikraft/). 53 | * Fixing inconsistencies or adding missing information in the [documentation](https://github.com/unikraft/docs) (rendered on the [main Unikraft website](https://unikraft.org/)). 54 | * Adding [tests](https://unikraft.org/docs/develop/writing-tests/) to Unikraft components. 55 | * Tasks in the [`Hackathons` GitHub project](https://github.com/orgs/unikraft/projects/29). 56 | * Issues marked with the [`good-first-issue` label](https://github.com/unikraft/unikraft/issues?q=is%3Aissue+is%3Aopen+label%3Agood-first-issue+). 57 | * Adding documentation as `README.md` files and [Doxygen](https://www.doxygen.nl/)-style comments to [internal libraries](https://github.com/unikraft/unikraft/tree/staging/lib). 58 | 59 | ### Decide on a GSoC project 60 | 61 | We put together a [list of project ideas](https://github.com/unikraft/gsoc/blob/staging/gsoc-2023/ideas.md) that you can choose from. 62 | 63 | Note that this is not an exclusive list. 64 | You can suggest new project ideas to the Unikraft GSoC mentors on the `#gsoc` channel on [Discord](https://bit.ly/UnikraftDiscord). 65 | If your idea has been vetted by a mentor (or more) in the community, then you can submit it as part of your application. 66 | 67 | If you fancy a given project idea, ask about that on the `#gsoc` channel on [Discord](https://bit.ly/UnikraftDiscord). 68 | A mentor will reply and give you extra information. 69 | If that is indeed a project you want to work on, then you can submit it as part of your application. 70 | 71 | Also see the [Unikraft OSS Roadmap](https://hackmd.io/@unikraft/HyNdSyAki). 72 | 73 | ### Fill out an application 74 | 75 | Once the application period has opened (in the March 20 - April 4, 2023 period), you have to submit your application on the [Google Summer of Code website](https://summerofcode.withgoogle.com/). 76 | Your application must be written in English. 77 | It should contain a detailed description of your project proposal. 78 | 79 | The application is a document that you will submit and that summarizes your motivation and suitability for the project. 80 | We recommend you copy our [Google Document template](https://docs.google.com/document/d/1TjoRgWMTjB114QlRVc7N5rZ6rswUzEN-JS-G_gB0Bso/edit?usp=sharing) and make sure you answer all the questions. 81 | 82 | ### Still have some doubts/questions? 83 | 84 | Ask away on [Discord](https://bit.ly/UnikraftDiscord), on the `#gsoc` channel. 85 | 86 | [^1]: Based on the excellent guide from [GNOME](https://gsoc.gnome.org/) 87 | -------------------------------------------------------------------------------- /gsoc-2023/ideas.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Google Summer of Code 2023 Ideas List 3 | --- 4 | 5 | ## Unikraft Project Ideas 6 | 7 | Thank you for your interest in participating in [Google Summer of Code 2023 (GSoC23)](https://summerofcode.withgoogle.com/programs/2023)! 8 | 9 | Unikernels are a novel Operating System (OS) model providing unprecedented optimization for software services. 10 | The technology offers a clean slate OS design which improves the efficiency of cloud services, IoT and embedded system applications by removing unnecessary software layers by specializing the OS image. 11 | One unikernel framework which provides minimal runtime footprint and fast (millisecond-level) boot times is Unikraft, and aims as a means to reduce operating costs for all services that utilize it as a runtime mechanism. 12 | 13 | Unikraft is a Unikernel Development Kit and consists of an extensive build system in addition to core and external library ecosystem which facilitate the underlying functionality of a unikernel. 14 | 15 | ## Mentors of the projects 16 | 17 | Mentors will be assigned when the project is initiated. Please feel free to reach out beforehand to discuss the project. 18 | 19 | | Mentor | Email | 20 | |--------|-------| 21 | | [Razvan Deaconescu](https://github.com/razvand) | razvan.deaconescu@upb.ro | 22 | | [Marc Rittinghaus](https://github.com/marcrittinghaus) | marc@unikraft.io | 23 | | [Alexander Jung](https://github.com/nderjung) | alex@unikraft.io | 24 | | [Simon Kuenzer](https://github.com/skuenzer) | simon@unikraft.io | 25 | | [Cezar Crăciunoiu](https://github.com/craciunoiuc) | cezar@unikraft.io | 26 | | [Michalis Pappas](https://github.com/michpappas) | michalis@unikraft.io | 27 | | [Andra Paraschiv](https://github.com/andraprs) | andra@unikraft.io | 28 | | [Ștefan Jumărea](https://github.com/StefanJum) | stefanjumarea02@gmail.com | 29 | | [Maria Sfîrăială](https://github.com/mariasfiraiala) | maria.sfiraiala@gmail.com | 30 | | [Răzvan Vîrtan](https://github.com/razvanvirtan) | virtanrazvan@gmail.com | 31 | | [Radu Nichita](https://github.com/RaduNichita) | radunichita99@gmail.com | 32 | | [Sergiu Moga](https://github.com/mogasergiu) | sergiu.moga@protonmail.com | 33 | 34 | Below are a list of open projects for Unikraft which can be developed as part of GSoC23. 35 | 36 | Also check the [Unikraft OSS Roadmap](https://hackmd.io/@unikraft/HyNdSyAki). 37 | 38 | --- 39 | 40 | ### Expanding the Unikraft Software Support Ecosystem 41 | 42 | | | | 43 | |-|-| 44 | | **Difficulty** | 3/5 | 45 | | **Project Size** | Variable (175 or 350 hours) | 46 | | **Maximum instances** | 2 | 47 | | **Constraints/requirements** | Basic OS concepts, familiarity with POSIX and system calls, build systems and tool stacks. | 48 | 49 | #### Description 50 | 51 | One of the weak points of most unikernel projects has always been application support, often requiring that applications be ported to the target unikernel OS. 52 | With Unikraft we have been making a strong push towards POSIX compatibility so that applications can run unmodified on Unikraft. 53 | We have been doing this in two different ways: 54 | 55 | 1. by adding support for the Musl libc library such that applications can be compiled against it, using their native build systems, and then linked into Unikraft 56 | 1. through binary compatibility mode, where unmodified ELFs are directly executed in Unikraft and the resulting syscalls trapped and redirected to the Unikraft core, via the [`app-elfloader`](https://github.com/unikraft/app-elfloader). 57 | 58 | This project focuses on expanding Unikraft's software support ecosystem by: 59 | 60 | 1. looking at the state of Musl integration and analyzing to what extent unmodified application can be successfully linked and run with Unikraft 61 | 1. conducting an equivalent analysis for binary compatibility mode 62 | 1. implementation or extension of syscalls 63 | 64 | The success of this project will directly impact Unikraft adoption. 65 | The project length can be varied depending on which of these items are covered by the project. 66 | 67 | #### Reading & Related Material 68 | 69 | * https://www.musl-libc.org/ 70 | * https://unikraft.org/docs/features/posix-compatibility/ 71 | 72 | --- 73 | 74 | ### Software Quality Assurance of Unikraft Codebase 75 | 76 | | | | 77 | |-|-| 78 | | **Difficulty** | 3/5 | 79 | | **Project Size** | Variable (175 or 350 hours) | 80 | | **Maximum instances** | 2 | 81 | | **Constraints/requirements** | C programming skills, Linux command-line experience, build tools | 82 | 83 | #### Description 84 | 85 | During its 5 years of existence, Unikraft, now at version 0.12, has grown in features, application support and codebase. 86 | As it matures, a high quality of the code and robust behavior are a must to provide a stable solution for its user base. 87 | 88 | The aim of this project is to assist in the software quality assurance of the Unikraft codebase, by tackling one of the following ideas: 89 | 90 | 1. The use of the [`uktest` framework](https://github.com/unikraft/unikraft/tree/staging/lib/uktest) to create unit tests for [internal libraries](https://github.com/unikraft/unikraft/tree/staging/lib/) and [external libraries](https://github.com/search?q=topic%3Alibrary+org%3Aunikraft+fork%3Atrue&type=repositories). 91 | Not many libraries have unit tests, those that do are mostly exceptions. 92 | This will directly impact the stability of the code base and allow quick validation of new features that may break existing functionality. 93 | 94 | 1. Inclusion of static and dynamic analysis tools that highlight potential spots of faulty or undefined behavior. 95 | 96 | 1. The use of compiler builtins and compiler flags providing constraints on the code to increase its resilience to faulty behavior. 97 | 98 | 1. Augmenting the [CI/CD system used by Unikraft](builds.unikraft.io/) (based on [Concourse](https://concourse-ci.org/)) to feature automatic testing, validation and vetting of contributions to Unikraft repositories: core, libraries, applications. 99 | Potential items are: 100 | 1. handling running of unikernels instead of simple builds 101 | 1. static analysis of images to be delivered as reports to GitHub pull requests 102 | 1. regression checks on performance (delivered as % change from the current upstream version) 103 | 104 | Any other project that is targeted towards increasing the robustness of Unikraft source code is welcome. 105 | These will both increase the viability of Unikraft as a stable solution and increase the quality of future contributions, by enforcing good practices on submitted code. 106 | 107 | #### Reading & Related Material 108 | 109 | * [Writing Tests in Unikraft](https://unikraft.org/docs/develop/writing-tests/) 110 | * https://www.guru99.com/unit-testing-guide.html 111 | * https://docs.kernel.org/dev-tools/kunit/index.html 112 | * https://concourse-ci.org/ 113 | * https://builds.unikraft.io/ 114 | * https://unikraft.org/docs/contributing/review-process/ 115 | * https://fosdem.org/2022/schedule/event/massive_unikernel_matrices_with_unikraft_concourse_and_more/ 116 | 117 | --- 118 | 119 | ### Build-once, Run Anything: Leveraging Unikraft to Run Any Linux Application 120 | 121 | | | | 122 | |-|-| 123 | | **Difficulty** | 2/5 | 124 | | **Project Size** | Variable (175 or 350 hours) | 125 | | **Maximum instances** | 1 | 126 | | **Constraints/requirements** | Go experience, Linux command-line experience, build tools | 127 | 128 | #### Description 129 | 130 | Towards easing the use of Unikraft and leveling-up the user experience of Unikraft, this project aims to enhance [Unikraft's CLI companion tool KraftKit](https://kraftkit.sh) to use unikernels via the use of the [Unikraft ELF loader](https://github.com/unikraft/app-elfloader). 131 | 132 | Kraftkit is the main entry point into the Unikraft world and has been written from scratch in Go and released in December 2022 to replace the now-deprecated version built in Python (known as [`pykraft`](https://github.com/unikraft/pykraft)). 133 | This re-implementation has already eased many previous pains, including enabling faster integration into the wider Cloud Native ecosystem, which Unikraft is targeted to the ELF loader 134 | unikernel. 135 | 136 | The approach will leverage the [ELF loader unikernel](https://github.com/unikraft/app-elfloader) which is based on the idea of binary and POSIX-compatibility which runs unmodified Linux applications atop a unikernel. 137 | The approach is made possible by loading the Linux application as initramfs. 138 | 139 | In this project you will take KraftKit and extend it to build and leverage unikernels based on the ELF loader application and to provide a tight integration with the ELF loader. 140 | The goal is to allow the `kraft` command-line tool to quickly access pre-built ELF loader unikernels so that users do not need to build a new unikernel for any provided Linux application and to to significantly simplify the user experience, making unikernels extremely easy to use, and thus boost bottoms-up adoption. 141 | 142 | #### Reading & Related Material 143 | 144 | * https://github.com/unikraft/kraftkit 145 | * https://github.com/unikraft/app-elfloader 146 | 147 | --- 148 | 149 | ### Enhancing the VSCode Developer Experience 150 | 151 | | | | 152 | |-|-| 153 | | **Difficulty** | 2/5 | 154 | | **Project Size** | Variable (175 or 350 hours) | 155 | | **Maximum instances** | 1 | 156 | | **Constraints/requirements** | TypeScript & Go experience, Linux command-line experience, build tools | 157 | 158 | #### Description 159 | 160 | The [VSCode Extension for Unikraft](https://github.com/unikraft/ide-vscode) enables developers to quickly and painlessly build unikernels from the VSCode IDE. 161 | Amongst other features, it allows developers to list and find Unikernel libraries as well as run basic commands via [`pykraft`](https://github.com/unikraft/pykraft). 162 | 163 | In this project, you will upgrade the VSCode extension to use [KraftKit](https://kraftkit.sh), the newly released CLI companion tool for Unikraft rewritten in Go. 164 | The project requires modifications to the project's main binary, `kraft`, to enable JSON output of various commands so that the integration with VSCode can be done through a machine-readable interface. 165 | 166 | Additionally, the project allows for enhancing the experience, including adding support for additional steps in Unikraft's build cycle; 167 | packaging unikernels in different formats; providing a linting mechanism so that projects which are developed for Unikraft can be checked for compatibility. 168 | 169 | #### Reading & Related Material 170 | 171 | * https://github.com/unikraft/ide-vscode 172 | * https://github.com/unikraft/kraftkit 173 | 174 | --- 175 | 176 | ### Packaging Pre-built Micro-libraries for Faster and More Secure Builds 177 | 178 | | | | 179 | |-|-| 180 | | **Difficulty** | 2/5 | 181 | | **Project Size** | Variable (175 or 350 hours) | 182 | | **Maximum instances** | 1 | 183 | | **Constraints/requirements** | Go experience, Linux command-line experience, build tools | 184 | 185 | #### Description 186 | 187 | Building a Unikraft unikernel is made possible by it's highly modular architecture which enables the use of third-party libraries which offer kernel-level and user-level interfaces for an application. 188 | To make accessing these libraries easier, the companion CLI tool [KraftKit](https://kraftkit.sh) helps managing these libraries, as well as the Unikraft core, their versions and metadata information. 189 | 190 | In this project, you will extend KraftKit to provide additional mechanisms to enable access to pre-built libraries to enable faster builds. 191 | Currently, libraries are accessed from source, either from a remote tarball or Git repository. 192 | To speed up builds, pre-built libraries can be made and delivered before the main build process to speed up the overall build of the unikernel. 193 | 194 | #### Reading & Related Material 195 | 196 | * https://github.com/unikraft/kraftkit 197 | 198 | --- 199 | 200 | ### re:Arch Unikraft 201 | 202 | | | | 203 | |-|-| 204 | | **Difficulty** | 3/5 | 205 | | **Project Size** | Variable (175 or 350 hours) | 206 | | **Maximum instances** | 1 | 207 | | **Constraints/requirements** | C programming skills, good software engineering skills | 208 | 209 | #### Description 210 | 211 | Unikraft provides specialization and strong modularity by strictly following the "everything is a library" concept. 212 | Support for hypervisors, bare metal nodes, and drivers is broken down into individual libraries and only those libraries necessary to run an application on a given target environment (e.g., hypervisor platform) are selected. 213 | 214 | Over time, we noticed that certain code organizations for drivers and platform support are semi-optimal and not clearly defined, creating uncertainty for contributors and maintenance headaches. 215 | In this project you get the opportunity to deeply engage in a restructuring process, understanding the low-level components of the Unikraft's code base, and contribute to the new the code structure guideline. 216 | You will interact directly with core maintainers and work with them on re-structuring and optimizing the code base. In doing so, you will enable much more streamlined upstreaming of additional platforms (e.g., Hyper-V, VMware), CPU architectures (e.g., RISC-V) and drivers. 217 | 218 | #### Reading & Related Material 219 | 220 | * https://unikraft.org/docs/concepts/architecture/ 221 | * https://unikraft.org/docs/concepts/build-process/ 222 | 223 | --- 224 | 225 | ### Embedded Devices & Driver Shim Layer 226 | 227 | | | | 228 | |-|-| 229 | | **Difficulty** | 4/5 | 230 | | **Project Size** | Variable (175 or 350 hours) | 231 | | **Maximum instances** | 1 | 232 | | **Constraints/requirements** | C programming skills, OS/driver concepts, familiarity with ARM64 architecture. Experience with ARM64 boards is a plus. | 233 | 234 | #### Description 235 | 236 | Thanks to its modularity, efficiency and support for ARM64, Unikraft is well suited for running on embedded/small devices (e.g., Raspberry Pis, Pine64s, etc.). We have done preliminary work to have Unikraft boot on some of these devices, but more work is needed for it to be able to run mainstream applications, frameworks and cool demos. 237 | The main part of the work would consist of building a driver shim layer that would allow Unikraft to transparently re-use unmodified drivers from an existing project (e.g., FreeRTOS) in order to support basic functionality such as networking and sensors. 238 | Time permitting, the project could be extended to include support for other devices as well, and to measure the efficiency of running Unikraft on them versus using mainstream OSes (e.g., Linux). 239 | 240 | #### Reading & Related Material 241 | 242 | * https://ieeexplore.ieee.org/document/9244044 243 | * https://www.freertos.org/ 244 | 245 | --- 246 | 247 | ### Driver Probing Framework 248 | 249 | | | | 250 | |-|-| 251 | | **Difficulty** | 3/5 | 252 | | **Project Size** | Variable (175 or 350 hours) | 253 | | **Maximum instances** | 1 | 254 | | **Constraints/requirements** | C programming skills, OS/driver concepts, device tree. | 255 | 256 | #### Description 257 | 258 | Unlike devices connected to enumeration-capable busses like PCI and USB, non-discoverable devices require that the operating system is manually provided with information on their presence, configuration, and their relation to other devices. Some commonly used methods to provide this information are ACPI, FDT (device-tree), or even the kernel's command line. 259 | 260 | This task involves introducing a generic driver probing framework to Unikraft. 261 | At a minimum, the framework must provide a way for drivers to associate themselves to compatible devices, and have these drivers probe devices based on the information provided by the underlying framework (eg FDT). 262 | More complex tasks involve handling device dependencies, deferred probing, and device prioritization. Common cases for such dependencies are clocks and crypto devices. 263 | 264 | The main focus will be on the device-tree, with additional options being available depending on the progress. 265 | 266 | #### Reading & Related Material 267 | 268 | * https://www.devicetree.org/specifications/ 269 | * https://lwn.net/Articles/662820/ 270 | * https://lwn.net/Articles/450460/ 271 | 272 | --- 273 | 274 | ### Unikraft as **the** Secure Configurable Unikernel 275 | 276 | | | | 277 | |-|-| 278 | | **Difficulty** | 4/5 | 279 | | **Project Size** | Variable (175 or 350 hours) | 280 | | **Maximum instances** | 2 | 281 | | **Constraints/requirements** | Good C skills, familiarity with security and hardening features, basic OS knowledge. Basic assembly (x86 / ARM) knowledge is a plus. | 282 | 283 | #### Description 284 | 285 | Unikraft has matured to a featureful unikernel. 286 | Key to its adoption in real world deployments is an extensive set of security features. 287 | 288 | In order to achieve this, Unikraft counts on a combination of unikernels' inherent security properties (minimal attack surface, strong cross-application isolation, safe languages), generic security features matching Linux (ASLR, stack protection, Write-xor-Execute, etc.), and state-of-the-art, fine-grained intra-unikernel compartmentalization. 289 | These are listed in its [Security Benefits](https://unikraft.org/docs/features/security/) page. 290 | 291 | Apart from existing ones, Unikraft must employ all other relevant security features out there. 292 | Top priority planned or ongoing security features include ASLR, shadow stacks and `FORTIFY_SOURCE`. 293 | Other targets include Intel Control-flow Enforcement Technology (CET), or ARM Speculation Barrier (SB). 294 | 295 | Apart from security features, Unikraft could benefit from VM-based isolation features such as ARM Confidential Compute Architecture (CCA), Intel Trust Domain Extensions (TDE) or AMD Secure Encrypted Virtualization (SEV). 296 | 297 | Another idea is the use of static or dynamic analysis techniques for software penetration testing of the Unikraft code base and for its security assessment. 298 | 299 | The goal is to make Unikraft **the** secure configurable unikernel of choice for researchers, professionals and commercial use cases. 300 | By combining its inherent design for specialization with an excellent set of security features, Unikraft will be an easy choice for anyone looking for a fast, secure and efficient unikernel solution. 301 | 302 | #### Reading & Related Material 303 | 304 | * https://unikraft.org/docs/features/security/ 305 | * https://dl.acm.org/doi/abs/10.1145/3503222.3507759 306 | * https://github.com/a13xp0p0v/linux-kernel-defence-map 307 | 308 | --- 309 | 310 | ### MSI/MSI-X Interrupt Driver Support (x86, KVM) 311 | 312 | | | | 313 | |-|-| 314 | | **Difficulty** | 3/5 | 315 | | **Project Size** | Variable (175 or 350 hours) | 316 | | **Maximum instances** | 1 | 317 | | **Constraints/requirements** | C programming skills, OS/driver concepts, familiarity with x86 architecture. Experience with interrupt controllers, the PCI standard, and virtio is a plus. | 318 | 319 | #### Description 320 | 321 | Unikraft's interrupt system on KVM/x86 is based on the legacy 8259 programmable interrupt controller (PIC) which is limited to 15 interrupt lines and programmed using slow port I/O. 322 | Because the interrupt vector space is so small, when having many devices, interrupt lines need to be shared. 323 | The operating system thus has to query multiple drivers to figure out which one is responsible for handling an interrupt on a shared line and which device caused the interruption. 324 | This entails reading many device registers, leading to high interrupt latency. 325 | However, in order to achieve high I/O performance, one key is to keep the software overhead of interrupt handlers minimal. 326 | Modern devices (including virtio) reduce software processing time further by setting up multiple interrupt lines, like one for each I/O queue they provide. 327 | With having just 15 interrupt lines, line sharing happens even with only a few devices attached. 328 | Advanced programmable interrupt controllers (APICs) utilizing the MSI and MSI-X PCI standards overcome this problem by providing a much larger interrupt vector space (currently up to 2048). 329 | Interrupt line sharing is thus not required anymore. 330 | 331 | In this project, you will: 332 | 333 | 1. develop a driver for interfacing a modern x86 I/O APIC and extend Unikraft's libpci to support MSI/MSI-X 334 | 2. enable the existing virtio drivers to make use of these technologies 335 | 336 | #### Reading & Related Material 337 | 338 | * [Intel 64 and IA-32 Architectures Software Developer's Manual](https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html) 339 | * https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.html 340 | * https://wiki.osdev.org/Interrupts 341 | * https://wiki.osdev.org/APIC 342 | * https://wiki.osdev.org/PCI#Message_Signaled_Interrupts 343 | * https://habr.com/en/post/501912/ 344 | 345 | --- 346 | 347 | ### Synchronization Support in Internal Libraries 348 | 349 | | | | 350 | |-|-| 351 | | **Difficulty** | 3/5 | 352 | | **Project Size** | Variable (175 or 350 hours) | 353 | | **Maximum instances** | 1 | 354 | | **Constraints/requirements** | C programming skills, familiarity with typical OS synchronization primitives, understanding of hardware (caching, reordering, atomic instructions). | 355 | 356 | #### Description 357 | 358 | As part of a [GSoC'22 project](https://github.com/unikraft/unikraft/pull/476) Unikraft now features new SMP-safe synchronization primitives such as mutexes, semaphores, reader-writer locks, and condition variables. 359 | This will enable Unikraft to protect critical sections and lay the foundation for full SMP support of core Unkraft components. 360 | 361 | These primitives have not yet been integrated in the Unikraft core libraries. 362 | These libraries need to be made SMP / thread-safe, by redesigning their data structures and making appropriate calls to synchronization primitives. 363 | The goal is to integrate synchronization primitives to ensure SMP safety while preserving a good level of performance. 364 | 365 | While locking is effective it is not always the most efficient solution. 366 | Sometimes, for example, when manipulating data structures it can be faster to operate on the data structures directly using atomic instructions. 367 | These lockless data structures can benefit SMP performance. 368 | One potential item is therefore to extend Unikraft's existing data structures with lockless variants and research alternatives to simple locking such as read-copy-update (RCU). 369 | 370 | #### Reading & Related Material 371 | 372 | * [Operating Systems: Three Easy Pieces](https://pages.cs.wisc.edu/~remzi/OSTEP/) (Chapter on Concurrency) 373 | * https://dl.acm.org/doi/abs/10.1145/2517349.2522714 374 | * https://wiki.osdev.org/Synchronization_Primitives 375 | * https://www.kernel.org/doc/html/latest/RCU/index.html 376 | -------------------------------------------------------------------------------- /gsoc-2023/work-product/Md-Sahil-Enhancing-the-VSCode-Developer-Experience/Md-Sahil-Enhancing-the-Vscode-Developer-Experience.md: -------------------------------------------------------------------------------- 1 | # Unikraft GSoC'23: Enhancing the VSCode Developer Experience 2 | 3 | ### Description 4 | The VS Code Extension for Unikraft enables developers to quickly and painlessly build unikernels from the VS Code IDE. 5 | Amongst other features, it allows developers to list and find unikernel libraries as well as run basic commands. 6 | In this project, I upgraded the VS Code extension to use [KraftKit](https://github.com/unikraft/kraftkit), 7 | the newly released CLI companion tool for Unikraft, written in Go as well as created a few commands for kraftkit. 8 | 9 | ### Preview (Unikraft's vs-code IDE extension usage & working) 10 | 11 | Listing packages available on the system & project directory: 12 | 13 | [listing_packages.webm](https://user-images.githubusercontent.com/85174511/262644232-96730487-ac27-4ab1-820f-d038f76a22cf.webm) 14 | 15 | Adding a package to the project: 16 | 17 | [adding_package.webm](https://user-images.githubusercontent.com/85174511/262644505-a2ba7f3a-961e-4c8c-9ad6-d2fa6a276c65.webm) 18 | 19 | Removing and purging a pakcage: 20 | 21 | [removing&purging_package.webm](https://user-images.githubusercontent.com/85174511/262644742-3a9a4f42-c40a-405f-8670-d34299d63466.webm) 22 | 23 | Fetching dependencies: 24 | 25 | [fetching.webm](https://user-images.githubusercontent.com/85174511/262645570-5c2ad777-329f-49ae-a892-5848983e8202.webm) 26 | 27 | Preparing a project to run: 28 | 29 | [preparing.webm](https://user-images.githubusercontent.com/85174511/262646044-ceb1fc9a-33b7-48c3-bc1c-669db6633c9f.webm) 30 | 31 | Building a project to run: 32 | 33 | [building.webm](https://user-images.githubusercontent.com/85174511/262646200-5901675b-3c25-40a9-8030-6a76254f594e.webm) 34 | 35 | Running a project: 36 | 37 | [running.webm](https://user-images.githubusercontent.com/85174511/262646373-50c39020-f5ff-410f-a8e0-ded1b9856f5c.webm) 38 | 39 | Initialising a library: 40 | 41 | [creating_library.webm](https://user-images.githubusercontent.com/85174511/262646570-0c206a8d-a024-48e9-95ba-3f72786c296a.webm) 42 | 43 | Cleaning a built project: 44 | 45 | [cleaning.webm](https://user-images.githubusercontent.com/85174511/262646945-10c8238c-95c3-48ed-8c9d-a5287bf13fae.webm) 46 | 47 | Cleaning builts properly: 48 | 49 | [proper_cleaning.webm](https://user-images.githubusercontent.com/85174511/262647105-f3d56682-6414-4722-abda-11441b39d39a.webm) 50 | 51 | ## GSoC contributor 52 | Name: Md Sahil 53 | 54 | Email: contact.afsaransari@gmail.com 55 | 56 | Github profile: https://github.com/MdSahil-oss 57 | 58 | ## Contributions 59 | For this project, I made enhancement in two diffrent repositories [Kraftkit](https://github.com/unikraft/kraftkit) and [ide-vscode](https://github.com/unikraft/ide-vscode) of Unikraft. Where Kraftkit repository contains all the enhancements related to CLI commands development and ide-vscode repository contains all enhancements have been made in Unikraft Vscode IDE extension to make it compatible with `Kraftkit` CLI. 60 | 61 | ### PR link in [ide-vscode repository](https://github.com/unikraft/ide-vscode) 62 | - [Update VS Code IDE extension to function properly with new Go-based KraftKit](https://github.com/unikraft/ide-vscode/pull/7) 63 | ### PR links in [kraftkit repository](https://github.com/unikraft/kraftkit/) 64 | - [Configurable output format](https://github.com/unikraft/kraftkit/pull/557/files) 65 | - [Added a subcommand `show` for command `kraft pkg`](https://github.com/unikraft/kraftkit/pull/536) 66 | - [Adds `kraft lib create` support](https://github.com/unikraft/kraftkit/pull/591) 67 | - [Add new subcommand `kraft pkg add`](https://github.com/unikraft/kraftkit/pull/622) 68 | - [Add new subcommand `kraft pkg rm`](https://github.com/unikraft/kraftkit/pull/631) 69 | - [Add subcommand `prune` for the command `kraft pkg`](https://github.com/unikraft/kraftkit/pull/663) 70 | 71 | ## Blog posts 72 | - [First blog post](https://github.com/unikraft/docs/pull/269) 73 | - [Second blog post](https://github.com/unikraft/docs/pull/293) 74 | - [Third blog post](https://github.com/unikraft/docs/pull/303) 75 | - [Forth blog post](https://github.com/unikraft/docs/pull/305) 76 | 77 | ## Current status 78 | The main part of my project is almost done (Only pull requests are pending to be reviewed & merged by mentors), Now IDE extension is working fine with newly created golang based CLI Kraftkit as well as able to execute some new commands that Kraftkit has like `Fetch`, `Prepare`, `Clean` and `Properclean`. 79 | 80 | ## Future work 81 | Some additional tasks are left to be accomplished in this project that are: 82 | * Adding support in Unikraft's build cycle for packaging unikernels in different formats. 83 | * The provisioning of an [LSP](https://code.visualstudio.com/api/language-extensions/language-server-extension-guide) that would allow checks when writing Unikraft code such that relevant libraries are imported or not. 84 | 85 | Once my created PRs get merged I'll start working on these remaining additional tasks one by one beyond GSoC. 86 | -------------------------------------------------------------------------------- /gsoc-2023/work-product/Rares-Miculescu-Plat-Re-Arch/Rares-Miculescu-plat-rearch.md: -------------------------------------------------------------------------------- 1 | # re:Arch Unikraft 2 | 3 | 4 | 5 | ## Summary 6 | 7 | Unikraft is an automated system for building specialized POSIX-compliant OSes, as unikernels. 8 | These unikernels are configured for the needs of specific applications. 9 | Being based on the concept that "everything is a library", Unikraft requires architectural changes that can improve the program’s modularity of its code base, together with improved developer and maintainer experience. 10 | This project consists in the reorganzing of platform and architecture code, through multiple tasks and subtasks. 11 | For example, the code is organised in multiple sections. 12 | Three out of five directories contain libraries. 13 | The sections describe the purpose of the libraries in detail. 14 | Based on conventions and ease of work, some libraries were moved to other sections (drivers) or new ones were created, with code that was not part of a library (e.g. `ukintctlr`). 15 | 16 | ## GSoC contributor 17 | 18 | Name: Rares Miculescu 19 | 20 | Email: 21 | 22 | Github profile: [rares-miculescu](https://github.com/rares-miculescu) 23 | 24 | ## Mentors 25 | 26 | * [Razvan Deaconescu](https://github.com/razvand) 27 | * [Simon Kuenzer](https://github.com/skuenzer) 28 | * [Sergiu Moga](https://github.com/mogasergiu) 29 | * [Michalis Pappas](https://github.com/michpappas) 30 | * [Marc Rittinghaus](https://github.com/marcrittinghaus) 31 | 32 | ## Contributions 33 | 34 | My contributions consist in working on migrating drivers, compiler definitions, registers and data types. 35 | At the momment, Unikraft uses `stdint.h` as library for data types. 36 | Because we need to be independent from any external libraries, it was decided to define our own data types and correct all the files. 37 | 38 | There are several drivers which provide hardware-centric low-level implementation, that are scattered around the filesystem. 39 | These drivers should be all in the same place. 40 | 41 | The work can be found here: 42 | 43 | * [plat: Move register definitions into arch](https://github.com/unikraft/unikraft/pull/937) 44 | 45 | * [doc: Replaced libc types with unikraft defined](https://github.com/unikraft/unikraft/pull/954) 46 | 47 | * [include/uk: Move compiler definitions from essentials.h to compiler.h](https://github.com/unikraft/unikraft/pull/960) 48 | 49 | * [lib: Add ofw from plat/drivers to lib](https://github.com/unikraft/unikraft/pull/966) 50 | 51 | * [plat: Migrate gic to drivers/ukintctlr](https://github.com/unikraft/unikraft/pull/971) 52 | 53 | * [drivers: Moving virtio from plat/drivers/ to drivers/](https://github.com/unikraft/unikraft/pull/967) 54 | 55 | * [plat: Migrate rtc pl031 to drivers/ukrtc/](https://github.com/unikraft/unikraft/pull/972) 56 | 57 | ## Blog posts 58 | 59 | You can find my blog posts here: 60 | 61 | * [Blog post #1](https://github.com/unikraft/docs/pull/268) 62 | 63 | * [Blog post #2](https://github.com/unikraft/docs/pull/289) 64 | 65 | * [Blog post #3](https://github.com/unikraft/docs/pull/302) 66 | 67 | * [Blog post #4](https://github.com/unikraft/docs/pull/307) 68 | 69 | ## Current status 70 | 71 | Besides creating a pull request with the definition of data types, the work is done. 72 | The pull requests need to be reviewed by the mentors. 73 | 74 | ## Future work 75 | 76 | The project is far from finished, so I will keep working on other tasks that need to be done, alongside other members of Unikraft. 77 | One task that we were discussing on proceeding after the merge of the pull requests, is the future `ukboot` part of plat re-arch. 78 | I plan to assist in other platform / architecture-related work as well, such as the addition of new platforms (VMware / Hyper-V) or new architectures (RISC-V). 79 | -------------------------------------------------------------------------------- /gsoc-2023/work-product/Xingjian-Zhang-Arm-CCA-Support/Xingjian-Zhang-Arm-CCA-Support.md: -------------------------------------------------------------------------------- 1 | # Arm CCA Support for Unikraft 2 | 3 | ## GSoC Contributor 4 | 5 | * **Name:** Xingjian Zhang 6 | * **Email:** zhxj9823@gmail.com 7 | * **Github profile:** [@zhxj9823](https://github.com/zhxj9823/) 8 | 9 | ## Mentors 10 | 11 | * [Michalis Pappas](https://github.com/michpappas) 12 | * [Hugo Lefeuvre](https://github.com/hlef) 13 | * [Răzvan Vîrtan](https://github.com/razvanvirtan) 14 | * [Maria Sfîrăială](https://github.com/mariasfiraiala) 15 | * [Vlad Bădoiu](https://github.com/vladandrew) 16 | 17 | ## Contributions 18 | 19 | ### Project Description 20 | 21 | [Arm CCA](https://www.arm.com/architecture/security-features/arm-confidential-compute-architecture) introduces the Realm Management Extension (RME), which extends [Arm TrustZone technology](https://www.arm.com/technologies/trustzone-for-cortex-a) with two new security states: the `realm` state and the `root` state. 22 | Instead of running a VM in the normal world, the CCA can run a VM in the realm state. 23 | The realm state constructs protected execution environments called realms, which protect the data in the realms from other components. 24 | This architecture allows the hypervisor to control the VM but removes the right for access to that VM. 25 | The following figure shows the system architecture of Arm CCA. 26 | **The primary goal of this project is to bring Arm CCA support to Unikraft, so it can run as a realm VM.** 27 | 28 | ![Arm CCA architecture](images/cca-arch.png) 29 | 30 | ### Arm CCA Support for Unikraft 31 | 32 | The main contributions of this project are in [PR #964](https://github.com/unikraft/unikraft/pull/964), which adds necessary modifications to Unikraft to support Arm CCA. 33 | The work can be categorized into three main parts. 34 | 35 | #### Changes to the Bootflow 36 | 37 | To use Unikraft in the realm world, we need to make some changes to the bootflow. 38 | The changes include the detection of RSI interfaces, setup of the realm memory region, and the marking of device memory regions as unprotected. 39 | 40 | #### Implementing `ukrsi` 41 | 42 | The latest [Realm Management Monitor specification](https://developer.arm.com/documentation/den0137/latest/) specifies the RSI commands, which provide certain functionalities for the realm VM. 43 | A new `ukrsi` under `drivers/arm-cca` implements all these commands: 44 | 45 | * `RSI_ATTESTATION_TOKEN_CONTINUE` 46 | * `RSI_ATTESTATION_TOKEN_INIT` 47 | * `RSI_HOST_CALL` 48 | * `RSI_IPA_STATE_GET` 49 | * `RSI_IPA_STATE_SET` 50 | * `RSI_MEASUREMENT_EXTEND` 51 | * `RSI_MEASUREMENT_READ` 52 | * `RSI_REALM_CONFIG` 53 | * `RSI_VERSION` 54 | 55 | #### Application Compatibility 56 | 57 | To demonstrate the use of Unikraft in the realm world, we bring several applications to the realm world. 58 | Launching an application in the realm world uses kvmtool, so we need to make applications compatible with kvmtool and the realm world. 59 | Currently, `app-helloworld`, `app-sqlite`, `app-httpreply`, `app-redis` can work with kvmtool. 60 | These applications leverage various devices, including the serial console, the `initrd` filesystem, and the networking device. 61 | Besides, `app-helloworld` and `app-sqlite` with initrd can work in the realm world, while other applications require additional support. 62 | 63 | ### Other PRs 64 | 65 | In addition to my main contribution of bringing Arm CCA support to Unikraft, I also contributed to other PRs in the Unikraft repository. 66 | These PRs address issues that I encountered when trying to make applications compatible with kvmtool. 67 | 68 | #### Merged PRs 69 | 70 | * [PR #970](https://github.com/unikraft/unikraft/pull/970) fixes an issue relating to unaligned read and write operations in `virtio_mmio`. 71 | * [PR #985](https://github.com/unikraft/unikraft/pull/985) adds two configurations to `ns16550`, so the serial driver can suit more use cases. 72 | * [PR #1059](https://github.com/unikraft/unikraft/pull/1059) swaps the last two arguments of `virtio_9p_feature_negotiate`'s first call to `virtio_config_get`. 73 | 74 | #### Pending PRs 75 | 76 | * [PR #986](https://github.com/unikraft/unikraft/pull/986) migrates console APIs into a new `libuktty`. 77 | 78 | ## Blog Posts 79 | 80 | - [First blog post](https://unikraft.org/blog/2023-06-23-unikraft-gsoc-arm-cca-1/) 81 | - [Second blog post](https://github.com/unikraft/docs/pull/287) 82 | - [Third blog post](https://github.com/unikraft/docs/pull/301) 83 | - [Forth blog post](https://github.com/unikraft/docs/pull/310) 84 | 85 | ## Documentation 86 | 87 | A more detailed documentation of `ukrsi` is in `drivers/arm-cca/ukrsi/README.md`, which decribes the implementation of `ukrsi` and how to use it. 88 | 89 | ## Current Status 90 | 91 | The table below summarizes the compatibility of applications with different environments. 92 | Three environments are considered: applications running in a native ARM64 machine using kvmtool, applications running in the normal world on FVP, and applications running in the realm world on FVP. 93 | 94 | | Applications | native kvmtool | kvmtool in FVP | Realm world | 95 | |-------------------------------------------------------------------- |:--------------: |:--------------: |:-----------: | 96 | | [`app-helloworld`](https://github.com/unikraft/app-helloworld) | Y | Y | Y | 97 | | [`app-httpreply`](https://github.com/unikraft/app-httpreply) | Y | N | N | 98 | | [`app-sqlite`](https://github.com/unikraft/app-sqlite) with initrd | Y | Y | Y | 99 | | [`app-sqlite`](https://github.com/unikraft/app-sqlite) with 9pfs | Y | Y | N | 100 | | [`app-redis`](https://github.com/unikraft/app-redis) | Y | N | N | 101 | 102 | ## Future Work 103 | 104 | While, my GSoC project journey is coming to an end, my work on Arm CCA support for Unikraft is not. 105 | As some applications do not work in the realm world, I will continue to work on making them work. 106 | Besides, as the Arm CCA technology continues to evolve, I will continue to improve its support for Unicraft. 107 | 108 | ## Acknowledgements 109 | 110 | Thanks to all my mentors and the Unikraft community for their guidance and support. 111 | -------------------------------------------------------------------------------- /gsoc-2023/work-product/Xingjian-Zhang-Arm-CCA-Support/images/cca-arch.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/unikraft/gsoc/4041e2b0b4e7c41935a983deeb412989e17ad0ab/gsoc-2023/work-product/Xingjian-Zhang-Arm-CCA-Support/images/cca-arch.png -------------------------------------------------------------------------------- /gsoc-2024/README.md: -------------------------------------------------------------------------------- 1 | # Unikraft at Google Summer of Code 2024 (GSoC'24) 2 | 3 | Make your way into open source development with operating systems, cloud, virtualization and low-level topics. 4 | Apply to [GSoC24](https://summerofcode.withgoogle.com/) with [Unikraft](https://summerofcode.withgoogle.com/programs/2024/organizations/unikraft). 5 | 6 | [Google Summer of Code 2024](https://summerofcode.withgoogle.com/) (GSoC'24) is a global online program focused on bringing new contributors into open source software development. 7 | GSoC Contributors work with an open source organization, such as Unikraft, on a 12+ week programming project under the guidance of mentors. 8 | 9 | [Unikraft](https://unikraft.org/) is a fast, secure and open-source Unikernel Development Kit. 10 | By tailoring the operating system, libraries and configuration to the particular needs of your application, it vastly reduces virtual machine and container image sizes to a few KBs, provides blazing performance, and drastically cuts down your software stack’s attack surface. 11 | 12 | Before you apply, see the [GSoC contributor eligibility](https://summerofcode.withgoogle.com/get-started). 13 | 14 | ## How to Apply[^1] 15 | 16 | * Connect to the community 17 | * Get accustomed to the Unikraft development ecosystem 18 | * Make a small contribution 19 | * Decide on a GSoC project 20 | * Fill out an application 21 | 22 | ### Connect to the community 23 | 24 | First join our [Discord server](https://bit.ly/UnikraftDiscord). 25 | This is where all (text) discussion and (live video) meetings take place. 26 | You will find multiple channels, each for a particular topic of the Unikraft ecosystem. 27 | 28 | As a newcomer, start by presenting yourself (name, university / occupation, interest in Unikraft, current experience). 29 | It's best if you use a `Firstname Lastname` nickname to make it easy for others to get in touch with you. 30 | 31 | Ask any questions, worry not about anything, we're happy to assist you in feeling at home in the Unikraft community. 32 | In particular, use the `#gsoc` and the `#support` channels. 33 | 34 | ### Get accustomed to the Unikraft development ecosystem 35 | 36 | Unikraft development happens on the [Unikraft GitHub organization](https://github.com/unikraft/). 37 | 38 | For starters, check the [guides](https://unikraft.org/guides) on using the [`catalog` repository](https://github.com/unikraft/catalog). 39 | These give you a very nice set of initial hands-on tasks to get you started with grabbing, configuring, building and running Unikraft. 40 | Look into other [guides](https://unikraft.org/guides) as well.j 41 | 42 | ### Make a small contribution 43 | 44 | The best way to prepare your application is to make small contributions. 45 | 46 | First off, browse the [Unikraft Contribution Guidelines](https://unikraft.org/docs/contributing/). 47 | This gives you an overview of how we expect you to write your code, create commits and make contributions and GitHub pull requests (PRs). 48 | 49 | Then aim for small, easy to do contributions. 50 | Look for items such as: 51 | 52 | * Removing build warnings for any of the repositories in the [Unikraft GitHub organization](https://github.com/unikraft/). 53 | * Fixing inconsistencies or adding missing information in the [documentation](https://github.com/unikraft/docs) (rendered on the [main Unikraft website](https://unikraft.org/)). 54 | * Adding [tests](https://unikraft.org/docs/develop/writing-tests/) to Unikraft components. 55 | * Tasks in the [`Hackathons` GitHub project](https://github.com/orgs/unikraft/projects/29). 56 | * Issues marked with the [`good-first-issue` label](https://github.com/unikraft/unikraft/issues?q=is%3Aissue+is%3Aopen+label%3Agood-first-issue+). 57 | * Adding documentation as `README.md` files and [Doxygen](https://www.doxygen.nl/)-style comments to [internal libraries](https://github.com/unikraft/unikraft/tree/staging/lib). 58 | 59 | ### Decide on a GSoC project 60 | 61 | We put together a [list of project ideas](https://github.com/unikraft/gsoc/blob/staging/gsoc-2024/ideas.md) that you can choose from. 62 | 63 | Note that this is not an exclusive list. 64 | You can suggest new project ideas to the Unikraft GSoC mentors on the `#gsoc` channel on [Discord](https://bit.ly/UnikraftDiscord). 65 | If your idea has been vetted by a mentor (or more) in the community, then you can submit it as part of your application. 66 | 67 | If you fancy a given project idea, ask about that on the `#gsoc` channel on [Discord](https://bit.ly/UnikraftDiscord). 68 | A mentor will reply and give you extra information. 69 | If that is indeed a project you want to work on, then you can submit it as part of your application. 70 | 71 | Also see the [Unikraft OSS Roadmap](https://hackmd.io/@unikraft/HyNdSyAki). 72 | 73 | ### Fill out an application 74 | 75 | Once the application period has opened (in the March 18 - April 2, 2024 period), you have to submit your application on the [Google Summer of Code website](https://summerofcode.withgoogle.com/). 76 | Your application must be written in English. 77 | It should contain a detailed description of your project proposal. 78 | 79 | The application is a document that you will submit and that summarizes your motivation and suitability for the project. 80 | We recommend you copy our [Google Document template](https://docs.google.com/document/d/1TjoRgWMTjB114QlRVc7N5rZ6rswUzEN-JS-G_gB0Bso/edit?usp=sharing) and make sure you answer all the questions. 81 | 82 | ### Still have some doubts/questions? 83 | 84 | Ask away on [Discord](https://bit.ly/UnikraftDiscord), on the `#gsoc` channel. 85 | 86 | [^1]: Based on the excellent guide from [GNOME](https://gsoc.gnome.org/) 87 | -------------------------------------------------------------------------------- /gsoc-2024/ideas.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Google Summer of Code 2024 Ideas List 3 | --- 4 | 5 | ## Unikraft Project Ideas 6 | 7 | Thank you for your interest in participating in [Google Summer of Code 2024 (GSoC24)](https://summerofcode.withgoogle.com/programs/2024)! 8 | 9 | Unikernels are a novel Operating System (OS) model providing unprecedented optimization for software services. 10 | The technology offers a clean slate OS design which improves the efficiency of cloud services, IoT and embedded system applications by removing unnecessary software layers by specializing the OS image. 11 | One unikernel framework which provides minimal runtime footprint and fast (millisecond-level) boot times is Unikraft, and aims as a means to reduce operating costs for all services that utilize it as a runtime mechanism. 12 | 13 | Unikraft is a Unikernel Development Kit and consists of an extensive build system in addition to core and external library ecosystem which facilitate the underlying functionality of a unikernel. 14 | 15 | ## Mentors of the projects 16 | 17 | Mentors will be assigned when the project is initiated. Please feel free to reach out beforehand to discuss the project. 18 | 19 | | Mentor | Email | 20 | |--------|-------| 21 | | [Razvan Deaconescu](https://github.com/razvand) | razvan.deaconescu@upb.ro | 22 | | [Alexander Jung](https://github.com/nderjung) | alex@unikraft.io | 23 | | [Simon Kuenzer](https://github.com/skuenzer) | simon@unikraft.io | 24 | | [Cezar Crăciunoiu](https://github.com/craciunoiuc) | cezar@unikraft.io | 25 | | [Michalis Pappas](https://github.com/michpappas) | michalis@unikraft.io | 26 | | [Ștefan Jumărea](https://github.com/StefanJum) | stefanjumarea02@gmail.com | 27 | | [Maria Sfîrăială](https://github.com/mariasfiraiala) | maria.sfiraiala@gmail.com | 28 | | [Răzvan Vîrtan](https://github.com/razvanvirtan) | virtanrazvan@gmail.com | 29 | | [Radu Nichita](https://github.com/RaduNichita) | radunichita99@gmail.com | 30 | | [Sergiu Moga](https://github.com/mogasergiu) | sergiu.moga@protonmail.com | 31 | 32 | Below are a list of open projects for Unikraft which can be developed as part of GSoC24. 33 | 34 | Also check the [Unikraft OSS Roadmap](https://hackmd.io/@unikraft/HyNdSyAki). 35 | 36 | --- 37 | 38 | ### Expanding the Unikraft Software Support Ecosystem 39 | 40 | | | | 41 | |-|-| 42 | | **Difficulty** | 3/5 | 43 | | **Project Size** | Variable (175 or 350 hours) | 44 | | **Maximum instances** | 2 | 45 | | **Constraints/requirements** | Basic OS concepts, familiarity with POSIX and system calls, build systems and tool stacks. | 46 | 47 | #### Description 48 | 49 | One of the weak points of most unikernel projects has always been application support, often requiring that applications be ported to the target unikernel OS. 50 | With Unikraft we have been making a strong push towards POSIX compatibility so that applications can run unmodified on Unikraft. 51 | We have been doing this in two different ways: 52 | 53 | 1. by adding support for the Musl libc library such that applications can be compiled against it, using their native build systems, and then linked into Unikraft 54 | 1. through [binary-compatibility mode](), where unmodified ELFs are directly executed in Unikraft and the resulting syscalls trapped and redirected to the Unikraft core, via the [`app-elfloader`](https://github.com/unikraft/app-elfloader). 55 | 56 | This has lead to the creation of the [application `catalog` repository](https://github.com/unikraft/catalog) where running applications and examples are brought together. 57 | 58 | This project focuses on expanding Unikraft's software support ecosystem by [adding new applications](https://unikraft.org/docs/contributing/adding-to-the-app-catalog) to the [application `catalog` repository](https://github.com/unikraft/catalog), primarily in binary-compatibility mode. 59 | While doing this, you will also: 60 | 61 | 1. implement and extend system calls 62 | 1. add extensive testing for the application or framework that is to be included in the catalog 63 | 1. add benchmarking scripts to measure the performance and resource consumption of the application running with Unikraft 64 | 1. conduct synthetic tests using tools such as [the Linux Test Project](https://linux-test-project.github.io/) 65 | 66 | The success of this project will directly impact Unikraft adoption. 67 | The project length can be varied depending on which of these items are covered by the project. 68 | 69 | #### Reading & Related Material 70 | 71 | * https://www.musl-libc.org/ 72 | * https://unikraft.org/guides/using-the-app-catalog 73 | * https://github.com/unikraft/catalog 74 | * https://unikraft.org/docs/contributing/adding-to-the-app-catalog 75 | 76 | --- 77 | 78 | ### Software Quality Assurance of Unikraft Codebase 79 | 80 | | | | 81 | |-|-| 82 | | **Difficulty** | 3/5 | 83 | | **Project Size** | Variable (175 or 350 hours) | 84 | | **Maximum instances** | 2 | 85 | | **Constraints/requirements** | C programming skills, Linux command-line experience, build tools | 86 | 87 | #### Description 88 | 89 | During its 6 years of existence, Unikraft, now at version 0.16.1, has grown in features, application support and codebase. 90 | As it matures, a high quality of the code and robust behavior are a must to provide a stable solution for its user base. 91 | 92 | The aim of this project is to assist in the software quality assurance of the Unikraft codebase, by tackling one of the following ideas: 93 | 94 | 1. The use of the [`uktest` framework](https://github.com/unikraft/unikraft/tree/staging/lib/uktest) to create unit tests for [internal libraries](https://github.com/unikraft/unikraft/tree/staging/lib/) and [external libraries](https://github.com/search?q=topic%3Alibrary+org%3Aunikraft+fork%3Atrue&type=repositories). 95 | Not many libraries have unit tests, those that do are mostly exceptions. 96 | This will directly impact the stability of the code base and allow quick validation of new features that may break existing functionality. 97 | 98 | 1. Inclusion of static and dynamic analysis tools that highlight potential spots of faulty or undefined behavior. 99 | 100 | 1. The use of compiler builtins and compiler flags providing constraints on the code to increase its resilience to faulty behavior. 101 | 102 | 1. Augmenting the CI/CD system used by Unikraft (based on [GitHub Actions](https://github.com/features/actions)) to feature automatic testing, validation and vetting of contributions to Unikraft repositories: core, libraries, applications. 103 | Potential items are: 104 | 1. handling running of unikernels instead of simple builds 105 | 1. static analysis of images to be delivered as reports to GitHub pull requests 106 | 1. regression checks on performance (delivered as % change from the current upstream version) 107 | 108 | Any other project that is targeted towards increasing the robustness of Unikraft source code is welcome. 109 | These will both increase the viability of Unikraft as a stable solution and increase the quality of future contributions, by enforcing good practices on submitted code. 110 | 111 | #### Reading & Related Material 112 | 113 | * [Writing Tests in Unikraft](https://unikraft.org/docs/develop/writing-tests/) 114 | * https://www.guru99.com/unit-testing-guide.html 115 | * https://docs.kernel.org/dev-tools/kunit/index.html 116 | * https://github.com/features/actions 117 | * https://unikraft.org/docs/contributing/review-process/ 118 | 119 | ### Supporting User-provided, Long-lived Environmental Variables for Unikraft Builds 120 | 121 | | | | 122 | |-|-| 123 | | **Difficulty** | 2/5 | 124 | | **Project Size** | Small (90 hours) | 125 | | **Maximum instances** | 1 | 126 | | **Constraints/requirements** | Good Go skills, familiarity with build tools, good OS knowledge | 127 | 128 | #### Description 129 | 130 | Unikraft is a highly modular library operating system designed for the cloud. 131 | Its high degree of modularization allows for extreme customization and specialization. 132 | As such, its tooling should not interfere with the user's desire to support such customization. 133 | Towards increasing the unikernel's developer's ability to customize the build whilst simultaneously systemitizing the process of retrieving, organizing and generally facilitating the build of a unikernel based on Unikraft and its many components, the supported tooling, [kraft](https://github.com/unikraft/kraftkit), should allow for the injection of the user's environment and or additional toolchain requirements. 134 | 135 | This project is designed to better facilitate the dynamic injection of user provided variables into Unikraft's build system through the addition of a dynamically configured toolchain towards greater customization of the unikernel build through the use of its command-line companion client tool, `kraft`. 136 | This manifests itself as an injection into KraftKit's core configuration system and must propagate across the codebase appropriately. 137 | 138 | Distinct results of this addition would enable, but are not limited to: alternating the GNU Compiler Collection (GCC) version, providing alternative compile-time flags, and more. 139 | 140 | #### Reading & Related Material 141 | 142 | * https://github.com/unikraft/kraftkit/issues/673 143 | 144 | ### Supporting macOS networking (medium-large, 175-350hrs) 145 | 146 | | | | 147 | |-|-| 148 | | **Difficulty** | 3/5 | 149 | | **Project Size** | Variable (175 or 350 hours) | 150 | | **Maximum instances** | 1 | 151 | | **Constraints/requirements** | Good Go skills, familiarity with virtualization, macOS and networking, good OS knowledge | 152 | 153 | #### Description 154 | 155 | [KraftKit](https://github.com/unikraft/kraftkit), the supporting codebase for the modular library operating system Unikraft designed for cloud native applications, provides users with the ability to build, package and run unikernels. 156 | As a swiss-army-knife of unikernel development, it eases both the construction and deployment of unikernels. 157 | To this end, supporting diverse user environments and their ability to run unikernels locally supports the ultimate goal of the project. One such environment which requires more attention is macOS. 158 | 159 | Towards better facilitating the execution of unikernel virtual machine images on macOS, this project aims to introduce new packages which interface directly with macOS environments by interfacing natively with the local networking environment such that the execution of unikernels is accessible through a more direct communication mechanisms of the host. 160 | Until now, the project only supports Linux bridge networking with accommodation (albeit "stubs") in the codebase for Darwin. 161 | 162 | #### Reading & Related Material 163 | 164 | * https://github.com/unikraft/kraftkit/issues/841 165 | 166 | --- 167 | 168 | ### Unikraft as **the** Secure Configurable Unikernel 169 | 170 | | | | 171 | |-|-| 172 | | **Difficulty** | 4/5 | 173 | | **Project Size** | Variable (175 or 350 hours) | 174 | | **Maximum instances** | 2 | 175 | | **Constraints/requirements** | Good C skills, familiarity with security and hardening features, basic OS knowledge. Basic assembly (x86 / ARM) knowledge is a plus. | 176 | 177 | #### Description 178 | 179 | Unikraft has matured to a featureful unikernel. 180 | Key to its adoption in real world deployments is an extensive set of security features. 181 | 182 | In order to achieve this, Unikraft counts on a combination of unikernels' inherent security properties (minimal attack surface, strong cross-application isolation, safe languages), generic security features matching Linux (ASLR, stack protection, Write-xor-Execute, etc.), and state-of-the-art, fine-grained intra-unikernel compartmentalization. 183 | These are listed in its [Security Benefits](https://unikraft.org/docs/features/security/) page. 184 | 185 | Apart from existing ones, Unikraft must employ all other relevant security features out there. 186 | Top priority planned or ongoing security features include ASLR, shadow stacks and `FORTIFY_SOURCE`. 187 | Other targets include Intel Control-flow Enforcement Technology (CET), or ARM Speculation Barrier (SB). 188 | 189 | Another idea is the use of static or dynamic analysis techniques for software penetration testing of the Unikraft code base and for its security assessment. 190 | 191 | The goal is to make Unikraft **the** secure configurable unikernel of choice for researchers, professionals and commercial use cases. 192 | By combining its inherent design for specialization with an excellent set of security features, Unikraft will be an easy choice for anyone looking for a fast, secure and efficient unikernel solution. 193 | 194 | #### Reading & Related Material 195 | 196 | * https://unikraft.org/docs/features/security/ 197 | * https://dl.acm.org/doi/abs/10.1145/3503222.3507759 198 | * https://github.com/a13xp0p0v/linux-kernel-defence-map 199 | 200 | --- 201 | 202 | ### Synchronization Support in Internal Libraries 203 | 204 | | | | 205 | |-|-| 206 | | **Difficulty** | 3/5 | 207 | | **Project Size** | Variable (175 or 350 hours) | 208 | | **Maximum instances** | 1 | 209 | | **Constraints/requirements** | C programming skills, familiarity with typical OS synchronization primitives, understanding of hardware (caching, reordering, atomic instructions). | 210 | 211 | #### Description 212 | 213 | As part of a [GSoC'22 project](https://github.com/unikraft/unikraft/pull/476) Unikraft now features new SMP-safe synchronization primitives such as mutexes, semaphores, reader-writer locks, and condition variables. 214 | This will enable Unikraft to protect critical sections and lay the foundation for full SMP support of core Unkraft components. 215 | 216 | These primitives have not yet been integrated in the Unikraft core libraries. 217 | These libraries need to be made SMP / thread-safe, by redesigning their data structures and making appropriate calls to synchronization primitives. 218 | The goal is to integrate synchronization primitives to ensure SMP safety while preserving a good level of performance. 219 | 220 | While locking is effective it is not always the most efficient solution. 221 | Sometimes, for example, when manipulating data structures it can be faster to operate on the data structures directly using atomic instructions. 222 | These lockless data structures can benefit SMP performance. 223 | One potential item is therefore to extend Unikraft's existing data structures with lockless variants and research alternatives to simple locking such as read-copy-update (RCU). 224 | 225 | #### Reading & Related Material 226 | 227 | * [Operating Systems: Three Easy Pieces](https://pages.cs.wisc.edu/~remzi/OSTEP/) (Chapter on Concurrency) 228 | * https://dl.acm.org/doi/abs/10.1145/2517349.2522714 229 | * https://wiki.osdev.org/Synchronization_Primitives 230 | * https://www.kernel.org/doc/html/latest/RCU/index.html 231 | 232 | --- 233 | 234 | ### Multiboot2 Support in Unikraft 235 | 236 | | | | 237 | |-|-| 238 | | **Difficulty** | 3/5 | 239 | | **Project Size** | Variable (175 or 350 hours) | 240 | | **Maximum instances** | 1 | 241 | | **Constraints/requirements** | C programming skills, familiarity with OS topics, knowledge of booting process | 242 | 243 | #### Description 244 | 245 | Unikraft is a unikernel capable to boot in various environments and through quite a few boot protocols. 246 | From supporting the first version of Multiboot, being able to boot through the Linux Boot Protocol on ARM64 and having its own UEFI stub enabling the Operating System to load without a Bootloader, Unikraft has still a lot to learn with respect to the booting environments it knows. 247 | 248 | One such booting protocol that would be very useful is Multiboot2. 249 | This protocol represents a significant improvement over Multiboot version 1, providing improved flexibility in the realm of bootloaders. 250 | A notable improvement is the extended information provided by Multiboot2, which provides detailed and accurate communication between the bootloader and the operating system kernel during the bootstrapping process. 251 | In addition, Multiboot2 comes with a standardized tag system, enabling easier data and system configuration parsing between the bootloader and the kernel and allowing greater interoperability and better integration of boot modules. 252 | The introduction of optional commandline further enhances the flexibility of the boot process. 253 | Together, these enhancements contribute to a more robust and scalable bootstrapping mechanism, making Multiboot2 a better choice than Multiboot version 1. 254 | 255 | Concretely speaking, it would allow us to boot directly in 64-bit mode, while having access to pointers to the UEFI tables as well as the ACPI tables, unlike Multiboot 1, offering us access to more modern firmware interfaces. 256 | The task at hand involves integrating the Multiboot2 definitions as well as its corresponding bootstrapping code into Unikraft. 257 | Auxiliary scripts may be implemented to allow the automatic creation of Multiboot2-based Unikraft bootable images. 258 | 259 | #### Reading & Related Material 260 | 261 | * https://www.gnu.org/software/grub/manual/multiboot/multiboot.html 262 | * https://www.gnu.org/software/grub/manual/multiboot2/multiboot.html 263 | 264 | --- 265 | 266 | ### UEFI Graphics Output Protocol Support in Unikraft 267 | 268 | | | | 269 | |-|-| 270 | | **Difficulty** | 3/5 | 271 | | **Project Size** | Variable (175 or 350 hours) | 272 | | **Maximum instances** | 1 | 273 | | **Constraints/requirements** | C programming skills, familiarity with OS topics, knowledge of booting process | 274 | 275 | #### Description 276 | 277 | When it comes to modern baremetal environments as well as second generation Virtual Machines, Unikraft's ability to print debugging logs to the screen is very limited. This can represent an unnecessary blocker for technical tracks such as Hyper-V, VMWare support or just being able to debug Unikraft on UEFI-based baremetal machines. While we may be able to debug in such situations using the serial port console, it is not as easily available for the usual consumer machines, leaving us with the main option that is used in the modern times: the widely available and standardized UEFI Graphics Output Protocol (GOP) interface. 278 | 279 | UEFI GOP remains a staple in today's computer systems, providing a customizable and versatile interface for viewing images generated during and after the boot process as well as being able to read and write raw pixels from and to the physical display. Its usefulness to the operating system is paramount in UEFI-based systems as it allows drawing fonts directly to the screen, thus enabling the printing of logs. Unlike the old, nowadays not so much available, VGA standard, its replacement, UEFI GOP, supports multiple rendering resolutions and color depths, ensuring close compatibility with hardware systems. This protocol enables operating systems to successfully boot and quickly manage graphics hardware during the boot process for a smoother and more accurate visual user experience. 280 | 281 | Supporting this modern interface would directly allow Unikraft to be easier to be debugged on UEFI-based systems and, furthermore, allow us to open a complex track, namely the one for increasing support on x86_64 baremetal machines. The proposed work involves writing a font parser and writing a UEFI GOP driver that would receive the necessary framebuffer information from the bootloader and implement the necessary functionality to interact with the display in order to print logs under the form of characters drawn through raw pixels on the screen. 282 | 283 | #### Reading & Related Material 284 | 285 | * https://uefi.org/specs/UEFI/2.10/12_Protocols_Console_Support.html#graphics-output-protocol 286 | 287 | --- 288 | 289 | ### Linux x86 Boot Protocol Support (medium-large, 175-350hrs) 290 | 291 | | | | 292 | |-|-| 293 | | **Difficulty** | 3/5 | 294 | | **Project Size** | Variable (175 or 350 hours) | 295 | | **Maximum instances** | 1 | 296 | | **Constraints/requirements** | C programming skills, familiarity with OS topics, knowledge of booting process | 297 | 298 | #### Description 299 | 300 | While Unikraft may have the bare minimum implementation required to receive and process the information passed from Firecracker under the form of the Linux Boot Protocol structures, it is not able to boot through this protocol from more strict and proper environments such as QEMU, GRUB, U-Boot or any of the many open source bootloaders that speak this protocol. 301 | The main reason this does not happen is because the Unikraft bootable images are missing the Linux header. 302 | This is a very large header with many fields, highly configurable and yet fairly difficult to debug since it involves a large amount of binary interfacing, proving to be a valuable debugging experience. 303 | 304 | The Linux boot protocol plays an important role in the initialization of the Linux operating system, emphasizing the importance of system optimization and scalability. 305 | This system ensures a seamless transfer of control from the bootloader to the Linux kernel by providing essential information including memory map, command line parameters, and device specifications. 306 | By adhering to a uniform boot protocol, Linux achieves a level of versatility across the hardware spectrum of architectures and bootloader functions. 307 | Essentially, this protocol is a commitment to a standardized approach that is not only stable but also facilitates bootloader development, improving compatibility and reliability. 308 | In particular, the Linux boot protocol greatly contributes to the overall robustness and reliability of the bootstrapping process on Linux-based systems. 309 | Almost, if not all, widely available bootloaders that exist on the market are able to speak this protocol and Unikraft, being unable to be detected by these bootloaders as a Linux Boot Protocol compliant system, is hindering the ability of Unikraft to boot on a very large amount of platforms. 310 | 311 | To be able to achieve such booting flexibility, the student will be required to write an external program that will be part of the build system and will be used to parse the usual Unikraft configurable metadata and convert it into its Linux Boot Protocol equivalents, the resulted data then is to be prepended to the bootable image as a header. 312 | Following this procedure, the bootable image media creation script we have begun writing will need to be adapted to create such a booting image and then tested on various platforms and bootloaders so as to catch potential underlying quirks of the different loaders. 313 | 314 | #### Reading & Related Material 315 | 316 | * https://www.kernel.org/doc/html/v5.6/x86/boot.html 317 | -------------------------------------------------------------------------------- /gsoc-2024/work-product/Maria-Pana-Multiboot2-Support-in-Unikraft/Maria-Pana-Multiboot2.md: -------------------------------------------------------------------------------- 1 | # Multiboot2 support in Unikraft 2 | 3 | 4 | 5 | ## Project Overview 6 | 7 | The aim of this project is to enhance Unikraft's compatibility and versatility by integrating support for the [Multiboot2](https://www.gnu.org/software/grub/manual/multiboot2/multiboot.html) protocol. 8 | By adopting [Multiboot2](https://www.gnu.org/software/grub/manual/multiboot2/multiboot.html), [Unikraft](https://github.com/unikraft/unikraft) will gain the ability to boot directly in 64-bit mode, access modern firmware interfaces, and leverage the protocol's improved communication mechanisms. 9 | 10 | When booting an x86 system, the CPU starts in 16-bit mode and the memory is limited to 1MB (in Real Mode). 11 | The CPU starts executing at a specific memory address known as a reset vector situated at 0xFFFF0 (for Intel 8086 processors) or 0xFFFFFFF0 (for Intel 80386 and later). 12 | The initial instructions found here are part of the BIOS, stored in flash memory on the motherboard. 13 | The BIOS's first goal is to run self test and initialization routines on hardware. 14 | During this phase, the BIOS sets up standardized interfaces (e.g. legacy BIOS interrupts or UEFI routines) that software that succeeds it (bootloader or operating system) will use to understand the computer's resources without needing special drivers for each different motherboard model. 15 | 16 | However, having the kernel directly deal with the interfaces installed by the BIOS unnecessarily increases complexity and maintenance effort. 17 | This is where the bootloader comes in. 18 | After its initial routines, BIOS looks for bootable devices, such as hard disk drives (HDDs). 19 | If it finds one that has a valid (P)MBR or GPT partitioning scheme with a boot partition, the control is passed to the bootloader. 20 | This will then load the OS kernel into memory either by using the interfaces offered by the BIOS or its own drivers, and transfer control to it. 21 | 22 | Boot protocols define the specific methods and standards used for this transfer of control. 23 | There are multiple of them, some already supported by Unikraft. 24 | Nonetheless, there is still room to add other boot protocols, such as [Multiboot2](https://www.gnu.org/software/grub/manual/multiboot2/multiboot.html), which is the focus of this project. 25 | 26 | [Multiboot2](https://www.gnu.org/software/grub/manual/multiboot2/multiboot.html), an enhanced version of [Multiboot](https://www.gnu.org/software/grub/manual/multiboot/multiboot.html), solves some of the limitations of the original protocol, such as the lack of support for 64-bit UEFI systems. 27 | It also provides a more accurate and detailed communication during the bootstrapping process and offers a standardized tag system for easier configuration. 28 | For instance, the [Command Line Tag](https://www.gnu.org/software/grub/manual/multiboot2/multiboot.html#Boot-command-line) retrieves boot parameters essential for configuring the kernel, while the [Memory Map Tag](https://www.gnu.org/software/grub/manual/multiboot2/multiboot.html#Memory-map) provides a memory map crucial for managing physical memory. 29 | Additionally, the ELF Sections Tag delivers information about ELF sections, aiding in the proper handling of executable formats. 30 | By leveraging these tags and the others Multiboot2 offers, we can ensure that the kernel has access to all the necessary information right from the boot process, which simplifies kernel initialization and enhances compatibility and flexibility. 31 | 32 | ## GSoC Contributor 33 | 34 | Name: Maria Pana 35 | 36 | Email: 37 | 38 | Github profile: [mariapana](https://github.com/mariapana) 39 | 40 | ## Mentors 41 | 42 | * [Razvan Deaconescu](https://github.com/razvand) 43 | * [Sergiu Moga](https://github.com/mogasergiu) 44 | * [Cristian Vijelie](https://github.com/cristian-vijelie) 45 | * [Michalis Pappas](https://github.com/michpappas) 46 | 47 | ## Contributions 48 | 49 | My contributions to the project, condensed into this [pull request](https://github.com/unikraft/unikraft/pull/1463), are focused on integrating Multiboot2 support into Unikraft. 50 | 51 | Once successful, the interaction between the bootloader (GRUB) and the kernel (Unikraft) goes as follows: 52 | 53 | The bootloader locates the Multiboot2 header within the ELF file. 54 | After verifying the magic number and architecture compatibility, it parses the header and tags. 55 | Next, the information requested by the tags is placed into the kernel memory and the bootloader passes control to the kernel. 56 | 57 | The kernel, in turn, accesses the Multiboot2 header using the information provided by the bootloader. 58 | It iterates through the tags to extract the necessary data, such as memory regions, boot command line, and other parameters. 59 | This information is used to initialize its own data structures, set up memory management, and configure the system for execution. 60 | 61 | To achieve this, I mirrored the existing file organization established for Multiboot and extended it to accommodate the new protocol. 62 | Three core files handle the protocol itself, while the rest of the codebase is updated around them to ensure proper integration and functionality. 63 | Let's take a closer look: 64 | 65 | ### `multiboot.S` 66 | 67 | This assembly file plays a pivotal role in preparing a standardized operating environment. 68 | It verifies the system is booted through a compliant Multiboot/Multiboot2 bootloader and manages essential memory relocations. 69 | In this context, it was required to update the file to support Multiboot2 as well. 70 | This way, based on the chosen configurations, the program uses either `multiboot.h` and `MULTIBOOT_BOOTLOADER_MAGIC` for Multiboot or their Multiboot2 counterparts. 71 | 72 | ### `multiboot2.py` 73 | 74 | The Python script generates and adds the Multiboot2 and updated ELF headers to the original ELF file. 75 | This ensures that the bootloader information is strategically positioned at the start of the resulting ELF, facilitating correct system initialization. 76 | Since the Multiboot protocol is limited to 32-bit systems, the `multiboot.py` script also required transforming 64-bit ELFs into 32-bit ones. 77 | This is no longer the case when it comes to Multiboot2, only needing to incorporate the Multiboot2 and updated ELF headers into the file, without any other alterations. 78 | 79 | The Multiboot2 header follows a specific format, starting with a fixed-size header followed by a series of variable-length tags. 80 | The fixed-size header includes: 81 | 82 | - The magic number `0xE85250D6` indicating a Multiboot2-compliant image 83 | - The target architecture (e.g. `i386`, `x86_64`) 84 | - The header length, including all tags 85 | - The checksum of the header, used for error detection 86 | 87 | The header continues with the header tags, which provide detailed information about the system's memory layout, boot command line, and other essential parameters. 88 | Commonly, each tag has a type, size and payload. 89 | There is a multitude of tags to choose from, depending on the specific requirements of the system, adding to the flexibility of Multiboot2. 90 | 91 | In the context of this project, it is worth noting that simply adding the Multiboot2 header to the ELF file is not sufficient. 92 | On top of that, both `multiboot.py` and `multiboot2.py` scripts add an extra ELF header with updated offsets, "sandwiching" the Multiboot2 header between it and the original ELF. 93 | To better visualize this, we can refer to the following diagram: 94 | 95 | ```text 96 | ┌────────────────────┐ 97 | ┌───────│ Updated EHDR |─────────────┐ 98 | | ├────────────────────┤ | 99 | | | MB2HDR | | 100 | | ├────────────────────┤ | 101 | └──────>| Updated PHDR | | 102 | ├────────────────────┤ | 103 | ┌───────| Original EHDR |────────┐ | 104 | | ├────────────────────┤ | | 105 | └──────>| Original PHDR | | | 106 | ├────────────────────┤ | | 107 | | Original SHDR |<───────┘ | 108 | ├────────────────────┤ | 109 | | ... | | 110 | ├────────────────────┤ | 111 | | Updated SHDR |<────────────┘ 112 | └────────────────────┘ 113 | ``` 114 | 115 | The offset to the ELF64 Program/Sections Headers are at the end of the Multiboot2 Header and the end of the file respectively, so that we do not mess up the Multiboot2 header, which must exist in the first 8192 bytes. 116 | Although the specification only enforces it to be contained completely within the first 32768 bytes, GRUB, for whatever reason, wants the Program Headers to also be placed in the first 8192 bytes (see commit 9a5c1ad). 117 | 118 | ### `multiboot2.c` 119 | 120 | This C program is responsible for processing boot information from a Multiboot2-compliant bootloader (the Multiboot2 `mbi` from GRUB in our case). 121 | It meticulously manages memory regions, integrates boot parameters, and prepares the system for kernel execution by consolidating memory configurations and allocating essential resources. 122 | 123 | Alongside these core files, I made adjustments to adjacent files to seamlessly link everything together and ensure successful booting under Multiboot2 (e.g. duplicating the `mkukimg` script's menuentry to use `multiboot2` instead of `multiboot` etc.). 124 | Additionally, I updated the `Linker.uk` script to replace uses of the `ELF64_TO_32` option with checks for Multiboot, ensuring smooth and similar processing/maintanence for both protocols. 125 | 126 | ## Blog Posts 127 | 128 | For more details of the process and the challenges faced, I documented my progress in a series of blog posts which can be found here: 129 | 130 | * [Blog post #1](https://github.com/unikraft/docs/pull/428) 131 | 132 | * [Blog post #2](https://github.com/unikraft/docs/pull/439) 133 | 134 | * [Blog post #3](https://github.com/unikraft/docs/pull/447) 135 | 136 | * [Blog post #4](https://github.com/unikraft/docs/pull/453) 137 | 138 | ## Current Status 139 | 140 | To test and validate the Multiboot2 support, I used the [`helloworld`](https://github.com/unikraft/catalog/tree/main/native/helloworld-c) and [`nginx`](https://github.com/unikraft/catalog/tree/main/library/nginx) applications to check if the tags are correctly parsed and have proper functionality. 141 | Unfortunately, QEMU doesn't natively support Multiboot2. 142 | Consequently, options such as `-kernel` and `-append` used in Unikraft's usual running script are not applicable. 143 | Instead, I tested on the `.iso` file generated by [`mkukimg`](https://github.com/unikraft/unikraft/blob/staging/support/scripts/mkukimg) while passing the command line arguments through the script's `-c` option. 144 | For a clearer understanding, you can check this sample [testing script](https://gist.github.com/mariapana/90ab2e61715e812def0c7582c9482626). 145 | 146 | With Multiboot2 support being successfully integrated into Unikraft, the next step is to review and merge the pull request. 147 | 148 | ## Future Work 149 | 150 | One of the greatest advantages of Multiboot2 is its flexibility and extensibility through tags. 151 | Therefore, I want to explore the possibility of adding more tags to the implementation, such as the Relocation Tag. 152 | Also on the TODO list is to extend the support to UEFI systems, besides the current GRUB support. 153 | -------------------------------------------------------------------------------- /gsoc-2024/work-product/Mihnea-Firoiu-Lxboot-Support-in-Unikraft/Mihnea-Firoiu-Lxboot.md: -------------------------------------------------------------------------------- 1 | # Lxboot Support in Unikraft 2 | 3 | 4 | 5 | ## Project Overview 6 | 7 | The Linux boot protocol plays an important role in the initialization of the Linux operating system, emphasizing the importance of system optimization and scalability. 8 | This system ensures a seamless transfer of control from the bootloader to the Linux kernel by providing essential information including memory map, command line parameters, and device specifications. 9 | By adhering to a uniform boot protocol, Linux achieves a level of versatility across the hardware spectrum of architectures and bootloader functions. 10 | Essentially, this protocol is a commitment to a standardized approach that is not only stable but also facilitates bootloader development, improving compatibility and reliability. 11 | In particular, the Linux boot protocol greatly contributes to the overall robustness and reliability of the bootstrapping process on Linux-based systems. 12 | Almost, if not all, widely available bootloaders that exist on the market are able to speak this protocol and Unikraft, being unable to be detected by these bootloaders as a Linux Boot Protocol compliant system, is hindering the ability to boot on a very large amount of platforms. 13 | 14 | This is how the Lxboot header looks: 15 | 16 | | Offset/Size | Protocol | Name | Meaning | 17 | |-------------|-------------|---------------------|--------------------------------------------------------| 18 | | 01F1/1 | ALL(1) | setup_sects | The size of the setup in sectors | 19 | | 01F2/2 | ALL | root_flags | If set, the root is mounted readonly | 20 | | 01F4/4 | 2.04+(2) | syssize | The size of the 32-bit code in 16-byte paras | 21 | | 01F8/2 | ALL | ram_size | DO NOT USE - for bootsect.S use only | 22 | | 01FA/2 | ALL | vid_mode | Video mode control | 23 | | 01FC/2 | ALL | root_dev | Default root device number | 24 | | 01FE/2 | ALL | boot_flag | 0xAA55 magic number | 25 | | 0200/2 | 2.00+ | jump | Jump instruction | 26 | | 0202/4 | 2.00+ | header | Magic signature “HdrS” | 27 | | 0206/2 | 2.00+ | version | Boot protocol version supported | 28 | | 0208/4 | 2.00+ | realmode_swtch | Boot loader hook (see below) | 29 | | 020C/2 | 2.00+ | start_sys_seg | The load-low segment (0x1000) (obsolete) | 30 | | 020E/2 | 2.00+ | kernel_version | Pointer to kernel version string | 31 | | 0210/1 | 2.00+ | type_of_loader | Boot loader identifier | 32 | | 0211/1 | 2.00+ | loadflags | Boot protocol option flags | 33 | | 0212/2 | 2.00+ | setup_move_size | Move to high memory size (used with hooks) | 34 | | 0214/4 | 2.00+ | code32_start | Boot loader hook (see below) | 35 | | 0218/4 | 2.00+ | ramdisk_image | initrd load address (set by boot loader) | 36 | | 021C/4 | 2.00+ | ramdisk_size | initrd size (set by boot loader) | 37 | | 0220/4 | 2.00+ | bootsect_kludge | DO NOT USE - for bootsect.S use only | 38 | | 0224/2 | 2.01+ | heap_end_ptr | Free memory after setup end | 39 | | 0226/1 | 2.02+(3) | ext_loader_ver | Extended boot loader version | 40 | | 0227/1 | 2.02+(3) | ext_loader_type | Extended boot loader ID | 41 | | 0228/4 | 2.02+ | cmd_line_ptr | 32-bit pointer to the kernel command line | 42 | | 022C/4 | 2.03+ | initrd_addr_max | Highest legal initrd address | 43 | | 0230/4 | 2.05+ | kernel_alignment | Physical addr alignment required for kernel | 44 | | 0234/1 | 2.05+ | relocatable_kernel | Whether kernel is relocatable or not | 45 | | 0235/1 | 2.10+ | min_alignment | Minimum alignment, as a power of two | 46 | | 0236/2 | 2.12+ | xloadflags | Boot protocol option flags | 47 | | 0238/4 | 2.06+ | cmdline_size | Maximum size of the kernel command line | 48 | | 023C/4 | 2.07+ | hardware_subarch | Hardware subarchitecture | 49 | | 0240/8 | 2.07+ | hardware_subarch_data| Subarchitecture-specific data | 50 | | 0248/4 | 2.08+ | payload_offset | Offset of kernel payload | 51 | | 024C/4 | 2.08+ | payload_length | Length of kernel payload | 52 | | 0250/8 | 2.09+ | setup_data | 64-bit physical pointer to linked list of struct setup_data| 53 | | 0258/8 | 2.10+ | pref_address | Preferred loading address | 54 | | 0260/4 | 2.10+ | init_size | Linear memory required during initialization | 55 | | 0264/4 | 2.11+ | handover_offset | Offset of handover entry point | 56 | 57 | ## GSoC Contributor 58 | 59 | Name: Mihnea Firoiu 60 | 61 | Email: 62 | 63 | GitHub profile: [Mihnea0Firoiu](https://github.com/Mihnea0Firoiu) 64 | 65 | ## Mentors 66 | 67 | * [Răzvan Deaconescu](https://github.com/razvand) 68 | * [Sergiu Moga](https://github.com/mogasergiu) 69 | * [Ștefan Jumărea](https://github.com/StefanJum) 70 | 71 | ## Contributions 72 | 73 | Here you can see the [pull request](https://github.com/unikraft/unikraft/pull/1491) that represents everything I did during this project. 74 | 75 | ### `mklinux_x86_64.py` 76 | 77 | The `mklinux_x86_64.py` is the biggest and most significant part of my project. 78 | Here you can find everything about from the way the image was prepended with the Lxboot header, to the creation of the 16bit assembly trampoline. 79 | 80 | The final image should look like this: 81 | 82 | ``` 83 | Padding to lxboot header 84 | Lxboot header 85 | Padding to alignment 86 | Binary 87 | ``` 88 | 89 | The padding before the Lxboot header is needed because it starts at offset `0x1f1`. 90 | This is because of the way the Lxboot protocol works. 91 | Inside the second padding area, the 16bit assembly trampoline is found, that makes the jump to the 32bit section, finishing the booting process. 92 | 93 | ### `plat/kvm/Linker.uk`, `plat/kvm/Config.uk` and `plat/common/Makefile.rules` 94 | 95 | These were modified to facilitate a seamless integration with the already available booting protocols. 96 | 97 | These files make everything work behind the scene, so by modifying them, Lxboot is able to be used. 98 | 99 | ## Blog Posts 100 | 101 | * [Blog post #1](https://github.com/unikraft/docs/pull/429) 102 | 103 | * [Blog post #2](https://github.com/unikraft/docs/pull/440) 104 | 105 | * [Blog post #3](https://github.com/unikraft/docs/pull/449) 106 | 107 | ## Current Status 108 | 109 | At this point, the Lxboot protocol reaches the 64bit section. 110 | A `Hello, world!` is not yet possible. 111 | For this to be possible, the `memory map` needs to be implemented alongside the `boot_params struct`. 112 | As it is now, everything stops when entering the 64bit zone. 113 | 114 | ## Future Work 115 | 116 | The [memory map](https://wiki.osdev.org/Detecting_Memory_(x86)#Getting_an_E820_Memory_Map) needs to be implemented and the [`boot_params` struct](https://github.com/torvalds/linux/blob/master/arch/x86/include/uapi/asm/bootparam.h#L116) needs to be built. 117 | Without a memory map, the operating system cannot know which parts of memory are safe to use. Implementing the memory map allows the OS to effectively manage resources and prevent conflicts or crashes caused by writing to protected or reserved regions of memory. 118 | The `boot_params` struct is a data structure that is passed from the bootloader (like GRUB) to the Linux kernel. It contains essential information about the system state at boot time, including: 119 | 120 | * The memory map (E820) data 121 | * Video information 122 | * Disk layout 123 | * Boot flags and other system parameters 124 | 125 | This struct allows the Linux kernel to initialize itself based on the hardware configuration it receives. 126 | -------------------------------------------------------------------------------- /gsoc-2024/work-product/Sriprad-Potukuchi-UEFI-GOP-Support/Sriprad-Potukuchi-UEFI-GOP-Support.md: -------------------------------------------------------------------------------- 1 | # Unikraft GSoC'24: UEFI Graphics Output Protocol Support in Unikraft. 2 | 3 | Unikraft's ability to print logs to the screen is quite limited, which makes it harder to debug it during development. 4 | While it is entirely possible to use the serial port console instead of a screen, it is not as easily accessible or available on usual consumer machines. 5 | 6 | The widely available and standardized [UEFI Graphics Output Protocol](https://uefi.org/specs/UEFI/2.10/12_Protocols_Console_Support.html#efi-graphics-output-protocol) (GOP) interface is an excellent candidate. 7 | 8 | The UEFI GOP interface allows us to query for a framebuffer, which is an array of pixels in memory. 9 | Setting the color value of the pixels in the framebuffer will set the colors of the corresponding pixels on the screen, thus enabling graphic output. 10 | 11 | This project aims to implement a UEFI GOP based console. 12 | This would directly allow Unikraft to be easier debugged on UEFI-based systems and fast track the development of x86_64 baremetal machine support. 13 | 14 | ## GSoC Contributor 15 | 16 | - Name: Sriprad Potukuchi 17 | - Email: 18 | - GitHub profile: [procub3r](https://github.com/procub3r) 19 | 20 | ## Mentors 21 | 22 | - [Sergiu Moga](https://github.com/mogasergiu) 23 | - [Răzvan Vîrtan](https://github.com/razvanvirtan) 24 | - [Michalis Pappas](https://github.com/michpappas) 25 | 26 | ## Contributions 27 | 28 | My main contribution is [PR #1448](https://github.com/unikraft/unikraft/pull/1448), which creates a UEFI GOP device driver in `drivers/uktty/gop`. 29 | 30 | This driver first locates and queries the UEFI Graphics Output Protocol for a framebuffer. 31 | It also queries some metadata about the framebuffer such as its width, height and total size. 32 | It then calculates the number of rows and columns of printable characters based on this metadata and the dimensions of a single character from the configured bitmap font. 33 | 34 | Upon receiving a message to print, the driver first parses any ANSI escape sequences within the message to format the output text. 35 | Then, for every printable character in the message, it performs a lookup in the bitmap font to determine the exact pixels to render and renders them with the appropriate formatting. 36 | 37 | The driver also supports scrolling when the console output is full. 38 | This is to ensure that the latest output is always visible on the console. 39 | 40 | ### The `ukconsole` Dependency 41 | 42 | `ukconsole` is a generic console device interface which allows device drivers (GOP, VGA, COM etc) to register themselves as console devices. 43 | All prints and reads in the the kernel go to these registered devices through the `ukconsole` interface. 44 | 45 | The GOP device driver introduced in this project is one such device driver which registers itself with `ukconsole`. 46 | 47 | At the time of writing, `ukconsole`, introduced in [PR #1464](https://github.com/unikraft/unikraft/pull/1464) is yet to be merged. 48 | My work with the GOP driver can be upstreamed as soon as the `ukconsole` PR is merged! 49 | 50 | ## Blog Posts 51 | 52 | - [Part 1](https://github.com/unikraft/docs/pull/430): Initializing GOP and implementing a proof of concept. 53 | - [Part 2](https://github.com/unikraft/docs/pull/441): Parsing and rendering a bitmap font. 54 | - [Part 3](https://github.com/unikraft/docs/pull/450): Arbitrary bitmap font support and migrating to `ukconsole`. 55 | - [Part 4](https://github.com/unikraft/docs/pull/454): Coloring logs with ANSI escape codes. 56 | 57 | ## Current Status 58 | 59 | The UEFI GOP console works as expected! 60 | Here's a screenshot of it in action: 61 | 62 | ![UEFI GOP console demonstration](images/uefi-gop-console.png) 63 | _Unikraft kernel logs printed to display using the UEFI GOP console._ 64 | 65 | ## Future Work 66 | 67 | Currently, the graphics mode being used is the default one returned by UEFI GOP. 68 | We could instead iterate through all the available modes and pick the most suitable one for the given display. 69 | 70 | To take this further, the bitmap font can be scaled fractionally to be of appropriate size to perfectly fit within the display. 71 | This would entail the usage of some clever techniques such as anti-aliasing. 72 | 73 | The scope of this project was to introduce a driver that supports console output only. 74 | It would be really cool to make it an interactive console by supporting console input too! 75 | 76 | ## Acknowledgements 77 | 78 | The Unikraft community has been extremely welcoming. 79 | I would like to thank my mentors and the amazing folk part of this community for their continued support. 80 | This work would not have been possible without them! :heart: 81 | -------------------------------------------------------------------------------- /gsoc-2024/work-product/Sriprad-Potukuchi-UEFI-GOP-Support/images/uefi-gop-console.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/unikraft/gsoc/4041e2b0b4e7c41935a983deeb412989e17ad0ab/gsoc-2024/work-product/Sriprad-Potukuchi-UEFI-GOP-Support/images/uefi-gop-console.png -------------------------------------------------------------------------------- /gsoc-2024/work-product/Yang-Hu-Synchronization-Support-in-Internal-Libraries/Yang-Hu-Synchronization-Support-in-Internal-Libraries.md: -------------------------------------------------------------------------------- 1 | # Unikraft GSoC'24: Synchronization Support In Internal Libraries 2 | 3 | 4 | 5 | ## Summary 6 | 7 | Memory allocators have a significant impact on application performance. 8 | There have been serveral [research papers](https://dl.acm.org/doi/10.1145/378795.378821) which compared different memory allocators. 9 | According to their work, switching to the appropiate memory allocator may improve the application performance by 60%. 10 | Unikraft currently supports only one non-synchronized memory allocator, the [*binary buddy* allocator](https://github.com/unikraft/unikraft/tree/staging/lib/ukallocbbuddy). 11 | Therefore, this project aims to enhance synchronization support in Unikraft's internal libraries and port [*mimalloc*](https://github.com/microsoft/mimalloc) (pronounced "me-malloc"), a high-performance general-purpose memory allocator developed by Microsoft, to it. 12 | 13 | ## GSoC Contributor 14 | 15 | Name: Yang Hu 16 | 17 | Email: yanghuu531@gmail.com 18 | 19 | Github profile: [huyang531](https://github.com/huyang531) 20 | 21 | ## Mentors 22 | 23 | * [Răzvan Vîrtan](https://github.com/razvanvirtan) 24 | * [Radu Nichita](https://github.com/RaduNichita) 25 | * [Sergiu Moga](https://github.com/mogasergiu) 26 | * [Răzvan Deaconescu](https://github.com/razvand) 27 | 28 | ## Contributions 29 | 30 | ### Porting *mimalloc* 31 | 32 | I started my work based on [Hugo Lefeuvre's](https://github.com/hlef) initial attempt to port mimalloc to Unikraft back in 2020 (see [this repo](https://github.com/unikraft/lib-mimalloc)). 33 | As Unikraft has evolved significantly over the years, I've had to adapt the port to work with the latest Unikraft core (v0.17.0), which includes: 34 | 35 | - Switch *mimalloc* from using `newlib` to `musl`: 36 | - [PR: Add the `stdatomic.h` header to `lib-musl`](https://github.com/unikraft/lib-musl/pull/80) 37 | - [PR: Adapt `lib-mimalloc` to using `lib-musl` and the new threading interface](https://github.com/unikraft/lib-mimalloc/pull/12) 38 | 39 | - [PR: Adapt Unikraft's heap initialization routine to support *mimalloc*](https://github.com/unikraft/unikraft/pull/1480) 40 | 41 | ### Benchmarking *mimalloc* 42 | 43 | I benchmarked the *mimalloc* allocator using the `cache-scratch` and `cache-thrash` benchmarks *without SMP support enabled*. 44 | The details of how the benchmarks work can be found in [my second blog post](https://unikraft.org/blog/2024-07-12-unikraft-gsoc-test-mimalloc-on-unikraft). 45 | 46 | In debugging the benchmarks, I have also ran into a confusing bug where the TLS's magic value would be corrupted when the user declares a thread-local array larger than 15 bytes. 47 | 48 | The product of this part of my work includes: 49 | 50 | - [Gist: The benchmark application ported to Unikraft](https://gist.github.com/huyang531/28a31fc2d9f348fafb5b9d8e6c9493d5) 51 | - [Issue: Cannot handle thread-local arrays larger than 15 bytes](https://github.com/unikraft/unikraft/issues/1478) 52 | 53 | ### Other Works 54 | 55 | During the course of this project, I have also fixed a few minor bugs and amended Unikraft's documentation: 56 | 57 | - [PR: lib/ukvmem: Fix dependency and test scripts](https://github.com/unikraft/unikraft/pull/1447) 58 | - [PR: Fix typos and add notes about the hardware acceleration with KVM for random number generation](https://github.com/unikraft/docs/pull/452) 59 | - [PR: Add tips for disabling compiler optimization in debug guide](https://github.com/unikraft/docs/pull/442) 60 | 61 | ## Blog Posts 62 | 63 | - [Blog post #1: Porting *mimalloc*](https://unikraft.org/blog/2024-06-16-unikraft-gsoc-port-mimalloc-to-unikraft) 64 | - [Blog post #2: Testing *mimalloc*](https://unikraft.org/blog/2024-07-12-unikraft-gsoc-test-mimalloc-on-unikraft) 65 | - [Blog post #3: Debugging *mimalloc*](https://github.com/unikraft/docs/pull/448) 66 | - [Blog post #4: Benchmarking *mimalloc* in an SMP environment](https://github.com/unikraft/docs/pull/455) 67 | 68 | ## Future Work 69 | 70 | ### Running *mimalloc* in an SMP Environment 71 | 72 | After running the benchmarks under multiple configurations, we noticed that *mimalloc* did not perform significantly better than the existing *binary buddy* allocator. 73 | This is because we are not running the virtual machine with SMP enabled, so *mimalloc* would have wasted much time on unnecessary synchronization. 74 | Therefore, to really benchmark the performance of *mimalloc* (and to justify Unikraft's potential for full SMP support), we need to get it running with real parallelism. 75 | 76 | I have outlined some key considerations and future steps in [this blog post](https://github.com/unikraft/docs/pull/455). 77 | 78 | ### Further Testing of *mimalloc* 79 | 80 | So far, we have only tested *mimalloc* on two multi-threaded benchmarks. 81 | To further validate its functionality, portability, and performance, we need to test *mimalloc* on [some more complicated benchmarks](https://unikraft.org/blog/2024-07-12-unikraft-gsoc-test-mimalloc-on-unikraft#next-steps) and on real-world applications like Redis. 82 | 83 | ### Porting the Latest *mimalloc* to Unikraft 84 | 85 | So far, we have been working on *mimalloc* v1.6.3. 86 | We can further improve our work by porting a newer version of the memory allocator to Unikraft. 87 | 88 | ### Towards Full Synchronization Support in Internal Libraries 89 | 90 | As the project title suggests, more work needs to be done for Unikraft to provide general synchronization support for user applications, which goes far beyond just providing a synchronous memory allocator. 91 | For example, we may need to synchronize the [Virtual Memory interface (`ukvmem`)](https://github.com/unikraft/unikraft/tree/staging/lib/ukvmem), the [cooperative scheduler (`ukschedcoop`)](https://github.com/unikraft/unikraft/tree/staging/lib/ukschedcoop), and rethink how every component interacts with each other in an SMP environment. 92 | 93 | ## Acknowledgements 94 | 95 | This has been an incredibly fun (and challenging) journey and I am grateful to every one in the Unikraft community who made this GSoC project possible. 96 | Special thanks to Răzvan Vîrtan, Radu Nichita, Sergiu Moga, and Răzvan Deaconescu, for all your support along the way! 97 | -------------------------------------------------------------------------------- /gsoc-2025/README.md: -------------------------------------------------------------------------------- 1 | # Unikraft at Google Summer of Code 2025 (GSoC'25) 2 | 3 | Make your way into open source development with operating systems, cloud, virtualization and low-level topics. 4 | Apply to [GSoC25](https://summerofcode.withgoogle.com/) with [Unikraft](https://unikraft.org/). 5 | 6 | [Google Summer of Code 2025](https://summerofcode.withgoogle.com/) (GSoC'25) is a global online program focused on bringing new contributors into open source software development. 7 | GSoC Contributors work with an open source organization, such as Unikraft, on a 12+ week programming project under the guidance of mentors. 8 | 9 | [Unikraft](https://unikraft.org/) is a fast, secure and open-source Unikernel Development Kit. 10 | By tailoring the operating system, libraries and configuration to the particular needs of your application, it vastly reduces virtual machine and container image sizes to a few KBs, provides blazing performance, and drastically cuts down your software stack’s attack surface. 11 | 12 | Before you apply, see the [GSoC contributor eligibility](https://summerofcode.withgoogle.com/get-started). 13 | 14 | ## How to Apply[^1] 15 | 16 | * Connect to the community 17 | * Get accustomed to the Unikraft development ecosystem 18 | * Make a small contribution 19 | * Decide on a GSoC project 20 | * Fill out an application 21 | 22 | ### Connect to the community 23 | 24 | First join our [Discord server](https://unikraft.org/discord). 25 | This is where all (text) discussion and (live video) meetings take place. 26 | You will find multiple channels, each for a particular topic of the Unikraft ecosystem. 27 | 28 | As a newcomer, start by presenting yourself (name, university / occupation, interest in Unikraft, current experience). 29 | It's best if you use a `Firstname Lastname` nickname to make it easy for others to get in touch with you. 30 | 31 | Ask any questions, worry not about anything, we're happy to assist you in feeling at home in the Unikraft community. 32 | In particular, use the `#gsoc` and the `#support` channels. 33 | 34 | ### Get accustomed to the Unikraft development ecosystem 35 | 36 | Unikraft development happens on the [Unikraft GitHub organization](https://github.com/unikraft/). 37 | 38 | For starters, check the [guides](https://unikraft.org/guides) on using the [`catalog` repository](https://github.com/unikraft/catalog): 39 | 40 | - https://unikraft.org/guides/using-the-app-catalog 41 | - https://unikraft.org/guides/catalog-behind-the-scenes 42 | - https://unikraft.org/guides/catalog-using-firecracker 43 | - https://unikraft.org/docs/contributing/adding-to-the-app-catalog 44 | 45 | See the [contributing guides](https://unikraft.org/docs/contributing). 46 | 47 | Also take a look and build, run and test as many applications in the [`catalog-core` repository](https://github.com/unikraft/catalog-core) as possible. 48 | These give you a very nice set of initial hands-on tasks to get you started with grabbing, configuring, building and running Unikraft. 49 | 50 | ### Make a small contribution 51 | 52 | The best way to prepare your application is to make small contributions. 53 | 54 | First off, browse the [Unikraft Contribution Guidelines](https://unikraft.org/docs/contributing/). 55 | This gives you an overview of how we expect you to write your code, create commits and make contributions and GitHub pull requests (PRs). 56 | 57 | Then aim for small, easy to do contributions. 58 | Look for items such as: 59 | 60 | * Removing build warnings for any of the repositories in the [Unikraft GitHub organization](https://github.com/unikraft/). 61 | * Fixing inconsistencies or adding missing information in the [documentation](https://github.com/unikraft/docs) (rendered on the [main Unikraft website](https://unikraft.org/)). 62 | * Adding [tests](https://unikraft.org/docs/develop/writing-tests/) to Unikraft components. 63 | * Adding applications to the [`catalog-core` repository](https://github.com/unikraft/catalog-core). 64 | * Adding applications to the [`catalog` repository](https://github.com/unikraft/catalog). 65 | * Tasks in the [`Hackathons` GitHub project](https://github.com/orgs/unikraft/projects/29). 66 | * Issues marked with the [`good-first-issue` label](https://github.com/unikraft/unikraft/issues?q=is%3Aissue+is%3Aopen+label%3Agood-first-issue+). 67 | * Adding documentation as `README.md` files and [Doxygen](https://www.doxygen.nl/)-style comments to [internal libraries](https://github.com/unikraft/unikraft/tree/staging/lib). 68 | 69 | ### Decide on a GSoC project 70 | 71 | We put together a [list of project ideas](https://github.com/unikraft/gsoc/blob/staging/gsoc-2025/ideas.md) that you can choose from. 72 | 73 | Note that this is not an exclusive list. 74 | You can suggest new project ideas to the Unikraft GSoC mentors on the `#gsoc` channel on [Discord](https://unikraft.org/discord). 75 | If your idea has been vetted by a mentor (or more) in the community, then you can submit it as part of your application. 76 | 77 | If you fancy a given project idea, ask about that on the `#gsoc` channel on [Discord](https://unikraft.org/discord). 78 | A mentor will reply and give you extra information. 79 | If that is indeed a project you want to work on, then you can submit it as part of your application. 80 | 81 | ### Fill out an application 82 | 83 | Once the application period has opened (in the March 24 - April 8, 2025 period), you have to submit your application on the [Google Summer of Code website](https://summerofcode.withgoogle.com/). 84 | Your application must be written in English. 85 | It should contain a detailed description of your project proposal. 86 | 87 | The application is a document that you will submit and that summarizes your motivation and suitability for the project. 88 | We recommend you copy our [Google Document template](https://docs.google.com/document/d/1TjoRgWMTjB114QlRVc7N5rZ6rswUzEN-JS-G_gB0Bso/edit?usp=sharing) and make sure you answer all the questions. 89 | 90 | ### Still have some doubts/questions? 91 | 92 | Ask away on [Discord](https://unikraft.org/discord), on the `#gsoc` channel. 93 | 94 | [^1]: Based on the excellent guide from [GNOME](https://gsoc.gnome.org/) 95 | -------------------------------------------------------------------------------- /gsoc-2025/ideas.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Google Summer of Code 2025 Ideas List 3 | --- 4 | 5 | ## Unikraft Project Ideas 6 | 7 | Thank you for your interest in participating in [Google Summer of Code 2025 (GSoC25)](https://summerofcode.withgoogle.com/programs/2025)! 8 | 9 | Unikernels are a novel Operating System (OS) model providing unprecedented optimization for software services. 10 | The technology offers a clean slate OS design which improves the efficiency of cloud services, IoT and embedded system applications by removing unnecessary software layers by specializing the OS image. 11 | One unikernel framework which provides minimal runtime footprint and fast (millisecond-level) boot times is Unikraft, and aims as a means to reduce operating costs for all services that utilize it as a runtime mechanism. 12 | 13 | Unikraft is a Unikernel Development Kit and consists of an extensive build system in addition to core and external library ecosystem which facilitate the underlying functionality of a unikernel. 14 | 15 | ## Mentors of the projects 16 | 17 | Mentors will be assigned when the project is initiated. Please feel free to reach out beforehand to discuss the project. 18 | 19 | | Mentor | Email | 20 | |--------|-------| 21 | | [Razvan Deaconescu](https://github.com/razvand) | razvan.deaconescu@upb.ro | 22 | | [Alexander Jung](https://github.com/nderjung) | alex@unikraft.io | 23 | | [Cezar Crăciunoiu](https://github.com/craciunoiuc) | cezar@unikraft.io | 24 | | [Michalis Pappas](https://github.com/michpappas) | michalis@unikraft.io | 25 | | [Ștefan Jumărea](https://github.com/StefanJum) | stefanjumarea02@gmail.com | 26 | | [Răzvan Vîrtan](https://github.com/razvanvirtan) | virtanrazvan@gmail.com | 27 | | [Hugo Lefeuvre](https://github.com/hlef) | hugo.lefeuvre@ubc.ca | 28 | 29 | Below are a list of open projects for Unikraft which can be developed as part of GSoC25. 30 | 31 | --- 32 | 33 | ### Expanding the Unikraft Software Support Ecosystem 34 | 35 | | | | 36 | |-|-| 37 | | **Difficulty** | 3/5 | 38 | | **Project Size** | Variable (175 or 350 hours) | 39 | | **Maximum instances** | 2 | 40 | | **Constraints/requirements** | Basic OS concepts, familiarity with POSIX and system calls, build systems and tool stacks. | 41 | 42 | #### Description 43 | 44 | One of the weak points of most unikernel projects has always been application support, often requiring that applications be ported to the target unikernel OS. 45 | With Unikraft we have been making a strong push towards POSIX compatibility so that applications can run unmodified on Unikraft. 46 | We have been doing this in two different ways: 47 | 48 | 1. by adding support for the Musl libc library such that applications can be compiled against it, using their native build systems, and then linked into Unikraft 49 | 1. through [binary-compatibility mode](https://unikraft.org/docs/concepts/compatibility), where unmodified ELFs are directly executed in Unikraft and the resulting syscalls trapped and redirected to the Unikraft core, via the [`app-elfloader`](https://github.com/unikraft/app-elfloader). 50 | 51 | This has lead to the creation of the [application `catalog` repository](https://github.com/unikraft/catalog) where running applications and examples are brought together. 52 | 53 | This project focuses on expanding Unikraft's software support ecosystem by [adding new applications](https://unikraft.org/docs/contributing/adding-to-the-app-catalog) to the [application `catalog` repository](https://github.com/unikraft/catalog), primarily in binary-compatibility mode. 54 | While doing this, you will also: 55 | 56 | 1. implement and extend system calls 57 | 1. add extensive testing for the application or framework that is to be included in the catalog 58 | 1. add benchmarking scripts to measure the performance and resource consumption of the application running with Unikraft 59 | 1. conduct synthetic tests using tools such as [the Linux Test Project](https://linux-test-project.github.io/) 60 | 61 | The success of this project will directly impact Unikraft adoption. 62 | The project length can be varied depending on which of these items are covered by the project. 63 | 64 | #### Reading & Related Material 65 | 66 | * https://www.musl-libc.org/ 67 | * https://unikraft.org/guides/using-the-app-catalog 68 | * https://github.com/unikraft/catalog 69 | * https://unikraft.org/docs/contributing/adding-to-the-app-catalog 70 | 71 | --- 72 | 73 | ### Software Quality Assurance of Unikraft Codebase 74 | 75 | | | | 76 | |-|-| 77 | | **Difficulty** | 3/5 | 78 | | **Project Size** | Variable (175 or 350 hours) | 79 | | **Maximum instances** | 2 | 80 | | **Constraints/requirements** | C programming skills, Linux command-line experience, build tools | 81 | 82 | #### Description 83 | 84 | During its 6 years of existence, Unikraft, now at version 0.16.1, has grown in features, application support and codebase. 85 | As it matures, a high quality of the code and robust behavior are a must to provide a stable solution for its user base. 86 | 87 | The aim of this project is to assist in the software quality assurance of the Unikraft codebase, by tackling one of the following ideas: 88 | 89 | 1. The use of the [`uktest` framework](https://github.com/unikraft/unikraft/tree/staging/lib/uktest) to create unit tests for [internal libraries](https://github.com/unikraft/unikraft/tree/staging/lib/) and [external libraries](https://github.com/search?q=topic%3Alibrary+org%3Aunikraft+fork%3Atrue&type=repositories). 90 | Not many libraries have unit tests, those that do are mostly exceptions. 91 | This will directly impact the stability of the code base and allow quick validation of new features that may break existing functionality. 92 | 93 | 1. Inclusion of static and dynamic analysis tools that highlight potential spots of faulty or undefined behavior. 94 | 95 | 1. The use of compiler builtins and compiler flags providing constraints on the code to increase its resilience to faulty behavior. 96 | 97 | 1. Augmenting the CI/CD system used by Unikraft (based on [GitHub Actions](https://github.com/features/actions)) to feature automatic testing, validation and vetting of contributions to Unikraft repositories: core, libraries, applications. 98 | Potential items are: 99 | 1. handling running of unikernels instead of simple builds 100 | 1. static analysis of images to be delivered as reports to GitHub pull requests 101 | 1. regression checks on performance (delivered as % change from the current upstream version) 102 | 103 | Any other project that is targeted towards increasing the robustness of Unikraft source code is welcome. 104 | These will both increase the viability of Unikraft as a stable solution and increase the quality of future contributions, by enforcing good practices on submitted code. 105 | 106 | #### Reading & Related Material 107 | 108 | * [Writing Tests in Unikraft](https://unikraft.org/docs/develop/writing-tests/) 109 | * https://www.guru99.com/unit-testing-guide.html 110 | * https://docs.kernel.org/dev-tools/kunit/index.html 111 | * https://github.com/features/actions 112 | * https://unikraft.org/docs/contributing/review-process/ 113 | 114 | --- 115 | 116 | ### Supporting macOS networking (medium-large, 175-350hrs) 117 | 118 | | | | 119 | |-|-| 120 | | **Difficulty** | 3/5 | 121 | | **Project Size** | Variable (175 or 350 hours) | 122 | | **Maximum instances** | 1 | 123 | | **Constraints/requirements** | Good Go skills, familiarity with virtualization, macOS and networking, good OS knowledge | 124 | 125 | #### Description 126 | 127 | [KraftKit](https://github.com/unikraft/kraftkit), the supporting codebase for the modular library operating system Unikraft designed for cloud native applications, provides users with the ability to build, package and run unikernels. 128 | As a Swiss-army-knife of unikernel development, it eases both the construction and deployment of unikernels. 129 | To this end, supporting diverse user environments and their ability to run unikernels locally supports the ultimate goal of the project. One such environment which requires more attention is macOS. 130 | 131 | Towards better facilitating the execution of unikernel virtual machine images on macOS, this project aims to introduce new packages which interface directly with macOS environments by interfacing natively with the local networking environment such that the execution of unikernels is accessible through a more direct communication mechanisms of the host. 132 | Until now, the project only supports Linux bridge networking with accommodation (albeit "stubs") in the codebase for Darwin. 133 | 134 | #### Reading & Related Material 135 | 136 | * https://github.com/unikraft/kraftkit/issues/841 137 | 138 | --- 139 | 140 | ### Converting the eroFS library to Golang and testing it 141 | 142 | | | | 143 | |-|-| 144 | | **Difficulty** | 3/5 | 145 | | **Project Size** | Variable (175 or 350 hours) | 146 | | **Maximum instances** | 1 | 147 | | **Constraints/requirements** | Good Go skills, decent C skills, familiarity with file systems, basic testing knowledge | 148 | 149 | #### Description 150 | 151 | [EROFS](https://docs.kernel.org/filesystems/erofs.html) (Enhanced Read-Only File System) is a lightweight, high-performance read-only filesystem tailored for Linux environments. 152 | It is designed to provide fast and efficient access to data while supporting built-in transparent compression, which helps reduce storage overhead. 153 | Currently, Golang has support through [libraries](https://pkg.go.dev/gvisor.dev/gvisor/pkg/erofs) only for reading EROFS files and no support for creating them. 154 | 155 | Towards better support in [KraftKit](https://github.com/unikraft/kraftkit/pull/2007), this project aims to introduce a new library that reimplements the `mkfs.erofs` command with all its functionality. 156 | This is [currently](https://github.com/erofs/erofs-utils/blob/dev/mkfs/main.c) implemented in C which can only be imported into Golang with C to Go bindings. 157 | Some [attempts](https://github.com/dpeckett/archivefs/tree/main/erofs) have been made to implement this, but are incomplete and do not offer all arguments, of which some we need. 158 | Finally, at all steps tests should be implemented that compare original functionality to the ported library functionality. 159 | 160 | #### Reading & Related Material 161 | 162 | * https://docs.kernel.org/filesystems/erofs.html 163 | * https://github.com/erofs/erofs-utils/blob/dev/mkfs/main.c 164 | * https://github.com/unikraft/kraftkit/pull/2007 165 | * https://pkg.go.dev/gvisor.dev/gvisor/pkg/erofs 166 | * https://github.com/dpeckett/archivefs/tree/main/erofs 167 | 168 | --- 169 | 170 | ### Fine-Tuning Unikraft's Performance 171 | 172 | | | | 173 | |-|-| 174 | | **Difficulty** | 3/5 | 175 | | **Project Size** | Variable (175 or 350 hours) | 176 | | **Maximum instances** | 1 | 177 | | **Constraints/requirements** | Good C skills, familiarity with general operating system concepts, good testing knowledge | 178 | 179 | #### Description 180 | 181 | Over the past releases the development focus of Unikraft has been set on improving its compatibility with existing code bases and adding missing operating system features. 182 | This means that less efforts were dedicated to performance-testing Unikraft, resulting in a potential loss of performance in recent releases. 183 | Now that Unikraft is reaching the desired level of maturity and compatibility, it is time to go back to evaluating and fine-tuning its performance. 184 | 185 | The aim of this project is to 1) evaluate the current performance of Unikraft, 2) identify potential performance bottlenecks, and 3) address these bottlenecks through targeted patches. 186 | - To evaluate the performance of Unikraft, this project will base on the evaluation of the Unikraft EuroSys paper, re-running experiments with the latest release of Unikraft. 187 | The first phase of the project will be to create a new repository with updated experiments that can easily be run in a push-button manner (deliverable 1). 188 | - Following this, bottlenecks will be identified. 189 | Performance bottlenecks may lie in any Unikraft component: this will be a unique opportunity to touch on many operating system concepts. 190 | Performance bottlenecks will be reported in the form of GitHub issues (deliverable 2). 191 | - Finally, the project will aim to provide self-contained, targeted fixes for these bottlenecks in the form of GitHub Pull-Requests (deliverable 3). 192 | 193 | This project is a unique opportunity to learn about performance evaluation and optimization in a production-grade operating system. 194 | It is also an opportunity to participate in a potential academic journal submission of Unikraft by refreshing its evaluation. 195 | 196 | #### Reading & Related Material 197 | 198 | * The Unikraft EuroSys 2021 paper (see the Evaluation, Section 5): https://dl.acm.org/doi/10.1145/3447786.3456248 199 | * The EuroSys 2021 evaluation repository: https://github.com/unikraft/eurosys21-artifacts 200 | 201 | --- 202 | 203 | ### Testing Framework for Unikraft Builds 204 | 205 | | | | 206 | |-|-| 207 | | **Difficulty** | 3/5 | 208 | | **Project Size** | Variable (175 or 350 hours) | 209 | | **Maximum instances** | 1 | 210 | | **Constraints/requirements** | Python knowledge, Linux CLI | 211 | 212 | #### Description 213 | 214 | We are currently developing a [testing framework](https://github.com/unikraft-upb/catalog/tree/razvand/generator/new-design/utils/new-design) that is able to multiplex the variety of configuration options, VMMs, hypervisors, architectures, boot protocols, to validate the successful building and running of unikernel images. 215 | This framework is able to configure, build, run and test the variety of Unikraft builds. 216 | It is written in Python and is subject to improvements and refactoring. 217 | 218 | We are looking to augment the testing infrastructure to make it seamless to be used by Unikraft developers and users. 219 | To this end we aim to: 220 | 221 | - Consolidate the testing framework as a separate project inside its own repository. 222 | - Have the testing framework work out-of-the-box with the [`catalog`](https://github.com/unikraft/catalog) and [`catalog-core`](https://github.com/unikraft/catalog-core) repositories. 223 | - Integrate the testing framework with the CI/CD system used in the [Unikraft organization repositories](https://github.com/unikraft) to automatically validate builds for contributions. 224 | Tests are to be triggered each time a pull request is open in the [`unikraft`](https://github.com/unikraft/unikraft) and in core library repositories. 225 | 226 | #### Reading & Related Material 227 | 228 | * https://github.com/unikraft/catalog 229 | * https://github.com/unikraft/catalog-core 230 | * https://github.com/unikraft-upb/catalog/tree/razvand/generator/new-design/utils/new-design 231 | 232 | --- 233 | 234 | ### Update Newlib and Pthread-embedded Libraries 235 | 236 | | | | 237 | |-|-| 238 | | **Difficulty** | 3/5 | 239 | | **Project Size** | Variable (175 or 350 hours) | 240 | | **Maximum instances** | 1 | 241 | | **Constraints/requirements** | C, assembly, Linux CLI, GNU build tools | 242 | 243 | #### Description 244 | 245 | The default Unikraft standard C library (libc) is [Musl](https://github.com/unikraft/lib-musl), a lightweight libc providing a POSIX interface. 246 | Up until 2022, the default libc was [Newlib](https://github.com/unikraft/lib-newlib). 247 | Starting with [release 0.11.0](https://unikraft.org/blog/2022-12-02-unikraft-releases-janus) the default libc switched to Musl. 248 | 249 | Ever since that point, Newlib supported hasn't been updated to keep up with the recent version of Unikraft. 250 | 251 | The goal of this project is to update [Newlib](https://github.com/unikraft/lib-newlib) and [`pthread-embedded`](https://github.com/unikraft/lib-pthread-embedded) support to the recent Unikraft versions. 252 | Such as current builds would work out-of-the-box with Newlib and pthread-embedded as well as Musl. 253 | 254 | The steps to be done are: 255 | 256 | 1. Update Newlib and pthread-embedded to build with the most recent Unikraft version. 257 | 1. Update Newlib version to the [most recent upstream version](https://sourceware.org/newlib/). 258 | 1. Build and run applications on the [`catalog-core`](https://github.com/unikraft/catalog-core) and [`catalog`](https://github.com/unikraft/catalog) repositories. 259 | 1. (Optionally) Add CI pipelines to work with Newlib and pthread-embedded. 260 | 261 | #### Reading & Related Material 262 | 263 | * https://github.com/unikraft/lib-newlib 264 | * https://github.com/unikraft/lib-pthread-embedded 265 | * https://github.com/RWTH-OS/pthread-embedded 266 | * https://sourceware.org/newlib/ 267 | 268 | --- 269 | 270 | ### Update Unikraft Core External Libraries 271 | 272 | | | | 273 | |-|-| 274 | | **Difficulty** | 3/5 | 275 | | **Project Size** | Variable (175 or 350 hours) | 276 | | **Maximum instances** | 2 | 277 | | **Constraints/requirements** | C, assembly, Linux CLI, GNU build tools | 278 | 279 | #### Description 280 | 281 | The Unikraft core external libraries haven't been updated in the past 2 years. 282 | We aim to update them to their latest version. 283 | That means: 284 | 285 | - Update [`lib-musl`](https://github.com/unikraft/lib-musl) from 1.2.3 to 1.2.5 (the most recent [upstream Musl](https://musl.libc.org/) version). 286 | - Update [`lib-lwip`](https://github.com/unikraft/lib-lwip) from 2.1.2 to 2.2.1 (the most recent [upstream LWIP](https://savannah.nongnu.org/projects/lwip/) version). 287 | - Update [`lib-gcc`](https://github.com/unikraft/lib-gcc) from 7.3.0 to 14.2.0 (the most recent [upstream GCC](https://ftp.gnu.org/gnu/gcc/) version). 288 | - Update [`lib-libcxx`](https://github.com/unikraft/lib-libcxx) from 14.0.6 to 19.1.7 (the most recent [upstream LLVM](https://github.com/llvm/llvm-project/releases) version). 289 | - Update [`lib-libcxxabi`](https://github.com/unikraft/lib-libcxxabi) from 14.0.6 to 19.1.7 (the most recent [upstream LLVM](https://github.com/llvm/llvm-project/releases) version). 290 | - Update [`lib-compiler-rt`](https://github.com/unikraft/lib-compiler-rt) from 14.0.6 to 19.1.7 (the most recent [upstream LLVM](https://github.com/llvm/llvm-project/releases) version). 291 | - Update [`lib-libunwind`](https://github.com/unikraft/lib-libunwind) from 14.0.6 to 19.1.7 (the most recent [upstream LLVM](https://github.com/llvm/llvm-project/releases) version). 292 | 293 | The update is aimed to use the [workflow for Unikraft microlibrary version](https://docs.google.com/document/d/1A-CAss5RvgYapg3YO8GNCdMki6cgq_7XG5om8nVWWGk/edit?usp=sharing). 294 | As part of the update effort, we aim to also test and validate builds for the [`catalog-core`](https://github.com/unikraft/catalog-core) and [`catalog`](https://github.com/unikraft/catalog) repositories. 295 | 296 | #### Reading & Related Material 297 | 298 | * [RFC: Unikraft Microlibrary Versioning](https://docs.google.com/document/d/1A-CAss5RvgYapg3YO8GNCdMki6cgq_7XG5om8nVWWGk/edit?usp=sharing) 299 | 300 | --- 301 | 302 | ### Update Unikraft Application Libraries 303 | 304 | | | | 305 | |-|-| 306 | | **Difficulty** | 3/5 | 307 | | **Project Size** | Variable (175 or 350 hours) | 308 | | **Maximum instances** | 2 | 309 | | **Constraints/requirements** | C, assembly, Linux CLI, GNU build tools | 310 | 311 | #### Description 312 | 313 | The Unikraft application libraries haven't been updated in the past 2 years. 314 | We aim to update them to their latest upstream version. 315 | Target libraries / applications are: 316 | 317 | - [`lib-nginx`](https://github.com/unikraft/lib-nginx) 318 | - [`lib-redis`](https://github.com/unikraft/lib-redis) 319 | - [`lib-sqlite`](https://github.com/unikraft/lib-sqlite) 320 | - [`lib-python3`](https://github.com/unikraft/lib-python3) 321 | - [`lib-libgo`](https://github.com/unikraft/lib-libgo) 322 | - [`lib-lua`](https://github.com/unikraft/lib-lua) 323 | 324 | The update is aimed to use the [workflow for Unikraft microlibrary version](https://docs.google.com/document/d/1A-CAss5RvgYapg3YO8GNCdMki6cgq_7XG5om8nVWWGk/edit?usp=sharing). 325 | As part of the update effort, we aim to also test and validate builds for the [`catalog-core`](https://github.com/unikraft/catalog-core) and [`catalog`](https://github.com/unikraft/catalog) repositories. 326 | 327 | #### Reading & Related Material 328 | 329 | * [RFC: Unikraft Microlibrary Versioning](https://docs.google.com/document/d/1A-CAss5RvgYapg3YO8GNCdMki6cgq_7XG5om8nVWWGk/edit?usp=sharing) 330 | 331 | --- 332 | 333 | ### Add FreeBSD Libc as Unikraft External Library 334 | 335 | | | | 336 | |-|-| 337 | | **Difficulty** | 3/5 | 338 | | **Project Size** | Variable (175 or 350 hours) | 339 | | **Maximum instances** | 1 | 340 | | **Constraints/requirements** | C, assembly, Linux CLI, GNU build tools | 341 | 342 | #### Description 343 | 344 | The default Unikraft standard C library (libc) is [Musl](https://github.com/unikraft/lib-musl), a lightweight libc providing a POSIX interface. 345 | [FreeBSD Libc](https://github.com/freebsd/freebsd-src/tree/main/lib/libc) is the default libc used by default by FreeBSD, with a compatible license with Unikraft. 346 | 347 | The goal of this project is have a FreeBSD libc build repository for Unikraft and build existing applications against it. 348 | In the end, you would be able to build and run applications on the [`catalog-core`](https://github.com/unikraft/catalog-core) and [`catalog`](https://github.com/unikraft/catalog) repositories using the FreeBSD libc variant. 349 | 350 | #### Reading & Related Material 351 | 352 | * https://github.com/freebsd/freebsd-src/tree/main/lib/libc 353 | 354 | --- 355 | -------------------------------------------------------------------------------- /gsoc-2025/work-product/.gitignore: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/unikraft/gsoc/4041e2b0b4e7c41935a983deeb412989e17ad0ab/gsoc-2025/work-product/.gitignore -------------------------------------------------------------------------------- /work-product-template.md: -------------------------------------------------------------------------------- 1 | # Project name 2 | 3 | ## GSoC contributor 4 | 5 | Name: 6 | 7 | Email: 8 | 9 | Github profile: 10 | 11 | ## Mentors 12 | 13 | ## Contributions 14 | 15 | ## Blog posts 16 | 17 | ## Documentation (opt) 18 | 19 | ## Current status 20 | 21 | ## Future work 22 | 23 | ## Main takeaways (opt) --------------------------------------------------------------------------------