January 3, 20188 yr AMD chips are not affected by the flaw. "Patches for Linux systems have been posted privately; although, some developers are said to be frustrated that the comments describing the fix for the open-source software have been redacted to prevent details of the bug from leaking." Full Article http://www.zdnet.com/article/tech-giants-scramble-to-fix-intel-processor-security-flaw/ Is there a patch for unRAID?
January 3, 20188 yr Not yet, my guess it will be incorporated into a RC once the changes required are merged upstream in the Linux kernel.
January 3, 20188 yr y my pc so slo!? Hold on, buying AMD stock. Depending on the reports you read, the slowness will be less noticeable on Desktop/gaming type functionality and more so on server-end stuff. Not sure how many memory calls unRaid base does, but seeing as most use docker/kvm and Hypervisors are said to be impacted the most by this issue it will be interesting to see what happens. I work in the IT field, so will be fun to follow this fallout. Edited January 3, 20188 yr by ninthwalker
January 3, 20188 yr Intel responds: Basically it says, "It's not just us, and the fix won't be as bad as others are saying." https://newsroom.intel.com/news/intel-responds-to-security-research-findings/ Edited January 3, 20188 yr by Hoopster
January 4, 20188 yr We are about to find out at work. I’d say whatever is done for the “meltdown” patching make sure the patch doesn’t include the AMD chips. Sounds like rumblings are that the current patch in the wild blankets all x86 CPUs. As I’m a Ryzen VM gamer with full gpu passthrough, if there’s a beta patch we can test I’d be happy to help. Haven’t heard word on KVM issues however ESX and Xen specifically have been called out by documentation I’ve read.
January 4, 20188 yr 5 minutes ago, markiii said: intel CEO sold a huge amount of stock last week, coincidence? Shhh no one was supposed to notice... motleyfool reported the sale as end of Nov to the minimum levels as a CEO.
January 5, 20188 yr Quick question regarding the release-schedule of unRaid: Will the fix once it's public a security update for 6.3.5 or only for the new 6.4 RC?
January 5, 20188 yr 12 minutes ago, Dr_Cox1911 said: Quick question regarding the release-schedule of unRaid: Will the fix once it's public a security update for 6.3.5 or only for the new 6.4 RC? Interesting point! my guess would be that it will only be done to the 6.4 release as the fix will almost certainly equire a kernel update which would need major regression testing to make it available with 6.3.5. Hopefully 6.4 is very close to final release so this does not become a significant factor. Of course the fix itself may delay 6.4 going Final if it has knock-off effects. In many ways this is likely not to be a significant issue for most unRAID users as it is only a very controlled set of binaries that are run on a typical unRAID system. i wonder if this issue affects VMs?
January 5, 20188 yr Hm, is the 6.4 already ready for a productive setup? unRaid is only used as my homeserver, but I don't really want to run an RC because stability is kinda necessary.
January 5, 20188 yr 20 minutes ago, Dr_Cox1911 said: Will the fix once it's public a security update for 6.3.5 or only for the new 6.4 RC? While I can't speak for LT I'm pretty sure v6.3.5 won't be patched.
January 5, 20188 yr From Ars Technica "Programs that don't use the kernel much might see a hit of perhaps 2-3 percent" but "a program that does virtually nothing other than call into the kernel saw its performance drop by about 50 percent" and "Benchmarks that use Linux's loopback networking also see a big hit, such as 17 percent". The issue being that "every time a program makes a call into the kernel —to read from disk, to send data to the network, to open a file, and so on" —it will force the translation lookaside buffer to be flushed, a ton of extra operations. I'm not feeling good about the impact to unRAID.
January 6, 20188 yr 2 hours ago, tdallen said: I'm not feeling good about the impact to unRAID. It likely will not be an option as I am sure LT does not want to maintain two versions, but, if the hit is too great, I would not mind an unpatched version of unRAID with lots of "user beware" warnings. Unfortunately, someone is bound to blame LT if, after installing the unpatched version when a fix is available, they get hit with the issues. Hopefully, the hit to unRAID won't be too great, but, it has the potential to be a "damned if we do, damned if we don't" situation. Should the worst case become reality, I am sure LT would not be alone in this boat and that's little consolation. Edited January 6, 20188 yr by Hoopster
January 6, 20188 yr Should be able to disable via kernel parameters at boot time if you really desire.
January 6, 20188 yr I don't know what I desire. We are all in "wait and see" mode until all the patches make their way into an unRAID release and we have some data concerning any performance impacts these patches may have on common unRAID operations.
January 8, 20188 yr Is this as much of a security risk on a home system that isn't directly connected to the net. Sure I can see the risk of you are on AWS and anyone can buy space on the SAME CPU as you and run code that can break through the VM layer and suck out info. But for my home server is this an issue?
January 9, 20188 yr 5 hours ago, wayner said: But for my home server is this an issue? Code does have to run on a box in order to exploit Meltdown. If all you do is run unRAID as a NAS from a trusted vendor like Limetech, you would be fine. But if you are running a ton of Dockers from random sources, not so much...
January 9, 20188 yr This is interesting... Hope it doesn’t end up being a standard case. SSD performance hit?
January 11, 20188 yr On 1/9/2018 at 1:21 AM, tdallen said: Code does have to run on a box in order to exploit Meltdown. If all you do is run unRAID as a NAS from a trusted vendor like Limetech, you would be fine. But if you are running a ton of Dockers from random sources, not so much... We have to be careful when we say things like this now. Unfortunately the days when this was really true are long gone, doubly so due to ransomware. Modern "Security in depth" practices call for essentially a "patch everything" policy because devices, people and WLAN are so ubiquitous now it is really just a matter of when, rather than if, a bad actor gains some foothold code in a "secure" private LAN. Terrible I know but thats the modern reality.
January 11, 20188 yr With unRAID it wasn't a realistic posture, anyway. Virtually everyone running unRAID 6 is also running a plugin or Docker of some sort.
January 13, 20188 yr Author Makes me wonder if data centers will look to do a tech refresh sooner than later to get these chips out of their production boxes and sell them for cheap on eBay! w00t!
January 13, 20188 yr 2 minutes ago, Joseph said: Makes me wonder if data centers will look to do a tech refresh sooner than later to get these chips out of their production boxes and sell them for cheap on eBay! w00t! The answer is "yes," but, there isn't anything to buy right now. No way am I comfortable enough yet with AMD's latest products to fill my data center with them. Unfortunately, we aren't allowed to sell anything after it has been decommissioned. Everything is physically destroyed.
January 13, 20188 yr 13 minutes ago, StevenD said: Unfortunately, we aren't allowed to sell anything after it has been decommissioned. Everything is physically destroyed. I can understand HDDs and such, but what's the logic behind destroying other kit?
January 13, 20188 yr 3 minutes ago, CHBMB said: I can understand HDDs and such, but what's the logic behind destroying other kit? "Security". I know, it's BS. That's just the way it is. It sucks because we have even destroyed HP Proliant Gen8s.
January 13, 20188 yr Just now, StevenD said: "Security". I know, it's BS. That's just the way it is. It sucks because we have even destroyed HP Proliant Gen8s. So, no logic then?
Archived
This topic is now archived and is closed to further replies.