In case you have not been watching the IT news over the past couple of months, this Intel thing just goes on and on. As was coverded Wired Magazine, it has been a total train wreck.
What we have done so far is to follow RedHat, When they released their original fix, we followed suite. They subsequently withdrew their patch as it was causing issues with stability. If you had crashes and reboots during that timeframe, my apologies. Now, it seems, Intel is ready to push some new firmware. This will only benefit the security of recent processors...what a joke.
In the meantime, keep your systems buttoned up. And cross your fingers or whatever else you can do to give yourself peace over this situation that is largely, still unresolved.
As this affects kernel space, you will likely need to reboot after this patch in order to determine whether it affects your system positively or negatively. Feel free to post your experiences. Especially if you are using virtualization on ClearOS.
Our team estimates that it will take a few days to bring this app up to snuff. Microsoft added some new features which greatly eases the deployment of this and they have to retool a bunch of steps to make this more stable in the long term.
You can read about that here:
Until then, I've asked the Marketplace engineering team to temporarily withdraw the app from being listed.
In one of our meetings yesterday we talked about the kernel move and decided to focus on working on this innovation for ClearOS 8.x. Logistically there is no problem with introducing this on new installs but on existing installs there could be issues moving someone in this manner if they are using drivers compiled under the older ABI.
I agree with Nick here, hardware RAID in this situation might not be the best solution.
If you still want to use this card, know that it isn't certified for ClearOS so as developers, we have no way to test or debug it. That card is supposed to have support in Linux but I see that it can have funky problems with issues related to IOMMU. And there are some issues with IOMMU on MicroServer as noted here. On the preload, we address some of those issues but you may have to play with the IOMMU. The behavior of this device during the certification process was that even when it is off in the BIOS, some elements are visible to the ClearOS kernel and it tries to load the software stack to support it. This results in a warning in the dmesg output. But it is possible that the load of the IOMMU is causing the bad behaviour in the card. Not a good sign though for the Marvel. IOMMU acts as a soft stack for PCI Interrupts in virtualization to improve performance. If this card cannot have IOMMU in the kernel running then it means that you will likely not get optimal performance if you try to use your MicroServer for virtualization.
HPE has a RAID card that is certified in ClearOS for the HPE MicroServer and it works splendidly.
Thanks Chris for taking the time to improve ClearOS and to share your work!!!
One thing that many browsers require with modern certificate providers is the intermediate certificate chain. For example, Comodo's certificates really need the intermediate chain for it to register without complaint in mode browsers. So you can/should add this line as well:
You can put it right next to your other lines you suggest:
I've asked the release manager a similar question. Right now it is in the hands of the community and we are validating any problems that may have occurred with the dissemination of the package. It should be promoted soon. Like you, I am eager for the package in the verified repos. I have several projects that require them before I can push, for example, a new Q1 ISO for Home, Business, and Community that includes the newer kernel and rolled up packages for 2018.
For more detail on these vulnerabilities, please consult the following from Redhat:
CVE-2017-5753 (variant #1/Spectre) is a Bounds-checking exploit during branching. This issue is fixed with a kernel patch. Variant #1 protection is always enabled; it is not possible to disable the patches. Red Hat’s performance testing for variant #1 did not show any measurable impact.Source: Redhat
CVE-2017-5715 (variant #2/Spectre) is an indirect branching poisoning attack that can lead to data leakage. This attack allows for a virtualized guest to read memory from the host system. This issue is corrected with microcode, along with kernel and virtualization updates to both guest and host virtualization software. This vulnerability requires both updated microcode and kernel patches. Variant #2 behavior is controlled by the ibrs and ibpb tunables (noibrs/ibrs_enabled and noibpb/ibpb_enabled), which work in conjunction with the microcode.
CVE-2017-5754 (variant #3/Meltdown) is an exploit that uses speculative cache loading to allow a local attacker to be able to read the contents of memory. This issue is corrected with kernel patches. Variant #3 behavior is controlled by the pti tunable (nopti/pti_enabled).