1. Client Virtualization Toolstack in Go
Nicholas Rosbrook, Software Engineer, Assured Information Security
Brendan Kerrigan, Principal Software Engineer, Assured Information Security

2. Overview
• Introduction
• Motivation
• Evaluation
• Redfield and redctl
• Libxl Go (Golang) bindings
• Questions

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. 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. Evaluation
• What’s out there we can leverage?
• XenMgr
• Libvirt (+ qubectl)
• What if we had a clean slate?

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. 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. 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. 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. What is cgo?

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. 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. Writing a Go Package for libxl

14. Writing a Go Package for libxl
• Finally, we need some wrappers…

15. Writing a Go Package for libxl
• Instead of:

16. Writing a Go Package for libxl
• We want:

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. Questions?
• https://ainfosec.com
• https://gitlab.com/redfield