Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Facebook Acquires Server-Focused Security Startup

samzenpus posted about a month ago | from the answering-the-acquisition-request dept.

Businesses 18

wiredmikey writes In a move to bolster the security of its massive global server network, Facebook announced on Thursday it was acquiring PrivateCore, a Palo Alto, California-based cybersecurity startup. PrivateCore describes that its vCage software transparently secures data in use with full memory encryption for any application, any data, anywhere on standard x86 servers. "I'm really excited that Facebook has entered into an agreement to acquire PrivateCore," Facebook security chief Joe Sullivan wrote in a post to his own Facebook page. "I believe that PrivateCore's technology and expertise will help support Facebook's mission to help make the world more open and connected, in a secure and trusted way," Sullivan said. "Over time, we plan to deploy PrivateCore's technology directly into the Facebook server stack."

cancel ×

18 comments

Sorry! There are no comments related to the filter you selected.

What this really means (0)

Anonymous Coward | about a month ago | (#47627843)

FB is going after AWS, thinks it can do better than JeffCloud.

Just use OpenBSD. It's the sensible option. (0, Insightful)

Anonymous Coward | about a month ago | (#47627861)

I see all sorts of people and companies spending a whole lot of time and money and personnel trying to improve the security of Linux or even Windows.

But security isn't the sort of thing you can just patch in or tack on! Security needs to start from the very core.

There's only one operating system around today that takes security that seriously: OpenBSD.

Security is the first and foremost thought of the OpenBSD developers. It is the centerpiece of all of their decisions. It isn't just an empty promise among many in a marketing checklist like it is for so many other operating systems. Security is OpenBSD's top priority.

OpenBSD is security. Security is OpenBSD. They have become one and the same.

So if you need to engage in secure computing (and everybody does, whether they realize it or not!), you really only have one choice, and that choice is OpenBSD.

Re: Just use OpenBSD. It's the sensible option. (0)

Anonymous Coward | about a month ago | (#47627895)

http://uncyclopedia.wikia.com/wiki/BSD_is_Dying
helloooo

Re:Just use OpenBSD. It's the sensible option. (4, Insightful)

manu0601 (2221348) | about a month ago | (#47628023)

OpenBSD is security. Security is OpenBSD

If you think that choosing OpenBSD will magically produce secure setups, you are doomed.

While I acknowledge valuable security-related work in OpenBSD, a moto such as "Only two remote holes in the default install, in a heck of a long time!" is harmful PR speak. Who use an OS as in the default install, without touching any settings? Just configuring the network push you out of default install (and you win two more remotely-exploitable holes in DNS resolvers).

And we could also speak about the numerous "reliability fixes" that are often really security fixes you should install to remain secure.

Cheney/Bush in 2016 (-1)

Anonymous Coward | about a month ago | (#47627889)

Say YEAH!
(YEAH!)
Say YEAH!
(YEAH!)

Hillary/Palin in 2016 (-1)

Anonymous Coward | about a month ago | (#47627911)

Say YEAH!
(YEAH!)
Say YEAH!
(YEAH!)
Say YEAH!
(YEAH!)

Re:Hillary/Palin in 2016 (-1)

Anonymous Coward | about a month ago | (#47628031)

Will they eat each other out during debates?

Cannot spell 'hypervisor' without 'hype' (1)

roman_mir (125474) | about a month ago | (#47627907)

You can't spell 'hypervisor' without 'hype'. Before I even clicked on TFS link (sorry, /.) I knew I was going to see that this has something to do with VMWare and lo and behold:

PrivateCore was founded in 2011 by security industry veterans from the IDF, VMware and Google. In June 2014, the company raised $2.25 million in seed funding from Foundation Capital.

so you can encrypt your virtual machine... Ok, great, an extra level of encryption, but doesn't it still have to decrypt whatever it is trying to run on the processor, eventually an unencrypted instruction has to be read and executed, or do they now allow encrypted instructions to run within a virtual machine player? I don't think so. This is not about security, this is about Facebook getting into the VMWare hype. More acquisition for the sake of acquisition, to keep FB in the news, to try and boost the stock higher.

Re:Cannot spell 'hypervisor' without 'hype' (1)

Lennie (16154) | about a month ago | (#47628795)

But the funny thing is, Facebook doesn't run on virtual machines.

So I wonder what their plans are.

ARRRRRR! (1)

ArcadeNut (85398) | about a month ago | (#47627915)

I keep reading that as "Pirate Cove"...

Re:ARRRRRR! (0)

Anonymous Coward | about a month ago | (#47627997)

Cool story, brah.

Keys (1)

manu0601 (2221348) | about a month ago | (#47628029)

They encrypt inside memory, but with what keys? How easily accessible are they?

The usual tradeoff here is choosing between something that can reboot unattended, but with private key easily accessible, or something that need a password to be entered on restart to decipher the private key

Re:Keys (3, Interesting)

slincolne (1111555) | about a month ago | (#47628059)

The FAQ posted on their web site makes mention to the Intel TPM chip.

Pointless, 3rd party. (1)

Dan Askme (2895283) | about a month ago | (#47628229)

I believe that PrivateCore's technology and expertise will help support Facebook's mission to help make the world more open and connected, in a secure and trusted way," Sullivan said.

Pointless, unless you sell user information to third party company's that only this service.
Or is that the end goal here, make third party company's pay £££ to use PrivateCore?

Regardless, once that data is in the hands of "Marketing Company X", kind of defeats the security it had in the 1st place.

Oh and, noone is truly "connected" on facebook. Its just a phase in our current generation to feel "important", which Facebook is profiting from.

PrivateCore's product - likely the employees (4, Interesting)

Menacer (222952) | about a month ago | (#47628327)

The goal of PrivateCore's product was to encrypt everything that's outside of the CPU core using software techniques. So once you've done an attested boot and gotten your crypto keys in order, from that point on anything outside the CPU socket is done in an encrypted manner (except I/O to the network I guess, but definitely hard disk and data going to the DRAM, etc.) Their important selling point here was that you could protect against cold boot attacks, DMA data dumps, data sniffers on the DRAM lines, etc [stanford.edu] . They also claim to have a secure hypervisor (preventing cross-VM thievery) because they've stripped it down to its bare bones, but I believe this ended up being a secondary concern.

Anyway, their goal was to have unencrypted data in the caches [stanford.edu] , but encrypt the data before it leaves the chips and goes out to DRAM. Their page is mostly high-level marketing fluff, so if they were claiming to do more than this, I missed it. The hardware for encrypted DRAM accesses exists in specialized platforms (e.g. the XBox 360) but doesn't currently exist in commodity x86 server parts. As such, a friend and I sat down for an evening a while ago and tried to work out how they would do this without a DRAM controller that did the encryption for you.

Again, their goal is to have decrypted data in the caches, encrypted data in the DRAM. The crypto routines would have to be contained in software. The major difficulty is that the cache does whatever the cache wants, so it's really rather difficult to say "when this data is leaving the cache, call the software crypto routines." There is no good way for the hardware to tell you it's kicking data out of the cache. (There are academic proposals for this kind of information, but nothing currently exists.)

We thought up of a number of solutions and were able to validate our guesses against their patent submission [google.com] . I will gloss over some of the deeper details (such as methods for reverse engineering the cache's replacement policy).

The shortened version is:
1) Work on Intel cores that have >=30 MB of L3
2) Run a tiny hypervisor that fits into some small amount of memory (let's say 10MB)
3) Mark all data in the system that is not the hypervisor code pages are non-cacheable
4) The hypervisor also has the crypto routines, so all of these non-cacheable pages can now be software encrypted using the hypervisor's routines. The DRAM-resident data is now encrypted.
4a) Because these were marked as non-cacheable data, the hypervisor is still resident in the cache (it was never displaced).
5) Mark some remaining amount of space (let's say 20MB) of physical memory as cacheable. This physical memory currently contains no data at all.
6) When you want to run a program or an OS, have the hypervisor move that program's starting code into the 20-meg-range (decrypt it along the way) and set its virtual pages to point to that physical memory range
7) The program can now run because (at least some of its pages) are decrypted. They are also cacheable, so it will hit in the cache
8) When you try to access code or data that is still encrypted, it will cause a page fault
9) The hypervisor's page fault handler will get that encrypted data, decrypt it, and put it somewhere in the 20-meg-range
9a) If the 20 meg page is already full of decrypted data, you will have to re-encrypt some of it and spill it back to DRAM (like paging it out to disk).

Because you are only touching ~30 megs of physical memory that is marked as cacheable, you will "never" spill decrypted data to the DRAM. Essentially, they built a system that has 30 megs of main memory (that 30 megs is SRAM in the core), and DRAM is treated like disk/swap in a demand-paging system.

The reason I am convinced this is likely an acquisition-hire, rather than a hire for a particular product is: this will be unbearably slow on anything but tiny cache-resident applications. Now, not only are cache misses page faults, but they also require moving data around and running through software crypto routines. They claim good performance, but I can't imagine anything but 100x or more slowdowns when dealing with server applications that have large working sets. Faults to supervisor/hypervisor mode are not cheap. Perhaps for CPU-bound benchmark applications you will see little slowdown, but I've seen no solid evidence that their performance is any good. Looking at the way they do this memory encryption, the evidence strongly points towards huge overheads when e.g. walking linked lists or dealing with disparate data. Imagine taking a page fault (and encrypting 4KB of data and then decrypting a different 4KB of data) on every memory access because you're jumping around a 40MB hash table.

Beyond the likely performance problems, they also cannot offer complete guarantees that data in the caches won't spill to DRAM by accident. I can think of a number of possible ways to trick a cache into spilling its data, and I don't believe that any processor manufacturer guarantees that cached data will remain resident. If your security stance is "well, a cache eviction probably won't happen due to reasons outside my control," I don't think you will be very safe against a particularly dedicated hacker. Mind you, this would only leak up to 30MB of user data at a time, but that's still a crack in the dam. Why would you page a huge performance overhead for no actual security guarantee?

Their solution to this problem (in the patent application, anyway) was to periodically scan the cacheable physical memory range and scrub it of unencrypted data.

In summary: I don't believe that Facebook will be implementing this technique in their servers. If they really wanted encrypted DRAM, they would pay Intel or AMD to build a semi-custom processor [wired.com] with encryption techniques built into the DRAM controllers. They bought this company because they want to hire these guys who have a lot of kernel and hypervisor knowledge.

Acquisition-hire: more proof (2)

DrYak (748999) | about a month ago | (#47628691)

In summary: I don't believe that Facebook will be implementing this technique in their servers. If they really wanted encrypted DRAM, they would pay Intel or AMD to build a semi-custom processor [wired.com] with encryption techniques built into the DRAM controllers. They bought this company because they want to hire these guys who have a lot of kernel and hypervisor knowledge.

More proof to your hypothesis:Facebook is currently hiring kernel hackers [phoronix.com] . With a humorous "we gotta beat FreeBSD!" target, but still. BSD-jokes aside, it's another proof that they are interested in increasing kernel performance and thus people with very good low-level knowledge would be welcome, no matter these people's current product has very few practical application.

Re:Acquisition-hire: more proof (1)

Lennie (16154) | about a month ago | (#47628813)

An other reason, as I mentioned above.

Facebook runs it's whole infrastructure on bare-metal with containers.

There are no hypervisors in use for most, if any, workload in their datacenter.

Some smart cards had this in HW ten years ago (0)

Anonymous Coward | about a month ago | (#47628775)

Infineon's SLE88 had its RAM, EEPROM and ROM encrypted (with checksum) with unencrypted cache at the beginning of the 2000s.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>