The SMAP-enhanced UDREF fixed Meltdown in v4.14.13 and the performance is better than KPTI, while it also provide more security features… PaX’s UDEREF implemented the per-cpu pgd back in 2013, which make it easy to implement the full kernel page isolation. SMAP-enhanced PaX’s UDEREF made the performance improvement since PaX/Grsecurity v4.12. V3a( CVE-2018-3640 – Rogue System Register Read (RSRE) V3 Meltdown( rogue data cache load (CVE-2017-5754)) More info about v3a and v4, check Google project zero’s bug tracker and INTEL-SA-00115. Google project zero’s write-up explains how the vulnerablities( meltdown, spectre v1/v2) work. If your company is in the cloud, it could cost you 5-30% more (Although, that isn’t 100% true because most companies don’t run their systems at capacity.)īecause of this, I challenge the tech world to accept the fact that knowing how to test a system really comes from understanding a system-and therefore understanding what could go wrong.Nightmares( Meltdown/Spectre/L1TF) never goes awayīy Shawn C Meltdown/Spectre The attack vector has been known for awhile so this isn’t some unknown type of bug.Īs we start out 2018 a little slower, since the fix will have to occur in software, in the operating systems, will slow computers down by 5-30%. Otherwise, folks like Linus, Microsoft and Google would have found the bugs years ago given they have people specifically looking for issues like this. To find these types of bugs, you have to really know how the system works and actively test for a very specific issue. As the world scrambles to fix an Intel issue that has been around as long as modern day computer chips, you have to wonder what other flaws are out there. My point, though? If you’re working on these bugs, it’s a pretty strong indication that you are (or should be) an expert in how the system works. Linus, the inventor of Linux, has become heavily involved with this topic of conversation- very publically too, might I add. What type of testing would have caught the recent critical errors like Meltdown and Spectre? What type of skills would be necessary? What type of knowledge would of been required? In light of that, here is a thought experiment. Others don’t include their quality assurance (QA) teams in architecture and development meetings, so by design the QA really doesn’t understand how the systems work. Some companies only do black box testing as a matter of principal. I’ve been lucky enough to work with great developers over the years and this sequence isn’t usually an issue for them. It’s better suited for the simple stuff: Putting some predetermined value into the system and expecting some value to come back out is fairly painless. (That’s a method that examines a system’s functionality without looking at its internal workings.) But I’ve never believed that it’s a great way to catch the really critical types of errors. It isn’t that I’m against black box testing. But instead of recapping what went wrong, I want to discuss a fresh idea as to how companies can better test systems to avoid any of this from happening in the first place. If you’re like me, you’re trying to keep up with the news surrounding the Meltdown and Spectre security flaws.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |