It does work, but due to the limitations of Cortex MPU windows I've moved over to code instrumentation for our protection which involves a very much beefed-up version of the GCC stack protector.
DWT includes "comparators" typically used as hardware watch points. My methodology was to use one of the DWT comparators to watch for something reading/writing the last u32 of the current task's stack. Note that this might not be perfect as it could be possible for the stack to somehow skip over the last u32.
Then, install a handler for the Debug Monitor exception (which triggers when a watch point is hit) to disable the DWT comparator, print/store the appropriate info, and finally reset the chip.
Essentially, we're behaving like a simple "debug monitor" which only is capable of setting a single hardware watch point automatically.
Note that DWT is technically an optional component in armv7m, so it may not be functional on every chip. That said, most folks like having debug capabilities (this is the same hardware that jtag debuggers use to set watchpoints), so most seem to include them. On that note: doing this can (to some extent) interfere with external debuggers. To mitigate some of that, I did try to use the last DWT comparator instead of the first, but this will really depend on how your debugger works.
I've got hopes for the v8-m arch as it modifies the MPU scheme to make it much more flexible than v7-m. I've had issues with fitting code around the power-of-2 size windows.... it makes things really clumsy.
I'm currently using code instrumentation to get our required level of robustness but I may have a play around with the DWT now.
1: https://github.com/jmesmon/ccan/blob/maskn/ccan/maskn/maskn....
In my case, with my domain protection system I had well defined domain-crossing points across which I could guarantee that no data was being passed-by-reference, At these points I was trying to fit the Cortex MPU windows as closely as possible over the 'used' stack area so I could prevent access to it by any potentially malicious code. I would poison the return address to cause a known fault when the code returned and move the MPU windows accordingly.
Although it worked, due to the limitations of the v7-M arch MPU windows the protection was never complete and proved to be time consuming to implement due to the size of the application. Maybe in future it will become more practical.