pfSense Gold Subscription

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - VAMike

Pages: [1] 2 3 4 5 ... 28
1
At this point I'm still waiting on patches for my Supermicro A1SRi-2758F (Intel® Atom™ Processor C2758) though I don't know if Atom processors are affected.
That generation of Atom is. The earlier/ridiculously slow ones are unaffected.

2
General Questions / Re: Intel CPUs Massive Security Flaw issue
« on: January 11, 2018, 12:22:25 pm »
The problem is you think things will be patched and fairly usable and secure.

We disagree on this point.  I think it is a basic flaw that will never be adequately patched.
No, you will never eliminate all side channel attacks in commodity hardware with commodity OSs. Nobody would buy a commodity OS on commodity hardware subject to the performance and functionality limitations that would entail. Again, there has been research on this topic literally for decades. The question is whether the systems are resistant to anticipated attacks. (That is always the bar to acceptance, nothing new or specific to this topic.) The only thing that happened in the past year is that some specific techniques for exploiting specific instances from a class of vulnerabilities were identified. Some countermeasures for those specific techniques have been deployed. The cat and mouse game continues, as it has since cats and mice were invented. What you seem to be conflating is whether the general class of problem has been fixed (no, that's impossible with the current technology) and whether the specific techniques have been mitigated against (yes, they have). There is the caveat that a lot of 3rd party code will need a lot of fixes, and there may be bugs in some of the code already released--but there is always the possibility of bugs.

Quote
Perhaps not going broke levels of cash but I wouldn't expect profits til the next slew of hardware is released and tested to be 100% immune.

We will know one way or another pretty soon whether people just accept this or if they start looking elsewhere for hardware.

If Intel is smart they have rooms filled with overpaid geniuses designing new hardware this very second working 24/7....  Because someone does.
I definitely won't buy the "We are the only game in town so you have to accept it" line.  If they try that nonsense, they will end up extinct.
There will not be any major differences in the next generation of hardware. It would require a major paradigm shift which is simply not on the horizon. There are no other hardware vendors, as every modern CPU design is subject to the same class of vulnerabilities. (Not just Intel and AMD, but also ARM, POWER, etc.) It's fundamental to the way modern CPUs work, and you can either accept the performance penalty of not utilizing modern functionality or you can come up with a radical new way to achieve equivalent performance. (That is, without caches or speculative execution or instruction pipelines or NUMA, etc.) That isn't the sort of thing that just happens because someone on the internet wants it to. Generally that kind of radical change is presaged by laboratory results that are eventually refined into something commercially viable, or by incremental changes to existing products. You don't go directly from an 8080 to a Kaby Lake with nothing in between--and there isn't any sign of that kind change making its way through the pipeline.

No offense, but it doesn't seem as though you have any particular expertise in this area--which seems pretty common for the most inflammatory rhetoric on the topic. If you want to be more specific than "I think it is a basic flaw" that can't be "fairly usable and secure", then we could try to talk at a more detailed level about what the implications of each of the three variants are. Lumping the whole mess together into a vague pile of FUD doesn't offer much insight.

3
General Questions / Re: Intel CPUs Massive Security Flaw issue
« on: January 11, 2018, 12:00:21 pm »
Put in other terms, if a computer was a car we would be dealing with a massive recall.
A proper car analogy would be:
1) someone sells a car with remote keyless entry. the key isn't super-secure, but it's good enough given what's practical to implement.
2) some time later, someone comes up with a way to override the keyless entry using what's now a fairly cheap and readily available device.
3) the car manufacturer shrugs.

A proper house analogy would be:
1) someone sells a remote garage door opener. the opener isn't super-secure, but it's good enough given what's practical to implement.
2) some time later, someone comes up with a way to override the garage door opener using what's now a fairly cheap and readily available device.
3) the garage door opener manufacturer shrugs.

Those are both actual examples. In no case was there a massive recall. I don't fully understand the level of irrational hysteria around the possibility that almost every general purpose CPU in existence might be replaced in some sort of ridiculously unlikely recall.

4
General Questions / Re: Intel CPUs Massive Security Flaw issue
« on: January 11, 2018, 11:53:44 am »
Quote
This time is a whole lot different: the hardware mis-design causes a security hole, and this cannot be fixed, because it's hardware...

