답변:
"bugs"필드의 의도는이 를 도입/proc/cpuinfo
한 커밋 메시지에 설명되어 있습니다 .
x86/cpufeature
:에 버그 플래그 추가/proc/cpuinfo
기능 플래그와 유사한 방식으로 실행중인 CPU에 버그 해결 방법을 감지했거나 적용했음을 나타내는 플래그를 덤프합니다.
장점은 CPU 기능과 같이 시간이 지남에 따라 누적되지 않는다는 것입니다.
이전에는 커널에서 감지 한 하드웨어 버그가 별도의 기능 ( 예 : 32 비트 x86 시스템 f00f_bug
에서 자체 항목 이있는 악명 높은 F00F 버그) 으로 나열되었습니다 /proc/cpuinfo
. "bugs"항목은 x86 CPU flags 와 같은 스타일로 앞으로 단일 기능으로이를 유지하기 위해 도입되었습니다 .
메시지에서 볼 수 있듯이 실제로 항목이 의미하는 바는 커널 이 하드웨어 버그를 감지 한 것입니다. 문제가 처리되는지 확인하려면 다른 곳 (부팅 메시지 또는 파일과 같은 특정 /proc
항목 또는 /sys
항목) 을 찾아야 합니다 /sys/devices/system/cpu/vulnerabilities/
.
"버그"항목의 유용성은 두 가지 방식으로 제한됩니다. 첫 번째는 진정한 네거티브를 알 수없는 것과 구별 할 수 없다는 것입니다. 필드가 "cpu_meltdown"을 지정하지 않으면 커널이 Meltdown에 대해 알지 못한다는 것을 의미하는지 (필드에서만) 알 수 없습니다. CPU는 Meltdown의 영향을받지 않습니다. 두 번째는 탐지가 너무 단순 할 수 있다는 것입니다. 주의를 기울여야하기 때문에 CPU가 취약하지 않은 경우 CPU가 취약하다고보고 할 수 있습니다. "감지"는 테이블 중심이므로 정확도는 실행중인 커널 버전에 따라 다릅니다.
Meltdown 및 Spectre 버그의 경우 x86에서 /proc/cpuinfo
다음과 같이 작동합니다 .
Meltdown / Spectre 취약점은 CPU 칩셋 디자인 / 아키텍처에 있으며, 향후 새로운 하드웨어 구매가 부족하여 패치는 장기적 으로 보안에 대한 좋은 환상입니다 . 결함을 악용하는 새로운 방법은 현재 패치를 우회 할 수있는 시간이 지남에 따라 나타날 수 있습니다.
요컨대, 현재 소프트웨어 패치 / 마이크로 코드 는 Spectre / Meltdown 익스플로잇의 알려진 방법에 대한 문제를 완화 시키지만, 처음부터이를 허용하는 기본 CPU 설계 문제를 해결하지는 않습니다. 영향을받는 (여러 세대) CPU는 장기적으로 취약성을 멈추지 않았으며 (아마도 그렇지 않을 것입니다).
그러나 @Gilles가 올바르게 말했듯이 경고가 있다고해서 현재 알려진 익스플로이 트 스펙터 / 멜트 다운 방법이 작동하지는 않습니다. 패치가 설치되어 있으면 작동하지 않습니다.
질문에서 언급 한 경우, 커널은 Spectre / Meltdown의 영향을받는 것으로 알려진 CPU 모델 (x86에 대해서만 이야기하는 경우 모든 x86 CPU) 만 검사하므로 cpu-insecure
여전히 버그 섹션에 나열됩니다 / 라인 /proc/cpuinfo
.
가서 확인하십시오
/proc/cpuinfo
. 커널에 KPTI 패치가 있으면 cpu_insecure를 포함합니다KPTI 패치에 다음 코드가 있음을 발견했습니다.
/* Assume for now that ALL x86 CPUs are insecure */ setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
커널 업데이트 후 다음과 같은 결과가 나타납니다.
bugs : cpu_insecure
추신. Spectre / Meltdown "버그"를 이용하는 새로운 방법에 대한 업데이트가 이미있었습니다. 아마 마지막이 아닐 것입니다.
/proc/cpuinfo
소프트웨어 패치로 완전히 완화 된 경우에도 나열됩니다 . 존재 한다고해서 시스템이 특정 버그에 취약하다는 의미 는 아닙니다 .
bugs
라인 쇼의 사실 이며 이것이 잘못되었음을 썼습니다 . 대부분의 CPU 디자인 버그에는 약간의 성능만으로도 완전한 소프트웨어 해결 방법이 있습니다. 커널이 해결 방법을 적용하면 버그는 무해합니다.