You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am proud to announce the release of Bareflank v3.0.0. It has been a long journey to get to this point, but we are finally here. Version v3.0.0 includes the following changes:
Microkernel
Previous versions of Bareflank used a monolithic approach, requiring the user to use Bareflank specific APIs to register callbacks to extend the functionality of the Bareflank hypervisor to create your own, customer hypervisors. This was similar to writing a device driver for the Linux kernel. The problem with this approach was that like the Linux kernel, APIs change and you have to code in the same language and build system required by the Linux kernel. As AIS made changes to the APIs to support it's own internal needs, this dramatically effected the rest of the community, often times breaking downstream projects. In addition, most hypervisor developers are unfamiliar with C++, which was required in previous versions (at least to some degree).
The microkernel design breaks the hypervisor up into a ring 0, kernel component and a ring 3 extension, both of which execute in VMX root (while everything else, including the host OS run in VMX non-root). Bareflank provides the kernel, while the user implements the actual VMM in the ring 3, userspace component we call an extension. The Bareflank then provides the Microkernel ABI Specification which documents a fully versioned, syscall ABI that extensions can use to communicate with the kernel to perform privileged operations. Not only does this provide better security for product focused use cases, it also provides a well defined division between the upstream logic, and your downstream logic with a simple and most importantly, stable ABI. The Bareflank project is committed to ensure changes to the ABI are backwards compatible, similar to how Windows and Linux make modifications to their syscall interfaces. If any, extension specific logic changes in the project, downstream users can safely use their existing extension specific logic with an updated kernel without breaking changes. In addition, extension authors can now, safely write their extensions in any language and use any build system they prefer. We even provide a default example using Rust instead of C++. That's right, Bareflank supports the development of a VMM in Rust. You can use whatever build system you want, and whatever language you want. If you stick to CMake, you can use integrate with Bareflank's existing build system for a seamless experience, but it is not required. Simply tell vmmctl which kernel and which extension you want to use, no matter how they were built, and that's it.
Native Windows Support
The previous version of Bareflank used libc++ and newlib with a custom unwinder. Although this provided support for a number of C++ features, it required the use of cygwin to compile on Windows due to newlib's use of a Linux specific build system. Bareflank now uses the BSL, which provides an exception free, dynamic memory free, critical system's compliant implementation of a small subset of the C++ library (that also supports Rust). This removed every external dependency the project had, meaning all of Bareflank can be compiled natively on Windows. The only Bareflank specific feature that is not supported on Windows is generating code coverage reports (as this still uses LCOV). Everything else uses LLVM, ninja and bash that comes with Git for Windows. This dramatically simplifies development on Windows and greatly improves the overall developer experience.
AMD support (and soon ARMv8)
Bareflank now comes with support for AMD. In fact, all of Bareflank v3.0 was developed on AMD and then ported to Intel, ensuring development for AMD was taken seriously. The loader also has support for ARMv8. Future support for ARMv8 is coming soon so stay tuned. Previous versions of Bareflank had too many dependencies that made ARM almost impossible including newlib and our custom unwinder. With the use of the BSL, ARM support is simply a matter of finding the time to complete this feature. If you are interested in helping to complete ARM support faster, please let us know.
Critical Systems Compliance
Bareflank is now compliant with AUTOSAR and MISRA including full unit and integration testing with MC/DC testing. Actually, Bareflank is developed without the use of any Boolean operators and a strick if/else policy enforced by Clang Tidy and our CI, ensuring that simple line coverage also satisfies all MC/DC paths. As a result, AIS is developing MicroV, which is a critical systems compliant, Type 1, cross platform, edge computing focused hypervisor that implements KVM's API, but with strong isolation and a small TCB capable of supporting your government and critical system needs.
This discussion was created from the release v3.0.0.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I am proud to announce the release of Bareflank v3.0.0. It has been a long journey to get to this point, but we are finally here. Version v3.0.0 includes the following changes:
Microkernel
Previous versions of Bareflank used a monolithic approach, requiring the user to use Bareflank specific APIs to register callbacks to extend the functionality of the Bareflank hypervisor to create your own, customer hypervisors. This was similar to writing a device driver for the Linux kernel. The problem with this approach was that like the Linux kernel, APIs change and you have to code in the same language and build system required by the Linux kernel. As AIS made changes to the APIs to support it's own internal needs, this dramatically effected the rest of the community, often times breaking downstream projects. In addition, most hypervisor developers are unfamiliar with C++, which was required in previous versions (at least to some degree).
The microkernel design breaks the hypervisor up into a ring 0, kernel component and a ring 3 extension, both of which execute in VMX root (while everything else, including the host OS run in VMX non-root). Bareflank provides the kernel, while the user implements the actual VMM in the ring 3, userspace component we call an extension. The Bareflank then provides the Microkernel ABI Specification which documents a fully versioned, syscall ABI that extensions can use to communicate with the kernel to perform privileged operations. Not only does this provide better security for product focused use cases, it also provides a well defined division between the upstream logic, and your downstream logic with a simple and most importantly, stable ABI. The Bareflank project is committed to ensure changes to the ABI are backwards compatible, similar to how Windows and Linux make modifications to their syscall interfaces. If any, extension specific logic changes in the project, downstream users can safely use their existing extension specific logic with an updated kernel without breaking changes. In addition, extension authors can now, safely write their extensions in any language and use any build system they prefer. We even provide a default example using Rust instead of C++. That's right, Bareflank supports the development of a VMM in Rust. You can use whatever build system you want, and whatever language you want. If you stick to CMake, you can use integrate with Bareflank's existing build system for a seamless experience, but it is not required. Simply tell vmmctl which kernel and which extension you want to use, no matter how they were built, and that's it.
Native Windows Support
The previous version of Bareflank used libc++ and newlib with a custom unwinder. Although this provided support for a number of C++ features, it required the use of cygwin to compile on Windows due to newlib's use of a Linux specific build system. Bareflank now uses the BSL, which provides an exception free, dynamic memory free, critical system's compliant implementation of a small subset of the C++ library (that also supports Rust). This removed every external dependency the project had, meaning all of Bareflank can be compiled natively on Windows. The only Bareflank specific feature that is not supported on Windows is generating code coverage reports (as this still uses LCOV). Everything else uses LLVM, ninja and bash that comes with Git for Windows. This dramatically simplifies development on Windows and greatly improves the overall developer experience.
AMD support (and soon ARMv8)
Bareflank now comes with support for AMD. In fact, all of Bareflank v3.0 was developed on AMD and then ported to Intel, ensuring development for AMD was taken seriously. The loader also has support for ARMv8. Future support for ARMv8 is coming soon so stay tuned. Previous versions of Bareflank had too many dependencies that made ARM almost impossible including newlib and our custom unwinder. With the use of the BSL, ARM support is simply a matter of finding the time to complete this feature. If you are interested in helping to complete ARM support faster, please let us know.
Critical Systems Compliance
Bareflank is now compliant with AUTOSAR and MISRA including full unit and integration testing with MC/DC testing. Actually, Bareflank is developed without the use of any Boolean operators and a strick if/else policy enforced by Clang Tidy and our CI, ensuring that simple line coverage also satisfies all MC/DC paths. As a result, AIS is developing MicroV, which is a critical systems compliant, Type 1, cross platform, edge computing focused hypervisor that implements KVM's API, but with strong isolation and a small TCB capable of supporting your government and critical system needs.
This discussion was created from the release v3.0.0.
Beta Was this translation helpful? Give feedback.
All reactions