Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

XPDDS19: Client Virtualization Toolstack in Go - Nick Rosbrook & Brendan Kerrigan, Assured Information Security, Inc.

6 views

Published on

High level toolstacks for server and cloud virtualization are very mature with large communities using and supporting them. Client virtualization is a much more niche community with unique requirements when compared to those found in the server space. In this talk, we’ll introduce a client virtualization toolstack for Xen (redctl) that we are using in Redfield, a new open-source client virtualization distribution that builds upon the work done by the greater virtualization and Linux communities. We will present a case for maturing libxl’s Go bindings and discuss what advantages Go has to offer for high level toolstacks, including in the server space.

Published in: Software
  • Be the first to comment

  • Be the first to like this

XPDDS19: Client Virtualization Toolstack in Go - Nick Rosbrook & Brendan Kerrigan, Assured Information Security, Inc.

  1. 1. Client Virtualization Toolstack in Go Nicholas Rosbrook, Software Engineer, Assured Information Security Brendan Kerrigan, Principal Software Engineer, Assured Information Security
  2. 2. Overview • Introduction • Motivation • Evaluation • Redfield and redctl • Libxl Go (Golang) bindings • Questions
  3. 3. Introduction • Brendan Kerrigan – Principal Engineer at Assured Information Security, Inc. • Hypervisors • Graphics virtualization • Embedded • Nicholas Rosbrook – Software Engineer at Assured Information Security, Inc. • Cryptography • VPNs and Networking • Go expert
  4. 4. Motivation • We do a lot of client virtualization work • Utilizing hypervisors to do end point security • Mostly OpenXT based products now • OpenXT isn’t the easiest project to work on (10 years of development means there are lots of components) • Sometimes key high-security features can be a hindrance to some use cases • Client virtualization is pretty different than server virtualization • Especially when it comes to toolstacks
  5. 5. Evaluation • What’s out there we can leverage? • XenMgr • Libvirt (+ qubectl) • What if we had a clean slate?
  6. 6. XenMgr • XenMgr is high friction • Haskell • Esoteric • Tough to find developers • Lots of legacy interfaces that are unexercised and unaudited (audit in progress) • A lot of cryptic code that essentially reads a database and writes an xl config and calls exec/fork • Local and remote APIs are different  • The command line tool is great
  7. 7. Libvirt • One layer of abstraction too many • XML domain configurations are too complex • Designed to work with several virtualization technologies – KVM, Xen, LXC, etc. • We want to work with Xen and do it well • Does a lot more than we need it to • There is an existing Go package (developed by DigitalOcean)
  8. 8. redctl • Introducing redctl, the client toolstack to our Xen distribution, Redfield • The good: • A client toolstack where remote and local management APIs are unified • Utilize gRPC • Don’t dictate transport (IPv4, IPv6, PV channels, Argo, vsock) • Easy to understand and test language (Go) • Make the command line tool awesome (like XenMgr’s) • The bad: • Still doing exec/fork a lot when dealing with libxl…
  9. 9. What is cgo? • Cgo enables Go programs to call C code through a pseudo- package, “C” • Allows access of C types, variables, and functions • E.g. C.size_t, C.stdout, C.printf • The “preamble” • A block comment used to include headers, set CFLAGS, LDFLAGS, etc. • Immediately precedes the import “C” statement
  10. 10. What is cgo?
  11. 11. What is cgo? • C fields that cannot be expressed in Go are omitted • The C type void* is represented by Go’s unsafe.Pointer • Cannot call C function pointers from Go • There are some restrictions on passing pointers between C and Go
  12. 12. Writing a Go Package for libxl • Writing the cgo code by hand is tedious • Cgo is simple enough to make code generation easy • We use c-for-go: https://github.com/xlab/c-for-go • Define translation and generation rules with a YAML configuration file • Accept or ignore symbols, rename variables, apply rules to a given scope, and more
  13. 13. Writing a Go Package for libxl
  14. 14. Writing a Go Package for libxl • Finally, we need some wrappers…
  15. 15. Writing a Go Package for libxl • Instead of:
  16. 16. Writing a Go Package for libxl • We want:
  17. 17. Future Work • Continue writing wrappers • Trim the size of the package • Integrate into redctl • Upstream • Current fork: https://github.com/enr0n/xen/tree/libxl-go
  18. 18. Questions? • https://ainfosec.com • https://gitlab.com/redfield

×