Interview with Chris Satchell - XNA and Security

[aaronspink]

The fact that avarage Joe cannot write BD should make a better financial motivation for people who earns of piracy.

Even for professional pirates the price factors come into play. Basically they need roughly a 10x cost differential to make the risk rewards work out (this is both from a profit perspective and the perspective of potential buyers in general), and while this is easily achieved with DVD even without pressing (of which there are many very shady pressing lines out there), BR pressing lines are currently fairly limited and locked down (and even these still have reasonably high cost factors) and the burner route requires media alone that restricts them to at most a 5 to 1 cost factor.

Until the cost of blank discs hits the $2-4 dollar range, Sony likely won't have to worry about the professionals.

Aaron Spink
speaking for myself inc.

 

[patsu]

Some mod files are just like movies, but a lot actually contain some scripting, etc. Its this scripting and not trusting the 3rd party code that likely concerns MS. In general MS has been burned on 3rd party code and now has a bunch of security people with TLA backgrounds as well who are always nervous of 3rd party code and exploit s of such code.

But MS has also been burnt by its own people. Is there really a big difference ?

Microsoft certainly has the rights to dictate the terms on their platform. But I don't see why their implementation is necessarily better than the rest just because we know they have a bunch of TLA people. Based on track record, their hypervisor has been compromised.

As for network and server security, there are top notch *nix server guys for hire too. MS's Windows security experts may not necessarily be the best there.

In user modding, Chris Satchell highlighted the need for a XNA-like sandbox, so they trust XNA programs created by arbitrary/amateur developers. As long as Sony has a similar/stronger sandbox (even at a lower level), I don't see why user modding and scripting is a worse monster.

 

[archangelmorph]

I mean currently you've got one PS3 game (UT3) with an fairly borked modding system (since you cannot find and download mods via in-game browser, but must use a fairly cumbersome outside system)

Correct me if i'm wrong but don't most if not all PC games supporting mods not have any kind of in-game browser for finding & downloading them?

If so then your point is pretty moot..

 

[mister slim]

Correct me if i'm wrong but don't most if not all PC games supporting mods not have any kind of in-game browser for finding & downloading them?

If so then your point is pretty moot..

Most PC games allowing sharing mods when a player without it joins the room. UT3 PS3 only shares mutators, not characters or maps, though Epic has hinted they'll fix this.

 

[archangelmorph]

Most PC games allowing sharing mods when a player without it joins the room. UT3 PS3 only shares mutators, not characters or maps, though Epic has hinted they'll fix this.

Not exactly an in-game mod browser however it's good to know i guess..

 

[dlm]

But MS has also been burnt by its own people. Is there really a big difference ?

There's a huge difference. I'll explain more below.

In user modding, Chris Satchell highlighted the need for a XNA-like sandbox, so they trust XNA programs created by arbitrary/amateur developers. As long as Sony has a similar/stronger sandbox (even at a lower level), I don't see why user modding and scripting is a worse monster.

XNA development and modding are significantly different. XNA is a managed language for which MS controls the VM. Game code runs significantly closer to the metal, and MS has much less control over it.

The security advantage is quite simple, if there's a flaw in the VM, Hypervisor, or anywhere else, MS has 100% control over it and can be dedicated to fixing it. If UE3 has an arbitrary execution flaw in the mod script handling, then all MS can do is beg Epic to fix it.

Unfortunately, as it turns out, you really *can't* trust people using your platform to fix their bugs. This has been proven out an uncountable number of times.

It's not about who's software is "most secure", it's about where you hedge your bets. MS appears to have decided to keep all of the hard points in their own house.

 

[patsu]

XNA development and modding are significantly different. XNA is a managed language for which MS controls the VM. Game code runs significantly closer to the metal, and MS has much less control over it.

The security advantage is quite simple, if there's a flaw in the VM, Hypervisor, or anywhere else, MS has 100% control over it and can be dedicated to fixing it. If UE3 has an arbitrary execution flaw in the mod script handling, then all MS can do is beg Epic to fix it.

Unfortunately, as it turns out, you really *can't* trust people using your platform to fix their bugs. This has been proven out an uncountable number of times.

This is from XNA's and MS's perspective. What if Sony has an efficient, lower level run-time that achieves something similar ? In which case, UT3 would be running in a "VM" too right ?

 

[dlm]

This is from XNA's and MS's perspective. What if Sony has an efficient, lower level run-time that achieves something similar ? In which case, UT3 would be running in a "VM" too right ?

