Microsoft is addressing the question of, "why can't an operating system protect itself and other users from buggy code?" Their answer seems to be using hardware to cover for their bad operating system coding. How about a followup with some meat instead of more FUD?

So far no one has stated how the palladium architecture is evil to open source software. M$ is (supposedly) publishing an open standard on how the signed code kernel and hardware will intereact. I am certain you read their blurb at:
http://www.microsoft.com/presspass/features/2002/jul02/07-01
palladium.asp

Surely other operating systems that will run on this hardware can use this stuff, if it makes sense.

Whether the buffer overlfow is on UNIX or M$ or some other OS, the trick is to make sure that the program does not go off in the weeds because a user supplied a too much input. Buggy coding obliged you to read all of that data or misinterpet valid data as instructions. Will palladium provide for every subroutine call to be authenticated? What about corrupting data within a routine itself?

Do you really believe that folks that sell Palladium based hardware will only make it for the microsoft server market? Several vendors heavily invested in UNIX operating systems that should be targeted for that platform. Will Intel want take a step back to make a chip that only microsoft software will run on?

FWIW, I am surprised that Linux/UNIX kernel architects are not publishing more about architectural methods to mitigate buffer overflows. Stackgaurd and the like are pretty cool, but blaming the application is a cheap shot.

-bof

[ reply ]

Link to this comment: http://www.securityfocus.com/comments/columns/96/15735#15735