14:10:19 <sbonazzo> #startmeeting Virt SIG Meeting
14:10:19 <centbot> Meeting started Tue Jun 13 14:10:19 2017 UTC.  The chair is sbonazzo. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:10:19 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:10:32 <sbonazzo> who's here for virt sig?
14:10:43 <alynpost> alynpost.
14:11:01 <sbonazzo> #chair alynpost
14:11:01 <centbot> Current chairs: alynpost sbonazzo
14:11:05 <srn_prgmr> srn_prgmr
14:11:17 <sbonazzo> #chair srn_prgmr
14:11:17 <centbot> Current chairs: alynpost sbonazzo srn_prgmr
14:11:18 <alynpost> #chair srn_prgmr
14:11:18 <centbot> Current chairs: alynpost sbonazzo srn_prgmr
14:11:20 <alynpost> hee.
14:11:40 <sbonazzo> alynpost: do you want to start?
14:12:11 <alynpost> I will, I can be quite brief.  Last meeting I asked for reading material to onboard myself.  I've worked through that at roughly what I'd call a week's pace.
14:12:30 <alynpost> That pace is not as fast as... well anyone else.
14:12:57 <alynpost> but having that material under me I'd like to spend this week playing with the tooling.  That's my report.
14:13:12 <sbonazzo> #topic onboaring
14:13:39 <sbonazzo> #info alynpost reading materia for onboarding, will continue during the week
14:13:49 <sbonazzo> thanks
14:13:52 <alynpost> I appreciate your patience!
14:14:02 <sbonazzo> alynpost: we'have no hurry :-)
14:14:13 <sbonazzo> srn_prgmr: willing to go next?
14:15:36 <srn_prgmr> uh, yeah. I've been working https://github.com/CentOS-virt7/xen/pull/16#pullrequestreview-43730806 for xen 4.8. gwd mentioned something about xsmpolicy being useless if flask isn't enabled, but we had vaguely talked about using it at some point, so I may look into how to use it.
14:15:52 <sbonazzo> #topic Xen updates
14:16:08 <srn_prgmr> Another thing I wanted to do was enable livepatch in the xen4centos kernel as well as debuginfo. I could use help with how to add a debuginfo package
14:16:27 <srn_prgmr> I got vmlinux copied into the debuginfo package but the module .debug's are wrong
14:16:58 <sbonazzo> #info srn_prgmr working on  https://github.com/CentOS-virt7/xen/pull/16#pullrequestreview-43730806 for xen 4.8.
14:17:37 <sbonazzo> #info might use xsmpolicy even if useless if flask isn't enabled
14:17:56 <sbonazzo> #info got vmlinux copied into the debuginfo package but the module .debug's are wrong
14:18:03 <sbonazzo> srn_prgmr: anything else?
14:18:25 <srn_prgmr> #info multiple reports of problems with 4.9 kernel
14:18:33 <srn_prgmr> if you look on the mailing list :/
14:19:04 <sbonazzo> :-/
14:19:19 <srn_prgmr> is anyone else in centos using that recent of a kernel?
14:19:38 <sbonazzo> srn_prgmr: you can ask on mailing list, I guess you'll have a wider audience
14:20:28 * gwd notices the meeting going on
14:20:28 <srn_prgmr> k
14:20:41 <sbonazzo> #chair gwd
14:20:41 <centbot> Current chairs: alynpost gwd sbonazzo srn_prgmr
14:20:46 <sbonazzo> gwd any update?
14:20:47 <gwd> Sorry. :-/
14:20:53 <sbonazzo> gwd np :-)
14:21:38 <gwd> #info A lot of XSAs coming out next Tuesday
14:22:27 <gwd> #info Confirm that 4.8 is making progress, should have something in testing soon
14:22:41 <gwd> #info In some discussions about how livepatching for Xen might work
14:22:50 <gwd> I think that's it for me.
14:22:56 <sbonazzo> gwd: thanks
14:23:03 <sbonazzo> #topic oVirt updates
14:23:36 <sbonazzo> #info kbsingh did the work yesterday and fixed all the scripts in the route from cbs to mirror, we should have packages being published soon
14:24:04 <sbonazzo> #info preparing for 4.1.3 release, scheduled on June 27th.
14:24:28 <sbonazzo> that's all on my side for now
14:24:43 <sbonazzo> any other topic to be covered?
14:25:04 <gwd> srn_prgmr: Did you want to chat quickly about xsmpolicy?
14:25:29 <sbonazzo> gwd, feel free to set appropriate topic :-)
14:25:38 <sbonazzo> giving back the meeting to your hands
14:25:42 <gwd> #topic Xen 4.8 package discussion
14:26:14 <srn_prgmr> gwd: sure. We had vaguely thought at some point of allowing customers to decide that they want to block us from accessing their memory. I thought that was possible with xsmflask but haven't seriously looked
14:27:32 <gwd> I think there are configurations where you can have the "toolstack domain" not actually have any permissions over normal running domains; seach for the "Xoar" paper.
14:27:58 <srn_prgmr> gwd: if it's better to disable flask in the interest of getting 4.8 out I'm willing to do that
14:27:59 <gwd> But that's a radically different architecture from a normal Xen system.
14:28:13 <gwd> So the thing is, flask is already disabled in the hypervisor.
14:28:47 <gwd> That's why I said that file is useless -- the binary that currently ships you can't even turn flask on.
14:29:24 <gwd> It's really a bug in the build system that it gets built at all.
14:29:36 <srn_prgmr> Right, per https://wiki.xenproject.org/wiki/Xen_Security_Modules_:_XSM-FLASK you have to turn it on explicitly
14:29:46 <srn_prgmr> I think it's probably too much to fit into the first 4.8 release
14:30:01 <srn_prgmr> turning it off in configure makes sense for now
14:30:16 <srn_prgmr> i will make that change
14:31:32 <gwd> Well more than that, the upstream version has some unresolved safety issues; namely, that at the moment we don't automatically detect deviations between the "default policy" and what happens when XSM is disabled
14:32:02 <gwd> And the only organization that maintains it (the NSA) only checks new versions when they themselves do an update.
14:32:22 <gwd> So it's not really safe for a downstream to enable it unless they're willing to do their own audit.
14:32:31 <srn_prgmr> That's good information, thank you
14:32:57 <gwd> It's on our list of "Important Things to Do", but the list is fairly long. :-)
14:33:34 <alphacc> hhorak: looking at your issue
14:34:12 <srn_prgmr> I have one issue so far with 4.8 btw
14:34:16 <srn_prgmr> "libxl: error: libxl_dom.c:60:libxl__domain_cpupool: got info for dom373, wanted dom372
14:34:17 <srn_prgmr> : No such file or directory"
14:34:23 <srn_prgmr> haven't looked at yet
14:34:27 <gwd> Oh, weird
14:34:59 <srn_prgmr> I have not seen any other failures so far
14:35:02 <gwd> Send a report when you get a chance.  I haven't seen that one before.
14:36:13 <gwd> srn_prgmr: OK, anything else about 4.8 to discuss?
14:36:24 <srn_prgmr> Not 4.8.
14:36:54 <gwd> OK, any other business at all (either Xen or something else)?
14:37:45 <srn_prgmr> 1. is it OK to enable livepatch in the xen4centos kernel even if it probably doesn't get used? 2. any guidance on how to debug the .debug debuginfo problems?
14:39:22 <gwd> Livepatching doesn't expose any hypercalls to unprivileged guests (and that aspect has been tested for a while), so it should be perfectly safe to enable even if it's not being used.
14:39:54 <gwd> It will also make it easier for anyone who wants to (e.g., CloudLinux) to publish live patches.
14:40:15 <srn_prgmr> cloudlinux already publishes kernel patches
14:40:17 <gwd> If they get to it before we get something set up within the Sig
14:40:39 <gwd> Oh, sorry -- you said the kernel rather than the hypervisor
14:41:01 <srn_prgmr> we are still evaluating them and have not made a thumbs up or down, and other people may want to do their own patches and not use a vendor
14:41:56 <gwd> If you send an e-mail to centos-virt and maybe CC me, I can do some research and get back to you.
14:42:24 <gwd> Or you could make a case that it's safe and we can consider it.
14:43:05 <srn_prgmr> gwd: I did send an email already with the change but didn't call out livepatch explicitly. I know fedora has chosen not to enable it by default, I think so that people don't ask for livepatches?
14:44:58 <gwd> It could also be because they're afraid of some quirk accidentally allowing an unprivileged user to livepatche the  kernel.
14:45:25 <gwd> There have been bugs like that with containers before, for example. :-0
14:45:30 <gwd> :-)
14:46:53 <srn_prgmr> gwd: that's fair. I'll send an email to the list asking for opinion. If the consensus is people want it, can we turn it on?
14:47:11 <srn_prgmr> But it's not worth anything without a proper debuginfo package which is the other problem I'm having
14:47:36 <gwd> turn it on> I think your last statement is a tautology. :-)
14:48:01 <gwd> Yes, I don't inherently have an objection to it; I just don't know anything about it.
14:48:23 <gwd> srn_prgmr: hughesjr is the one who made the current package
14:48:29 <gwd> kernel package, that is
14:49:09 <srn_prgmr> gwd: when I asked about debuginfo back in 2016 I think, he said I was welcome to add. I've got the basic mechanisms there but it's buggy
14:49:26 <srn_prgmr> either it's being run at the wrong stage or with wrong args or something
14:49:43 <gwd> Does the CentOS Core kernel package have a debuginfo sub-package?
14:49:50 <gwd> Could you see how that package does it?
14:50:20 <srn_prgmr> gwd: I could rebuild that with extra logging I guess? the macros are more complicated than what I'm used to
14:50:35 <srn_prgmr> it's a much more complicated spec file
14:50:40 <gwd> I bet. :-)
14:51:01 <srn_prgmr> I can spend some more time on it
14:51:20 <srn_prgmr> it's useful for systemtap etc. even if not for live patching
14:52:29 <gwd> I think ask hughesjr for help again too -- if you've tried it and got stuck then I think he should be willing to try to point you in the right direction
14:52:58 <gwd> I mean, I could take a look, but spec files aren't really my expertise either.
14:53:45 <srn_prgmr> k
14:55:33 <gwd> OK, anything else?
14:55:45 <hughesjr> srn_prgmr: I am not a kernel programmer .. the xen kernel needs to compile on CentOS-7 and CentOS-6 and it is based on the elrepo kernel from a while back
14:56:06 <hughesjr> srn_prgmr: none of the elrepo kernels have debuginfo
14:57:08 <hughesjr> I have no objections to add any of that in .. but I certainly do not have the capability to do that myself (specifcally the debuginfo)
14:57:47 <srn_prgmr> hughesjr: thank you. I think this is more about packaging than the kernel. I know many kernel developers who would also not have the capability
14:58:27 <hughesjr> if someone does the techinical work (ie, patches and testing) to make that happen, we can certainly roll it in, so long as it still allows us to follow the LTS tree
14:59:56 <hughesjr> one major key here is el6 and el7 .. so nothing that does not work with either gcc/glibc/ssl, etc.   ..   and less complicated is good (so it will work with generic LTS kernel from kernel.org
15:00:11 <srn_prgmr> incidentally there is a ticket for elrepo too https://elrepo.org/bugs/view.php?id=684
15:00:54 <srn_prgmr> hughesjr: I got something that produces .debug, just the modules are stripped, which is kind of useless. I can do a compare with the stock centos 7 kernel build and try to figure out where the differences are
15:01:39 <hughesjr> well .. as I said, as long as it will continue to work for the generic LTS trees, I have no issue implmenting it .. of course, we would also discuss it on list, etc.
15:01:57 <gwd> Let's end the official meeting; conversation can continue as long as no one else has a meeting.
15:02:07 <gwd> If they do, we can move the discussion to #centos-virt
15:02:12 <gwd> #endmeeting