New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update spectre meltdown checker #620

merged 2 commits into from Jan 26, 2019


None yet
2 participants
Copy link

alexAubin commented Jan 19, 2019

The problem

Spectre Meltdown checker was last updated around May : #464


Update to most recent version with git subtree pull --prefix src/yunohost/vendor/spectre-meltdown-checker master --squash

PR Status

Tested, works as expected

How to test

Pull the branch and run yunohost tools diagnosis, see if there's an output in security section


  • Principle agreement 0/2 :
  • Quick review 0/1 :
  • Simple test 0/1 :
  • Deep review 0/1 :

alexAubin added some commits Jan 19, 2019

Squashed 'src/yunohost/vendor/spectre-meltdown-checker/' changes from…
… edebe4dc..d7d2e693

d7d2e693 fix: typo in bare metal detection (fixes #269)
b0083d91 Remove unneeded volumes in Dockerfile (#266)
904a83c6 Fix Arch kernel image detection (#268)
906f54cf Improved hypervisor detection (#259)
c45a06f4 Warn on missing kernel info (#265)
4a6fa070 Fix misdetection of files under Clear Linux (#264)
c705afe7 bump to v0.40
401ccd4b Correct aarch64 KPTI dmesg message
55120839 Fix a typo in check_variant3_linux()
f5106b3c update MCEDB from v83 to v84 (no actual change)
68289dae feat: add --update-builtin-mcedb to update the DB inside the script
3b2d5296 feat(l1tf): read & report ARCH_CAPABILITIES bit 3 (SKIP_VMENTRY_L1DFLUSH)
cbb18cb6 fix(l1tf): properly detect status under Red Hat/CentOS kernels
299103a3 some fixes when script is not started as root
dc5402b3 chore: speed optimization of hw check and indentation fixes
90c2ae5d feat: use the MCExtractor DB as the reference for the microcode versions
53d6a447 Fix detection of CVE-2018-3615 (L1TF_SGX) (#253)
297d890c fix ucode version check regression introduced by fbbb19f under BSD
0252e74f feat(bsd): implement CVE-2018-3620 and CVE-2018-3646 mitigation detection
fbbb19f2 Fix cases where a CPU ucode version is not found in $procfs/cpuinfo. (#246)
1571a56c feat: add L1D flush cpuid feature bit detection
3cf91416 fix: don't display summary if no CVE was tested (e.g. --hw-only)
bff38f1b BSD: add not-implemented-yet notice for Foreshadow-NG
b419fe7c feat(variant4): properly detect SSBD under BSD
f193484a chore: fix deprecated SPDX license identifier (#249) (#251)
349d77b3 Fix kernel detection when /lib/kernel exists on a distro (#252)
e589ed7f fix: don't test SGX again in check_CVE_2018_3615, already done by is_cpu_vulnerable
ae120628 fix: remove some harcoded /proc paths, use $procfs instead
b44d2b54 chore: remove 'experimental' notice of Foreshadow from README
7b72c20f feat(l1tf): explode L1TF in its 3 distinct CVEs
b48b2177 feat: Add Clear Linux Distro (#244)
8f31634d feat(batch): Add a batch short option for one line result (#243)
96798b19 chore: add SPDX GPL-3.0 license identifier (#245)
687ce1a7 fix: load cpuid module if absent even when /dev/cpu/0/cpuid is there
80e0db7c fix: don't show erroneous ucode version when latest version is unknown (fixes #238)
e8890ffa feat(config): support for genkernel kernel config file (#239)
b2f64e11 fix README after merge
42a3a61f Slightly improved Docker configuration (#230)
afb36c51 Fix typo: 'RBS filling' => 'RSB filling' (#237)
0009c0d4 fix: --batch now implies --no-color to avoid colored warnings
dd67fd94 feat: add FLUSH_CMD MSR availability detection (part of L1TF mitigation)
339ad317 fix: add missing l1tf CPU vulnerability display in hw section
794c5be1 feat: add optional git describe support to display inter-release version numbers
a7afc585 fix several incorrect ucode version numbers
fc1dffd0 feat: implement detection of latest known versions of intel microcodes
e9426161 feat: initial support for L1TF
360be7b3 fix: hide arch_capabilities_msr_not_read warning under !intel
5f592578 bump to v0.39
92d59cbd chore: adjust some comments, add 2 missing inits
4747b932 feat: add detection of RSBA feature bit and adjust logic accordingly
860023a8 fix: ARCH MSR was not read correctly, preventing proper SSB_NO and RDCL_NO detection
ab67a922 feat: read/write msr now supports msr-tools or perl as dd fallback
f4592bf3 Add Arch armv5/armv7 kernel image location (#227)
be15e476 chore: setting master to v0.38+
d3481d95 Add support for the kernel being within a btrfs subvolume (#226)
21af5611 bump to v0.38
cb740397 feat(arm32): add spectrev1 mitigation detection
84195689 change: default to --no-explain, use --explain to get detailed mitigation help
b637681f fix: debug output: msg inaccuracy for ARM checks
9316c305 fix: armv8: models < 0xd07 are not vulnerable
f9dd9d8c add guess for archlinuxarm aarch64 kernel image on raspberry pi 3 (#222)
0f0d103a fix: correctly init capabilities_ssb_no var in all cases
b262c405 fix: remove spurious character after an else statement
cc2910fb fix: read_cpuid: don't use iflag=skip_bytes for compat with old dd versions
30c4a1f6 arm64: cavium: Add CPU Implementer Cavium (#216)
cf06636a fix: prometheus output: use printf for proper \n interpretation (#204)
60077c8d fix(arm): rewrite vuln logic from latest arm statement for Cortex A8 to A76
c181978d fix(arm): Updated arm cortex status (#209)
9a6406a9 chore: add docker support (#203)
5962d20b fix(variant4): whitelist from common.c::cpu_no_spec_store_bypass (#202)
17a34885 fix(help): add missing references to variants 3a & 4 (#201)
e54e8b3e chore: remove warning in README, fix display indentation
39c778e3 fix(amd): AMD families 0x15-0x17 non-arch MSRs are a valid way to control SSB
2cde6e46 feat(ssbd): add detection of proper CPUID bits on AMD
f4d51e7e fix(variant4): add another detection way for Red Hat kernel
85d46b27 feat(variant4): add more detailed explanations
61e02abd feat(variant3a): detect up to date microcode
114756fa fix(amd): not vulnerable to variant3a
ea75969e fix(help): Update variant options in usage message (#200)
ca391cbf fix(variant2): correctly detect IBRS/IBPB in SLES kernels
68af5c5f feat(variant4): detect SSBD-aware kernel
19be8f79 doc: update README with some info about variant3 and variant4
f75cc0bb feat(variant4): add sysfs mitigation hint and some explanation about the vuln
f33d65ff feat(variant3a): add information about microcode-sufficient mitigation
725eaa8b feat(arm): adjust vulnerable ARM CPUs for variant3a and variant4
c6ee0358 feat(variant4): report SSB_NO CPUs as not vulnerable
22d0b203 fix(ssb_no): rename ssbd_no to ssb_no and fix shift
3062a841 fix(msg): add missing words
6a4318ad feat(variant3a/4): initial support for 2 new CVEs
c1998618 fix(variant2): adjust detection for SLES kernels
7e4899bc  ibrs can't be enabled on no ibrs cpu  (#195)
5cc77741 Update
1c0f6d95 cpuid and msr module check
4acd0f64 Suggestion to change VM to a CPU with IBRS capability
fb52dbe7 set master branch to v0.37+

git-subtree-dir: src/yunohost/vendor/spectre-meltdown-checker
git-subtree-split: d7d2e6934ba08a2de2e2c80bb42936a60b884b78

This comment has been minimized.

Copy link
Member Author

alexAubin commented Jan 19, 2019

By the way : so far we are only checking Variant 3 (c.f. this comment : #406 (comment) )

What about other variants ? In particular, on one of my test machines (a VPS), I noticed that it is vulnerable to newer variants, though it's not clear how I'm supposed to fix them (maybe they can't be fixed for now)


This comment has been minimized.

Copy link

Psycojoker commented Jan 20, 2019

What about other variants ? In particular, on one of my test machines (a VPS), I noticed that it is vulnerable to newer variants, though it's not clear how I'm supposed to fix them (maybe they can't be fixed for now)

It's a hard question: those other variants aren't fixed everywhere according to debian CVE pages. So, what should we do? Options that I see:

  1. don't handle this situation, it's been so long since that
  2. show a warning if possible
  3. show a warning only if it's possible to fix it? That would require quite moar code that needs to evolve with debian data (I know this website allow to download a json with all its data)

For me it's either 1 or 3 and probably 1 in the meantime, 2 wouldn't be god as a UX stand point because informing users that they are vulnerable with not way to fix that would sucks I think (but ... they are still vulnerable and I don't like that x( but that's on debian/hardware builder side I think :/) and only generate problems that can't be solved and support for us.

That's not really a trivial situation :/


This comment has been minimized.

Copy link
Member Author

alexAubin commented Jan 21, 2019

I dunno much what to do either :/

An interesting anecdote is a user who recently checked this and the script reported that the instance was vulnerable to variant 3. After contacting the VPS provider (Gandi), they told that "everything has been done to mitigate the issue and this is probably the tool misdiagnosis this" (paraphrasing what they wrote but this is pretty close).

If they are right, then that is disappointing that they are not contacting the script author in order to improve the accuracy of the diagnosis ... But that basically adds more questions to what should be done about those diagnosis results.

Naively I would just test all variants and inform the user about vulnerabilities found, but just make it "less scary" somehow, and provide link to human-readable infos about this, idk @.@


This comment has been minimized.

Copy link
Member Author

alexAubin commented Jan 26, 2019

Merging this meanwhile ... I guess we can postpone the discussion :/

@alexAubin alexAubin merged commit 758028b into stretch-unstable Jan 26, 2019

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
continuous-integration/travis-ci/push The Travis CI build passed

@alexAubin alexAubin deleted the update-spectre-meltdown-checker branch Jan 26, 2019

@alexAubin alexAubin added this to the 3.4.x milestone Jan 26, 2019


This comment has been minimized.

Copy link

Psycojoker commented Jan 27, 2019

Yes, we should copy/paste/move that discussion to somewhere else like an issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment