Smashguard, if I recall correctly, offers approximately the protection of existing compiler methods, but with the added fun of requiring modified (non-existent) hardware.
The referenced hardware in the IEEE article and the intel.com pages appears to be some descendant of Palladium; it is a hardware integrity checker/attestation mechanism. A small, hardware-enforced core performs a chain of crypto-checks prior to boot strapping the BIOS, and then the OS, and makes itself available to applications. Thus an application can (more or less) "prove" to a remote machine that the BIOS, kernel, and application are in fact the "approved" versions that the remote machine wants to see. The closest published work would be Bill Arbaugh's dissertation and associated papers. Real security benefit: remote machine can detect that your box has not been rootkit'd. Hoarding "benefit": remote machine can detect that you are running the approved DRM-enforcing media player so that (for instance) it can enforce that you only get to play that movie the specified number of times and you don't get to copy it. Malignant effect: Document master at an organization can make all documents transient, so that whistle-blowers can no longer access the documents they are trying to use to blow the whistle on such as, say, Enron, WorldCom, or Abu Grab-ass. Be very, very careful about tolerating strong-attestation hardware. The implications are profound, for both good and evil. Crispin mudge wrote: > > 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). > > www.smashguard.org and https://engineering.purdue.edu/ > ResearchGroups/SmashGuard/smash.html have more data. > > 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 >> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >> >> _______________________________________________ >> Secure Coding mailing list (SC-L) >> SC-L@securecoding.org <mailto: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 > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 > -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering, Novell http://novell.com _______________________________________________ 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
