[GH-ISSUE #1712] Intel/AMD CPU security flaws

gitea-mirror commented

2026-05-05 07:33:37 -06:00

Owner

Originally created by @nick75e on GitHub (Jan 4, 2018).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1712

Hi,

It's been recently found out that Intel and AMD CPUs are affected by security flaws: Meltdown and Spectre.
More information: Google's Projet Zero, Arstechnica and dedicated website.

It's planned to patch v4.15 of the kernel and backport it to v4.14.11. There's no information as to whether it'll be backported to earlier versions. So in the meantime, is there a way Firejail can mitigate (or fix) this problem with an option like a seccomp filter or anything ?

Happy New Year!

Originally created by @nick75e on GitHub (Jan 4, 2018). Original GitHub issue: https://github.com/netblue30/firejail/issues/1712 Hi, It's been recently found out that Intel and AMD CPUs are affected by security flaws: [Meltdown](https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)) and [Spectre](https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)). More information: [Google's Projet Zero](https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html), [Arstechnica](https://arstechnica.com/gadgets/2018/01/meltdown-and-spectre-every-modern-processor-has-unfixable-security-flaws/) and [dedicated website](https://meltdownattack.com/). It's planned to patch v4.15 of the kernel and backport it to v4.14.11. There's no information as to whether it'll be backported to earlier versions. So in the meantime, is there a way Firejail can mitigate (or fix) this problem with an option like a seccomp filter or anything ? Happy New Year!

gitea-mirror

2026-05-05 07:33:37 -06:00

closed this issue
added the
question_old
label

gitea-mirror commented

2026-05-05 07:33:42 -06:00

Author

Owner

@topimiettinen commented on GitHub (Jan 4, 2018):

Seccomp works by blocking system calls and the CPU flaws are not using system call interface but more primitive memory access and branch operations. I don't see how seccomp could be used here directly. The other protections like blacklisting files, dropping capabilities, private network namespaces, firewalls and so forth are also way too high level. It's also not possible to protect kernel memory on behalf of kernel by a user process.

The attacks seem to rely on access to precision time like processor Time Stamp Counter (TSC). We could add an option to disable TSC by Firejail with prctl(PR_SET_TSC, PR_TSC_SIGSEGV). I don't know if that would break something else. There are still less precise methods to get time like gettimeofday() system call. Blocking those with seccomp would be possible but it could break normal uses.

@topimiettinen commented on GitHub (Jan 4, 2018): Seccomp works by blocking system calls and the CPU flaws are not using system call interface but more primitive memory access and branch operations. I don't see how seccomp could be used here directly. The other protections like blacklisting files, dropping capabilities, private network namespaces, firewalls and so forth are also way too high level. It's also not possible to protect kernel memory on behalf of kernel by a user process. The attacks seem to rely on access to precision time like processor Time Stamp Counter (TSC). We could add an option to disable TSC by Firejail with `prctl(PR_SET_TSC, PR_TSC_SIGSEGV)`. I don't know if that would break something else. There are still less precise methods to get time like `gettimeofday()` system call. Blocking those with seccomp would be possible but it could break normal uses.

gitea-mirror commented

2026-05-05 07:33:43 -06:00

Author

Owner

@topimiettinen commented on GitHub (Jan 4, 2018):

I made a small program to test disabling TSC:

$ cat notsc.c 
#define _GNU_SOURCE
#include <linux/prctl.h>
#include <sys/prctl.h>
#include <unistd.h>

int main(int argc, char **argv)
{
        prctl(PR_SET_TSC, PR_TSC_SIGSEGV, 0, 0, 0);
        execve(argv[1], &argv[1], environ);
}
$ gcc -Wall notsc.c -o notsc
$ ./notsc /bin/ls
Segmentation fault
$ gdb --quiet --args ./notsc /bin/ls
Reading symbols from ./notsc...(no debugging symbols found)...done.
(gdb) r
Starting program: /tmp/notsc /bin/ls
process 6637 is executing new program: /bin/ls

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7ddb864 in ?? () from /lib64/ld-linux-x86-64.so.2
(gdb) x /i $rip
=> 0x7ffff7ddb864:      rdtsc

Before any main part of /bin/ls even starts, the dynamic loader crashes due to rdtsc instruction which uses TSC. So, disabling TSC does not look promising.

@topimiettinen commented on GitHub (Jan 4, 2018): I made a small program to test disabling TSC: ``` $ cat notsc.c #define _GNU_SOURCE #include <linux/prctl.h> #include <sys/prctl.h> #include <unistd.h> int main(int argc, char **argv) { prctl(PR_SET_TSC, PR_TSC_SIGSEGV, 0, 0, 0); execve(argv[1], &argv[1], environ); } $ gcc -Wall notsc.c -o notsc $ ./notsc /bin/ls Segmentation fault $ gdb --quiet --args ./notsc /bin/ls Reading symbols from ./notsc...(no debugging symbols found)...done. (gdb) r Starting program: /tmp/notsc /bin/ls process 6637 is executing new program: /bin/ls Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7ddb864 in ?? () from /lib64/ld-linux-x86-64.so.2 (gdb) x /i $rip => 0x7ffff7ddb864: rdtsc ``` Before any main part of /bin/ls even starts, the dynamic loader crashes due to rdtsc instruction which uses TSC. So, disabling TSC does not look promising.

gitea-mirror commented

2026-05-05 07:33:45 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (Jan 4, 2018):

To patch against Meltdown (Intel only), please update your kernel to 4.14.11. 4.14.11 is currently available in Arch and Fedora repos. Verify that PTI is enabled by checking if /proc/cpu contains "bugs: cpu_insecure".

To mitigate against Spectre (Basically all processors)

Firefox/IceCat: Disable "javascript.options.shared_memory" and "dom.enable_performance" via about:config
Chrome/Chromium/Inox: Enable "Site Isolation" via chrome://flags

Edit: Please see the table here for details about mitigation

@SkewedZeppelin commented on GitHub (Jan 4, 2018): To patch against Meltdown (Intel only), please update your kernel to [4.14.11](https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.11). 4.14.11 is currently available in Arch and Fedora repos. Verify that PTI is enabled by checking if /proc/cpu contains "bugs: cpu_insecure". To mitigate against Spectre (Basically all processors) - [Firefox/IceCat](https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/): Disable "javascript.options.shared_memory" and "dom.enable_performance" via about:config - [Chrome/Chromium/Inox](https://www.chromium.org/Home/chromium-security/ssca): Enable "Site Isolation" via chrome://flags Edit: Please see the table [here](https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html) for details about mitigation

gitea-mirror commented

2026-05-05 07:33:46 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (Jan 4, 2018):

@topimiettinen what about a LD_PRELOAD shim that fuzzes the result of calls to TSC?

@SkewedZeppelin commented on GitHub (Jan 4, 2018): @topimiettinen what about a LD_PRELOAD shim that fuzzes the result of calls to TSC?

gitea-mirror commented

2026-05-05 07:33:47 -06:00

Author

Owner

@topimiettinen commented on GitHub (Jan 4, 2018):

@SpotComms do you have pointers on how these browser flags work?

The attacking program would probably hardcode the RDTSC machine instruction, so how could it be fuzzed?

@topimiettinen commented on GitHub (Jan 4, 2018): @SpotComms do you have pointers on how these browser flags work? The attacking program would probably hardcode the RDTSC machine instruction, so how could it be fuzzed?

gitea-mirror commented

2026-05-05 07:33:48 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (Jan 4, 2018):

@topimiettinen I added links about that. But tl;dr Chrome puts each site in its own process so malicious JS on one page can't perform the attack and get access to another processes memory. And for Firefox disabling SharedArrayBuffers makes the attack much harder to perform.

@SkewedZeppelin commented on GitHub (Jan 4, 2018): @topimiettinen I added links about that. But tl;dr Chrome puts each site in its own process so malicious JS on one page can't perform the attack and get access to another processes memory. And for Firefox disabling SharedArrayBuffers makes the attack much harder to perform.

gitea-mirror commented

2026-05-05 07:33:49 -06:00

Author

Owner

@topimiettinen commented on GitHub (Jan 4, 2018):

@SpotComms thanks. I suppose SharedArrayBuffers is disabled so that worker threads can't be used as simple counters which would give access to good enough time, rather than memory protection (which can be bypassed by the CPU bug).

The example implementation in Spectre paper constructs large, executable memory areas for branch predictor mistraining. This could be stopped by memory-deny-write-execute. But maybe that's only an example and there are other ways. Especially browsers need JIT which does not work with memory-deny-write-execute enabled in any case.

@topimiettinen commented on GitHub (Jan 4, 2018): @SpotComms thanks. I suppose SharedArrayBuffers is disabled so that worker threads can't be used as simple counters which would give access to good enough time, rather than memory protection (which can be bypassed by the CPU bug). The example implementation in Spectre paper constructs large, executable memory areas for branch predictor mistraining. This could be stopped by memory-deny-write-execute. But maybe that's only an example and there are other ways. Especially browsers need JIT which does not work with memory-deny-write-execute enabled in any case.

gitea-mirror commented

2026-05-05 07:33:51 -06:00

Author

Owner

@nick75e commented on GitHub (Jan 5, 2018):

Thanks for all the information guys.

Since I'm on Linux Mint 18.3 (based on Ubuntu 16.04), I can only hope that the fix is backported to earlier versions or that Ubuntu decides to make v4.15 or v4.14.11 available.
Fingers crossed.

Note: uBlock origin's developer @gorhill released uMatrix v1.2.0 which can enable and disable web workers on a per-site basis.

Update: blocking web workers everywhere by default should lower quite significantly the probability of falling prey to exploits taking advantage of Meltdown/Spectre vulnerabilities through your browser (assuming your browser is vulnerable).

@nick75e commented on GitHub (Jan 5, 2018): Thanks for all the information guys. Since I'm on Linux Mint 18.3 (based on Ubuntu 16.04), I can only hope that the fix is backported to earlier versions or that Ubuntu decides to make v4.15 or v4.14.11 available. _Fingers crossed._ Note: uBlock origin's developer @gorhill released [uMatrix v1.2.0](https://github.com/gorhill/uMatrix/releases/tag/1.2.0) which can enable and disable web workers on a per-site basis. > Update: blocking web workers everywhere by default should lower quite significantly the probability of falling prey to exploits taking advantage of Meltdown/Spectre vulnerabilities through your browser (assuming your browser is vulnerable).

gitea-mirror commented

2026-05-05 07:33:51 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (Jan 5, 2018):

@nick75e KPTI has been backported and is available in 4.14.11, 4.9.75, and 4.4.110 as well as 4.15 itself. But as detailed here, that only solves 1/3 of the problem.

@SkewedZeppelin commented on GitHub (Jan 5, 2018): @nick75e KPTI has been backported and is available in 4.14.11, 4.9.75, and 4.4.110 as well as 4.15 itself. But as detailed [here](https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html), that only solves 1/3 of the problem.

Rows
Columns

[GH-ISSUE #1712] Intel/AMD CPU security flaws #1157