Reply to post: Re: Alternative security measures

Intel SGX 'safe' room easily trashed by white-hat hacking marauders: Enclave malware demo'd


Re: Alternative security measures

I should probably clarify, to show at least “incomplete” ignorance.

I do know that Linux today allows 8MB stack per thread, which blows way past 256k total stack....

My point is - OS design encodes a set of decision making based on a history of CPU microarchitecure, particularly Intel and AMD. This looks “cost-free” on current architectures with stack mapped into main memory, but it is turning out to be very costly from a security perspective.

Are such large stack sizes really needed, or are we just encouraging greedy developer practices. Being controversial (and I know there are people who *love* recursion), if I discovered my team were writing something that required even 1M stack, I would be really worried. If 1M, what are the edge cases that it needs 2M? Or 20M? It seems to me like an accident waiting to happen, without fairly severe numerical analysis, especially when an unrelated team adds an unrelated feature in object-oriented fashion two years later.

If instead, we prioritised security, and accepted hardware limitations on stack-size. Trade-off, on the one hand a majority of metal-level security issues are prevented. Maintenance becomes much cheaper downstream. On the other hand, Linux and Win have to change thread stack-size, and a bunch of legacy applications containing bloated stack assumptions need to be re-spun. Would there be a net benefit for the industry in theory, even if it difficult to get there from here.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019