- kata-dev - lists.katacontainers.io

Logging and Tracing presentation link
by Hunt, James O 13 Aug '18

13 Aug '18

Hi All, Here's a link to the presentation I just gave in the Kata Architecture Committee meeting: - https://docs.google.com/presentation/d/1TlzV-2IIcEwYK7f5FPvA2YxKhBaoBZ36dxL… Cheers, James --- https://katacontainers.io/ | https://github.com/kata-containers <https://github.com/clearcontainers> Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.

1 0

Kat-herders for this week
by Whaley, Graham 13 Aug '18

13 Aug '18

Good morning, The 'Kat Herders' for this week are Peng (bergwolf) and Archana (amshinde). Details can be found on the wiki page at https://github.com/kata-containers/community/wiki/Review-Team-Rota Graham --------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

1 0

Intel Gatekeepers for Kata
by Whaley, Graham 09 Aug '18

09 Aug '18

Good morning. As Eric mentioned in last week's Arch call, the Kata team at Intel are trialing a 'round robin Gatekeeper schedule' for Kata PR review. That is, each week one of our team will prioritise reviewing and moving forwards the open PRs on the Kata repos. This is a process we used for some time with Clear Containers. We are trying this out to see if we can try and reduce the pending PR list, in particular some of the longer standing or more urgent PRs. This is by no means an Intel-only initiative :-) If you want to be on the rota then just let me know and I'll add you into the cycle. It would be great if we can try and get at least two nominated reviewers each week, ideally located in different time zones. Note that to be a gatekeeper you don't have to understand the whole project, or even have to be the most technical person. Being a gatekeeper is a great opportunity to both get to know the project in more depth and to hone your technical skills. Sometimes all it needs is for somebody to read the list of open PRs and nudge a few along that have been inactive and ask the appropriate domain experts if they could do a review. All volunteers welcome. If you are new to the project and/or PR reviews, we have a PR review guide document that is well worth reviewing: https://github.com/kata-containers/community/blob/master/PR-Review-Guide.md . Today we are sat with 42 open items (you can coax that info out of github via this link: https://github.com/search?o=asc&q=org%3Akata-containers+is%3Apr+is%3Aopen&s…) This week's gatekeeper is .... myself :-) Graham --------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

8 11

Denver meeting: Decision by Aug 7
by Anne Bertucio 09 Aug '18

09 Aug '18

Hi all, The Denver in-person teams meeting [1] will be here before we know it (Sept 11-13), and I’ve been keeping an eye on the etherpad to make sure we have enough active contributors present. The Denver meeting is a time for our community to have dedicated space in a focused environment—no conference distractions or trying to create ad hoc space. The next opportunity to have in-person time like this is the OpenStack Summit Berlin, although knowing that it overlaps with KubeCon Shanghai, our community might be split in two that week. The Denver meeting will only be valuable if we have enough active contributors there to push things forward, and to be considerate of travel plans, I’d like to propose that we decide to commit to meeting in Denver by August 7, or let the space go to another team. If you have confirmed your travel approval, please add your name to the etherpad before August 7: https://etherpad.openstack.org/p/KataContainersPTG4 <https://etherpad.openstack.org/p/KataContainersPTG4> [1] https://www.openstack.org/ptg <https://www.openstack.org/ptg> Anne Bertucio OpenStack Foundation anne(a)openstack.org | irc: annabelleB

1 1

Branching strategy proposal for Kata Containers
by Ernst, Eric 08 Aug '18

08 Aug '18

Hey Kata-kats, With help from others, I put together the following proposal for handling stable and master branches and corresponding releases for Kata Containers. I have some good input already, and am hoping to hear from more folks on their input on this. Please take a look. https://docs.google.com/document/d/18R8Ckl20PIP5FeC81faNEhbcX7ydgsCTHPlwogr… Thanks! Eric

1 0

Kata metrics deck for Monday 2017-07-30
by Graham Whaley 03 Aug '18

03 Aug '18

