docs: direct host owners to their distribution security advisories

Listing out individual kernel vulnerabilities will tend to be out of
date and gives a false sense of security. Move up the recommendation to
keep host & guest kernels up to date and give ALAS as an example for
following security advisories.

Signed-off-by: Derek Manwaring <[email protected]>

Author: derekmanwaring

docs/prod-host-setup.md

@@ -1,9 +1,12 @@
 # Production Host Setup Recommendations
 
-Firecracker relies on KVM and on the processor virtualization features
-for workload isolation. Security guarantees and defense in depth can only be
-upheld, if the following list of recommendations are implemented in
-production.
+Firecracker relies on KVM and on the processor virtualization features for
+workload isolation. The host and guest kernels and host microcode must be
+regularly patched in accordance with your distribution's security advisories
+such as [ALAS](https://alas.aws.amazon.com/alas2023.html) for Amazon Linux.
+
+Security guarantees and defense in depth can only be upheld, if the following
+list of recommendations are implemented in production.
 
 ## Firecracker Configuration
 
@@ -301,6 +304,14 @@ For vendor-specific recommendations, please consult the resources below:
 - AMD: [AMD Product Security](https://www.amd.com/en/resources/product-security.html)
 - ARM: [Speculative Processor Vulnerability](https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability)
 
+##### [ARM only] Physical counter directly passed through to the guest
+
+On ARM, the physical counter (i.e `CNTPCT`) it is returning the
+[actual EL1 physical counter value of the host][1]. From the discussions before
+merging this change [upstream][2], this seems like a conscious design decision
+of the ARM code contributors, giving precedence to performance over the ability
+to trap and control this in the hypervisor.
+
 ##### Verification
 
 [spectre-meltdown-checker script](https://github.com/speed47/spectre-meltdown-checker)
@@ -315,143 +326,5 @@ downloaded and executed like:
 wget -O - https://meltdown.ovh | bash
 ```
 
-### Known kernel issues
-
-General recommendation: Keep the host and the guest kernels up to date.
-
-#### [CVE-2019-3016](https://nvd.nist.gov/vuln/detail/CVE-2019-3016)
-
-##### Description
-
-In a Linux KVM guest that has PV TLB enabled, a process in the guest kernel
-may be able to read memory locations from another process in the same guest.
-
-##### Impact
-
-Under certain conditions the TLB will contain invalid entries. A malicious
-attacker running on the guest can get access to the memory of other running
-process on that guest.
-
-##### Vulnerable systems
-
-The vulnerability affects systems where all the following conditions
-are present:
-
-- the host kernel >= 4.10.
-- the guest kernel >= 4.16.
-- the `KVM_FEATURE_PV_TLB_FLUSH` is set in the CPUID of the
-  guest. This is the `EAX` bit 9 in the `KVM_CPUID_FEATURES (0x40000001)` entry.
-
-This can be checked by running
-
-```bash
-cpuid -r
-```
-
-and by searching for the entry corresponding to the leaf `0x40000001`.
-
-Example output:
-
-```console
-0x40000001 0x00: eax=0x200 ebx=0x00000000 ecx=0x00000000 edx=0x00000000
-EAX 010004fb = 0010 0000 0000
-EAX Bit 9: KVM_FEATURE_PV_TLB_FLUSH = 1
-```
-
-##### Mitigation
-
-The vulnerability is fixed by the following host kernel
-[patches](https://lkml.org/lkml/2020/1/30/482).
-
-The fix was integrated in the mainline kernel and in 4.19.103, 5.4.19, 5.5.3
-stable kernel releases. Please follow [kernel.org](https://www.kernel.org/) and
-once the fix is available in your stable release please update the host kernel.
-If you are not using a vanilla kernel, please check with Linux distro provider.
-
-#### [CVE-2022-1789](https://nvd.nist.gov/vuln/detail/CVE-2022-1789)
-
-##### Description
-
-With shadow paging enabled, the `INVPCID` instruction results in a call to
-`kvm_mmu_invpcid_gva`. If `INVPCID` is executed with `CR0.PG=0`, the invlpg
-callback is not set and the result is a NULL pointer dereference.
-
-##### Impact
-
-A malicious attacker running on the guest can cause a DoS (Denial of Service).
-
-##### Vulnerable systems
-
-The vulnerability affects systems that have shadow paging enabled and use
-the following host kernel versions:
-
-- 5.10.x prior to 5.10.119
-- 5.15.x prior to 5.15.44
-- 5.17.x prior to 5.17.12
-
-Systems that use extended page table are not susceptible to this attack.
-To verify that extended page table is enabled, run the following command:
-
-```bash
-cat /sys/module/kvm_intel/parameters/ept
-```
-
-If the output is `Y` then KVM uses extended page table, otherwise if `N`
-then KVM uses shadow pages.
-
-##### Mitigation
-
-The vulnerability is fixed by [this commit][4]. The fix was integrated in
-5.10.119, 5.15.44 and 5.17.12 kernel releases.
-
-#### [CVE-2022-26373](https://nvd.nist.gov/vuln/detail/CVE-2022-26373)
-
-##### Description
-
-Isolation boundaries between processes are vulnerable to a return stack
-buffer underflow. This may result in some processors allowing neighbouring
-guests to access data in other processes via local access.
-
-This issue is not impacted by environments that make use of `RETPOLINE` as
-this results in [RSB stuffing implemented by KVM][5] which Firecracker uses
-exclusively.
-
-##### Impact
-
-A malicious attacker running on a guest can access information in other guests
-running on the same host.
-
-##### Vulnerable systems
-
-The vulnerability affects systems that do not have `RETPOLINE` enabled
-and use the following host kernel versions:
-
-- 5.10.x prior to 5.10.135
-- 5.15.x prior to 5.15.57
-
-See earlier in this document for checking `RETPOLINE` configuration.
-You can check the version of the kernel being used with:
-
-```
-uname -r
-```
-
-##### Mitigation
-
-The vulnerability is fixed in [these releases][6] by the [commits merged upstream][7].
-
-#### [ARM only] Physical counter directly passed through to the guest
-
-On ARM, the physical counter (i.e `CNTPCT`) it is returning the
-[actual EL1 physical counter value of the host][1]. From the discussions before
-merging this change [upstream][2], this seems like a conscious design decision
-of the ARM code contributors, giving precedence to performance over the ability
-to trap and control this in the hypervisor.
-
 [1]: https://elixir.free-electrons.com/linux/v4.14.203/source/virt/kvm/arm/hyp/timer-sr.c#L63
 [2]: https://lists.cs.columbia.edu/pipermail/kvmarm/2017-January/023323.html
-[3]: https://elixir.bootlin.com/linux/v4.17/source/include/uapi/linux/prctl.h#L212
-[4]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=9f46c187e2e680ecd9de7983e4d081c3391acc76
-[5]: https://elixir.bootlin.com/linux/v5.10.131/source/arch/x86/kvm/vmx/vmenter.S#L78
-[6]: https://alas.aws.amazon.com/cve/html/CVE-2022-26373.html
-[7]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ce114c866860