Че, не мог даже, как все приличные люди-не-лохи, дать на лапу или задействовать связи родаков? Ну тогда да, рофллол!

Багрепорт как багрепорт. Просто кодеры из опенки по сравнению с Максом детвора детворой. Зато визгу от openbsd и хайпа на весь мир. Хотя последние несколько месяцев какая-то контора показала, что баги в нутрях опёнка довольно примитивные. NetBSD и то будет защищённее (даже согласно статам на cvedetails).

In vmm_update_pvclock():

6868 pvclock_gpa = vcpu->vc_pvclock_system_gpa & 0xFFFFFFFFFFFFFFF0;  <-- controlled by the guest
6869 if (!pmap_extract(vm->vm_map->pmap, pvclock_gpa, &pvclock_hpa))
6870 return (EINVAL);
6871 pvclock_ti = (void*) PMAP_DIRECT_MAP(pvclock_hpa);
6872
6873 /* START next cycle (must be odd) */
6874 pvclock_ti->ti_version =
6875     (++vcpu->vc_pvclock_version << 1) | 0x1;

Three things are wrong:

  1) The RO protections are not enforced, so the guest could have data be
     written to a GPA it can only access as RO.

  2) If 'pvclock_ti' crosses a page, its second half could point to an HPA
     that doesn't belong to the guest. The guest can therefore, to some
     limited extent, overwrite host kernel memory.

  3) The pmap is not locked, so if the GPA gets unmapped and its
     corresponding HPA recycled, there is a small window where the (new)
     content of the HPA can get overwritten.

There is, in fact, a fourth case. Watch closely. On AMD CPUs the NPTs are
a regular pmap. The higher half of the GPA space is therefore mapped to
host kernel memory as KVA. Given that there is no check on PG_u here, the
guest can just put a host KVA in pvclock_gpa, and have its content be
overwritten. This gives write-where ability for the guest.

The OpenBSD kernel does not perform full ASLR, in that the PTE space and
direct map are at static addresses (contrary to eg NetBSD where everything
is randomized). These addresses are known. The guest can therefore use the
static address of the direct map for example to write at whatever HPA by
issuing the following instruction:

wrmsr(KVM_MSR_SYSTEM_TIME, PMAP_DIRECT_MAP(hpa) | 1);

This means the guest can overwrite whatever host kernel memory, and can
control *where* to write. I have tested this, and it works.

The guest can also choose *what* to write, because it just so happens that
'vc_pvclock_version' is the number of VMEXITs that occurred with pvclock
enabled, and the guest can reliably craft this value. So this is not just
a write-where, this is a full guest-to-host write-what-where.

Had there been proper ASLR, it still could have been somewhat bypassable,
because VMD does a pass-through of RDMSR on AMD CPUs (??), which can leak
HPAs such as HSAVE_PA.

(Speaking about direct map, notice how an alignment bug in locore0.S
causes the first 2MB of .text to be writable on Intel CPUs. So there is a
static address that maps the kernel .text as writable.)

There are additional assorted bugs and vulns that could be used to some
degree:

  - On AMD CPUs the CPL check on XSETBV VMEXITs must be performed by
    software. VMD forgot to do that, so from guest-userland, we can control
    the XCR0 that guest-kernel will use.

  - This XSETBV issue actually has an additional ramification. Right now
    OpenBSD doesn't check that the guest XCR0 is a subset of the host XCR0,
    which means that the guest can use more FPU states than the host allows.
    It looks like this check was lost when fixing another bug I reported one
    year ago which could cause guest-to-host DoS.

  - The TLB handling of guest pages is broken, in that the INVEPT
    instructions in the host could be issued on the wrong CPUs. This means
    that if UVM decides to swap out a guest page, the guest could still
    access it via stale TLB entries. On AMD CPUs, there is no TLB handling
    at all (??).

  - vmx_load_pdptes is broken.

In order to make this whole thing less of a security joke, I would suggest
the following:

  - Fix TLB handling, sanitize the GPAs, lock the pages correctly.
  - Don't pass-through RDMSR.
  - Fix the XSETBV issues.
  - Provide *real* ASLR: randomize the PTE space and the direct map.
  - Fix the alignment bug in the direct map to not map the text as writable.

Maxime Villard

После того как он всё это разжевал, разумеется, что ему было дико нелепо видеть нубский патч от OpenBSD.

>[оверквотинг удален]
> Module name: src
> Changes by: mortimer@cvs.openbsd.org 2020/02/15 15:59:55
>
> Modified files:
> sys/arch/amd64/amd64: vmm.c
>
> Log message:
> Add bounds check on addresses passed from guests in pvclock.
>
> Fixes an issue where a guest can write to host memory by passing bogus addresses.

I'm a bit confused here. It is not because the GPAs are contiguous that the
HPAs are too. If the structure crosses a page, the guest still can write to
host memory.

Вот тебе и ку-ка-ре-ку самая безопасная в мире ОС OpenBSD ку-ка-ре-ку. Добавить тут особенно нечего... Ах, да, Макс уже тонко троллирует ребят из OpenBSD, используя фразы а-ля

In order to make this whole thing less of a security joke

Вот репорт:
https://marc.info/?l=openbsd-tech&m=158176939604512&w=2

Я даже не знаю, как тут подробнее разжевать. Начать с алфавита английского языка, что ли?

угу. На коленях, смерд, подползать должон! Держа в зубах готовый патч, непременно одобренный не меньше чем шестью виликими разработчиками!

Желательно не ранее чем через пятнадцать лет после того как уговоришь этот патч принять.

Публичные багрепорты именно так и делаются - нашел баг - зарепортил публике. Если и дал время на исправление - это твоя добрая воля, и не более того.

А он что, так плох?

У бзд перед линуксом я вижу только одно гигантское преимущество: capitalism-friendly-лицензия без бессмысленных 1980-хиппи-лозунгов и кучи ограничений (id est несвобод).

Зато OpenVZ был (хоть и отставал сильно по ядрам).

С того, что сравнивать докер с jail — это как сравнивать грузовик с велосипедом. Изоляция на уровне cgroups и namespaces — это только вишенка на торте. Главное — унифицированный механизм упаковки и распространения образов, который сделал докер лучшим (и, практически, единственным) пакетным менеджером для серверов.

Нет Wayland и systemd