Mask Linux thermal interrupt info in /proc and /sys. #49560

ctalledo · 2025-02-28T00:45:08Z

- What I did

Mask Linux thermal interrupt info inside a container's /proc and /sys.

Mitigates the use of thermal event interrupt information (available within the container via /proc/interrupts or /sys/devices/system/cpu/<cpuX>/thermal_throttle/) to perform thermal side channel attacks.

Big thanks to @zhangxin00 for reporting this issue.

- How I did it

Mask /proc/interrupts and /sys/devices/system/cpu/<cpuX>/thermal_throttle inside containers by default. Privileged containers or containers started with --security-opt="systempaths=unconfined" are not affected.

Integration test TestCreateWithCustomMaskedPaths() was updated with the new masked paths and improved to ensure the default masked paths don't apply to privileged containers.

- How to verify it

docker run -it --rm alpine sh -c "cat /proc/interrupts"
docker run -it --rm alpine sh -c "cat /sys/devices/system/cpu/cpu0/thermal_throttle"

Should each return an empty file.

- Human readable description for the release notes

Mask Linux thermal interrupt info in a container's `/proc` and `/sys` by default. Mitigates potential [Thermal Side-Channel Vulnerability Exploit](https://github.com/moby/moby/security/advisories/GHSA-6fw5-f8r9-fgfm).

- A picture of a cute animal (not mandatory but encouraged)

vvoland · 2025-02-28T10:25:47Z

internal/platform/platform.go