Except that we already know that UT3 is written in native code. Obviously there are security constraints on it, but these are based on the system architecture and HyperV, not a VM.

 

[patsu]

Except that we already know that UT3 is written in native code. Obviously there are security constraints on it, but these are based on the system architecture and HyperV, not a VM.

How extensive is the protection ? How are the system partitioned ? Do you have the details ? I was told in PS3, all the I/O goes through the hypervisor, and some parts of memories can be totally cordoned off.

 

[Shifty Geezer]

'System architecture' and 'HyperV' and 'VM' are all variations on the same principal though, that seek to enforce the same thing - keeping code out of places you don't want it to go. So UT3 running in an XNA VM that prevents it accessing system resources, or UT3 running on a hardware architecture that prevents it accessing system resources, achieve the same thing. The advantage with the hardware level security is that the hardware then opens for devs to use more effectively and flexibly. All systems are also open to hacks in theory.

 

[patsu]

On Hypervisor, partial/full virtualization for embedded systems, and paravirtualization: http://en.wikipedia.org/wiki/Hypervisor
How extensive is the PS3 HyperVisor ? The only thing I know is it is proprietary to Sony and not created by IBM.

 

[dlm]

'System architecture' and 'HyperV' and 'VM' are all variations on the same principal though, that seek to enforce the same thing - keeping code out of places you don't want it to go. So UT3 running in an XNA VM that prevents it accessing system resources, or UT3 running on a hardware architecture that prevents it accessing system resources, achieve the same thing. The advantage with the hardware level security is that the hardware then opens for devs to use more effectively and flexibly. All systems are also open to hacks in theory.

I only half agree with you here.

If your application is managed code, then nobody can achieve arbitrary code execution by compromising your application (unless it implements unsafe methods or COM interop, which XNA doesn't allow). This means that your only option to execute arbitrary code is to compromise the VM itself. However, in this case, MS owns the VM, so they can make sure it gets fixed.

If you have a game in native code that someone compromises, they may have arbitrary code execution. Yes, if you have a hypervisor, you may prevent them from bricking the system or doing some other bit of silliness, but there are interesting things that you can do without taking over the box itself.

Consider the implications for multiplayer. MS is *extremely* hardcore about trying to keep cheating out of XBox Live. However, if I can write a mod that gets me code execution in UE3's process space, I can happily inject whatever hacks I want into the process. Cheat city, yay me.

 

[Shifty Geezer]

Well yes, regards game security that's right. And that's a reason to exclude mods. But

1) MS haven't implemented a secure VM solution for developer software so that UT3 can run mods securely - regards mainstream software development they're in the same boat as everyone else; it's only homebrew applications where they offer a secure software platform. Plus in 3rd party cases the game developers can patch the software to close cheats, as happens already online - sometimes. Keeping out the cheaters is the developer's responsibility to their paying customers, even if the console company is taking measures to secure games from cheating.

2) Satchell's comments were looking at system security, not game security...

Now the modding's a little different. Yes it could help rate mods, but the core issue of modding is what we talked about earlier - if you're not running in that sandbox, how do you guarantee security?
That's really where we've got stuck - making sure that nothing will hurt the user's system,

Which was the source of this discussion - game mods as a security risk to the system. You'd only want to disallow mods for this reason is if you feel the mods could gain destructive access to the system resources. Likewise the reason you'd prevent homebrew is for fear of homebrew programs accessing the system. MS have opened homebrew by implementing the software security layer, but declined open mods. In contrast, Sony have been happy to accept mods, and to throw open Linux! Sony feel they're in a secure position, and as I understand are in a more secure position because of the hardware designs chosen. They seem to be offering the same system security as MS's VM XNA sandbox, but at a lower level. Either that, or they're reckless as Satchell says!

 

[dlm]

1) MS haven't implemented a secure VM solution for developer software so that UT3 can run mods securely - regards mainstream software development they're in the same boat as everyone else; it's only homebrew applications where they offer a secure software platform. Plus in 3rd party cases the game developers can patch the software to close cheats, as happens already online - sometimes. Keeping out the cheaters is the developer's responsibility to their paying customers, even if the console company is taking measures to secure games from cheating.

This is exactly the reason why there will be no mods on 360 UT3. Also, despite that it should indeed be the developer's responsibility to stop cheating, most developers lack either the know-how, the resources, or the concern to actually do anything about it.

