- kata-dev - lists.katacontainers.io

Kat herder's for the week
by yash jain 27 Aug '18

27 Aug '18

Good morning! The Kat Herder's for this week are Jodh (@jodh-intel), Rico Ravarena (@rico) and me (@ydjainopensource). Jodh's out on Monday while I leave half day on Thursday. I am new here so please give me all the help and support you can to help clear down our backlog and keep things flowing.... Details can be found on the wiki page at https://github.com/kata-containers/community/wiki/Review-Team-Rota -- Thanks Yash D Jain Github : @ydjainopensource <https://github.com/ydjainopensource> Twitter : @Yash_D_Jain <https://twitter.com/Yash_D_Jain> LinkedIn : in/yash-d-jain <https://www.linkedin.com/in/yash-d-jain/>

1 0

Declare candidacy of Arch Committee -- Kaly Xin
by Kaly Xin 27 Aug '18

27 Aug '18

Hi, This is to declare the candidacy of Arch Committee for Arm. The PR is at https://github.com/kata-containers/community/pull/56. The candidacy text file as below: Kata-containers Architecture Committee Candidacy Declaration Platform: Arm Candiate: Kaly Xin <Kaly.Xin(a)arm.com> I'm working for Arm Electronic Technology (Shanghai) Co.Ltd. This candidacy is representing Arm company to be voted for one seat of the Kata-container architecture committee. My current role is Senior Engineering Manager in the Open Source Software Group and I lead a team working on virtualization and container technology on the Arm platform. I have more than 10 years of experience in virtualization, especially for hardware virtualization development including KVM and Xen. After that, I transferred focus to OS virtualization and container development. In recent years, my team started development on RunV project, one of the predecessors to Kata-containers, to enable and enhance the multi-arch support. Our focus areas included KVMtool support, performance profiling of the network and storage devices for virtual machines, and we also worked on stability and density improvements. For example, we identified a networking performance gap and improved throughput by 10x on both Arm and x86 platforms. Another example, we proposed and modified the synchronization mechanism between the hyperstart thread and VM. These and other contributions were all merged in RunV upstream. Some of them are already in Kata-container project too. For these collaborations, there were public blogs announced at https://blog.hyper.sh/arm_and_hyper.html and https://community.arm.com/iot/b/blog/posts/arm-and-hyper-hq-will-push-runv-…. We have met regularly with Hyper team to discuss the development issues and solutions of the project. When RunV evolved into kata-containers, we transferred our effort into this new joint project and contribute to it as ever. Initially, We found it couldn't run successfully with multi-arch as before, lots of current test cases and CI environment setting up are not for multi-arch in the first stage. We start to fix the compatibility issues for different architectures. We are also working on the public CI support for mutli-arch to ensure the ongoing reliability and stability of the project. During the process, we feel this new joint project is very open, friendly and full of vitality as before. That's so great to work in the community! Interests: We believe this is just the beginning for the Kata-containers project and that it will have much broader applicability across different architectures and use cases, especially within the emerging next-generation IoT and 5G era! These different use cases will generate new design requirements of the underlying architecture and we believe strongly that good multi-architecture support will be essential to position Kata-containers for broad adoption throughout the cloud native ecosystem. We look forward to driving these changes together, so the Kata-containers project can reach its full potential! 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.

2 2

Renaming to "kata-discuss"?
by Anne Bertucio 25 Aug '18

25 Aug '18

