[Git][reproducible-builds/reproducible-website][master] Add images to Kees Cook spotlight and various corrections.
Vagrant Cascadian (@vagrant)
gitlab at salsa.debian.org
Wed Sep 25 23:15:04 UTC 2024
Vagrant Cascadian pushed to branch master at Reproducible Builds / reproducible-website
Commits:
04eb01ff by Vagrant Cascadian at 2024-09-25T16:14:40-07:00
Add images to Kees Cook spotlight and various corrections.
- - - - -
3 changed files:
- _posts/2024-08-01-supporter-spotlight-kees-cook.md
- + images/news/supporter-spotlight-kees-cook/kees.jpg
- + images/news/supporter-spotlight-kees-cook/linux-kernel-security.png
Changes:
=====================================
_posts/2024-08-01-supporter-spotlight-kees-cook.md
=====================================
@@ -6,13 +6,14 @@ categories: org
draft: true
---
-[](FIXME)
+[![]({{ "/images/news/supporter-spotlight-kees-cook/kees.jpg#right" | relative_url }})]()
<big>The Reproducible Builds project [relies on several projects, supporters and sponsors]({{ "/who/" | relative_url }}) for financial support, but they are also valued as ambassadors who spread the word about our project and the work that we do.</big>
-This is the *eighth* instalment in a series featuring the projects, companies and individuals who support the Reproducible Builds project. We started this series by [featuring the Civil Infrastructure Platform]({{ "/news/2020/10/21/supporter-spotlight-cip-project/" | relative_url }}) project, and followed this up with a [post about the Ford Foundation]({{ "/news/2021/04/06/supporter-spotlight-ford-foundation/" | relative_url }}) as well as recent ones about [ARDC]({{ "/news/2022/04/14/supporter-spotlight-ardc/" | relative_url }}), the [Google Open Source Security Team (GOSST)]({{ "/news/2022/04/26/supporter-spotlight-google-open-source-security-team/" | relative_url }}), [Bootstrappable Builds]({{ "/news/2022/05/18/jan-nieuwenhuizen-on-bootrappable-builds-gnu-mes-and-gnu-guix/" | relative_url }}), [the F-Droid project]({{ "/news/2022/06/24/supporter-spotlight-hans-christoph-steiner-f-droid-project/" | relative_url }}), [David A. Wheeler]({{ "/news/2022/12/15/supporter-spotlight-davidawheeler-supply-chain-security/" | relative_url }}) and [Simon Butler]({{ "/news/2023/08/01/supporter-spotlight-simon-butler/" | relative_url }}).
+This is the *eighth* installment in a series featuring the projects, companies and individuals who support the Reproducible Builds project. We started this series by [featuring the Civil Infrastructure Platform]({{ "/news/2020/10/21/supporter-spotlight-cip-project/" | relative_url }}) project, and followed this up with a [post about the Ford Foundation]({{ "/news/2021/04/06/supporter-spotlight-ford-foundation/" | relative_url }}) as well as recent ones about [ARDC]({{ "/news/2022/04/14/supporter-spotlight-ardc/" | relative_url }}), the [Google Open Source Security Team (GOSST)]({{ "/news/2022/04/26/supporter-spotlight-google-open-source-security-team/" | relative_url }}), [Bootstrappable Builds]({{ "/news/2022/05/18/jan-nieuwenhuizen-on-bootrappable-builds-gnu-mes-and-gnu-guix/" | relative_url }}), [the F-Droid project]({{ "/news/2022/06/24/supporter-spotlight-hans-christoph-steiner-f-droid-project/" | relative_url }}), [David A. Wheeler]({{ "/news/2022/12/15/supporter-spotlight-davidawheeler-supply-chain-security/" | relative_url }}) and [Simon Butler]({{ "/news/2023/08/01/supporter-spotlight-simon-butler/" | relative_url }}).
-Today, however, we will be talking with <big>**Kees Cook**</big>, FIXME.
+Today, however, we will be talking with <big>**Kees Cook**</big>,
+founder of the [Kernel Self-Protection Project](https://kspp.github.io/).
<br>
<br>
@@ -21,15 +22,15 @@ Today, however, we will be talking with <big>**Kees Cook**</big>, FIXME.
of things do you work on?**
**Kees Cook:** I'm a Free Software junkie living in Portland, Oregon, USA.
-I have been focusing on the upstream Linux kernel's
-protection of itself. There is a lot of support that the kernel gives
-for userspace but when I first started focusing on this there was not
-as much work giving entire classes of bugs in the kernel itself as
-userspace itself gets more hardened the kernel itself became a bigger
-target. Almost 9 years ago I formally announced the [Kernel Self-Protection Project](https://kspp.github.io/)
+I have been focusing on the upstream Linux kernel's protection
+of itself. There is a lot of support that the kernel provides
+userspace to defend itself, but when I first started focusing on this
+there was not as much attention given to the kernel protecting
+itself. As userspace got more hardened the kernel itself became a
+bigger target. Almost 9 years ago I formally announced the [Kernel Self-Protection Project](https://kspp.github.io/)
because the work necessary was way more than my time and expertise could do
alone. So I just try to get people to help as much as possible; people who
-understand the arm architecture, people who understand the memory management
+understand the ARM architecture, people who understand the memory management
subsystem to help, people who understand how to make the kernel less buggy.
<br>
@@ -74,7 +75,7 @@ when it wasn't already their job.
<br>
-[](FIXME)
+[![]({{ "/images/news/supporter-spotlight-kees-cook/linux-kernel-security.png#right" | relative_url }})]()
**Vagrant: So my understanding of some of your recent work is basically
defining [undefined behavior](https://en.wikipedia.org/wiki/Undefined_behavior) in the language or compiler?**
@@ -110,7 +111,7 @@ spending a bit of time on lately is looking at how defensive security work has
challenges associated with metrics. How do you measure your defensive security
impact? You can't say "because we installed locks on the doors, 20% fewer
break-ins have happened." Much of our signal is always secondary or
-retrospective, which is frustrating: "This class of flaw was used $X much over
+retrospective, which is frustrating: "This class of flaw was used X much over
the last decade so, and if we have eliminated that class of flaw and will never
see it again, what is the impact?" Is the impact infinity? Attackers will just
move to the next easiest thing. But it means that exploitation gets
@@ -161,7 +162,7 @@ The worry was that developers would come to depend on zero-initialized stack
variables, but this hasn't been the case because we still warn about
uninitialized variables when the compiler can figure that out. So you still
still get the warnings at compile time but now you can count on the contents of
-your stack at run-time and we drop an entire class of uninitialized variables.
+your stack at run-time and we drop an entire class of uninitialized variable flaws.
While the exploitation of this class has mostly been around memory content
exposure, it has also been [used for control flow attacks](https://outflux.net/slides/2011/defcon/kernel-exploitation.pdf).
So that was politically and technically a large challenge: convincing people it
=====================================
images/news/supporter-spotlight-kees-cook/kees.jpg
=====================================
Binary files /dev/null and b/images/news/supporter-spotlight-kees-cook/kees.jpg differ
=====================================
images/news/supporter-spotlight-kees-cook/linux-kernel-security.png
=====================================
Binary files /dev/null and b/images/news/supporter-spotlight-kees-cook/linux-kernel-security.png differ
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/04eb01ff38b6afd71d1a227b15dcb09b9d4c7100
--
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/04eb01ff38b6afd71d1a227b15dcb09b9d4c7100
You're receiving this email because of your account on salsa.debian.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.reproducible-builds.org/pipermail/rb-commits/attachments/20240925/52353af9/attachment.htm>
More information about the rb-commits
mailing list