2) Satchell's comments were looking at system security, not game security...Which was the source of this discussion - game mods as a security risk to the system. You'd only want to disallow mods for this reason is if you feel the mods could gain destructive access to the system resources.

What about a mod that wipes all your save data for the game? I'd say that rates. You're looking at this in a very narrow context. Once you have code execution, you can do a lot of things that aren't format C: that could really hurt legitimate users. MS is simply trying to prevent this to a higher degree than Sony.

They seem to be offering the same system security as MS's VM XNA sandbox, but at a lower level. Either that, or they're reckless as Satchell says!

The truth lies somewhere in the middle.

 

[aaronspink]

This is from XNA's and MS's perspective. What if Sony has an efficient, lower level run-time that achieves something similar ? In which case, UT3 would be running in a "VM" too right ?

For sony you are directly running machine code, for XNA you are running through an interpreter with no actual programming level access to the hardware.

The major difference between something like a managed runtime from Epic and XNA from MS is that MS has both the will and ability to update and patch any issues found in the XNA managed runtime where as the motivation and responsibility may or may not be there and if it is, it is certainly not to the same level as MS itself.

Aaron Spink
speaking for myself inc.

 

[aaronspink]

'System architecture' and 'HyperV' and 'VM' are all variations on the same principal though, that seek to enforce the same thing - keeping code out of places you don't want it to go. So UT3 running in an XNA VM that prevents it accessing system resources, or UT3 running on a hardware architecture that prevents it accessing system resources, achieve the same thing. The advantage with the hardware level security is that the hardware then opens for devs to use more effectively and flexibly. All systems are also open to hacks in theory.

They aren't really the same thing. A managed runtime doesn't allow any code to actually run directly, either interpreting a byte code byte by byte or doing JIT complication to a cached instruction store.

OTOH, the HV is just another application running on the hardware doing its best to prevent other applications from accessing places where they shouldn't.

Aaron spink
speaking for myself inc.

 

[archangelmorph]

This is exactly the reason why there will be no mods on 360 UT3. Also, despite that it should indeed be the developer's responsibility to stop cheating, most developers lack either the know-how, the resources, or the concern to actually do anything about it.

& you know this because you're obviously well informed of the competency, motivations & focuses of "most" developers..

Utter bollocks..

 

[patsu]

They aren't really the same thing. A managed runtime doesn't allow any code to actually run directly, either interpreting a byte code byte by byte or doing JIT complication to a cached instruction store.

OTOH, the HV is just another application running on the hardware doing its best to prevent other applications from accessing places where they shouldn't.

That's right. HV can provide a partitioned and virtualized space for its app to run on. The approach is different from managed code but they both implement the notion of a "Virtual Machine". It seems that in 360 (and probably PS3 too), this is done via system calls. But there has been some VooDoo talks about partitioning on Cell.

Naturally, no details was given. I know this is your area, so while you're at it... would you be able to shed some light on the techniques ?

 

[aaronspink]

That's right. HV can provide a partitioned and virtualized space for its app to run on. The approach is different from managed code but they both implement the notion of a "Virtual Machine". It seems that in 360 (and probably PS3 too), this is done via system calls. But there has been some VooDoo talks about partitioning on Cell.

Naturally, no details was given. I know this is your area, so while you're at it... would you be able to shed some light on the techniques ?

For a traditional (read IBM) VM, you basically have fully compiled object code running directly on the metal. The security/isolation is provided via TLB entry security and privileged instruction trapping to the HV. While this can work well in a purely computational environment, it gets much more complex on something like PS3 which has to account for additional actors like the GPU.

Now the problem becomes, the HV really can only allow/disallow access to specific memory spaces and to higher protection levels of the processor. By default the application, esp in an environment like PS3, have lots of default access to things like NVRAM and disk. The fear is that someone figures out how to utilize the scripting interface of a game to access the disk access abilities of the base program and then put malicious code on the disk.

For a managed runtime, you are effectively trapping ALL operations and therefore can restrict things like disk reads/write to specific defined functions and areas.

Aaron Spink
speaking for myself inc.

 

[dlm]

& you know this because you're obviously well informed of the competency, motivations & focuses of "most" developers..

Utter bollocks..

Have you ever read SecurityFocus? Have you seen the kind of crap that goes unpatched month after month, or gets fixed incorrectly over and over again? It's a simple fact that most developers simply don't understand security, and if they do, are rarely budgeted to manage it properly.