Hi Kata crew, A while back there was some discussion about renaming this list to “kata-discuss” and having it be broader topics than just development discussions. We were about to make a mailing list for community and advocacy work, but rather than segregate that work (and the people working on those things), it seems better to have a single list (“kata-discuss”) and use the subject line to let people filter through the messages that are most relevant to them (I’d suggest using brackets with the topic area in front of the subject, ie “[advocacy] Container Camp UK sessions” and “[dev] Review needed on PR #305”). How does that sound? Anne Bertucio OpenStack Foundation anne(a)openstack.org | irc: annabelleB

5 5

Declaring candidacy for Eric Ernst
by Ernst, Eric 24 Aug '18

24 Aug '18

Hey Katazens, I would like to throw my hat into the ring as well! I’ve enjoyed the kat-herding so far, and look forward to plenty more opportunities to contribute to the project. Thanks for considering. -Eric -- Background: I am a senior software engineer in Intel's Open Source Technology Center, acting both as a contributor as well as a technical lead for the Intel-team contributing to Kata Containers. Before Kata, I spent time working on Clear Containers, and prior to that spent a few years working on Linux kernel. Since the initial discussions of creating Kata started I have been an active contributor and advocate for the project, both in code and in the greater Kata community/ecosystem. While I do work within a silicon company, one of my primary goals for helping guide Kata has been developing a neutral and diverse contribution base. Aside from having a stable, compatible, and viable technical basis for the project, I think a healthy and robust community is key to sustained success. For me, working with end-users to understand use cases and seeing how Kata can be part of their solution is very exciting. I think this will be a big part of Kata as we continue to move forward. In addition, continued focus on scaling, ecosystem integration, performance, security and stability will be key to meeting user needs. I've also been focusing on making sure Kata fits into Kubernetes and the rest of the ecosystem, which Has been evolving over time. There is a lot to focus on! The journey to Kata 1.2 has been great, and I look forward to continuing to contribute to the project.

1 0

Berlin Community Contributor Awards
by Kendall Nelson 24 Aug '18

24 Aug '18

Hello Everyone! As we approach the Summit (still a ways away thankfully), its time to kick off the Community Contributor Award nominations! For those of you that might already know what they are, here is the form[1]. For those of you that have never heard of the CCA, I'll briefly explain what they are :) We all know people in the community that do the dirty jobs, we all know people that will bend over backwards trying to help someone new, we all know someone that is a savant in some area of the code we could never hope to understand. These people rarely get the thanks they deserve and the Community Contributor Awards are a chance to make sure they know that they are appreciated for the amazing work they do and skills they have. So go forth and nominate these amazing community members[1]! Nominations will close on October 21st at 7:00 UTC and winners will be announced at the OpenStack Summit in Berlin[2]. -Kendall Nelson (diablo_rojo) [1] https://openstackfoundation.formstack.com/forms/berlin_stein_ccas [2]https://www.openstack.org/summit/berlin-2018/

1 0

Kata Architecture Committee Elections: Nomination period now open
by Anne Bertucio 24 Aug '18

24 Aug '18

Hi all, The nomination period for the Architecture Committee election is now open. How to run for a seat: 1) Review the responsibilities of the Architecture Committee members [1] 2) Between now and August 27 at 14:59 UTC, you can declare your candidacy for one of the three open seats by submitting a textfile with your name (please put your name as the file name), reason for running and your platform/objectives to this folder[2]. Please also send a message to the kata-dev ML with this same info, declaring your candidacy. Election Process: The full process is outlined here [3], but key dates are as follows: August 20, 1500 UTC - August 27, 2018 14:59 UTC: Candidate nominations open August 27, 1500 UTC - September 3, 2018 14:59 UTC: Q&A/Debate period September 3, 1500 UTC - September 10, 2018 14:59 UTC: Voting open Week of September 11, 2018, results announced Who can vote: Anyone who has had a commit merged into the project in the last 12 months will be eligible to vote. Because this is our first election, I’d like to test our electorate generation process--I will send a message to all eligible voters this week, and give anyone who doesn’t receive a message (who thinks they should have) a chance to raise their hand. Keep an eye out for those emails later on. Please let me know if you have any questions about running for a seat or the election process! [1] https://github.com/kata-containers/community/tree/master/elections#architec… <https://github.com/kata-containers/community/tree/master/elections#architec…> [2] https://github.com/kata-containers/community/tree/master/elections/arch-com… <https://github.com/kata-containers/community/tree/master/elections/arch-com…> [3] https://github.com/kata-containers/community/tree/master/elections <https://github.com/kata-containers/community/tree/master/elections> Anne Bertucio OpenStack Foundation anne(a)openstack.org | irc: annabelleB

2 3

Testing Kata Security Promises
by Larrew, Jesse 22 Aug '18

22 Aug '18

Hi all, Are there any tools or tests available that aim to validate the security promises of the Kata architecture? I've looked in the testing repo, but that seems to contain mostly functional tests. I'm interested in something that could be used to validate statements like, "The guest cannot do X. The host cannot do Y. Etc." Does something like this exist for Kata? Sincerely, Jesse

2 1

Declare candidacy: Wei Zhang
by zhangwei (CR) 22 Aug '18

22 Aug '18

