From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EB03E652 for ; Wed, 8 Nov 2023 01:24:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="X/+VjHiO" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1699406699; x=1730942699; h=message-id:date:mime-version:from:subject:to: content-transfer-encoding; bh=2BFtOPR4IeFxoePlClBBCcOPt/XReC87njXr0Ha0tTA=; b=X/+VjHiOWmWsmC/Tuct1AjeJs16mIIIUtxXMhszAhT2Ln6VKNyOClmkk wameI+YR+oekJWc1Lli5DCfYwqHIfGWJyMdMT2IxQfjSombhDkQ9qnQ5E qlR1SigqFG/hRsIor4QG7782Ui7GjGEUtGPJFGi8tqauqSWwx7D/U5ydw oY3NUkaEP6r8C9MdWNUj+yy8Y66EJNLaBAsjvPkwxCiHlierDmGUWisDV kdt576dYHH4XM0NK9DzaFWvtEwiKq1HRc6Gvu0GpkFwApRBdJUxg0IM+9 CD5uiIOp11+6fEliHxBiIWwBlWyloZTjwO8jVUt5Ib1AKOxxkxav8xPRS g==; X-IronPort-AV: E=McAfee;i="6600,9927,10887"; a="475893342" X-IronPort-AV: E=Sophos;i="6.03,285,1694761200"; d="scan'208";a="475893342" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Nov 2023 17:24:58 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.03,285,1694761200"; d="scan'208";a="10627252" Received: from pjperrel-mobl.amr.corp.intel.com (HELO [10.92.32.81]) ([10.92.32.81]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Nov 2023 17:24:57 -0800 Message-ID: <4dcca77e-e6d0-4cd1-9813-6a7ad24ba0e8@linux.intel.com> Date: Tue, 7 Nov 2023 19:24:56 -0600 Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US From: Dan Middleton Subject: RFC: CCC Linux Kernel SIG To: linux-coco@lists.linux.dev Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi from the CCC! Many of our companies also collaborate in the Confidential Computing Consortium. There we are proposing a SIG and invite your feedback and involvement: https://github.com/confidential-computing/governance/pull/196 The entirety of the proposal is also copied below. Thanks, Dan Middleton CCC TAC Chair # Proposal: CCC Linux Kernel SIG This proposal seeks to accelerate Confidential Computing feature velocity in the Linux kernel. By creating a Linux Kernel SIG in the CCC we can foster community dialog to develop vendor neutral architectural approaches to new features and thereby reduce complexity in associated kernel patches. # Background: One of the technical limitations to the adoption rate for Confidential Computing is the speed at which we as a community can add features to the Linux kernel. Each vendor has similar needs of the kernel but has historically presented significantly different ABIs. To contain complexity and manage maintainability, the Linux kernel community tries to prevent proliferation of unnecessarily vendor specific ABIs. Often the opportunity for commonality is unclear until multiple vendors have proposed separate interfaces [0]. The CCC as the home of open collaboration for Confidential Computing hardware vendors, software vendors, and end users facilitates a unique environment for exchanging views on features and requirements. Up to this point in time though most CCC collaboration has been on user space software and use cases. The Linux kernel community has not been a regular part of discussions and the CCC has not been a regular participant on the Linux Kernel Mail List (LKML)[1]. Bringing these communities together in a structured forum has the promise of accelerating their joint work towards broad availability of Confidential Computing in Linux environments. # Scope: 1. Facilitate dialog between Linux kernel and Confidential Computing subject matter experts:     * to facilitate direction for topics that need formal collaboration,     * to have an additional venue to facilitate direction for topics that are stalled on LKML,       which would benefit from higher bandwidth communication,     * to have a common place to record decisions and formalize the output for others to reference,     * and to introduce new technical topics emerging in either domain, e.g., attestation mechanisms       approaching standardization. 2. Create recommendations for other organizations and communities such as LKML, IETF, etc.    on topics at the intersection of the Linux kernel and Confidential Computing. # Governance: The CCC adheres to a culture of Minimum Viable Governance [2]. We prefer not to create rules that inhibit the progress of substantive work. All are welcome at all CCC community forums. This SIG is targeted to all Linux kernel maintainers and Confidential Computing vendors, project contributors, and end users with a dependence on the Linux kernel. Meetings will follow standard CCC practices of inclusivity and openness adhering to the community code of conduct [3] and the Linux Foundation’s Antitrust policy [4]. ## Decision Making: This SIG will use consensus decision making [5] wherein not all participants must be in full agreement but that there should not be a strong consensus against a proposal [6]. In most cases we expect that once the SIG reaches consensus on a kernel topic, contributors will propose aligned patches to LKML without any explicit communication from the SIG or the CCC. If a formal CCC recommendation to another organization, e.g., IETF, TCG, eBPF Foundation, etc. is required, the SIG will rely on the CCC Technical Advisory Council (TAC) to ratify proposals from the SIG. The pipeline of activity is expected (but not required) to look like this: 1. Identify feature need on mailing list or informal forum. 2. Exchange community proposals in the SIG. 3. Achieve informal consensus in the SIG.     a. Author patches and take them to the appropriate community, e.g., LKML.     or     b. Raise an agenda item for the CCC TAC to formally ratify a proposal and publish to the        appropriate organization. ## Initial Logistics: The community will set its own meeting cadence starting from an initial cadence of meeting twice per month. The CCC will provide a Zoom channel. At the end of each meeting a new chair may volunteer to organize the agenda for the next meeting. The chair role confers no other responsibility or authority beyond collecting agenda requests from the community and enforcing minutes and good order. In addition to video meetings, the community will use an existing Discord channel for ongoing communication. No mail list is required at this time. # References: [0] https://lore.kernel.org/all/64876bf6c30e2_1433ac29415@dwillia2-xfh.jf.intel.com.notmuch/ [1] https://lore.kernel.org/linux-coco/ [2] Sarah Novotny, Stephen Walli, “Minimum Viable Governance”, Linux Foundation Open Source Summit Europe 2020, https://www.youtube.com/watch?v=C2-_MjzP-Rs [3] https://github.com/confidential-computing/governance/blob/main/code-of-conduct.md [4] https://www.linuxfoundation.org/legal/antitrust-policy [5] https://en.wikipedia.org/wiki/Consensus_decision-making [6] See Rust’s Final Comment Period (FCP) https://github.com/rust-lang/rfcs