I guess you've never heard of microcode.  It's the software within the CPU that enables it to understand the instruction set.  Back when I used to maintain DEC VAX 11/780 computers, there were occasional microcode updates.  Modern CPUs also use microcode and a recent Linux update for this problem included some microcode.
Again, there are multiple different issues being lumped together. The meltdown/variant3 issue can't be fixed in microcode because it's an MMU problem, and the microcode patching function can only affect instruction processing. That vulnerability is addressed by adding additional code to the kernel. The intel microcode updates are mostly aimed at spectre/variant2, which can largely be addressed in software--but the software changes can also take advantage of new CPU functionality to improve protections.

5
General Questions / Re: Intel CPUs Massive Security Flaw issue
« on: January 11, 2018, 11:23:52 am »
Limiting access to high resolution timers is what google chrome and firefox have done.  Also strictly segmenting memory between pages.  The patch sucks to high heaven performance wise and still is vunerable. 

Good enough security?  Hmmmm.   I don't think we will have that before a processor redesign.  I mean I'm not selling my laptop or anything but I'm well aware that I need to change how I use my machines.  I'm going to have to cut way back on the number of sketchy porn sites I visit.

I think they should be presenting the patches for what they are.  An attempt to reduce the risk.  However they consistently use language that leads people to believe the patches fix things.  Last time I saw writing that misleading was when cigarette companies tried to convince everyone that smoking was perfectly harmless.

However, because of the way pfsense is used and the fact that it isn't a web browsing machine, I worry about pfsense way less than my computers that have desktops and keyboards.
No, google has also implemented per-site process segmentation as a chrome option. That makes inter-site security subject to hardware-enforced page table permissions. The hard problem is restricting memory access from a virtual machine running in the same address space as sensitive data. There are various approaches for addressing this ranging from changing the isolation model (as google did in chrome, sidestepping the problem) to adding various kinds of barriers to the userspace code (including by adding new CPU instructions). What we're talking about here is "spectre variant 1". The "meltdown variant 3" part of the announcement was basically that the guarantees provided by the page table permissions weren't being properly enforced, but that issue has been addressed. Way too many people are confused because there are multiple different vulnerabilities with a different number of different cutesy names, and those different things are being lumped together in various incorrect ways.

The "spectre variant 1" problem is the hardest and can't be magically fixed with a single patch, because there's nothing in the current design of that software to indicate to the kernel or to the hardware what code is untrusted and should be restricted from accessing memory within the process. That's why people say the problem isn't "fixed"--it can't be, until every software vendor addresses it in their own code. It isn't a fault in the hardware the way the crazies want to believe (e.g., a full replacement of basically every CPU in operation) because there was never a guarantee that code in a particular address space couldn't perform a side channel attack against data in the same address space. This basic class of attack has been known for more than 40 years, but it simply wasn't something anyone tried to address in commodity hardware & software. (Hence my comment that if we were waiting for perfect you would have had to just not use a computer for the past 40 years--which is a silly position to take, because good enough has been good enough for decades.)

6
Hardware / Re: APU2 BIOS
« on: January 11, 2018, 10:39:03 am »
I've been having some issues with my APU2 routers
How excitingly secretive!

7
Hardware / Re: How do I use AES-NI and hardware acceleration
« on: January 11, 2018, 10:38:21 am »
how do I set it up so it uses hardware acceleration on Pfsense 2.4.2
You leave it alone. It wouldn't be going that fast if you'd actually managed to turn off hardware acceleration.

8
General Questions / Re: Intel CPUs Massive Security Flaw issue
« on: January 10, 2018, 09:12:03 pm »
Mikeisrespectful...   Yeah.  32 bit got hit too.

The thing I find interesting is that researchers with nothing to gain or lose say this can't be truly fixed.

Meanwhile people who stand to lose billions upon billions are saying "We can fix it with patches".
researchers with nothing to lose have no reason to distinguish between "perfect" and "good enough". for most people "good enough" is sufficient, or else we'd all be twiddling our thumbs waiting for a "perfect" system to appear.

9
General Questions / Re: Intel CPUs Massive Security Flaw issue
« on: January 04, 2018, 11:37:14 am »
AMD CPUs are impacted by this just as much as Intel CPUs.

Not true

No, completely true. First, you trimmed off one heck of a lot of context that's really important:

Quote
It's also worth pointing out that this isn't a kernel-specific issue, and that side channel attacks can impact any program that tries to isolate untrusted code. (For example, a browser running javascript.) The kernel mitigations don't fix all of those other programs--and AMD CPUs are impacted by this just as much as Intel CPUs.

