[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] RFC: Still TODO for 4.2?

On Thu, Jan 19, 2012 at 8:35 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>> On 17.01.12 at 10:09, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>>>> On 16.01.12 at 14:39, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
>> On Wed, 2012-01-04 at 16:55 +0000, Jan Beulich wrote:
>>> >>> On 04.01.12 at 17:29, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
>>> > What are the outstanding things to do before we think we can start on
>>> > the 4.2 -rc's? Does anyone have a timetable in mind?
>>> >
>>> > hypervisor:
>>> >
>>> >       * ??? - Keir, Tim, Jan?
>>> Apart from a few small things that I have on my todo list, the only
>>> bigger one (at least from an possible impact perspective) is the
>>> round-up of the closing of the security hole in MSI-X passthrough
>>> (uniformly - i.e. even for Dom0 - disallowing write access to MSI-X
>>> table pages), which I intended to do only once the upstream qemu
>>> patch series also incorporates the respective recent qemu-xen
>>> change.
>> It sounds like this issue is a blocker for the release, whereas the
>> upstream qemu support for pci passthrough is not necessarily. Has your
>> precondition for inclusion been met yet or do we need to prod someone?
> Just for reference, below the intended (trivial) change.

As unfortunate as it is - I just found that the security hole is all but
closed, due to xen/arch/x86/hvm/vmsi.c:msixtbl_write() writing
whatever the guest specified into the 3rd word of each MSI-X table
entry. There is also another hypervisor data corrupting flaw in that
code; I'm in the process of putting together a patch, but will (again)
need someone with suitable hardware to test this.


Xen-devel mailing list

I do have a set of initial patches for xl remus. Since the "script=" support
doesnt exist for disk configurations (required to support both DRBD and tapdisk backends).

So, currently I only have memory checkpointing functionality. No disk buffering.
Will submit it in a day or so.

About network buffering:
a.  There is code to install and manipulate the network buffer via netlink messages. And its
in python. While the "xl remus" control flow starts off from C. Either I implement the C equivalent
of the python code or call the python code from C (this is C->python and not the other way around).
Please correct me if I am wrong.

b. The kernel module (sch_plug):  Last I knew, the network
buffering module (sch_plug) was in the pvops tree (2.6.* series). When the tree
moved to 3.0 series, it got axed off.

 While I am still, convincing the netdev folks into accepting this module upstream,
I  have a link in the remus wiki, asking people to download/compile the module.
(People do this only after shooting a couple of "Remus is not working" emails to the
mailing list)

 As an alternative, I could pull it into the tools/remus/ folder (just like
the way it used to be before the pvops kernels) and compile it as part of the
tools compilation process.

But as starters, people would be able to play with remus via xl (just memory
What do you folks think?

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.