There was a lady who went to Purdue, I believe her name was Carla Brodley. She is a professor at Tufts currently. One of her projects, I'm not sure whether it is ongoing or historic, was surrounding hardware based stack protection. There wasn't any protection against heap / pointer overflows and I don't know how it fares when stack trampoline activities (which can be valid, but are rare outside of older objective-c code).
I'm not sure if this is a similar solution to what Intel might be pursuing. I believe the original "smashguard" work was based entirely on Alpha chips.
cheers,
.mudge
On Dec 13, 2005, at 15:19, Michael S Hines wrote: Doesn't a hardware 'feature' such as this lock software into a two-state model (user/priv)?
Who's to say that model is the best? Will that be the model of the future?
Wouldn't a two-state software model that works be more effective?
It's easier to change (patch) software than to rewire hardware (figuratively speaking).
Just wondering...
Mike Hines ----------------------------------- Michael S Hines
_______________________________________________ Secure Coding mailing list (SC-L)
|
_______________________________________________
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