Hi Everyone, This is an email for declaring my own candidacy as requested, PR is https://github.com/kata-containers/community/pull/55 Copy text: ``` Name: Wei Zhang Email: zhangwei555(a)huawei.com Introduction: I am now working as a Senior Engineer in Huawei Corporation, leading a team which is responsible for providing container solutions based on K8s/docker/kata-containers to other departments and Huawei Public Cloud. I was once a docker developer and now is an active kata contributor, and has been Architecture Committee Member for about eight months. Kata Containers is a great project which can help reduce some security concerns comparing to native container solution, and I don't think I need more words to elaborate how great it is because I believe all the readers of this file are familiar enough to Kata. :-) So I wish to renew my seat, and do more work to help kata community to make excellent open source project, and then make better product based on Kata to our customers. ``` Hope this can become a good start of our election ☺ Thank you! Wei Zhang 发件人: Anne Bertucio [mailto:anne@openstack.org] 发送时间: 2018年8月20日 22:59 收件人: kata-dev(a)lists.katacontainers.io 主题: [kata-dev] Kata Architecture Committee Elections: Nomination period now open Hi all, The nomination period for the Architecture Committee election is now open. How to run for a seat: 1) Review the responsibilities of the Architecture Committee members [1] 2) Between now and August 27 at 14:59 UTC, you can declare your candidacy for one of the three open seats by submitting a textfile with your name (please put your name as the file name), reason for running and your platform/objectives to this folder[2]. Please also send a message to the kata-dev ML with this same info, declaring your candidacy. Election Process: The full process is outlined here [3], but key dates are as follows: * August 20, 1500 UTC - August 27, 2018 14:59 UTC: Candidate nominations open * August 27, 1500 UTC - September 3, 2018 14:59 UTC: Q&A/Debate period * September 3, 1500 UTC - September 10, 2018 14:59 UTC: Voting open * Week of September 11, 2018, results announced Who can vote: Anyone who has had a commit merged into the project in the last 12 months will be eligible to vote. Because this is our first election, I’d like to test our electorate generation process--I will send a message to all eligible voters this week, and give anyone who doesn’t receive a message (who thinks they should have) a chance to raise their hand. Keep an eye out for those emails later on. Please let me know if you have any questions about running for a seat or the election process! [1] https://github.com/kata-containers/community/tree/master/elections#architec… [2] https://github.com/kata-containers/community/tree/master/elections/arch-com… [3] https://github.com/kata-containers/community/tree/master/elections Anne Bertucio OpenStack Foundation anne(a)openstack.org<mailto:anne@openstack.org> | irc: annabelleB

1 0

Architecture Committee electorate notified
by Anne Bertucio 22 Aug '18

22 Aug '18

Hi all, As I mentioned on the Architecture Committee call yesterday, the AC has an election coming up! If you are eligible to vote in the upcoming election, you should have just received an email from me. If you have made commits with multiple email addresses, the email address notified is the one listed as your primary in your GitHub. If you did not receive an email and believe you should have (based on the electorate definition [1]) please let me know. Cheers, Anne [1] https://github.com/kata-containers/community/tree/master/elections#electora… <https://github.com/kata-containers/community/tree/master/elections#electora…> Anne Bertucio OpenStack Foundation anne(a)openstack.org | irc: annabelleB

1 0

Clear Linux* OS announces Kata Containers to be set as default runtime (Final notice)
by Lamego, Jose A 21 Aug '18

21 Aug '18

Clear Linux* OS announces Kata Containers to be set as default runtime As previously announced, Kata Containers is available in any Clear Linux* OS version above 23380, and Clear Containers is scheduled to be deprecated. As part of the Clear Containers deprecation, the default containers runtime will be set to be Kata Containers on August 21. What should you do if you are already using Kata Containers? No further action is required from you, since you already have the latest configuration in place. What should you do if you are using Clear Containers? Use the Migrate Clear Containers to Kata Containers* tutorial at https://clearlinux.org/documentation/clear-linux/tutorials/kata_migration to migrate to Kata Containers if you want to migrate immediately. From August 21, after the next Clear Linux OS update performed on your system (either manual or automated), Kata Containers runtime will be the default. Although further Clear Containers usage is not recommended, you will temporarily be able to do so by manually re-configuring your system to point to cc-runtime as default runtime until it is removed on August 21th. For any issues or questions regarding Kata Containers in Clear Linux, please contact us through the mailing list: https://lists.clearlinux.org/mailman/listinfo/dev or the IRC channel: https://clearlinux.org/community/irc-channel. COPYRIGHT (c) 2018 Intel Corporation, All Rights Reserved *Other names and brands may be claimed as the property of others

1 0

Kat herder for this week
by Whaley, Graham 20 Aug '18

20 Aug '18