Hi folks. I'm lined up to present the current state and plans of the metrics tests and systems to the Kata Architecture Committee call on Monday. You can preview the deck on gdrive at the link https://docs.google.com/presentation/d/1eKLQX2g_4fRdM0QLzP06p16WcuEYWWrKcA5… Let me know if you cannot see that or would like a pdf mailing out etc. And you can fire questions at me on the list, or keep them ready for Monday. Graham

2 1

Improving isolation in Kata
by Stefan Hajnoczi 24 Jul '18

24 Jul '18

Kata currently launches QEMU as user 'root' and I haven't found isolation mechanisms that would confine the QEMU process in the event of a guest escape. Inevitably there will be a security bug that allows a malicious guest to escape to QEMU, so it's important that the QEMU process is unprivileged and isolated. Running QEMU as 'root' simplifies 9p configuration by allowing the QEMU process to access files with any uid/gid. QEMU does support other 9p configurations where the QEMU process does not run as root, including the virtfs-proxy-helper privilege separation approach. Are there any other reasons for running the QEMU process as root? For comparison, libvirt launches QEMU as the unprivileged 'qemu' user with a unique SELinux context. This makes it much harder to access other guests or escape to the host if the guest compromises QEMU. Is there any work underway to improve isolation in Kata? Two directions that come to mind are: 1. Design isolation from scratch for Kata, including unprivileged uid/gid, namespaces, and SELinux. This requires changes to Kata because the QEMU process will not be able to open arbitrary files (e.g. device hotplug, 9p configuration). FWIW, relying on namespaces doesn't add a lot of security because if the guest is malicious, then that may well be because of a Linux namespaces security hole - the attacker could just use the same exploit again to escape from QEMU to the host. 2. Use libvirt-go (API) or libvirt-go-xml (XML) instead of govmm to get strong isolation. This would also slim down virtcontainers and remove the dependency on govmm (no more command-line munging and defining object models for QEMU command-line concepts). Stefan

5 15

[kata-release] release cadence, process
by Ernst, Eric 20 Jul '18

20 Jul '18

Carlos et al, I am proposing that we continue to roll releases; we are having a good amount of fixes merge and I think it warrants having a regular weekly cadence (likely a 0.0.x update). I believe we discussed this before – let’s start driving it. Carlos, Raju, Akshay – from prior emails/request for volunteers, you were all listed for folks to help with packaging and release. Carlos, is the process defined enough that you think we can start rotating the release duties among more stakeholders? WDYT? Thx, Eric

7 7

Re: [kata-dev] [Qemu-devel] [PATCH] migration: add capability to bypass the shared memory
by Peng Tao 18 Jul '18

18 Jul '18