+// larger to the number of CPUs currently online). The returned set may be a
+// single CPU number ({0}), or a continuous range of CPU numbers ({0,1,2,3}), or
+// a non-continuous range of CPU numbers ({0,1,2,3,12,13,14,15}).
+func PossibleCPU() []int {


Not sure if internal/platform is the best package for this.
In general we refer to "platform" in the context of an image (OS, architecture, variant, ...) instead of the running system.

Perhaps internal/system would be more appropriate? 🤔

Pushing back a bit: platform generally means the underlying hw environment the software is running on, so the number of CPUs falls within that category.

Having said that, if you feel strongly about it, I can create a separate internal/system package, though doing so may raise confusion since we already have a pkg/system package (where PossibleCPU() would not fit well IMO).

Given that there's only a single consumer of this function, the easy way out could be to move these files inside the oci packages, and un-export the possibleCPU() function

I think it fits well in internal/platform, as opposed to hiding it within the oci package (where it really does not fit, even though it's the only consumer currently).

Hi @thaJeztah, @vvoland, any further feedback on this PR? I would like to merge it if possible.

platform generally means the underlying hw environment the software is running on, so the number of CPUs falls within that category.

Right, but in our context (container runtime), platform has a more specific meaning.

How about putting it in a cpu/cpus package? We could then rename the function name to just Possible (so it would make it cpu.Possible.

How about putting it in a cpu/cpus package?

We could do that but notice that:

Package internal/platform already has a NumProcs() function.

Package internal/platform also has an Architecture() function which is a property of the CPU.

In other words, there's no clear difference between platform and cpu currently, so I would vote to simplify and keep it all under the platform package.

internal/platform/platform_linux_test.go

On Linux, mask "/proc/interrupts" and "/sys/devices/system/cpu/cpu<x>/thermal_throttle" inside containers by default. Privileged containers or containers started with --security-opt="systempaths=unconfined" are not affected. Mitigates potential Thermal Side-Channel Vulnerability Exploit (https://github.com/moby/moby/security/advisories/GHSA-6fw5-f8r9-fgfm). Also: improve integration test TestCreateWithCustomMaskedPaths() to ensure default masked paths don't apply to privileged containers. Signed-off-by: Cesar Talledo <[email protected]>

ctalledo · 2025-03-12T18:19:40Z

@thaJeztah: could I please get your approval for this PR (assuming it's all good)? Thanks!

robmry

LGTM

thaJeztah

LGTM

sorry, was waiting for that discussion that was happening; code looks good

On Linux, mask "/proc/interrupts" and "/sys/devices/system/cpu/*/thermal_throttle" inside containers by default. It is the equivalent of moby/moby#49560 for Moby. Mitigates potential Thermal Side-Channel Vulnerability Exploit (https://github.com/moby/moby/security/advisories/GHSA-6fw5-f8r9-fgfm). Signed-off-by: Giuseppe Scrivano <[email protected]>

On Linux, mask "/proc/interrupts" and "/sys/devices/system/cpu/cpu<x>/thermal_throttle" inside containers by default. Privileged containers or containers started with --security-opt="systempaths=unconfined" are not affected. Mitigates potential Thermal Side-Channel Vulnerability Exploit (https://github.com/moby/moby/security/advisories/GHSA-6fw5-f8r9-fgfm). Also: improve integration test TestCreateWithCustomMaskedPaths() to ensure default masked paths don't apply to privileged containers. Refers to moby/moby#49560 Signed-off-by: Sascha Grunert <[email protected]>

This is following upstream Docker/Podman, specifically following Podman's implementation by pulling in github.com/containers/common. That repo appears to be a shared library among all their other projects. We could potentially simplify some of our container creation behaviour by leveraging more of that package in our own runtime code. For now we're pulling in the lists of masked and readonly paths that they also use for unprivileged containers. They appear to follow whatever Docker does, so this keeps us inline with what the overall container community expects for non-privileged containers. Motivation for this change came from this Docker PR: moby/moby#49560 Which was detected by our pipeline job that checks for new docker mounts in privileged and non-privileged containers. Signed-off-by: Taylor Silva <[email protected]>

On Linux, mask "/proc/interrupts" and "/sys/devices/system/cpu/cpu<x>/thermal_throttle" inside containers by default. Privileged containers or containers started with --security-opt="systempaths=unconfined" are not affected. Mitigates potential Thermal Side-Channel Vulnerability Exploit (https://github.com/moby/moby/security/advisories/GHSA-6fw5-f8r9-fgfm). Also: improve integration test TestCreateWithCustomMaskedPaths() to ensure default masked paths don't apply to privileged containers. Refers to moby/moby#49560 Signed-off-by: Sascha Grunert <[email protected]>

thaJeztah added area/runtime Runtime status/2-code-review impact/changelog labels Feb 28, 2025

thaJeztah added this to the 28.0.2 milestone Feb 28, 2025

thaJeztah added process/cherry-pick/23.0 process/cherry-pick/25.0 process/cherry-pick/27.x labels Feb 28, 2025

vvoland reviewed Feb 28, 2025

View reviewed changes

internal/platform/platform_linux_test.go Outdated Show resolved Hide resolved

internal/platform/platform_linux_test.go Outdated Show resolved Hide resolved

ctalledo force-pushed the mask-thermal-interrupt-info branch from 24dd26c to 6d3a73e Compare February 28, 2025 18:50

ctalledo requested a review from vvoland February 28, 2025 18:51

thompson-shaun assigned thaJeztah and vvoland Mar 6, 2025

temenuzhka-thede approved these changes Mar 10, 2025

View reviewed changes

ctalledo force-pushed the mask-thermal-interrupt-info branch from 6d3a73e to a3fef5d Compare March 11, 2025 00:18

vvoland added the kind/enhancement Enhancements are not bugs or new features but can improve usability or performance. label Mar 12, 2025

vvoland approved these changes Mar 12, 2025

View reviewed changes

vvoland requested a review from thaJeztah March 12, 2025 16:43

vvoland requested a review from robmry March 13, 2025 15:12

robmry approved these changes Mar 13, 2025

View reviewed changes

robmry merged commit 97c3971 into moby:master Mar 13, 2025
155 checks passed

ctalledo deleted the mask-thermal-interrupt-info branch March 13, 2025 16:02

thaJeztah reviewed Mar 13, 2025

View reviewed changes

This was referenced Mar 20, 2025

Mask Linux thermal interrupt info in /proc and /sys containers/podman#25634

Closed

Mask Linux thermal interrupt info in /proc and /sys containers/buildah#6073

Closed

Mask Linux thermal interrupt info in /proc and /sys cri-o/cri-o#9068

Closed

giuseppe mentioned this pull request Mar 20, 2025

config: mask thermal interrupt info paths containers/common#2375

Merged

saschagrunert mentioned this pull request Mar 24, 2025

Mask Linux thermal interrupt info in /proc and /sys. kubernetes/kubernetes#131018

Merged

jtgasper3 mentioned this pull request Mar 24, 2025

Bump github.com/docker/docker from 28.0.1+incompatible to 28.0.2+incompatible jtgasper3/swarm-visualizer#12

Closed

thaJeztah removed the process/cherry-pick/27.x label Sep 9, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Mask Linux thermal interrupt info in /proc and /sys. #49560

Mask Linux thermal interrupt info in /proc and /sys. #49560

Uh oh!

ctalledo commented Feb 28, 2025 •

edited by vvoland

Loading

Uh oh!

vvoland Feb 28, 2025

Uh oh!

ctalledo Feb 28, 2025 •

edited

Loading

Uh oh!

thaJeztah Feb 28, 2025

Uh oh!

ctalledo Mar 4, 2025

Uh oh!

ctalledo Mar 6, 2025

Uh oh!

vvoland Mar 11, 2025

Uh oh!

ctalledo Mar 11, 2025

Uh oh!

Uh oh!

Uh oh!

ctalledo commented Mar 12, 2025

Uh oh!

robmry left a comment

Uh oh!

Uh oh!

thaJeztah left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Mask Linux thermal interrupt info in /proc and /sys. #49560

Mask Linux thermal interrupt info in /proc and /sys. #49560

Uh oh!

Conversation

ctalledo commented Feb 28, 2025 • edited by vvoland Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vvoland Feb 28, 2025

Choose a reason for hiding this comment

Uh oh!

ctalledo Feb 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

thaJeztah Feb 28, 2025

Choose a reason for hiding this comment

Uh oh!

ctalledo Mar 4, 2025

Choose a reason for hiding this comment

Uh oh!

ctalledo Mar 6, 2025

Choose a reason for hiding this comment

Uh oh!

vvoland Mar 11, 2025

Choose a reason for hiding this comment

Uh oh!

ctalledo Mar 11, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

ctalledo commented Mar 12, 2025

Uh oh!

robmry left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

thaJeztah left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

ctalledo commented Feb 28, 2025 •

edited by vvoland

Loading

ctalledo Feb 28, 2025 •

edited

Loading