Good morning! This week's Kat Herder is Julio(devimc) - please give him all the help and support you can to help clear down our backlog and keep things flowing.... 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

Kata on Mainframes
by yash jain 16 Aug '18

16 Aug '18

Hi, I am an intern with the Open Mainframe Project <https://www.openmainframeproject.org/>. First off, you guys are doing an awesome job actively developing Kata. Thanks a lot. Second, we were initially working on porting gvisor. However, considering the stability and performance of Kata, we have decided to drop gvisor and we will now be working on porting Kata to the IBM Z mainframe platform. This fork would as of now reside under Qata Containers. I would personally love to have the port incorporated into Qata however, some managerial and legal issues remain a hurdle. Once those are sorted and if the community agrees, we would love to merge the port into Kata. The port is not complete yet. Hence, its not publicly available yet. I am just writing this mail to thank you and inform you about the same. -- Thanks Yash D Jain Github : @ydjainopensource <https://github.com/ydjainopensource> Twitter : @Yash_D_Jain <https://twitter.com/Yash_D_Jain> LinkedIn : in/yash-d-jain <https://www.linkedin.com/in/yash-d-jain/>

4 5

Clear Linux* OS announces Kata Containers to be set as default runtime
by Lamego, Jose A 16 Aug '18

16 Aug '18

Clear Linux* OS announces Kata Containers to be set as default runtime As previously announced, Kata Containers is available in any Clear Linux* OS version above 23380, and Clear Containers is scheduled to be deprecated. As part of the Clear Containers deprecation, the default containers runtime will be set to be Kata Containers on August 21. What should you do if you are already using Kata Containers? No further action is required from you, since you already have the latest configuration in place. What should you do if you are using Clear Containers? Use the Migrate Clear Containers to Kata Containers* tutorial: https://clearlinux.org/documentation/clear-linux/tutorials/kata_migration to migrate to Kata Containers if you want to migrate immediately. From August 21, after the next Clear Linux OS update performed on your system (either manual or automated), Kata Containers runtime will be the default. Although further Clear Containers usage is not recommended, you will temporarily be able to do so by manually re-configuring your system to point to cc-runtime as default runtime until it is removed on August 21th. For any issues or questions regarding Kata Containers in Clear Linux, please contact us through the mailing list: https://lists.clearlinux.org/mailman/listinfo/dev or the IRC channel: https://clearlinux.org/community/irc-channel. COPYRIGHT (c) 2018 Intel Corporation, All Rights Reserved *Other names and brands may be claimed as the property of others

3 2

Kata Containers 1.2.0
by Venegas Munoz, Jose Carlos 15 Aug '18

15 Aug '18

Welcome to Kata Containers 1.2.0! This release includes new features: VSOCK support: Now if your host kernel supports VSOCK the runtime will create VM that uses VSOCK sockets, this will help to not use a proxy and do connections between the VM and runtime and shim without any proxy program running. New Factory support: The factory support now is part of the Kata Containers. This will allow creating VMs based on a template that will increase the boot time and memory usage. For more information check the full release notes at: https://github.com/kata-containers/runtime/releases/tag/1.2.0

4 5

Check out the Kata Containers sessions at OpenStack Summit Berlin, Nov 13-15
by Anne Bertucio 14 Aug '18

14 Aug '18

Hey Kata crew, The schedule for the OpenStack Summit Berlin, which takes place November 13-15, is now live, including a handful of Kata Containers sessions—congrats to all our community members who had their talks accepted! [1] You can check out the full schedule, which includes 100+ sessions, demos and workshops across 35+ different open source projects like Kata. [2] Similar to the Vancouver Summit in May, we’ll have a Kata project update, contributor onboarding, and time to meet each other and be together as a community. To get the best prices on Summit tickets ($699 USD), register before August 22 at 6:59 UTC (August 21 at 11:59pm PT). [3] Hope to see you in Berlin! [1] https://www.openstack.org/summit/berlin-2018/summit-schedule/global-search?… <https://www.openstack.org/summit/berlin-2018/summit-schedule/global-search?…> [2] https://www.openstack.org/summit/berlin-2018/summit-schedule/#day=2018-11-13 <https://www.openstack.org/summit/berlin-2018/summit-schedule/#day=2018-11-13> [3] https://www.eventbrite.com/e/openstack-summit-november-2018-berlin-tickets-… <https://www.eventbrite.com/e/openstack-summit-november-2018-berlin-tickets-…> Anne Bertucio OpenStack Foundation anne(a)openstack.org | irc: annabelleB

1 0

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