Monthly Archives: February 2017

Xen Project Participates in Google Summer of Code and Outreachy

This is a quick announcement that the Xen Project is again participating in Google Summer of Code (GSoC), a program that awards three-month paid stipends to University students to work on open source projects, with the goal to get open source experience. The Xen Project will also again participate in Outreachy, which is an internship program that organises three-month paid internships with free and open-source software projects for people who are typically underrepresented in the technology industry. Outreachy has been helping women (cis and trans), trans men, genderqueer people and people from other discriminated backgrounds get involved in free and open source software for several years. The Xen Project is proud that it has participated continually in Outreachy (and its predecessor OPW) for 4 years.

I want to participate, how do I get started?

If you are not at all familiar with programs such as GSoC and Outreachy, have a quick look at our introduction. In a nutshell, both programs go through several stages:

  • Check eligibility requirements.
  • Now until application period: Preparation by working on small tasks (also called micro-tasks) within our community to identify a suitable project and to familiarise yourself with the technology.
  • Application Period (aka paperwork): For GSoC, the application system is open from March 20 to Apr 3, 2017; however you should work on micro-tasks before and prepare your application together with a mentor as early as possible. For Outreachy, the application system is already open and will close March 30, 2017 (but you can edit and modify proposals submitted in agreement with your mentor until April 28th).
  • Selection Period: After applying to participate, our mentors will chose the most promising candidates. Successful candidates will be announced on the following dates: April 28 (Outreachy), May 4 (GSoC).
  • Internship Duration: May 30 to August 29 (GSoC) and August 30 (Outreachy).

For a list of projects for participants and more information on how to apply, check our Xen Project 2017 Summer Internship Portal. We have many different projects in many different areas: from Hypervisor work, projects in Mirage OS, to tools and test related tasks. Note that we will be adding extra projects to this page in the coming weeks and that applicants can suggest projects on their own.

You may also want to check out the pages of GSoC mentoring organisations which we collaborate with. Sometimes, you will find Xen related projects there: FreeBSD (currently 2 projects), QEMU, Libvirt.

Learn about the Experience of past Participants

At a past Xen Project Developer Summit, we ran a panel discussion that included Outreachy interns, GSoC students as well as mentors.


You may also want to read Women interns rocking open source at Xen Project.

How To Shrink Attack Surfaces with a Hypervisor

A software environment’s attack surface is defined as the sum of points in which an unauthorized user or malicious adversary can enter or extract data. The smaller the attack surface, the better. Linux.com recently sat down with Doug Goldstein (https://github.com/cardoe or @doug_goldstein) to discuss how companies can use hypervisors to reduce attack surfaces and why the Xen Project hypervisor is a perfect choice for security-first environments. Doug is a principal software engineer at Star Lab, a company focused on providing software protection and integrity solutions for embedded systems.

You can read the full interview here.

Request for Comment: Scope of Vulnerabilities for which XSAs are issued

Issuing advisories has a cost: It costs the security team significant amounts of time to craft and send the advisories; it costs many of our downstreams time to apply, build, and test patches; and it costs many of our users time to decide whether to do an update, and if so, to test and deploy it.

Given this, the Xen Project Security Team wants to clarify when they should issue an advisory or not: the Xen Security Response Process only mentions “‘vulnerabilities”, without specifying what constitutes a vulnerability.

We would like guidelines from the community about what sorts of issues should be considered security issues (and thus will have advisories issued). I have posted the second version a draft of a section I am proposing to be added to the Xen Security Policy to xen-devel; a copy is included below for your convenience. There are only minor modifications from the first draft, so barring major feedback from the wider community it will likely achieve consensus. If you want input, now is the time to speak up.

Most of it is just encoding long-established practice. But there are two key changes and / or clarifications that deserve attention and discussion:

    Criteria 2c: Leaking of mundane information from Xen or dom0 will not be considered a security issue unless it may contain sensitive guest or user data

Criteria 4: If no operating systems are vulnerable to a bug, no advisory will be issued.

If you want to weigh in on the question, please join the discussion on xen-devel before 28 February. The title of the thread is “RFC v2: Scope of Vulnerabilities for which XSAs are issued”.

Continue reading