Intel Responds to Security Research Findings • Hacker News Board

Re: Intel Responds to Security Research Findings

#241

Post by SAI_Peregrinus » Thu, Jan 04, 2018, 6:41 PM UTC

haberman wrote: post #177

redcalx wrote: post #164

Earlier quoted context omitted.

It's kind of semantics though isn't it? If I write a piece of software that follows the spec and fulfils the customer's need, but then someone tries to do something with it that we hadn't thought of and that results in a security hole... around here we call that a bug, a flaw, something we missed. Maybe it's reasonable to have not spotted the bug, but that wouldn't make it not a bug/flaw.

Yeah I agree there is a line there somewhere. If someone sells you a safe and it can be opened with a ballpoint pen, that seems like a flaw. If someone sells you a safe and it can be opened with a military grade laser, that's sort of expected. If someone sells you a safe and it can be opened with a cheap consumer gadget, but that gadget is complex and was unforeseen when the safe was designed, what do you say about t…

I'd agree. The implementation conforms to the specification, so it's not a bug. The specification is flawed.

Re: Intel Responds to Security Research Findings

#242

Post by deadshift » Thu, Jan 04, 2018, 8:55 PM UTC

teilo wrote: post #96

thezilch wrote: post #69

Earlier quoted context omitted.

Devils advocate. Workload dependence... average user... not significant: A lot of users probably see "30%" and will assume the worst. There really isn't a lot of evidence of how much an average consumer will be affected. Pretty sure your average consumer isn't running pgbench all day. Hell, I'm willing to bargain 90% of servers (I really want to say more) are over-provisioned by 30% or more. Mitigated over time: Kern…

The problem is that "average users" pointedly does not include server and DB admins. I don't know about anyone else, but that's what I'm sweating over. We already know high I/O is what takes the biggest hit. I want to know what kind of a hit I can expect on our MSSQL VMs, and I am pretty sure the answer is not "minimal."

If you're running SQL in a VM ... I'm pretty sure I know how to improve your performance by 30%.

Re: Intel Responds to Security Research Findings

#243

Post by teilo » Fri, Jan 05, 2018, 4:40 PM UTC

deadshift wrote: post #242

teilo wrote: post #96

Earlier quoted context omitted.

The problem is that "average users" pointedly does not include server and DB admins. I don't know about anyone else, but that's what I'm sweating over. We already know high I/O is what takes the biggest hit. I want to know what kind of a hit I can expect on our MSSQL VMs, and I am pretty sure the answer is not "minimal."

If you're running SQL in a VM ... I'm pretty sure I know how to improve your performance by 30%.

If you mean run on bare metal, not happening, due to MSFT's outrageous core pricing model. They force you to license every core available to the OS, whether you need the capacity or not. Running in a VM is the only way of getting around that requirement.

If you mean run something other than MSSQL — also not happening. Vendor lock in.

Re: Intel Responds to Security Research Findings

#244

Post by PeterisP » Fri, Jan 05, 2018, 5:04 PM UTC

int0x80 wrote: post #121

vhold wrote: post #82

Earlier quoted context omitted.

Somebody please correct me if I'm wrong, but I believe they're basically saying "These exploits do have the potential to read data."

There are not saying it explicitly, which they should.

They are - literally the sentence before that states "methods that, when used for malicious purposes, have the potential to improperly gather sensitive data from computing devices that are operating as designed".

Re: Intel Responds to Security Research Findings

#245

Post by path411 » Fri, Jan 05, 2018, 5:48 PM UTC

Danihan wrote: post #219

bjornedstrom wrote: post #73

This is probably one of the poorest and most defensive PR pieces I've read from a company in a long time, and it does not really make me sympathetic to them at all. > Intel and other technology companies have been made aware of new security research describing software analysis methods that, when used for malicious purposes, have the potential to improperly gather sensitive data from computing devices that are operat…

> Intel believes these exploits do not have the potential to corrupt, modify or delete data. Unless you view a key or password... then use it to corrupt, modify or delete data.

Bugs don't cause security leaks, it's the hackers that do! Software security is really just a social problem.