Microsoft reveals why no Surface device has Thunderbolt and why you can’t upgrade your RAM

[corsairian]

If I can solder on some ram chips to double the ram in my  original Xbox...(Has the pads there already)

 

I wonder if that can be done here. Soldering on more or higher density ram. As long as you can find the ram, I dont see why it isnt doable. Iirc there are guys that have replaced all the memory chips on a GPU to go to Samsung from another manufacturer or something like that. 

[straight_stewie]

3 hours ago, Twilight said:

still it's been around for SO LONG, why isn't it secure yet?

You are misunderstanding how DMA works.

Direct Memory Access works so well specifically because it's designed to go around the OS, meaning that peripheral devices, like hard drives and graphics processors, can access RAM without all of the data having to go through the processor. This is why, for example, your web browser doesn't come to a grinding halt when you are copying a file from one folder to another, and why transferring data to a graphics card is fairly efficient. We couldn't have modern games without DMA.

If you were to design an implementation of DMA that required all of the data to be processed by the processor, it wouldn't be DMA anymore, and it would make your computer ALOT slower, as in "comes to a grinding halt when doing basic things" slower.

[GoodBytes]

So, security of the Surface Pro, has pushed by Microsoft since the first model. It was one of the early systems with TPM chips. It wasn't common back then to have that chip (well, still isn't on the consumer space, but is commonly found on the business models of systems today)

 

If it where my guess, is that they evaluated TB3. Now, TB3 has a cost to implement. A high cost. I mean you need to implement everything needed for firmware update, you need to find room on the PCB to add it, hopefully it doesn't require an entire redesign, support, licensing costs to Intel (at the time), chip cost from Intel, QA, and of course time.

 

Then they looked at the security impact it has, and they probably decided: Is it worth implement this or not. And the answer is, well as we can see, no. And the reality is that, yea, it makes no sense. Let's be honest here:

• The CPU sucks for gaming to start with. It is not only a U series chip, but has aggressive power saving profile applied to it to reduce its power consumption while not throttling per se, but Turbo Boost is clearly limited. The profile of the device and the fact that it has no fans (after the Pro 3) beside the i7 model (which cost a fortune) is a clear indicator of the requirement they need to set. And Intel chip didn't get much power efficient to actually not need a fan. 
• External GPUs is still today expensive. The enclosure still very expensive, and TB3 is a bottleneck for premium cards which justifies better the cost of the enclosure.
• Not popular.

So, what is the point of TB3? The only one really complaining are mostly YouTuber's.

 