What a lot of fanboys seem to be missing in their urgency to have an intel bonfire is that this is about a class of vulnerabilities, not a specific vulnerability. AMD processors seem at this point to not be vulnerable to one particular mode of attack, but are vulnerable to other modes of attack. And I guarantee that this area of research will get a lot more attention, and there will be other exploit vectors discovered. Side channel attacks have simply not been something that commodity CPU vendors have worried about, so to some degree finding them is like shooting fish in a barrel. (This is true of all the vendors, not just intel.) "Meltdown" is getting most of the press (that which isn't completely confused about the various attack vectors) and is the biggest PITA for shared infrastructure providers, but "Spectre" is actually much harder to fix, and just as relevant to actual users who do things like browse the web. The most straightforward fixes involve giving up any hope of sandboxing potentially malicious code within a process and relying on process isolation instead--which will have a performance impact on everyone's web browsing.

And as long as we're talking about AMD, they really botched up the disclosure timeline by publicly asserting that they weren't vulnerable to certain kinds of cache timing attacks in the context of the linux kpti patches...people are going to think twice before trusting AMD to keep their mouths shut in the future.

10
OpenVPN / Re: Extremely Low Download Speed (0.5mbps?!) ExpressVPN (LOGS!)
« on: January 04, 2018, 08:56:09 am »
Not sure how anyone actually thought that these commodity VPN providers had a sustainable business model as traffic/subscribership increased.

i understand what you are saying but they advertise only 30% decrease in speeds from your ISP.
I, for one, have never seen misleading advertising or inflated claims!

The bottom line is that no VPN can avoid adding latency. Depending on what you're doing that may be a small impact or a huge impact. But, given the billions of dollars of R&D that have poured into reducing latency over the internet, it's got to have some noticeable effect. You may be willing to make that tradeoff, but be aware there is a tradeoff.

11
Hardware / Re: Intel CPU Vulnerability
« on: January 03, 2018, 11:07:05 pm »
Looking at this article:
https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
That article was really badly titled.

Quote
I manage a couple of Not-for-profits, and wanted to allow the new Arm architecture some more time to mature before steering them in that direction.

That's good, since the newer ARM CPUs have the same sort of speculative execution problems as intel CPUs...

12
General Questions / Re: Intel CPUs Massive Security Flaw issue
« on: January 03, 2018, 10:57:28 pm »
From my understanding of the problem all x86 processors are effected but the AMD processors have the ability to turn off the branch prediction feature. It would seem to me that if some bioses can be updated to turn this feature off on Intel Processors than the problem can be minimized without the 5% performance hit. We all want speed and putting the Kernel page file and user page file in the same space was a way for them to achieve this. I don't really think it's fair to blame Intel. Security is really hard and I would say the problem is really at the OS level. OS makers are working on the fix now so I would say everyone is doing their job. I would imagine in the future Intel processors will have the ability to turn the branch prediction off which will fix this issue.
Turning off branch prediction would be a much more significant performance hit. The impact of KPTI is felt on code with a lot of system calls, and has close to zero impact on code that stays in user land. Killing branch prediction would impact everything.

It's also worth pointing out that this isn't a kernel-specific issue, and that side channel attacks can impact any program that tries to isolate untrusted code. (For example, a browser running javascript.) The kernel mitigations don't fix all of those other programs--and AMD CPUs are impacted by this just as much as Intel CPUs.

13
Hardware / Re: Memory for Supermicro A1SRi-2558 build
« on: December 14, 2017, 12:22:37 pm »
you're looking for the wrong thing. it's 204 pin ecc so-dimm unbuffered (the opposite of registered)

14
Hardware / Re: pfSense 2.4.1 and Intel Atom 3858 - 3958
« on: December 13, 2017, 07:18:02 am »

It's still young and not super much tested. Once pfSense does an update for the FreeBSD underpinnings it will work, but it still wouldn't recommend it, unless you like being a guinea pig. You'll probably want to wait at least 2 more months before building something with Denverton.

You got a point - I just cant seem to find any other setup with both quick-assist and AES-NI. I am looking for a setup to handle 2500 clients and 1gigabit WAN that also cable of doing 500mb/s of VPN/SSL
Why have you decided you need quickassist? pfsense doesn't even use it.

15
Hardware / Re: Is this setup going to work without any errors?
« on: December 07, 2017, 12:36:34 pm »
My experience with design temperatures....

CPUs with design temperatures of 100c start throttling at 70c.

People can say they do not, but I've never had a chip with a t-junction of 100c make it beyond 80c before my computer turned into a snail.
well, since I haven't seen an APU2 get that hot I'm not sure it's relevant. they tend to run hotter than a regular desktop at idle, but they don't get all that much hotter under load. (assuming the heatsink isn't installed wrong.)

Pages: [1] 2 3 4 5 ... 28