3 ms·

The main problem with the view that a single-user system is safe from this is the point that even single-user systems run untrusted code. For example, your web

The main problem with the view that a single-user system is safe from this is the point that even single-user systems run untrusted code. For example, your web browser probably by default runs Javascript, NaCl, or WebAsm code, which is supposedly sandboxed sufficiently to no longer be a threat to the other stuff running on your machine. This sort of exploit (which was kind of obviously going to happen at some point) breaks this sandbox to some extent.

xoa 8y ago
>For example, your web browser probably by default runs Javascript, NaCl, or WebAsm code, which is supposedly sandboxed sufficiently to no longer be a threat to the other stuff running on your machine. I think that would fall under "Even if it's desirable to run some risky code as well" and using hard core affinity wouldn't it? For performance oriented use cases 8-core and higher systems are not exactly super rare at this point, and AMD at least has been pushing the physical core counts pretty hard even on non-super high end chips. In a single owner/trusted dedicated metal case it's a lot easier to just say "core 1 is for running web code and that's it, if every core is needed for something else the web stuff will all be evicted and slept until that's over" which on a percentage basis doesn't incur that big a hit in a high core system. It's not like a IaaS system that's devoted to running dozens/hundreds of commercial client VMs and needs to be able to perform dynamic allocation with no manual intervention and untrusted code is the rule not the exception. IaaS is all about scaling, and that's a hard and interesting problem. But sometimes for individual instances it works fine to just pick a completely non-scalable solution that gets the job done and brute force it. I'm just thinking that it's worth remembering that most security is an economic equation, and sometimes performance is in fact worth it, or the security issue can be soft mitigated sufficiently in a restricted case. "Only trusted signed code may use SMT" for example, that won't work everywhere and it doesn't mitigate SMT still being a dangerous feature, but it may be plenty good enough in some instances. Or perhaps there is a server where the only truly sensitive piece is the private key, and that simply gets offloaded into an HSM blackbox and thus isn't available to be compromised anyway. Or the auth/signing servers disable it but other boxes do not. Basically, it just seems like it's too valuable a feature and the threat scenario not universal enough for it to be simply abandoned entirely as the authors suggest given the physical and economic realities we're facing right now with silicon.

xoa 8y ago

>For example, your web browser probably by default runs Javascript, NaCl, or WebAsm code, which is supposedly sandboxed sufficiently to no longer be a threat to the other stuff running on your machine. I think that would fall under "Even if it's desirable to run some risky code as well" and using hard core affinity wouldn't it? For performance oriented use cases 8-core and higher systems are not exactly super rare at this point, and AMD at least has been pushing the physical core counts pretty hard even on non-super high end chips. In a single owner/trusted dedicated metal case it's a lot easier to just say "core 1 is for running web code and that's it, if every core is needed for something else the web stuff will all be evicted and slept until that's over" which on a percentage basis doesn't incur that big a hit in a high core system. It's not like a IaaS system that's devoted to running dozens/hundreds of commercial client VMs and needs to be able to perform dynamic allocation with no manual intervention and untrusted code is the rule not the exception. IaaS is all about scaling, and that's a hard and interesting problem. But sometimes for individual instances it works fine to just pick a completely non-scalable solution that gets the job done and brute force it. I'm just thinking that it's worth remembering that most security is an economic equation, and sometimes performance is in fact worth it, or the security issue can be soft mitigated sufficiently in a restricted case. "Only trusted signed code may use SMT" for example, that won't work everywhere and it doesn't mitigate SMT still being a dangerous feature, but it may be plenty good enough in some instances. Or perhaps there is a server where the only truly sensitive piece is the private key, and that simply gets offloaded into an HSM blackbox and thus isn't available to be compromised anyway. Or the auth/signing servers disable it but other boxes do not. Basically, it just seems like it's too valuable a feature and the threat scenario not universal enough for it to be simply abandoned entirely as the authors suggest given the physical and economic realities we're facing right now with silicon.