geico · graysonguarino · Feb 5, 2025
diff --git a/AUTHORS b/AUTHORS
@@ -0,0 +1,5 @@
+Unless mentioned otherwise in a specific file's header, all code in this
+project is released under the Apache 2.0 license.
+
+The list of authors and contributors can be retrieved from the git
+commit history and in some cases, the file headers.
diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
@@ -0,0 +1,72 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, sex characteristics, gender identity and expression,
+level of experience, education, socio-economic status, nationality, personal
+appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at [email protected]. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at <https://www.contributor-covenant.org/version/1/4/code-of-conduct.html>
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see <https://www.contributor-covenant.org/faq>
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -0,0 +1,87 @@
+# Contributing
+
+<!-- Include start contributing -->
+
+The TuxTape team appreciates contributions to the project through pull requests and issues on the GitHub repository.
+
+Check the following guidelines before contributing to the project.
+
+## Code of Conduct
+
+When contributing, you must adhere to the Code of Conduct.
+
+## License and copyright
+
+By default, any contribution to this project is made under the Apache
+2.0 license.
+
+The author of a change remains the copyright holder of their code
+(no copyright assignment).
+
+## Pull requests
+
+Changes to this project should be proposed as pull requests on GitHub.
+
+Proposed changes will then go through review there and once approved,
+be merged in the main branch.
+
+### Developer Certificate of Origin
+
+To improve tracking of contributions to this project we use the DCO 1.1
+and use a "sign-off" procedure for all changes going into the branch.
+
+The sign-off is a simple line at the end of the explanation for the
+commit which certifies that you wrote it or otherwise have the right
+to pass it on as an open-source contribution.
+
+```
+Developer Certificate of Origin
+Version 1.1
+
+Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
+660 York Street, Suite 102,
+San Francisco, CA 94110 USA
+
+Everyone is permitted to copy and distribute verbatim copies of this
+license document, but changing it is not allowed.
+
+Developer's Certificate of Origin 1.1
+
+By making a contribution to this project, I certify that:
+
+(a) The contribution was created in whole or in part by me and I
+    have the right to submit it under the open source license
+    indicated in the file; or
+
+(b) The contribution is based upon previous work that, to the best
+    of my knowledge, is covered under an appropriate open source
+    license and I have the right under that license to submit that
+    work with modifications, whether created in whole or in part
+    by me, under the same open source license (unless I am
+    permitted to submit under a different license), as indicated
+    in the file; or
+
+(c) The contribution was provided directly to me by some other
+    person who certified (a), (b) or (c) and I have not modified
+    it.
+
+(d) I understand and agree that this project and the contribution
+    are public and that a record of the contribution (including all
+    personal information I submit with it, including my sign-off) is
+    maintained indefinitely and may be redistributed consistent with
+    this project or the open source license(s) involved.
+```
+
+An example of a valid sign-off line is:
+
+```
+Signed-off-by: Random J Developer <[email protected]>
+```
+
+Use a known identity and a valid e-mail address.
+Sorry, no anonymous contributions are allowed.
+
+We also require each commit be individually signed-off by their author,
+even when part of a larger set. You may find `git commit -s` useful.
+
+<!-- Include end contributing -->
diff --git a/README.md b/README.md
@@ -0,0 +1,33 @@
+# TuxTape
+
+TuxTape is an ecosystem for generating, compiling, deploying, and installing Linux kernel livepatches.
+
+Kernel livepatching is a service provided by many large companies (Canonical, Red Hat, Oracle, SuSE, TuxCare, etc), but as of today, no open source toolchain exists to allow individuals to self manage such a service. Additionally, most of these companies (with the exception of TuxCare) only provide livepatching services for their own custom kernel, e.g. Red Hat will only provide livepatches for the RHEL kernel.
+
+The mission of TuxTape is not to invalidate these services. Reviewing patches, monitoring the success of patch application, and maintaining infrastructure to distribute patches are tasks that will make sense for many system administrators to outsource. 
+
+One should consider TuxTape if they, whether for security reasons, cost reasons, or requirements to maintain custom kernels, have the need to maintain their own livepatching solution.
+
+## Development Status
+
+TuxTape is currently exiting the proof of concept phase and entering the minimum viable product (MVP) phase, which is why the `main` branch is currently free of code. The proof of concept code, which varies greatly in implementation from the MVP, is accessible in the `poc` branch.
+
+At this point in time, planning for the MVP is still in progress so implementation specifics are not yet available.
+
+## Pieces
+
+The full livepatch solution will consist of the following pieces: 
+
+1. Common Vulnerabilities and Exposures (CVE) Scanner: The kernel community is its own CVE Numbering Authority (CNA) and publishes all CVE information in a [public mailing list](https://lore.kernel.org/linux-cve-announce/) and in [a git tree](https://git.kernel.org/pub/scm/linux/security/vulns.git). The CVE scanner will monitor this list for vulnerabilities which affect files which are compiled into our kernel. Fortunately, each email lists links to the patches fixing the vulnerability. The scanner can be run as a cronjob.
+
+1. CVE Prioritizer: Unfortunately, since the kernel community believes that every bug is a possible security bug, the mailing list is very active. A method of prioritizing CVEs is still being devised.
+
+1. Applicability Gauge: For any CVE which is deemed high enough priority, we must also decide whether it is applicable. This step is separated from the prioritizer because a basic priority applies for the CVE across all kernels, while applicability is per kernel. Since TuxTape is built to support multiple kernel configurations and distributions besides just mainline, some CVEs will stem from source files which are built into some but not all kernels. The applicability gauge will determine, for each kernel, whether a CVE is applicable.
+
+1. Patch Generator: Once a CVE has been identified as worthy of live-patching, the Patch Generator will fetch the fixing commits and automatically generate a loadable module for the fix. In case the generator is unable to do so, it will send a notice to the system administrators to manually attempt to generate a livepatch module. Patches which are auto-generated will need to be carefully vetted through some combination of CI, heuristics, AI review, and human review.
+
+1. Kernel Log Parser: Analyzes kernel warnings to determine whether a livepatch module has misbehaved.
+
+1. Patch Archive: There is a need to publish all livepatch modules, as well as per-kernel and per-version lists of applicable modules. We are considering signing these using the [The Update Framework (TUF)](https://theupdateframework.io/) approach – signing using short-lived keys so that clients can be sure not to be handed stale data. The final state of the Patch Archive is still in discussion.
+
+1. Fleet Client: Every node in the fleet will run a lightweight client which tracks the kernel version and livepatch status of the node on which it runs. It will periodically fetch the latest information from the Patch Archive. See below for details about how we intend to handle cases like [a system being buggy after a livepatch update](https://web.archive.org/web/20240913235734/https://ubuntu.com/security/livepatch/docs/livepatch/reference/what_if_my_system_crashes).