Now, if enclosures where much cheaper (ex: $50 at most) and TB4 becomes a thing (which doesn't look like, it looks Intel doesn't care anymore about it, probably because of the low popularity of it), then maybe Microsoft might consider the security trade off (or at least have it disabled in the UEFI (and promote UEFI password lock), or have a different SKU without it, like have it only the i7 model which has a fan and can see a use case for gaming and productivity tasks, or invest in R&D to implement a security chip of sorts so solve the security problems if TB4 doesn't have a fix for it.

 

Now this leak presentation segment.. well.. we nothing about the target audience. It is clear that it is a Microsoft Teams or whatever recording. Sounds to me a presentation aimed at new Surface team recruits to put them up to speed on the Surface Pro, probably some manager or someone just doing a quick overview (as there is no actual details on anything). Or, some sort of Lunch & Learn presentation offered company wide with no target audience in mind (assumes that they are no engineers. Again, I say this, because every statement said in the video clips, are very broad. Doesn't actually talk about any details).

 

[kelvinhall05]

7 minutes ago, GoodBytes said:

So, what is the point of TB3? The only one really complaining are mostly YouTuber's.

bu bu bu my EXTENAL GPPU ENKLOSURE!!!11!11!11111!1

[Ashley MLP Fangirl]

4 hours ago, schwellmo92 said:

LPDDR is solder only

uuh no? i have plenty of DDR3L sodimms... 

[dalekphalm]

51 minutes ago, Twilight said:

uuh no? i have plenty of DDR3L sodimms... 

FYI DDR3L is not the same thing as soldered LPDDR (whether gen 3 or not).

 

LPDDR has a much lower standby power draw compared to DDRxL

https://blogs.synopsys.com/committedtomemory/2014/01/10/when-is-lpddr3-not-lpddr3-when-its-ddr3l/

Quote

DDR3L is a lower-voltage (and thus lower power) version of DDR3, but the term “LPDDR3″ refers to a specific DRAM implementation that is not DDR3.

 

See the table here (from the link above) that goes over some of the differences:

 

The key difference is in the "Approximate relative power" row - DDR3L standby power is 85% of regular DDR3 standby power. LPDDR3 standby power is 10% of regular DDR3 standby power.

 

That's a massive difference. And also as noted, LPDDRx is soldered, while DDRxL can use DIIM's.

[hishnash]

6 hours ago, SansVarnic said:

including important items such as your Bitlocker key and other encryption keys, or even inject malware which allows hackers to bypass the lock screen.

 

And this is why apple use the T2 chip for encryption, the CPU (and system memory) do not have any crypt keys at all within them.

In addition the T2 chip boots before the system and it sets up the memory isolation (of all PCIe devices) before the cpu powers on so that you cant use a (bad) PCIe device to bypass secure boot.
 

4 hours ago, pierom_qwerty said:

*please note i am a security researcher*

 

*Laughs in "Im about to hack a mac and theres nothing they can do about it"*

All TB3 devices have T2 chips...

These solve this problem (it cost apple a lot of money to develope this solution).
 

[wanderingfool2]

4 hours ago, pierom_qwerty said:

*please note i am a security researcher*

 

*Laughs in "Im about to hack a mac and theres nothing they can do about it"*

It is a valid point though, firewire on the Mac did and has lead to exploits when having physical access to the computer (because firewire had DMA and the system passwords were able to pulled from RAM) and does highlight the fact that it can be things to sometimes consider.

 

It is hard to patch exploits that are a result of a hardware specification (or there are penalties involved in that).  Similar concepts to meltdown/spectre

[hishnash]

9 minutes ago, wanderingfool2 said:

It is a valid point though, firewire on the Mac did and has lead to exploits when having physical access to the computer (because firewire had DMA and the system passwords were able to pulled from RAM) and does highlight the fact that it can be things to sometimes consider.

 

It is hard to patch exploits that are a result of a hardware specification (or there are penalties involved in that).  Similar concepts to meltdown/spectre

I think apples experience with firewire lead them to develop the security model managed by the T2 chips. It is very annoying when it comes to receiving data but it is also the only way to ensure it is realy encrypted and the only way to ensure a secure boot chain. 

Here is apple video that talks about the T2 chip and mentions the work they did to ensure that PCIe devices (even internal ones) cant comproise the secure boot chian or read full system memory.  

In summary apple solved the TB3 problem by using intels VT-d mode, but they needed to do this not in the OS kernal but all the way up the stack in the UEFI. 
 

[StDragon]

2 hours ago, hishnash said:

And this is why apple use the T2 chip for encryption, the CPU (and system memory) do not have any crypt keys at all within them.

In addition the T2 chip boots before the system and it sets up the memory isolation (of all PCIe devices) before the cpu powers on so that you cant use a (bad) PCIe device to bypass secure boot.

In the future, I'm not so sure Microsoft will need to implement anything more than just the TPM chip. Just as AMD did, Intel too is working on total memory encryption (TME). In addition, Windows 10 (64bit) offers robust ASLR for memory address randomization.

 

So a few things come to mind.

• ASLR prevents any device with DMA from guessing where sensitive decryption info is in RAM.
• BitLocker decryption still has to go through CPU, so DMA access to encrypted partitions won't yield access to user data directly.
• Once TME becomes more widespread, the entire issue becomes moot.

[captain_to_fire]

9 hours ago, SansVarnic said:

Thunderbolt uses DMA (Direct Memory Access) which means the port can read and write directly to your device’s RAM without the OS or processor being involved. This offers great speed, but also means a malicious device could read any part of your RAM at will, including important items such as your Bitlocker key and other encryption keys, or even inject malware which allows hackers to bypass the lock scree

Looks like Apple figured it out how to secure Thunderbolt with their T2 chip, thus making it harder to use DMA based attacks.

watch until 10:12

Quote

s. However, malicious peripherals can also overwrite code and data while the UEFI firmware is running in order to compromise boot security. macOS 10.12.3 updated the UEFI firmware for all VT-d-capable Mac computers to use VT-d to protect against malicious FireWire and Thunderbolt peripherals. It also isolates peripherals so that they can see only their own memory ranges, not the memory of other peripherals. For example, an Ethernet peripheral running in UEFI can’t read the memory of a storage peripheral.DMA protections in UEFI firmware were further improved in macOS 10.13 to move the initialization earlier in the UEFI firmware startup sequence to protect against:

 

• Malicious internal peripheral processors on the PCIe bus
• A class of Message Signaled Interrupt (MSI) attacks presented by security researchers

 

All Mac computers with the Apple T2 Security Chip come with further improved DMA protections, where the initialization is performed as early as possible. Specifically, the protection is enabled before any RAM is even available to the UEFI firmware. This protects against any compromised PCIe bus zero devices (such as the Intel ME) that may be running and capable of DMA at the instant that RAM becomes available. This protection was also added to Mac computers without a T2 chip in macOS 10.15

 

[captain_to_fire]

46 minutes ago, StDragon said:

Windows 10 (64bit) offers robust ASLR for memory address randomization

@leadeater can correct me on this but I think there's an Intel bug that makes ASLR easier to defeat. Also, not every application is compiled for ASLR.

[StDragon]

27 minutes ago, captain_to_fire said:

Also, not every application is compiled for ASLR.

But the OS itself (kernel) is. So if the disk is encrypted with BitLocker, there's no way to effectively parse the info to decrypt the volume. But yes, other applications executed in RAM could be left more vulnerable; in theory at least. How practical it is to exploit those via DMA is another matter entirely.

[Arika]

This forum is confusing.

 

this thread: just do it Microsoft, STFU, other laptop manufactures do it.

 

Other threads: So <company> doesn't care about security. They put performance above the security of their products, never buying <company product> again.

 

 

There so many instances of a company knowing about a vulnerability and just doing it anyway. MS know about the vulnerability and are removing it from the equation.

[justpoet]

25 minutes ago, Arika S said:

This forum is confusing.

 

this thread: just do it Microsoft, STFU, other laptop manufactures do it.

 

Other threads: So <company> doesn't care about security. They put performance above the security of their products, never buying <company product> again.

 

There so many instances of a company knowing about a vulnerability and just doing it anyway. MS know about the vulnerability and are removing it from the equation.

The difference is the technical details.  In this case, there are proper ways to do it securely.  MS just doesn't want to because of cost benefit.  It is absolutely the correct decision to not include it unless you're also going to do the additional silicon and UEFI development work that Apple does.

 

Other PC laptops on the other hand…well…mind if I "charge" my "phone battery" off your laptop?

[captain_to_fire]

4 hours ago, hishnash said:

I think apples experience with firewire lead them to develop the security model managed by the T2 chips. It is very annoying when it comes to receiving data but it is also the only way to ensure it is realy encrypted and the only way to ensure a secure boot chain. 

Which makes me think that the only way Microsoft can secure their own Surface devices from DMA attacks is adding an Apple-style security chip that handles the SSD controller, secure boot, and encryption. 

[hishnash]

2 hours ago, StDragon said:

In the future, I'm not so sure Microsoft will need to implement anything more than just the TPM chip. Just as AMD did, Intel too is working on total memory encryption (TME). In addition, Windows 10 (64bit) offers robust ASLR for memory address randomization.

 

So a few things come to mind.

• ASLR prevents any device with DMA from guessing where sensitive decryption info is in RAM.
• BitLocker decryption still has to go through CPU, so DMA access to encrypted partitions won't yield access to user data directly.
• Once TME becomes more widespread, the entire issue becomes moot.

In memory encryption does not help if the PCIe device can inject code into the kernel/before the kernal starts and the TME starts. You can just inject into the kernal and behave like an application copying data to an external device (aka unencrypted data out).

[hishnash]

17 minutes ago, captain_to_fire said:

Which makes me think that the only way Microsoft can secure their own Surface devices from DMA attacks is adding an Apple-style security chip that handles the SSD controller, secure boot, and encryption. 

Yes, they need a chip that handles all the crypto within itself so even if you do have a cpu vulnerability you cant get the key for the hard drive.  Notice how the T2 was released 1 month before spector/meltdown become public, apple will have known since day one of spectre/meltdown when intel were told.

 

[hishnash]

2 hours ago, captain_to_fire said:

@leadeater can correct me on this but I think there's an Intel bug that makes ASLR easier to defeat. Also, not every application is compiled for ASLR.

Does not matter, if your able to interupt the boot process. (before ASLR starts) you own the machine. Since TB3 cand init before the os kernel it can do anything the only protection is to change your UEFI.

 

 

1 hour ago, Arika S said:

There so many instances of a company knowing about a vulnerability and just doing it anyway. MS know about the vulnerability and are removing it from the equation.

The other solution is to put *lots and lot` of R&D $$$ and increase the product cost by doing what apple have done with the T2. It also adds some downsides:

* in the extra complexity of the system, so more likly to break

* moving the UEFI to the T2chip means that (like @LinusSebastian noted int he macPro review the system just cant boot without the integrated SSDs, since these containe the UEFI that the T2 validates then copies to the x86 cpu before boot)

* moving the UEFI to the T2 chip also means you cant just use a random stick of empty SDD and install an os onto it, you first need the correct UEFI to by placed onto that ssd (and it needs to be signed properly).
* all data is encrypted using a derived key from both the users passphrase and a large random key stored on each T2 chips secure enclave that means if you need to recover your data but cant use the T2 chip that it was written with you are unable to do this.  

* if you forget your passphrase for encryption the T2 chip is stateful and remembers how many failed attempts, after a given number it will wipe all of its internal keys and you will not be able to recover any of your data... this is good when you think of people brute forcing into your device but painful for many users.

 

2 hours ago, StDragon said:

But the OS itself (kernel) is. So if the disk is encrypted with BitLocker, there's no way to effectively parse the info to decrypt the volume. But yes, other applications executed in RAM could be left more vulnerable; in theory at least. How practical it is to exploit those via DMA is another matter entirely.

The issue is a TB3 device and inject itself before the os kernel boots this way it `owns` the system, you would need the UEFI to init these protections.

[PlayStation 2]

1 hour ago, Arika S said:

This forum is confusing.

 

this thread: just do it Microsoft, STFU, other laptop manufactures do it.

 

Other threads: So <company> doesn't care about security. They put performance above the security of their products, never buying <company product> again.

 

 

There so many instances of a company knowing about a vulnerability and just doing it anyway. MS know about the vulnerability and are removing it from the equation.

This forum, like many other forums, likes to complain because complaining is easier than actually looking at something objectively or in a more positive manner. Microsoft doesn't feel the need for Thunderbolt on their tablets for their reasons (essentially unhindered access to RAM), plain and simple. Nothing really newsworthy, hell of a nothing-burger.

[hishnash]

27 minutes ago, handymanshandle said:

This forum, like many other forums, likes to complain because complaining is easier than actually looking at something objectively or in a more positive manner. Microsoft doesn't feel the need for Thunderbolt on their tablets for their reasons (essentially unhindered access to RAM), plain and simple. Nothing really newsworthy, hell of a nothing-burger.

There is a story here, namely Microsoft consider windows laptops with TB3 to be insecure

This is a story about all other windows laptops with TB3 

 

--

and if you think your not vulnerable to a TB3 attack, you just need to ensure you never plug anything into those ports (including your charging cable, a double or a USB-c to USB-a converter that you buy someplace) any of these could attack your system.

[leadeater]

5 hours ago, captain_to_fire said:

@leadeater can correct me on this but I think there's an Intel bug that makes ASLR easier to defeat. Also, not every application is compiled for ASLR.

Dunno, I stopped following the hellstorm that is side channel attack after the first wave of them and going through all the effort of trying to get microcode updates out to all the CPUs. After that I just threw my hands in the air and said "screw it". New hardware will fix the problems and I can deal with that, Windows updates will cover the rest if they can if it's important.

 

Edit:

Plus you won't find any TB ports on our servers 

[hishnash]

10 minutes ago, leadeater said:

Plus you won't find any TB ports on our servers

Your other PCIe devices could compromise your servers still

[StDragon]

31 minutes ago, leadeater said:

Dunno, I stopped following the hellstorm that is side channel attack after the first wave of them and going through all the effort of trying to get microcode updates out to all the CPUs. After that I just threw my hands in the air and said "fuck it". New hardware will fix the problems and I can deal with that, Windows updates will cover the rest if they can if it's important.

Yup, ditto. It's a giant game of Whac-A-Mole because the entire concept of speculative execution was fundamentally flawed from a computer science perspective. It didn't effect just Intel (although they deserve fair criticism), but AMD and yes, some ARM CPUs namely Apple A series.

 

All mitigation at this point are bolt-ons. It will take an entirely new architecture that's fundamentally based on security to get this right.

 

The TLDR version of mitigating against side-channel attacks is to disable HT. Just ask Theo De Raadt

[leadeater]

1 hour ago, hishnash said:

Your other PCIe devices could compromise your servers still

Not on ours no, HPE iLO security prevents that. Nothing boots until that does and provides platform security, bad devices get rejected.

 

Quote

1. Silicon to supply chain
With HPE Gen10 Servers, HPE offers the first industry standard servers to include a silicon root of trust. Before the server is even manufactured, HPE is designing the silicon root of trust which allows firmware to be scanned and monitored through a series of integrity checks that initiate from an immutable link embedded in the silicon. From the custom silicon fabrication facility, the HPE firmware anchored in the silicon root of trust is inserted in a mother board and the server is assembled. Once the server arrives safely at the customer location and it is put into operation, the iLO firmware is the first component to initialize. Over 1 million lines of firmware code run before the operating system is even started and the silicon root of trust acts as an authentication fingerprint, ensuring the server essential firmware has not been compromised. 

2. Ongoing operations
While the server is operating, if any unwanted action to gain access to the server's firmware occurs, HPE will notify the customer through an iLO audit log alert. In addition, HPE provides the unprecedented ability to fully recover firmware to a known good state in the unlikely event of a security breach. HPE can automatically recover the server essential firmware through the HPE iLO 5 Advanced Premium Security Edition. This new license gives customers the option of recovering to the last known good state of firmware, the factory settings, or customers may choose to not recover and instead take the server offline for forensic analysis to determine how the breach occurred

https://community.hpe.com/t5/alliances/defend-against-server-attacks-with-hpe-secure-compute-lifecycle/ba-p/7015275#.XqUrHcgzbup

 

https://support.hpe.com/hpesc/public/docDisplay?docId=a00018320en_us