C++ memory safety errors<\/a> are a top concern<\/a> for the industry. In Visual Studio 17.6, we deliver a new experimental Address Sanitizer feature: continue_on_error (COE). We\u2019ll remove the experimental label in 17.8. You compile as before, by simply adding the compiler flag To stream unique memory safety errors to stdout(1) or stderr(2):<\/p>\n To stream to a log file of your choice:<\/p>\n When you opt into the new continue on error (COE) feature, your application automatically diagnoses and reports unique memory safety errors as it runs. At program exit, the runtime produces a final summary<\/a> that follows the unique detailed reports normally produced by the Address Sanitizer.<\/p>\n The compiler instruments your binaries to work with the address sanitizer runtime to diagnose hidden memory safety errors. You can add the This new COE functionality provides a \u201cchecked build\u201d for C and C++ that finds hidden memory safety errors with zero false positives.<\/p>\n Hidden memory safety errors<\/span><\/p>\n The source code in Figure 1 which follows creates a buffer overflow due to the off-by-one error in the loop exit test. The code should check for Errors will only be observable if the following page is unmapped, or upon some subsequent use of corrupted data. All other cases are silent in the Figure 1 example that follows.<\/p>\n Figure 1<\/strong><\/span><\/p>\n In this example, where the parameter Figure 2<\/strong><\/span><\/p>\n Note that Description<\/span><\/p>\n The default Address Sanitizer runtime behavior terminates your application after reporting the first error encountered while running your program. It does not allow the \u201cbad\u201d machine instruction to execute. COE is a customer-requested change significantly different compared to the \u201cone-n-done\u201d behavior of the existing Address Sanitizer runtime. The new Address Sanitizer runtime diagnoses and reports errors, but then executes subsequent instructions.<\/p>\n The new COE functionality allows an application to continue running while reporting<\/strong> unique memory safety errors to a log file or to the command line. When enabled, COE tries to automatically return control back to the application after reporting each memory safety error, except for an access violation (AV) or failed memory allocation. With COE, you can compile and deploy an existing application into limited production to find memory safety issues while running for days (albeit slower).<\/p>\n By adding compiler flags and setting an environment variable, you can immediately improve correctness and security. Your existing tests will still pass but will also<\/em><\/strong> uncover hidden memory safety errors. The compiler option ( Internally we have found that using this technology significantly reduces memory safety errors. If all your existing tests pass, but<\/em><\/strong> this new feature reports a memory safety error or a leak, don\u2019t ship your new code or integrate it into a parent branch.<\/p>\n Example<\/strong><\/span><\/p>\n Figure 3<\/strong><\/span><\/p>\n With Figure 4<\/strong><\/span><\/p>\n Beneath the first red box at the top of Figure 4, there are three files sorted by error. This is followed by the file, function, and line displayed beneath the second box. The third box calls out eight unique errors, where “unique” is defined in terms of a hash function which uses call stacks and error descriptions. Use of the term unique<\/a> is discussed in the next section.<\/p>\n The detailed error reports (omitted in the screen capture in Figure 4) are printed before this summary and contain shadow bytes with all the details for each error in the summary.<\/p>\n Unique<\/span><\/p>\n The uniqueness of an error (to limit streaming duplicates) is determined by an internal hash function<\/strong> that uses the type of error and the call stack(s) at the time of error. A detailed individual error report includes stack trace(s). Here are the two detailed errors in the \u201csecure by coincidence\u201d example in Figure 1. The call stacks and types of errors are used to internally create an internal C++ error object, which is then hashed to a unique integer. The global-buffer-overflow in Figure 5 only has one call stack and is a different type of error object from the heap-buffer-overflow in Figure 6, which has two call stacks.<\/p>\n Figure 5<\/strong><\/span><\/p>\n Figure 6<\/strong><\/span><\/p>\n The runtime will hash each occurrence of an error at runtime in order to prevent duplication. Consider a memory-safety<\/a> error that\u2019s executed 10000 times in a loop. The detailed error will be reported once, but its \u201chit count\u201d of 1000 will be reported in the summary.<\/p>\n Not continuing.<\/span><\/p>\n Two examples where the continue on error feature cannot continue<\/em><\/strong> are:<\/p>\n Consider the following program which has an access violation because it tries to read from location Figure 7<\/strong><\/span><\/p>\n On Windows 11, when the example in Figure 7 above, is compiled with Figure 8<\/strong><\/span><\/p>\n We choose to \u201cgracefully cancel\u201d the attempt to continue from access violations that are not<\/strong> caught with a user\u2019s structured exception handling.<\/p>\n We haven\u2019t been able to do a complete audit that would allow us to \u201cmatch\u201d undefined behaviors for C and C++. The following example in Figure 9, makes this tangible. At the commented line in the following code example, code generation from the compiler and the runtime implementation are both different for Figure 9<\/strong><\/span><\/p>\n The previous example, in Figure 9, prints pass<\/strong> without With the Address Sanitizer in There will be no stack overflow exception to process the We have not had time to document or clearly define the subtle differences when a program has undefined behavior. This was a reason for releasing NOTE: The frequency with which this concern has become visible, has been rare with our testing infrastructure.<\/strong><\/p>\n There were six categories of C++ memory safety<\/a> errors in the 2021 Common Weakness Enumeration (CWE) Top 25 Most Dangerous Software Weaknesses<\/a>. The best Remote Code Execution Bug<\/a> was a 20 year old heap-buffer-overflow. This award in 2022 went to BugHunter010 at Cyber KunLun Lab. This engineer discovered a heap-buffer-overflow vulnerability in the RPC protocol with CVSS score 9.8. This bug has existed in the Windows system for more than 20 years. There are new C++ memory safety bugs introduced daily because traditional testing can\u2019t expose these types of bugs without compiler and runtime support.<\/p>\n This new feature is designed to enable developers to implement a simple new gate for shipping C++ on Windows. Using this technology will significantly reduce memory safety errors. If your tests pass but continue_on_error reports any hidden memory safety errors, you should not ship or integrate new code into the development branch.<\/a><\/p>\n We intend that continue_on_error be used as pass\/fail gate, for all CI\/CD pipelines using C and C++.<\/strong><\/p>\n We invite you to install the 17.6 version of Visual Studio<\/a> or later, try out the continue on error feature, and give us feedback<\/a><\/a>.<\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" Visual Studio 17.6 comes with new functionality in the Address Sanitizer runtime which provides a new \u201cchecked build\u201d for C and C++. This new runtime mode diagnoses and reports hidden memory safety errors, with zero false positives, as your app runs. Introduction C++ memory safety errors are a top concern for the industry. In Visual […]<\/p>\n","protected":false},"author":37422,"featured_media":32506,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1,280,3929,277],"tags":[3893,3930,3938,3937,3934,3935,3931,3933,3932,3936],"class_list":["post-32499","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cplusplus","category-new-user","category-pure-virtual-c","category-writing-code","tag-address-sanitizer","tag-asan","tag-c-ci-cd","tag-c-memory-safety","tag-checked","tag-checked-builds","tag-continue","tag-continue-on-error","tag-continue_on_error","tag-memory-safety"],"acf":[],"blog_post_summary":" Visual Studio 17.6 comes with new functionality in the Address Sanitizer runtime which provides a new \u201cchecked build\u201d for C and C++. This new runtime mode diagnoses and reports hidden memory safety errors, with zero false positives, as your app runs. Introduction C++ memory safety errors are a top concern for the industry. In Visual […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/32499","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/users\/37422"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/comments?post=32499"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/32499\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media\/32506"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media?parent=32499"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/categories?post=32499"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/tags?post=32499"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}-fsanitize=address<\/code>. With 17.6 you can enable the COE functionality by setting environment variables from the command line.<\/p>\n\n
\n
-fsanitize=address -Zi<\/code> compiler flags and set the ASAN_OPTIONS<\/code> or COE_LOG_FILE<\/code> environment variable with values shown previously. You can then build and run your existing tests to exercise your code to find hidden memory-safety errors.<\/p>\nii < sz<\/code>, but instead checks for ii <= sz<\/code>. When the example runs, it is secure by coincidence<\/strong>. That\u2019s because of the over-allocation and alignment done by most C++ runtime implementations. When sz % 16 == 0<\/code>, the final write to local<\/code> corrupts data. In other cases only read\/write to the \u201cmalloc slop\u201d which is due to the C Runtime (CRT), padding allocations out to a 0 mod 16<\/code> aggregate boundary.<\/p>\n#include <stdlib.h> \r\nchar* func(char* buf, size_t sz) { \r\n char* local = (char*)malloc(sz); \r\n for (auto ii = 0; ii <= sz; ii++) { \/\/ bad loop exit test \r\n local[ii] = ~buf[ii]; \/\/ Two memory safety errors \r\n } \r\n return local; \r\n} \r\n\r\nchar original[10] = { 0,1,2,3,4,5,6,7,8,9 }; \r\n\r\nvoid main() { \u00a0 \r\n char* inverted_buf= func(original,10); \r\n}<\/code><\/pre>\nsz<\/code> is 10 and the original buffer is 10-bytes, there are two memory safety errors: one is an out-of-bounds load from buf<\/code> and the other is an out-of-bounds store to local<\/code>. With continue_on_error<\/code>, you will see both errors in the summary, and the program will run to completion. Here\u2019s the summary:<\/p>\n![\"Terminal](\"https:\/\/devblogs.microsoft.com\/cppblog\/wp-content\/uploads\/sites\/9\/2023\/06\/a-screenshot-of-a-computer-program-description-au-4.png\")
<\/p>\ncontinue_on_error<\/code> reports two distinct errors that occur on the same source line. The first error reads memory at a global address in the .data<\/code> section, and the other writes to memory allocated from the heap.<\/p>\n-fsanitizer=address<\/code>) and runtime environment flag can be used to introduce a new \u201cshipping gate.\u201d Subsequently COE can then be used with all your existing tests. The developer gets a simple, well-defined, pass\/fail for shipping any C or C++ app on Windows.<\/p>\n#include <cstdio>\r\n#include <string>\r\n\r\nstruct Base {\r\n \/\/virtual ~Base() = default;\r\n};\r\n\r\nstruct Derived : public Base {\r\n std::wstring Value = L\"Leaked if Base destructor is not virtual!\";\r\n};\r\n\r\nconstexpr size_t PointDims = 3;\r\ndouble pointsInGlobalData[PointDims] = { 1.0, 2.0, 3.0 };\r\n\r\nint main() {\r\n\r\n pointsInGlobalData[3] = 3.0;\r\n\r\n for (int i = 0; i < 2; i++) {\r\n double pointOnStack[PointDims] = { 1.0, 2.0, 3.0 };\r\n pointOnStack[-1] = 3.0;\r\n pointOnStack[PointDims] = 0.0;\r\n\r\n double* pointOnHeap = new double[PointDims + 100000];\r\n pointOnHeap[-1] = 4.0;\r\n delete[] pointOnHeap;\r\n\r\n double* pointDouble = new double[PointDims] { 1.0, 2.0, 3.0 };\r\n pointDouble[PointDims] = 4.0; \/\/ overflow\r\n delete[] pointDouble; \/\/ we continue\r\n Base* base = new Derived();\r\n delete base; \/\/ missing virtual destructor\r\n\r\n constexpr size_t buff_size = 128;\r\n char* buffer = new char[buff_size];\r\n std::memset(buffer, '\\0', buff_size);\r\n std::memset(&buffer[buff_size - 28], '=', 30);\r\n }\r\n wprintf_s(L\"Loop completed! \\r\\n\");\r\n}<\/pre>\ncontinue_on_error<\/code>, the program in Figure 3 above, produces the summary in Figure 4. That summary is printed after<\/em><\/strong> streaming all unique detailed error reports which are produced using the existing default mode of the Address Sanitizer. The existing default mode is \u201cone-n-done\u201d. The previous Address Sanitizer only prints one detailed error report, and then exits your process. With continue_on_error<\/code>, we continue to execute after various memory safety errors. This summary illustrates continuing after many memory safety errors:<\/p>\n![\"Console](\"https:\/\/devblogs.microsoft.com\/cppblog\/wp-content\/uploads\/sites\/9\/2023\/06\/a-screenshot-of-a-computer-description-automatica.png\")
<\/p>\n![](\"https:\/\/devblogs.microsoft.com\/cppblog\/wp-content\/uploads\/sites\/9\/2023\/06\/word-image-32499-3.png\")
<\/p>\n![](\"https:\/\/devblogs.microsoft.com\/cppblog\/wp-content\/uploads\/sites\/9\/2023\/06\/word-image-32499-4.png\")
<\/p>\n\n
0x13<\/code><\/strong>:<\/p>\n#include <stdio.h>\r\n\r\nvoid main()\r\n{\r\n unsigned int* local_ptr = (unsigned int*) 0x13;\r\n printf(\"use of undefined address %p [%x]\\n\", local_ptr, *local_ptr);\r\n}<\/pre>\n-fsanitize=address -Zi<\/code>, you\u2019ll see the following error message in Figure 8, below.<\/p>\n![\"CONTINUE](\"https:\/\/devblogs.microsoft.com\/cppblog\/wp-content\/uploads\/sites\/9\/2023\/06\/word-image-32499-5.png\")
<\/p>\nMatching undefined behavior<\/span><\/h2>\n
_alloca <\/code>when compiling with -fsanitize=address -Zi<\/code>:<\/p>\n#include <cstdio>\r\n#include <cstring>\r\n#include <malloc.h>\r\n#include <excpt.h>\r\n#include <windows.h>\r\n\r\n#define RET_FINISH 0\r\n#define RET_STACK_EXCEPTION 1\r\n#define RET_OTHER_EXCEPTION 2\r\n\r\nint foo_redundant(unsigned long arg_var) {\r\n\r\n char *a;\r\n int ret = -1;\r\n\r\n __try\r\n {\r\n if ((arg_var+3) > arg_var) {\r\n \/\/ Call to alloca using parameter from main<\/strong>\r\n a = (char *) _alloca(arg_var); <\/strong>\r\n memset(a, 0, 10);\r\n }\r\n ret = RET_FINISH;\r\n }\r\n __except(1)\r\n {\r\n ret = RET_OTHER_EXCEPTION;\r\n int i = GetExceptionCode();\r\n if (i == EXCEPTION_STACK_OVERFLOW) {\r\n ret = RET_STACK_EXCEPTION;\r\n }\r\n } \r\n return ret;\r\n}\r\n\r\nvoid main(){ \r\n int cnt = 0;\r\n if (foo_redundant(0xfffffff0) == RET_STACK_EXCEPTION)\r\n cnt++; \/\/increment count of <\/b>exceptions<\/b><\/span> handled.<\/b>\r\n\r\n if (cnt == 1)\r\n printf(\"pass\\n\");\r\n else\r\n printf(\"fail\\n\");\r\n}<\/pre>\n-fsanitize=address<\/code>. That\u2019s because cnt==1 <\/code>due to an exception. It will fail when compiled with that flag and run with the Address Sanitizer runtime. In main()<\/code> we pass a large number to foo_redundant<\/code>, which is passed to _alloca()<\/code>.<\/p>\ncontinue_on_error<\/code> (COE) mode, this program runs to completion, but prints fail<\/strong>. The code generation from the compiler must match the ABI for the Address Sanitizer runtime. For the Address Sanitizer runtime, the compiler grows the allocation size and aligns it 0 mod 32 (a cache line). That math will cause an integer overflow (i.e., wrap around) creating a reasonable, small positive number as the parameter to _alloca<\/code>.<\/p>\n__except<\/code> handler.` <\/strong><\/p>\ncontinue_on_error<\/code> as experimental at first.<\/p>\n<\/a>Top Concern \u2013 don\u2019t ship without it.<\/span><\/h2>\n
Call To Action<\/span><\/h2>\n