Meltdown & Specter-패치되지 않은 하이퍼 바이저의 게스트 커널을 패치하면 교차 VM 메모리 누수가 방지됩니까?

취약점의 광범위한 릴리스 24 시간 후 Rackspace는 Spectre 및 Meltdown에 대해 침묵합니다. 모든 Xen 하이퍼 바이저를 패치 할 계획이 없습니다. 모든 최신 플랫폼 서버는 취약한 HVM 서버입니다. 오래된 PV 서버는 취약하지 않습니다.

HVM 게스트의 Linux 커널을 업데이트했지만 Rackspace에서 하이퍼 바이저를 업데이트하지 않았습니다. 패치되지 않은 하이퍼 바이저에서 게스트 커널을 업데이트하면 "나쁜 사람"VM이 패치 된 호스트에서 누수 된 메모리에 액세스하지 못합니까?

내가 취약성에 대해 이해 한 바에 따르면, 추측 캐싱 공격은 임의의 주소에서 메모리를 가져 오는 프로세스에 대해 모든 CPU 보호를 우회합니다.

하이퍼 바이저의 커널 메모리 공간뿐만 아니라 주변 VM (공격 자체를 보호하기 위해 패치 된 것 포함)과 직접 메모리 공개를 방지 할 수있는 기능이없는 경우에도 잠재적 인 가능성이 있습니다. 공격자는 커널 메모리에 대한 액세스 권한을 사용하여 하이퍼 바이저에보다 완전하게 액세스 할 수 있습니다.

실행중인 모든 VM을 신뢰할 수없는 경우 패치되지 않은 하이퍼 바이저에서 민감한 워크로드를 실행하는 위험을 감수하고 싶지 않습니다.

유령과 붕괴.

우리는 어디에서 시작합니까? 나쁘다, 나는 클라우드의 컴퓨터, 워크 스테이션, 서버 또는 서버에 영향을 줄 수도 있고 그렇지 않을 수도있는 매우 나쁜 보도 자료를 의미합니다. 그렇습니다.하지만 관련 CPU에 로컬로 액세스 할 수 있어야합니다 .PC 또는 전화 일 수 있습니다 .Apple은 모범이되었지만 ARM CPU를 생각할 수 있도록 (모바일 플랫폼을 지원하는 모든 모바일 플랫폼) / 마이크로 코드 노출 / OS / etc / etc에서 CPU를 너무 많이 제어)

응용 프로그램은 장치의 CPU에서 실행되어야하므로 콘솔 액세스 또는 적어도 시스템에 액세스하는 원격 사용자, 입력 장치 액세스 ....

현재이 취약점을 악용하는 유일한 방법은 로컬 / 직접 CPU에 액세스하는 것입니다 (SSH / VNC 등을 사용하면 원격으로 다시 할 수 있음)

아래는 지금까지 찾은 패치입니다.

VMWare has released a security advisory for their ESXi, Workstation and Fusion products: VMSA-2018-0002
[https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html][1]

RedHat has released a security advisory for their qemu product:  [https://access.redhat.com/errata/RHSA-2018:0024][1]

Amazon has released a security advisory for their Amazon Linux AMI product: ALAS-2018-939

https://alas.aws.amazon.com/ALAS-2018-939.htm l

이제 이것은 현재 당면한 문제에 대한 최선의 대응이어야합니다

우리 BSD 친구들은 무엇을 말했습니까?

나쁜 구글; (

동일한 Powershell 검사;)

Linux Kernel Ok, 우리는 재미있는 일주일을 보냈으며, 이제 모든 일반 릴리스 타이밍 규칙을 따르지 않고 모든 이상한 x86 페이지 테이블 격리 패치를 병합하는 이유를 모두가 알고 있습니다.

이 글을 다시 보거나 편집 할 수 있습니다. 나는 비 이슈 (야생 때까지)가 실제로 문제가되지 않을 것이라고 확신합니다. Google은 여기에 공개 릴리스 날짜를 준수해야합니다! Google의 경우 -1