On Tue, Jul 3, 2018 at 6:05 PM, Stefan Hajnoczi <stefanha(a)gmail.com> wrote: > On Mon, Jul 02, 2018 at 09:52:08PM +0800, Peng Tao wrote: >> On Mon, Jul 2, 2018 at 9:10 PM, Stefan Hajnoczi <stefanha(a)gmail.com> wrote: >> > On Sat, Mar 31, 2018 at 04:45:00PM +0800, Lai Jiangshan wrote: >> > Risks: >> > 1. If one cloned VM is exploited then all other VMs are more likely to >> > be exploitable (e.g. kernel address space layout randomization). >> w.r.t. KASLR, any memory duplication technology would expose it. I >> remember there are CVEs (e.g., CVE-2015-2877) specific to this kind >> attack against KSM and it was stated that "Basically if you care about >> this attack vector, disable deduplication.". Share-until-written >> approaches for memory conservation among mutually untrusting tenants >> are inherently detectable for information disclosure, and can be >> classified as potentially misunderstood behaviors rather than >> vulnerabilities. [1] >> >> I think the same applies to vm templating as well. Actually VM >> templating is more useful (than KSM) in this regard since we can >> create a template for each trusted tenant where as with KSM all VMs on >> a host are treated equally. >> >> [1] https://access.redhat.com/security/cve/cve-2015-2877 > > That solves the problem between untrusted users but a breach in one > clone may reveal secrets of all other clones belonging to the same > tenant. As a user, I would be uncomfortable knowing that if one of my > machines is breached then secrets used by all of my machines might be > exposed. > Secrets are really point 2 in your list and I'll answer it below :) >> > 2. If you give VMs cloned from the same template to untrusted users, >> > they may be able to determine the secrets other users' VMs. >> In kata and runv, vm templating is used carefully so that we do not >> use or save any secret keys before creating the template VM. IOW, the >> feature is not supposed to be used generally to create any template >> VMs at any stage. > > At what point are templates captured to avoid these problems? Is there > code that shows how to do this? > Both runv and kata pauses the VM right after the agent inside guest is up and running, which, in the initramfs case, translates into the point that kernel boots and the init process starts. If you are interested in seeing the actual code, you can look at https://github.com/hyperhq/hyperstart/ and https://github.com/kata-containers/agent for what is done in the guest at that point. If you see any secrets being saved there, I'll be more than happy to fix it. :) >> > Security is a >> > major factor for using Kata, so it's important not to leak secrets >> > between cloned VMs. >> > >> Yes, indeed! And it is all about trade-offs, VM templating or KSM. If >> we want security above anything, we should just disable all the >> sharing. But there is actually no ceiling (think about physical >> isolation!). So it's more about trade-offs. With Kata, VM templating >> and KSM give users options to achieve better performance and lower >> memory footprint with little sacrifice. The security advantage of >> running VM-based containers is still there. > > Adding options to enable/disable features leads to confusion among > users, makes performance comparisons harder, and increases support > overhead. > > Technical solutions to the security problems are possible. I'm > interested in progress in this area because it means users don't need to > make a choice, they can benefit from the feature without sacrificing > security. > Well, that is really beyond the scope of the reviewing of this particular QEMU patch. But as a Kata developer, I can answer it anyway. For one thing, Kata already has quite a few configuration options that let users choose different features. For another thing, Kata already ships with KSM support by default and VM templating in Kata is better off than KSM in many aspects (e.g., by providing similar level of memory conservation w/o affecting host and guest performance). So from Kata containers point of view, it makes sense to have VM templating support and let users decide which one they want to use. PS: CCing kata-dev since the discussion starts to concern about Kata specific usage. Cheers, Tao

2 3

ARM CI status for Kata container
by Kaly Xin 17 Jul '18

17 Jul '18

Hi, These days we are working on the ARM CI setting up for Kata container project. For hardware, thanks for Hyper friends who applied for a ThunderX2 server on packet.net WorksOnArm project. And we plan to utilize this machine as a Jenkins slave to be scheduled by Jenkins master with CI tasks on ARM. For software preparation, we are going through the scripts under https://github.com/kata-containers/tests/tree/master/.ci to setup the testing environment. We met some issues in environment setting up for ARM. We resolved the issues and the PR were merged. See https://github.com/kata-containers/tests/issues/472 for example. Currently, the environment setting up is successful. Now we are going through the integration test cases under https://github.com/kata-containers/tests/tree/master/integration on our internal server. Unfortunately, most of the cases fail. We are trying to figure out what happens now. We believe that it might not be a short term development to pass most of the test cases. It will lag the process a bit longer. The reasonable solution could be setting up the CI infrastructure on ARM first - just to add one ARM server as a Jenkins slave which can be scheduled by Jenkins master. And it can be configured to run a limited number of successful tasks as Jenkins jobs in initial stage. At this step, we need the help from the CI infrastructure team - at least, both the master and slave have to know the IP/hostname, slave has to know the plugin to be installed and the credential things, etc. After the infrastructure is setting up, we could add more Jenkins jobs in. But that almost means different architecture could have different Jenkins job to test. To make the process happen, it's better to have some kind of mechanism (indicated by @Xu Wang<mailto:xu@hyper.sh> as "filter") to define and generate the set of Jenkins jobs running by different architectures. We have a proposal for this and will raise an issue to discuss it in community very soon. We plan to have Zuul support as the further step after above is working. Thanks Kaly IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

1 0