CINXE.COM

<!DOCTYPE html> <html lang="en-US" xmlns:og="http://opengraphprotocol.org/schema/" xmlns:fb="http://www.facebook.com/2008/fbml" itemscope itemtype="http://schema.org/Article" class="no-js"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <link rel="profile" href="http://gmpg.org/xfn/11"> <link rel="pingback" href="https://blogs.coreboot.org/xmlrpc.php">  <script>(function(){document.documentElement.className='js'})();</script> <script>(function(html){html.className = html.className.replace(/\bno-js\b/,'js')})(document.documentElement);</script> <title>ASan – coreboot</title> <meta name='robots' content='max-image-preview:large' /> <style>img:is([sizes="auto" i], [sizes^="auto," i]) { contain-intrinsic-size: 3000px 1500px }</style> <link rel='dns-prefetch' href='//blogs.coreboot.org' /> <link rel="alternate" type="application/rss+xml" title="coreboot » Feed" href="https://blogs.coreboot.org/feed/" /> <link rel="alternate" type="application/rss+xml" title="coreboot » Comments Feed" href="https://blogs.coreboot.org/comments/feed/" /> <link rel="alternate" type="application/rss+xml" title="coreboot » ASan Tag Feed" href="https://blogs.coreboot.org/blog/tag/asan/feed/" /> <link rel='stylesheet' id='wp-block-library-css' href='https://blogs.coreboot.org/wp-includes/css/dist/block-library/style.min.css?ver=6.7.1' media='all' /> <style id='wp-block-library-theme-inline-css'> .wp-block-audio :where(figcaption){color:#555;font-size:13px;text-align:center}.is-dark-theme .wp-block-audio :where(figcaption){color:#ffffffa6}.wp-block-audio{margin:0 0 1em}.wp-block-code{border:1px solid #ccc;border-radius:4px;font-family:Menlo,Consolas,monaco,monospace;padding:.8em 1em}.wp-block-embed :where(figcaption){color:#555;font-size:13px;text-align:center}.is-dark-theme .wp-block-embed :where(figcaption){color:#ffffffa6}.wp-block-embed{margin:0 0 1em}.blocks-gallery-caption{color:#555;font-size:13px;text-align:center}.is-dark-theme .blocks-gallery-caption{color:#ffffffa6}:root :where(.wp-block-image figcaption){color:#555;font-size:13px;text-align:center}.is-dark-theme :root :where(.wp-block-image figcaption){color:#ffffffa6}.wp-block-image{margin:0 0 1em}.wp-block-pullquote{border-bottom:4px solid;border-top:4px solid;color:currentColor;margin-bottom:1.75em}.wp-block-pullquote cite,.wp-block-pullquote footer,.wp-block-pullquote__citation{color:currentColor;font-size:.8125em;font-style:normal;text-transform:uppercase}.wp-block-quote{border-left:.25em solid;margin:0 0 1.75em;padding-left:1em}.wp-block-quote cite,.wp-block-quote footer{color:currentColor;font-size:.8125em;font-style:normal;position:relative}.wp-block-quote:where(.has-text-align-right){border-left:none;border-right:.25em solid;padding-left:0;padding-right:1em}.wp-block-quote:where(.has-text-align-center){border:none;padding-left:0}.wp-block-quote.is-large,.wp-block-quote.is-style-large,.wp-block-quote:where(.is-style-plain){border:none}.wp-block-search .wp-block-search__label{font-weight:700}.wp-block-search__button{border:1px solid #ccc;padding:.375em .625em}:where(.wp-block-group.has-background){padding:1.25em 2.375em}.wp-block-separator.has-css-opacity{opacity:.4}.wp-block-separator{border:none;border-bottom:2px solid;margin-left:auto;margin-right:auto}.wp-block-separator.has-alpha-channel-opacity{opacity:1}.wp-block-separator:not(.is-style-wide):not(.is-style-dots){width:100px}.wp-block-separator.has-background:not(.is-style-dots){border-bottom:none;height:1px}.wp-block-separator.has-background:not(.is-style-wide):not(.is-style-dots){height:2px}.wp-block-table{margin:0 0 1em}.wp-block-table td,.wp-block-table th{word-break:normal}.wp-block-table :where(figcaption){color:#555;font-size:13px;text-align:center}.is-dark-theme .wp-block-table :where(figcaption){color:#ffffffa6}.wp-block-video :where(figcaption){color:#555;font-size:13px;text-align:center}.is-dark-theme .wp-block-video :where(figcaption){color:#ffffffa6}.wp-block-video{margin:0 0 1em}:root :where(.wp-block-template-part.has-background){margin-bottom:0;margin-top:0;padding:1.25em 2.375em} </style> <style id='classic-theme-styles-inline-css'> /*! This file is auto-generated */ .wp-block-button__link{color:#fff;background-color:#32373c;border-radius:9999px;box-shadow:none;text-decoration:none;padding:calc(.667em + 2px) calc(1.333em + 2px);font-size:1.125em}.wp-block-file__button{background:#32373c;color:#fff;text-decoration:none} </style> <style id='global-styles-inline-css'> :root{--wp--preset--aspect-ratio--square: 1;--wp--preset--aspect-ratio--4-3: 4/3;--wp--preset--aspect-ratio--3-4: 3/4;--wp--preset--aspect-ratio--3-2: 3/2;--wp--preset--aspect-ratio--2-3: 2/3;--wp--preset--aspect-ratio--16-9: 16/9;--wp--preset--aspect-ratio--9-16: 9/16;--wp--preset--color--black: #000000;--wp--preset--color--cyan-bluish-gray: #abb8c3;--wp--preset--color--white: #fff;--wp--preset--color--pale-pink: #f78da7;--wp--preset--color--vivid-red: #cf2e2e;--wp--preset--color--luminous-vivid-orange: #ff6900;--wp--preset--color--luminous-vivid-amber: #fcb900;--wp--preset--color--light-green-cyan: #7bdcb5;--wp--preset--color--vivid-green-cyan: #00d084;--wp--preset--color--pale-cyan-blue: #8ed1fc;--wp--preset--color--vivid-cyan-blue: #0693e3;--wp--preset--color--vivid-purple: #9b51e0;--wp--preset--color--dark-gray: #111;--wp--preset--color--light-gray: #f1f1f1;--wp--preset--color--yellow: #f4ca16;--wp--preset--color--dark-brown: #352712;--wp--preset--color--medium-pink: #e53b51;--wp--preset--color--light-pink: #ffe5d1;--wp--preset--color--dark-purple: #2e2256;--wp--preset--color--purple: #674970;--wp--preset--color--blue-gray: #22313f;--wp--preset--color--bright-blue: #55c3dc;--wp--preset--color--light-blue: #e9f2f9;--wp--preset--gradient--vivid-cyan-blue-to-vivid-purple: linear-gradient(135deg,rgba(6,147,227,1) 0%,rgb(155,81,224) 100%);--wp--preset--gradient--light-green-cyan-to-vivid-green-cyan: linear-gradient(135deg,rgb(122,220,180) 0%,rgb(0,208,130) 100%);--wp--preset--gradient--luminous-vivid-amber-to-luminous-vivid-orange: linear-gradient(135deg,rgba(252,185,0,1) 0%,rgba(255,105,0,1) 100%);--wp--preset--gradient--luminous-vivid-orange-to-vivid-red: linear-gradient(135deg,rgba(255,105,0,1) 0%,rgb(207,46,46) 100%);--wp--preset--gradient--very-light-gray-to-cyan-bluish-gray: linear-gradient(135deg,rgb(238,238,238) 0%,rgb(169,184,195) 100%);--wp--preset--gradient--cool-to-warm-spectrum: linear-gradient(135deg,rgb(74,234,220) 0%,rgb(151,120,209) 20%,rgb(207,42,186) 40%,rgb(238,44,130) 60%,rgb(251,105,98) 80%,rgb(254,248,76) 100%);--wp--preset--gradient--blush-light-purple: linear-gradient(135deg,rgb(255,206,236) 0%,rgb(152,150,240) 100%);--wp--preset--gradient--blush-bordeaux: linear-gradient(135deg,rgb(254,205,165) 0%,rgb(254,45,45) 50%,rgb(107,0,62) 100%);--wp--preset--gradient--luminous-dusk: linear-gradient(135deg,rgb(255,203,112) 0%,rgb(199,81,192) 50%,rgb(65,88,208) 100%);--wp--preset--gradient--pale-ocean: linear-gradient(135deg,rgb(255,245,203) 0%,rgb(182,227,212) 50%,rgb(51,167,181) 100%);--wp--preset--gradient--electric-grass: linear-gradient(135deg,rgb(202,248,128) 0%,rgb(113,206,126) 100%);--wp--preset--gradient--midnight: linear-gradient(135deg,rgb(2,3,129) 0%,rgb(40,116,252) 100%);--wp--preset--gradient--dark-gray-gradient-gradient: linear-gradient(90deg, rgba(17,17,17,1) 0%, rgba(42,42,42,1) 100%);--wp--preset--gradient--light-gray-gradient: linear-gradient(90deg, rgba(241,241,241,1) 0%, rgba(215,215,215,1) 100%);--wp--preset--gradient--white-gradient: linear-gradient(90deg, rgba(255,255,255,1) 0%, rgba(230,230,230,1) 100%);--wp--preset--gradient--yellow-gradient: linear-gradient(90deg, rgba(244,202,22,1) 0%, rgba(205,168,10,1) 100%);--wp--preset--gradient--dark-brown-gradient: linear-gradient(90deg, rgba(53,39,18,1) 0%, rgba(91,67,31,1) 100%);--wp--preset--gradient--medium-pink-gradient: linear-gradient(90deg, rgba(229,59,81,1) 0%, rgba(209,28,51,1) 100%);--wp--preset--gradient--light-pink-gradient: linear-gradient(90deg, rgba(255,229,209,1) 0%, rgba(255,200,158,1) 100%);--wp--preset--gradient--dark-purple-gradient: linear-gradient(90deg, rgba(46,34,86,1) 0%, rgba(66,48,123,1) 100%);--wp--preset--gradient--purple-gradient: linear-gradient(90deg, rgba(103,73,112,1) 0%, rgba(131,93,143,1) 100%);--wp--preset--gradient--blue-gray-gradient: linear-gradient(90deg, rgba(34,49,63,1) 0%, rgba(52,75,96,1) 100%);--wp--preset--gradient--bright-blue-gradient: linear-gradient(90deg, rgba(85,195,220,1) 0%, rgba(43,180,211,1) 100%);--wp--preset--gradient--light-blue-gradient: linear-gradient(90deg, rgba(233,242,249,1) 0%, rgba(193,218,238,1) 100%);--wp--preset--font-size--small: 13px;--wp--preset--font-size--medium: 20px;--wp--preset--font-size--large: 36px;--wp--preset--font-size--x-large: 42px;--wp--preset--spacing--20: 0.44rem;--wp--preset--spacing--30: 0.67rem;--wp--preset--spacing--40: 1rem;--wp--preset--spacing--50: 1.5rem;--wp--preset--spacing--60: 2.25rem;--wp--preset--spacing--70: 3.38rem;--wp--preset--spacing--80: 5.06rem;--wp--preset--shadow--natural: 6px 6px 9px rgba(0, 0, 0, 0.2);--wp--preset--shadow--deep: 12px 12px 50px rgba(0, 0, 0, 0.4);--wp--preset--shadow--sharp: 6px 6px 0px rgba(0, 0, 0, 0.2);--wp--preset--shadow--outlined: 6px 6px 0px -3px rgba(255, 255, 255, 1), 6px 6px rgba(0, 0, 0, 1);--wp--preset--shadow--crisp: 6px 6px 0px rgba(0, 0, 0, 1);}:where(.is-layout-flex){gap: 0.5em;}:where(.is-layout-grid){gap: 0.5em;}body .is-layout-flex{display: flex;}.is-layout-flex{flex-wrap: wrap;align-items: center;}.is-layout-flex > :is(*, div){margin: 0;}body .is-layout-grid{display: grid;}.is-layout-grid > :is(*, div){margin: 0;}:where(.wp-block-columns.is-layout-flex){gap: 2em;}:where(.wp-block-columns.is-layout-grid){gap: 2em;}:where(.wp-block-post-template.is-layout-flex){gap: 1.25em;}:where(.wp-block-post-template.is-layout-grid){gap: 1.25em;}.has-black-color{color: var(--wp--preset--color--black) !important;}.has-cyan-bluish-gray-color{color: var(--wp--preset--color--cyan-bluish-gray) !important;}.has-white-color{color: var(--wp--preset--color--white) !important;}.has-pale-pink-color{color: var(--wp--preset--color--pale-pink) !important;}.has-vivid-red-color{color: var(--wp--preset--color--vivid-red) !important;}.has-luminous-vivid-orange-color{color: var(--wp--preset--color--luminous-vivid-orange) !important;}.has-luminous-vivid-amber-color{color: var(--wp--preset--color--luminous-vivid-amber) !important;}.has-light-green-cyan-color{color: var(--wp--preset--color--light-green-cyan) !important;}.has-vivid-green-cyan-color{color: var(--wp--preset--color--vivid-green-cyan) !important;}.has-pale-cyan-blue-color{color: var(--wp--preset--color--pale-cyan-blue) !important;}.has-vivid-cyan-blue-color{color: var(--wp--preset--color--vivid-cyan-blue) !important;}.has-vivid-purple-color{color: var(--wp--preset--color--vivid-purple) !important;}.has-black-background-color{background-color: var(--wp--preset--color--black) !important;}.has-cyan-bluish-gray-background-color{background-color: var(--wp--preset--color--cyan-bluish-gray) !important;}.has-white-background-color{background-color: var(--wp--preset--color--white) !important;}.has-pale-pink-background-color{background-color: var(--wp--preset--color--pale-pink) !important;}.has-vivid-red-background-color{background-color: var(--wp--preset--color--vivid-red) !important;}.has-luminous-vivid-orange-background-color{background-color: var(--wp--preset--color--luminous-vivid-orange) !important;}.has-luminous-vivid-amber-background-color{background-color: var(--wp--preset--color--luminous-vivid-amber) !important;}.has-light-green-cyan-background-color{background-color: var(--wp--preset--color--light-green-cyan) !important;}.has-vivid-green-cyan-background-color{background-color: var(--wp--preset--color--vivid-green-cyan) !important;}.has-pale-cyan-blue-background-color{background-color: var(--wp--preset--color--pale-cyan-blue) !important;}.has-vivid-cyan-blue-background-color{background-color: var(--wp--preset--color--vivid-cyan-blue) !important;}.has-vivid-purple-background-color{background-color: var(--wp--preset--color--vivid-purple) !important;}.has-black-border-color{border-color: var(--wp--preset--color--black) !important;}.has-cyan-bluish-gray-border-color{border-color: var(--wp--preset--color--cyan-bluish-gray) !important;}.has-white-border-color{border-color: var(--wp--preset--color--white) !important;}.has-pale-pink-border-color{border-color: var(--wp--preset--color--pale-pink) !important;}.has-vivid-red-border-color{border-color: var(--wp--preset--color--vivid-red) !important;}.has-luminous-vivid-orange-border-color{border-color: var(--wp--preset--color--luminous-vivid-orange) !important;}.has-luminous-vivid-amber-border-color{border-color: var(--wp--preset--color--luminous-vivid-amber) !important;}.has-light-green-cyan-border-color{border-color: var(--wp--preset--color--light-green-cyan) !important;}.has-vivid-green-cyan-border-color{border-color: var(--wp--preset--color--vivid-green-cyan) !important;}.has-pale-cyan-blue-border-color{border-color: var(--wp--preset--color--pale-cyan-blue) !important;}.has-vivid-cyan-blue-border-color{border-color: var(--wp--preset--color--vivid-cyan-blue) !important;}.has-vivid-purple-border-color{border-color: var(--wp--preset--color--vivid-purple) !important;}.has-vivid-cyan-blue-to-vivid-purple-gradient-background{background: var(--wp--preset--gradient--vivid-cyan-blue-to-vivid-purple) !important;}.has-light-green-cyan-to-vivid-green-cyan-gradient-background{background: var(--wp--preset--gradient--light-green-cyan-to-vivid-green-cyan) !important;}.has-luminous-vivid-amber-to-luminous-vivid-orange-gradient-background{background: var(--wp--preset--gradient--luminous-vivid-amber-to-luminous-vivid-orange) !important;}.has-luminous-vivid-orange-to-vivid-red-gradient-background{background: var(--wp--preset--gradient--luminous-vivid-orange-to-vivid-red) !important;}.has-very-light-gray-to-cyan-bluish-gray-gradient-background{background: var(--wp--preset--gradient--very-light-gray-to-cyan-bluish-gray) !important;}.has-cool-to-warm-spectrum-gradient-background{background: var(--wp--preset--gradient--cool-to-warm-spectrum) !important;}.has-blush-light-purple-gradient-background{background: var(--wp--preset--gradient--blush-light-purple) !important;}.has-blush-bordeaux-gradient-background{background: var(--wp--preset--gradient--blush-bordeaux) !important;}.has-luminous-dusk-gradient-background{background: var(--wp--preset--gradient--luminous-dusk) !important;}.has-pale-ocean-gradient-background{background: var(--wp--preset--gradient--pale-ocean) !important;}.has-electric-grass-gradient-background{background: var(--wp--preset--gradient--electric-grass) !important;}.has-midnight-gradient-background{background: var(--wp--preset--gradient--midnight) !important;}.has-small-font-size{font-size: var(--wp--preset--font-size--small) !important;}.has-medium-font-size{font-size: var(--wp--preset--font-size--medium) !important;}.has-large-font-size{font-size: var(--wp--preset--font-size--large) !important;}.has-x-large-font-size{font-size: var(--wp--preset--font-size--x-large) !important;} :where(.wp-block-post-template.is-layout-flex){gap: 1.25em;}:where(.wp-block-post-template.is-layout-grid){gap: 1.25em;} :where(.wp-block-columns.is-layout-flex){gap: 2em;}:where(.wp-block-columns.is-layout-grid){gap: 2em;} :root :where(.wp-block-pullquote){font-size: 1.5em;line-height: 1.6;} </style> <link rel='stylesheet' id='twentyfifteen-fonts-css' href='https://blogs.coreboot.org/wp-content/themes/twentyfifteen/assets/fonts/noto-sans-plus-noto-serif-plus-inconsolata.css?ver=20230328' media='all' /> <link rel='stylesheet' id='genericons-css' href='https://blogs.coreboot.org/wp-content/themes/twentyfifteen/genericons/genericons.css?ver=20201026' media='all' /> <link rel='stylesheet' id='twentyfifteen-style-css' href='https://blogs.coreboot.org/wp-content/themes/twentyfifteen-child/style.css?ver=20240716' media='all' /> <link rel='stylesheet' id='twentyfifteen-block-style-css' href='https://blogs.coreboot.org/wp-content/themes/twentyfifteen/css/blocks.css?ver=20240609' media='all' /> <script src="https://blogs.coreboot.org/wp-includes/js/jquery/jquery.min.js?ver=3.7.1" id="jquery-core-js"></script> <script src="https://blogs.coreboot.org/wp-includes/js/jquery/jquery-migrate.min.js?ver=3.4.1" id="jquery-migrate-js"></script> <script id="twentyfifteen-script-js-extra"> var screenReaderText = {"expand":"<span class=\"screen-reader-text\">expand child menu<\/span>","collapse":"<span class=\"screen-reader-text\">collapse child menu<\/span>"}; </script> <script src="https://blogs.coreboot.org/wp-content/themes/twentyfifteen/js/functions.js?ver=20221101" id="twentyfifteen-script-js" defer data-wp-strategy="defer"></script> <link rel="https://api.w.org/" href="https://blogs.coreboot.org/wp-json/" /><link rel="alternate" title="JSON" type="application/json" href="https://blogs.coreboot.org/wp-json/wp/v2/tags/4223" /><link rel="EditURI" type="application/rsd+xml" title="RSD" href="https://blogs.coreboot.org/xmlrpc.php?rsd" /> <meta name="generator" content="WordPress 6.7.1" />  <meta property="og:site_name" content="coreboot" /> <meta property="og:title" content="coreboot" /> <meta property="og:url" content="https://blogs.coreboot.org" /> <meta property="og:description" content="News from coreboot world" /> <meta property="og:type" content="website" /> <meta property="og:locale" content="en_us" />   <meta itemprop="name" content="coreboot" /> <meta itemprop="description" content="News from coreboot world" /> <meta itemprop="type" content="Article" />  </head> <body class="archive tag tag-asan tag-4223 wp-embed-responsive"> <div id="page" class="hfeed site"> <a class="skip-link screen-reader-text" href="#content">Skip to content</a> <div id="sidebar" class="sidebar"> <header id="masthead" class="site-header" role="banner"> <div class="site-branding"> <p class="site-title"><a href="https://blogs.coreboot.org/" rel="home"><img src="https://blogs.coreboot.org/files/2014/10/Coreboot_full_web.png" alt="coreboot" /></a></p> <p class="site-description">News from coreboot world</p> <button class="secondary-toggle">Menu and widgets</button> </div> </header> <div id="secondary" class="secondary"> <div id="widget-area" class="widget-area" role="complementary"> <aside id="search-3" class="widget widget_search"><form role="search" method="get" class="search-form" action="https://blogs.coreboot.org/"> <label> <span class="screen-reader-text">Search for:</span> <input type="search" class="search-field" placeholder="Search …" value="" name="s" /> </label> <input type="submit" class="search-submit screen-reader-text" value="Search" /> </form></aside> <aside id="recent-posts-3" class="widget widget_recent_entries"> <h2 class="widget-title">Recent Posts</h2><nav aria-label="Recent Posts"> <ul> <li> <a href="https://blogs.coreboot.org/blog/2024/10/29/response-to-blog-post-from-malibal/">Response to blog post from MALIBAL</a> </li> <li> <a href="https://blogs.coreboot.org/blog/2024/09/02/coreboot-24-08-release/">coreboot 24.08 release</a> </li> <li> <a href="https://blogs.coreboot.org/blog/2024/05/23/coreboot-24-05-release/">coreboot 24.05 release</a> </li> <li> <a href="https://blogs.coreboot.org/blog/2024/03/01/coreboot-24-02-and-24-02-1-released/">coreboot 24.02 and 24.02.1 released!</a> </li> <li> <a href="https://blogs.coreboot.org/blog/2023/11/28/coreboot-4-22-4-22-01-have-been-released/">coreboot 4.22 & 4.22.01 have been released</a> </li> </ul> </nav></aside><aside id="linkcat-2" class="widget widget_links"><h2 class="widget-title">Blogroll</h2> <ul class='xoxo blogroll'> <li><a href="https://9esec.io/blog/" title="Security meets usability">9elements Cyber Security</a></li> <li><a href="https://blog.3mdeb.com/tags/coreboot/" title="Recent content in coreboot on Thoughts dereferenced from the scratchpad noise.">coreboot on Thoughts dereferenced from the scratchpad noise.</a></li> <li><a href="http://firmwaresecurity.com/" title="a blog focused on hardware/firmware security news/info for BIOS, UEFI, and Coreboot, on Linux, Android, FreeBSD, Chrome, and other OSes.">FIRMWARESECURITY</a></li> <li><a href="http://biosengineer.blogspot.com/">Harrison Hsieh's BIOS blog</a></li> <li><a href="https://libreboot.org/news" title="News for libreboot.org">News for libreboot.org</a></li> <li><a href="https://blog.osfw.foundation/">Open Source Firmware Foundation</a></li> <li><a href="http://bioshacking.blogspot.com/">The BIOS Blog</a></li> <li><a href="http://uefi.blogspot.com/">UEFI BLOG by Tim Lewis</a></li> <li><a href="http://vzimmer.blogspot.com/">Vincent Zimmer's blog</a></li> </ul> </aside> <aside id="tag_cloud-2" class="widget widget_tag_cloud"><h2 class="widget-title">Tags</h2><nav aria-label="Tags"><div class="tagcloud"><ul class='wp-tag-cloud' role='list'> <li><a href="https://blogs.coreboot.org/blog/tag/amd/" class="tag-cloud-link tag-link-15 tag-link-position-1" style="font-size: 8pt;" aria-label="AMD (1 item)">AMD</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/arm/" class="tag-cloud-link tag-link-4196 tag-link-position-2" style="font-size: 13.167785234899pt;" aria-label="ARM (6 items)">ARM</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/asan/" class="tag-cloud-link tag-link-4223 tag-link-position-3" style="font-size: 11.758389261745pt;" aria-label="ASan (4 items)">ASan</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/bios/" class="tag-cloud-link tag-link-4195 tag-link-position-4" style="font-size: 14.107382550336pt;" aria-label="BIOS (8 items)">BIOS</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/coreboot/" class="tag-cloud-link tag-link-4191 tag-link-position-5" style="font-size: 16.456375838926pt;" aria-label="coreboot (15 items)">coreboot</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/coreboot-release/" class="tag-cloud-link tag-link-4230 tag-link-position-6" style="font-size: 8pt;" aria-label="coreboot release (1 item)">coreboot release</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/ec/" class="tag-cloud-link tag-link-4182 tag-link-position-7" style="font-size: 13.167785234899pt;" aria-label="ec (6 items)">ec</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/filo/" class="tag-cloud-link tag-link-4190 tag-link-position-8" style="font-size: 8pt;" aria-label="FILO (1 item)">FILO</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/flashrom/" class="tag-cloud-link tag-link-4189 tag-link-position-9" style="font-size: 15.986577181208pt;" aria-label="flashrom (13 items)">flashrom</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/git/" class="tag-cloud-link tag-link-128 tag-link-position-10" style="font-size: 9.6912751677852pt;" aria-label="git (2 items)">git</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/gsoc/" class="tag-cloud-link tag-link-4194 tag-link-position-11" style="font-size: 22pt;" aria-label="GSoC (60 items)">GSoC</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/gsoc-2013/" class="tag-cloud-link tag-link-4176 tag-link-position-12" style="font-size: 12.510067114094pt;" aria-label="GSoC 2013 (5 items)">GSoC 2013</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/gsoc2015/" class="tag-cloud-link tag-link-4180 tag-link-position-13" style="font-size: 13.167785234899pt;" aria-label="GSoC2015 (6 items)">GSoC2015</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/gsoc-2015/" class="tag-cloud-link tag-link-4178 tag-link-position-14" style="font-size: 8pt;" aria-label="GSOC 2015 (1 item)">GSOC 2015</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/gsoc-2016/" class="tag-cloud-link tag-link-4198 tag-link-position-15" style="font-size: 15.610738255034pt;" aria-label="GSoC 2016 (12 items)">GSoC 2016</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/gsoc-2019/" class="tag-cloud-link tag-link-4220 tag-link-position-16" style="font-size: 17.771812080537pt;" aria-label="GSoC 2019 (21 items)">GSoC 2019</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/gsoc-2020/" class="tag-cloud-link tag-link-4222 tag-link-position-17" style="font-size: 11.758389261745pt;" aria-label="GSoC 2020 (4 items)">GSoC 2020</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/gsoc-2022/" class="tag-cloud-link tag-link-4232 tag-link-position-18" style="font-size: 8pt;" aria-label="GSoC 2022 (1 item)">GSoC 2022</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/gsoc-update/" class="tag-cloud-link tag-link-4171 tag-link-position-19" style="font-size: 13.167785234899pt;" aria-label="GSoC Update (6 items)">GSoC Update</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/h8s/" class="tag-cloud-link tag-link-4181 tag-link-position-20" style="font-size: 13.167785234899pt;" aria-label="h8s (6 items)">h8s</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/kasan/" class="tag-cloud-link tag-link-4221 tag-link-position-21" style="font-size: 8pt;" aria-label="KASAN (1 item)">KASAN</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/libgfxinit/" class="tag-cloud-link tag-link-4224 tag-link-position-22" style="font-size: 8pt;" aria-label="libgfxinit (1 item)">libgfxinit</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/network-console/" class="tag-cloud-link tag-link-278 tag-link-position-23" style="font-size: 8pt;" aria-label="network console (1 item)">network console</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/openembedded/" class="tag-cloud-link tag-link-4173 tag-link-position-24" style="font-size: 8pt;" aria-label="openembedded (1 item)">openembedded</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/payload/" class="tag-cloud-link tag-link-4175 tag-link-position-25" style="font-size: 8pt;" aria-label="payload (1 item)">payload</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/pmh4/" class="tag-cloud-link tag-link-4184 tag-link-position-26" style="font-size: 8pt;" aria-label="pmh4 (1 item)">pmh4</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/pmh7/" class="tag-cloud-link tag-link-4185 tag-link-position-27" style="font-size: 8pt;" aria-label="pmh7 (1 item)">pmh7</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/rayer-spipgm/" class="tag-cloud-link tag-link-4167 tag-link-position-28" style="font-size: 8pt;" aria-label="RayeR SPIPGM (1 item)">RayeR SPIPGM</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/reproducible/" class="tag-cloud-link tag-link-4183 tag-link-position-29" style="font-size: 8pt;" aria-label="reproducible (1 item)">reproducible</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/risc-v/" class="tag-cloud-link tag-link-4199 tag-link-position-30" style="font-size: 13.637583892617pt;" aria-label="RISC-V (7 items)">RISC-V</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/serialice/" class="tag-cloud-link tag-link-4200 tag-link-position-31" style="font-size: 9.6912751677852pt;" aria-label="SerialICE (2 items)">SerialICE</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/spice/" class="tag-cloud-link tag-link-4174 tag-link-position-32" style="font-size: 8pt;" aria-label="spice (1 item)">spice</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/subversion/" class="tag-cloud-link tag-link-4170 tag-link-position-33" style="font-size: 8pt;" aria-label="subversion (1 item)">subversion</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/svn/" class="tag-cloud-link tag-link-4169 tag-link-position-34" style="font-size: 8pt;" aria-label="svn (1 item)">svn</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/thinker/" class="tag-cloud-link tag-link-4186 tag-link-position-35" style="font-size: 8pt;" aria-label="thinker (1 item)">thinker</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/u-boot/" class="tag-cloud-link tag-link-4172 tag-link-position-36" style="font-size: 8pt;" aria-label="U-boot (1 item)">U-boot</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/uefi/" class="tag-cloud-link tag-link-4188 tag-link-position-37" style="font-size: 9.6912751677852pt;" aria-label="UEFI (2 items)">UEFI</a></li> <li><a href="https://blogs.coreboot.org/blog/tag/usb/" class="tag-cloud-link tag-link-16 tag-link-position-38" style="font-size: 8pt;" aria-label="USB (1 item)">USB</a></li> </ul> </div> </nav></aside> </div> </div> </div> <div id="content" class="site-content"> <section id="primary" class="content-area"> <main id="main" class="site-main"> <header class="page-header"> <h1 class="page-title">Tag: <span>ASan</span></h1> </header> <article id="post-5108" class="post-5108 post type-post status-publish format-standard hentry category-coreboot category-gsoc tag-asan tag-gsoc tag-gsoc-2020"> <header class="entry-header"> <h2 class="entry-title"><a href="https://blogs.coreboot.org/blog/2020/08/31/gsoc-address-sanitizer-wrap-up/" rel="bookmark">[GSoC] Address Sanitizer, Wrap-up</a></h2> </header> <div class="entry-content"> <p>Hello everyone. The coding period for GSoC 2020 is now officially over and it’s time for the final evaluation. I’ll use this blog post to summarize the project details, illustrate the instructions to use ASan, and discuss some ideas on what can be done further to enhance this feature.</p> <p>You can find the complete list of commits I made during GSoC with <a href="https://review.coreboot.org/q/topic:%2522ASan%2522+status:merged+author:harshitsharmajs%2540gmail.com" target="_blank" rel="noreferrer noopener">this Gerrit query</a>.</p> <hr class="wp-block-separator" /> <h2 class="wp-block-heading">Project details</h2> <p>Memory safety is hard to achieve. We, as humans, are bound to make mistakes in our code. While it may be straightforward to detect memory corruption bugs in few lines of code, it becomes quite challenging to find those bugs in a massive code. In such cases, ‘Address Sanitizer’ may prove to be useful and could help save time.</p> <p>Address Sanitizer, also known as ASan, is a runtime memory debugger designed to find out-of-bounds accesses and use-after-scope bugs. Over the past couple of weeks, I’ve been working to add support for ASan to coreboot. You can read my previous blog posts (<a rel="noreferrer noopener" href="https://blogs.coreboot.org/blog/2020/07/16/gsoc-address-sanitizer-part-1/" target="_blank">Part 1</a>, <a rel="noreferrer noopener" href="https://blogs.coreboot.org/blog/2020/08/17/gsoc-address-sanitizer-part-2/" target="_blank">Part 2</a>, and <a rel="noreferrer noopener" href="https://blogs.coreboot.org/blog/2020/08/29/gsoc-address-sanitizer-part-3/" target="_blank">Part 3</a>) to see my progress throughout the summer.</p> <p>Here is a description of the components included in the project:</p> <h4 class="wp-block-heading">GCC patch</h4> <p>The design of ASan in coreboot is based on its implementation in Linux kernel, also known as Kernel Address Sanitizer (KASAN). However, we can鈥檛 directly port the code from Linux.</p> <p>Unlike the Linux kernel which has a static shadow region layout, we have multiple stages in coreboot and thus require a different shadow offset address. Unfortunately, GCC currently only supports adding a static shadow offset at compile time using <code>-fasan-shadow-offset</code> flag. Therefore the foremost task was to add support for dynamic shadow offset to GCC.</p> <p>We enabled GCC to determine the shadow offset address at runtime using a callback function named <code>__asan_shadow_offset</code>. This supersedes the need to specify this address at compile time. GCC then makes use of this shadow offset in its internal <code>mem_to_shadow</code> translation function to poison stack variables’ redzones.</p> <p>The patch further allowed us to place the shadow region in a separate linker section. This ensured if a platform didn’t have enough memory space to hold the shadow buffer, the build would fail. </p> <p>The way the patch was introduced to GCC’s code base ensures that if<br />one compiles a piece of code with the new switch enabled i.e. <code>--param asan-use-shadow-offset-callback=1</code> but has not applied the patch itself to GCC, the compiler will throw the following error because the newly introduced switch is unknown for an out of box GCC: <code>invalid --param name 'asan-use-shadow-offset-callback</code>‘.</p> <p>I believe this patch might also be useful to the developers who contribute to other open-source projects. Hence, I’ve put this patch on <a href="https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550176.html">GCC’s </a><a rel="noreferrer noopener" href="https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550176.html" target="_blank">mailing</a><a href="https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550176.html"> list</a> and asked GCC’s developers to include this feature in their upcoming release.</p> <h4 class="wp-block-heading">ASan in ramstage</h4> <p>Since ramstage uses DRAM, regardless of the platform, it should always have enough room in the memory to hold the shadow buffer. Therefore, I began by adding support for ASan in ramstage on x86 architecture.</p> <p>To reserve space in memory for the shadow region, I created a separate linker section and named it <code>asan_shadow</code>. Here, instead of allocating shadow memory for the whole memory region which includes drivers and hardware mapped addresses, I only defined shadow region for the data and heap sections.</p> <p>Then I started porting KASAN library functions, tweaking them to make them suitable for coreboot.</p> <p>The next task was to initialize the shadow memory at runtime. I created a function called <code>asan_init</code> which unpoisons i.e. sets the shadow memory corresponding to the addresses in the data and heap sections to zero.</p> <p>In the case of global variables, instead of poisoning the redzones directly, the compiler inserts constructors invoking the library function named<code> __asan_register_globals</code> to populate the relevant shadow memory regions. So, I wrote a function named <code>asan_ctors</code> which calls these constructors at runtime and added a call to this function to <code>asan_init()</code>.</p> <p>After doing some tests, I realized that compiler’s ASan instrumentation cannot insert <code>asan_load</code> or <code>asan_store</code> state checks in the memory functions like <code>memset</code>, <code>memmove</code> and <code>memcpy</code> as they are written in assembly. So, I added manual checks using the library function named <code>check_memory_region</code> for both source and destination pointers.</p> <h4 class="wp-block-heading">ASan in romstage</h4> <p>Once I had ASan in ramstage working as expected, I started adding support for ASan to romstage. </p> <p>It was challenging because of two reasons. First, even within the same architecture, the size of L1 cache varies across the platforms from 32KB in <em>Braswell</em> to 80KB in <em>Ice Lake</em> and thus we can’t enable ASan in romstage for all platforms by doing tests on a handful of devices. Second, the size of a cache is very small compared to RAM making it difficult to fit <code>asan_shadow</code> section in the limited memory.</p> <p>Thankfully, the latter issue, to a large extent, was solved by our GCC patch which allowed us to append <code>asan_shadow</code> section to the region already occupied by the coreboot program and make efficient use of limited memory.</p> <p>Now to resolve the first issue, I introduced a Kconfig option called <code>HAVE_ASAN_IN_ROMSTAGE</code> to denote if a particular platform supports ASan in romstage. This allowed us to enable ASan in romstage only for the platforms which have been tested. </p> <p>Based on the hardware available with me and my mentor, I enabled ASan in romstage for <em>Haswell </em>and <em>Apollo Lake</em> platforms, apart from <em>QEMU</em>.</p> <hr class="wp-block-separator" /> <h2 class="wp-block-heading">Project usage</h2> <p>Instructions for how to use ASan are included in <a href="https://doc.coreboot.org/technotes/asan.html" target="_blank" rel="noreferrer noopener">ASan documentation</a>. I’ll restate them with an example here.</p> <p>Suppose there is a stack-out-of-bounds error in <code>cbfs.c</code> that we aren’t aware of. Let’s see if ASan can help us detect it.</p> <pre class="wp-block-code"><code>int cbfs_boot_region_device(struct region_device *rdev) { int stack_array[5], i; boot_device_init(); for (i = 10; i > 0; i--) stack_array[i] = i; return vboot_locate_cbfs(rdev) && fmap_locate_area_as_rdev("COREBOOT", rdev); }</code></pre> <p>First, we have to enable ASan from the configuration menu. Just select <code>Address sanitizer support</code> from <code>General setup</code> menu. Now, build coreboot and run the image.</p> <p>ASan will report the following error in the console log:</p> <pre class="wp-block-code"><code>ASan: stack-out-of-bounds in 0x7f7432fd Write of 4 bytes at addr 0x7f7c2ac8</code></pre> <p>Here <code>0x7f7432fd</code> is the address of the last good instruction before the bad access. In coreboot, stages are relocated. So, we have to normalize this address to find the instruction which causes this error. </p> <p>For this, let’s subtract the start address of the stage i.e. <code>0x7f72c000</code>. The difference we get is <code>0x000172fd</code>. As per our console log, this error happened in the ramstage. So, let’s look at the sections headers of ramstage from <code>ramstage.debug</code>.</p> <pre class="wp-block-code"><code> $ objdump -h build/cbfs/fallback/ramstage.debug build/cbfs/fallback/ramstage.debug: file format elf32-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 00070b20 00e00000 00e00000 00001000 2**12 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 1 .ctors 0000036c 00e70b20 00e70b20 00071b20 2**2 CONTENTS, ALLOC, LOAD, RELOC, DATA 2 .data 0001c8f4 00e70e8c 00e70e8c 00071e8c 2**2 CONTENTS, ALLOC, LOAD, RELOC, DATA 3 .bss 00012940 00e8d780 00e8d780 0008e780 2**7 ALLOC 4 .heap 00004000 00ea00c0 00ea00c0 0008e780 2**0 ALLOC</code></pre> <p>Here the offset of the text segment is <code>0x00e00000</code>. Let’s add this offset to the difference we calculated earlier. The resultant address is <code>0x00e172fd</code>.</p> <p>Next, we read the contents of the symbol table and search for a function having an address closest to<code> 0x00e172fd</code>.</p> <pre class="wp-block-code"><code> $ nm -n build/cbfs/fallback/ramstage.debug ........ ........ 00e17116 t _GLOBAL__sub_I_65535_1_gfx_get_init_done 00e17129 t tohex16 00e171db T cbfs_load_and_decompress 00e1729b T cbfs_boot_region_device 00e17387 T cbfs_boot_locate 00e1740d T cbfs_boot_map_with_leak 00e174ef T cbfs_boot_map_optionrom ........</code></pre> <p>The symbol having an address closest to <code>0x00e172fd</code> is <code>cbfs_boot_region_device</code> and its address is <code>0x00e1729b</code>. This is the function in which our memory bug is present.</p> <p>Now, as we know the affected function, we read the assembly contents of <code>cbfs_boot_region_device</code> which is present in <code>cbfs.o</code> to find the faulty instruction. </p> <pre class="wp-block-code"><code> $ objdump -d build/ramstage/lib/cbfs.o ........ ........ 51: e8 fc ff ff ff call 52 <cbfs_boot_region_device+0x52> 56: 83 ec 0c sub $0xc,%esp 59: 57 push %edi 5a: 83 ef 04 sub $0x4,%edi 5d: e8 fc ff ff ff call 5e <cbfs_boot_region_device+0x5e> 62: 83 c4 10 add $0x10,%esp 65: 89 5f 04 mov %ebx,0x4(%edi) 68: 4b dec %ebx 69: 75 eb jne 56 <cbfs_boot_region_device+0x56> ........</code></pre> <p>Let’s look for the last good instruction before the error happens. It would be the one present at the offset 62 (<code>0x00e172fd</code> – <code>0x00e1729b</code>). </p> <p>The instruction is <code>add $0x10,%esp</code> and it corresponds to <code>for (i = 10; i > 0; i--)</code> in our code. It means the very next instruction i.e. <code>mov %ebx,0x4(%edi)</code> is the one that causes the error. Now, if you look at C code of <code>cbfs_boot_region_device()</code> again, you’ll find that this instruction corresponds to <code>stack_array[i] = i</code>. </p> <p>Voil脿! we just caught the memory bug using ASan.</p> <hr class="wp-block-separator" /> <h2 class="wp-block-heading">Future work</h2> <p>While my work for GSoC 2020 is complete, I think the following extensions would be useful for this project:</p> <h4 class="wp-block-heading">Heap buffer overflow</h4> <p>Presently, ASan doesn’t detect out-of-bounds accesses for the objects defined in heap. Fortunately, the support for these types of memory bugs can be added easily. </p> <p>We just have to make sure that whenever some block of memory is allocated in the heap, the surrounding areas (redzones) are poisoned. Correspondingly, these redzones should be unpoisoned when the memory block is de-allocated.</p> <h4 class="wp-block-heading">Post-processing script</h4> <p>Unlike Linux, coreboot doesn’t have <code>%pS</code> printk format to dereference a pointer to its symbolic name. Therefore, we normalize the pointer address manually as I showed above to determine the name of the affected function and further use it to find the instruction which causes the error. </p> <p>A custom script can be written to automate this process.</p> <h4 class="wp-block-heading">Support for other platforms and architectures</h4> <p>Jenkins builder built successfully for all x86 boards except for the ones that hold either <em>Braswell</em> SoC or <em>i440bx</em> northbridge where the cache area got full and thus couldn鈥檛 fit the <code>asan_shadow</code> section. It shows that support for ASan in romstage can be easily added to most x86 platforms. We just have to test them by selecting <code>HAVE_ASAN_IN_ROMSTAGE</code> option and resolve the compilation errors if any.</p> <p>Enabling ASan in ramstage on other architectures like ARM or RISC-V should be easy too. We just have to make sure the shadow memory is initialized as early as possible when ramstage is loaded. This can be done by making a function call to <code>asan_init()</code> at the appropriate place. </p> <p>Similarly, ASan in romstage can be enabled for other architectures. I have mentioned some key points in ASan documentation which could be used by someone who might be interested in doing so.</p> <p>For the platforms that don’t have enough space in the cache to hold the <code>asan_shadow</code> section, we have to come up with a new translation function that uses a much compact shadow memory. Since the stack buffers are protected by the compiler, we’ll also have to create another GCC patch forcing it to use the new translation function for this particular platform.</p> <hr class="wp-block-separator" /> <h2 class="wp-block-heading">Acknowledgement</h2> <p>I’d like to thank my mentor <em>Werner Zeh</em> for his continued assistance during the past 13 weeks. This project certainly wouldn’t have been possible without his valuable suggestions and the knowledge he shared. I’d also like to thank <em>Patrick Georgi</em> for helping me with the work authorization initially and later supervising my work during the time when <em>Werner</em> was on vacation.</p> <p>Further, I am grateful to every member of the community for assisting me whenever I got stuck, reviewing my code, reading my blogs, and sharing their feedback.</p> <hr class="wp-block-separator" /> <p>It has been an amazing journey and I look forward to contributing to coreboot in the future.</p> </div> <footer class="entry-footer"> <span class="posted-on"><span class="screen-reader-text">Posted on </span><a href="https://blogs.coreboot.org/blog/2020/08/31/gsoc-address-sanitizer-wrap-up/" rel="bookmark"><time class="entry-date published" datetime="2020-08-31T07:19:33+00:00">August 31, 2020</time><time class="updated" datetime="2020-09-22T05:37:47+00:00">September 22, 2020</time></a></span><span class="byline"><span class="author vcard"><span class="screen-reader-text">Author </span><a class="url fn n" href="https://blogs.coreboot.org/blog/author/harshitsharma/">harshitsharma</a></span></span><span class="cat-links"><span class="screen-reader-text">Categories </span><a href="https://blogs.coreboot.org/blog/category/coreboot/" rel="category tag">coreboot</a>, <a href="https://blogs.coreboot.org/blog/category/gsoc/" rel="category tag">GSoC</a></span><span class="tags-links"><span class="screen-reader-text">Tags </span><a href="https://blogs.coreboot.org/blog/tag/asan/" rel="tag">ASan</a>, <a href="https://blogs.coreboot.org/blog/tag/gsoc/" rel="tag">GSoC</a>, <a href="https://blogs.coreboot.org/blog/tag/gsoc-2020/" rel="tag">GSoC 2020</a></span> </footer> </article> <article id="post-5109" class="post-5109 post type-post status-publish format-standard hentry category-coreboot category-gsoc tag-asan tag-gsoc tag-gsoc-2020"> <header class="entry-header"> <h2 class="entry-title"><a href="https://blogs.coreboot.org/blog/2020/08/29/gsoc-address-sanitizer-part-3/" rel="bookmark">[GSoC] Address Sanitizer, Part 3</a></h2> </header> <div class="entry-content"> <p>Hello again! The third and final phase of GSoC is coming to an end and I’m glad that I made it this far. In this blog post, I’d like to outline the work done in the last two weeks.</p> <hr class="wp-block-separator" /> <h4 class="wp-block-heading">Memory functions</h4> <p>Compiler’s ASan instrumentation cannot insert <code>asan_load</code> or <code>asan_store</code> memory checks in the memory functions like <code>memset</code>, <code>memmove</code> and <code>memcpy</code>. This is because these functions are written in assembly.</p> <p>While Linux kernel replaces these functions with their variants which are written in C, I took a different approach. </p> <p>In coreboot, the assembly instructions for these memory functions are embedded into C code using GNU’s <code>asm</code> extension. This provided me with an opportunity to use the ASan library function named <code>check_memory_region</code> to manually check the memory state before performing each of these operations. At the start of each function, I added the following code snippet:</p> <pre class="wp-block-code"><code>#if (ENV_ROMSTAGE && CONFIG(ASAN_IN_ROMSTAGE)) || (ENV_RAMSTAGE && CONFIG(ASAN_IN_RAMSTAGE)) check_memory_region((unsigned long)src, n, false, _RET_IP_); check_memory_region((unsigned long)dest, n, true, _RET_IP_); #endif</code></pre> <p>This way neither I had to fiddle with the assembly instructions nor I had to replace these functions with their C variants which might have caused some performance issues. [<a rel="noreferrer noopener" href="44307" target="_blank">CB:</a><a rel="noreferrer noopener" href="https://review.coreboot.org/c/coreboot/+/44307" target="_blank">44307</a>]</p> <hr class="wp-block-separator" /> <h4 class="wp-block-heading">Documentation</h4> <p>Since I finished a little early with what I had proposed to deliver, Werner suggested that I should write documentation on ASan and I am happy that he did. When I read the intro of the <a rel="noreferrer noopener" href="https://doc.coreboot.org/getting_started/writing_documentation.html" target="_blank">documentation</a><a href="https://doc.coreboot.org/getting_started/writing_documentation.html"> guidelines</a>, I realized how a feature as significant as ASan might go unnoticed and unused by many if it lacks proper documentation.</p> <p>In ASan documentation, I have tried my best to answer questions like how to use ASan, what kind of bugs can be detected, what devices are currently supported, and how ASan support can be added to other architectures like ARM or RISC-V. </p> <p>The documentation is not final yet and I’d really appreciate inputs from the community. So, please give it a read and share your feedback. [<a href="https://review.coreboot.org/c/coreboot/+/44814">CB:</a><a rel="noreferrer noopener" href="https://review.coreboot.org/c/coreboot/+/44814" target="_blank">44814</a>]</p> <hr class="wp-block-separator" /> <p>In the end, I’d like to announce that ASan patches have been merged into the coreboot source tree. You can go ahead and make use of this debugging tool to look for memory corruption bugs in your code.</p> <p>[<a href="https://review.coreboot.org/q/topic:%2522ASan%2522+status:merged+author:harshit" target="_blank" rel="noreferrer noopener">ASan patches</a>]</p> </div> <footer class="entry-footer"> <span class="posted-on"><span class="screen-reader-text">Posted on </span><a href="https://blogs.coreboot.org/blog/2020/08/29/gsoc-address-sanitizer-part-3/" rel="bookmark"><time class="entry-date published" datetime="2020-08-29T07:08:06+00:00">August 29, 2020</time><time class="updated" datetime="2020-08-29T07:09:05+00:00">August 29, 2020</time></a></span><span class="byline"><span class="author vcard"><span class="screen-reader-text">Author </span><a class="url fn n" href="https://blogs.coreboot.org/blog/author/harshitsharma/">harshitsharma</a></span></span><span class="cat-links"><span class="screen-reader-text">Categories </span><a href="https://blogs.coreboot.org/blog/category/coreboot/" rel="category tag">coreboot</a>, <a href="https://blogs.coreboot.org/blog/category/gsoc/" rel="category tag">GSoC</a></span><span class="tags-links"><span class="screen-reader-text">Tags </span><a href="https://blogs.coreboot.org/blog/tag/asan/" rel="tag">ASan</a>, <a href="https://blogs.coreboot.org/blog/tag/gsoc/" rel="tag">GSoC</a>, <a href="https://blogs.coreboot.org/blog/tag/gsoc-2020/" rel="tag">GSoC 2020</a></span> </footer> </article> <article id="post-5040" class="post-5040 post type-post status-publish format-standard hentry category-coreboot category-gsoc tag-asan tag-gsoc tag-gsoc-2020"> <header class="entry-header"> <h2 class="entry-title"><a href="https://blogs.coreboot.org/blog/2020/08/17/gsoc-address-sanitizer-part-2/" rel="bookmark">[GSoC] Address Sanitizer, Part 2</a></h2> </header> <div class="entry-content"> <p>Hello again! Its been a month since my last blog post. So, there are many updates I’d like to share. I’ll first cover the Address Sanitizer (ASan) algorithm in detail and then summarize the progress made until the second evaluation period.</p> <hr class="wp-block-separator" /> <p>If you recall my <a href="https://blogs.coreboot.org/blog/2020/07/16/gsoc-address-sanitizer-part-1/" target="_blank" rel="noreferrer noopener">last post</a>, I had briefly talked about the principle behind ASan. Now, let us discuss the ASan algorithm in much more depth. But first, we need to understand the memory layout and how the compiler’s instrumentation works.</p> <h4 class="wp-block-heading">Memory mapping</h4> <p>ASan divides the memory space into 2 disjoint classes:</p> <ul class="wp-block-list"><li>Main Memory (<em>mem</em>): This represents the original memory used by our coreboot program in a particular stage.</li><li>Shadow Memory (<em>shadow</em>): This memory region contains the shadow values. The state of each 8 aligned bytes of <em>mem</em> is encoded in a byte in <em>shadow</em>. As a consequence, the size of this region is equal to 1/8th of the size of <em>mem</em>. To reserve a space in memory for this class, we added a new linker section and named it <code>asan_shadow</code>.</li></ul> <p>This is how we added <code>asan_shadow</code> in romstage:</p> <pre class="wp-block-code"><code>#if ENV_ROMSTAGE && CONFIG(ASAN_IN_ROMSTAGE) _shadow_size = (_ebss - _car_region_start) >> 3; REGION(asan_shadow, ., _shadow_size, ARCH_POINTER_ALIGN_SIZE) #endif</code></pre> <p>and in ramstage:</p> <pre class="wp-block-code"><code>#if ENV_RAMSTAGE && CONFIG(ASAN_IN_RAMSTAGE) _shadow_size = (_eheap - _data) >> 3; REGION(asan_shadow, ., _shadow_size, ARCH_POINTER_ALIGN_SIZE) #endif </code></pre> <p>The linker symbol pairs (<code>_car_region_start</code>, <code>_ebss</code>) and ( <code>_data</code>, <code>_eheap</code>) are references to the boundary addresses of <em>mem</em> in romstage and ramstage respectively.</p> <p>Now, there exists a correspondence between <em>mem</em> and <em>shadow</em> classes and we have a function named <code>asan_mem_to_shadow</code> that performs this translation:</p> <pre class="wp-block-code"><code>void *asan_mem_to_shadow(const void *addr) { #if ENV_ROMSTAGE return (void *)((uintptr_t)&_asan_shadow + (((uintptr_t)addr - (uintptr_t)&_car_region_start) >> ASAN_SHADOW_SCALE_SHIFT)); #elif ENV_RAMSTAGE return (void *)((uintptr_t)&_asan_shadow + (((uintptr_t)addr - (uintptr_t)&_data) >> ASAN_SHADOW_SCALE_SHIFT)); #endif } </code></pre> <p>In other words, <code>asan_mem_to_shadow</code> maps each 8 bytes of <em>mem</em> to 1 byte of <em>shadow</em>.</p> <p>You may wonder what is stored in <em>shadow</em>? Well, there are only 9 possible shadow values for any aligned 8 bytes of <em>mem</em>:</p> <ul class="wp-block-list"><li>The shadow value is 0 if all 8 bytes in qword are unpoisoned (i.e. addressable).</li><li>The shadow value is negative if all 8 bytes in qword are poisoned (i.e. not addressable).</li><li>The shadow value is k if the first k bytes are unpoisoned but the rest 8-k bytes are poisoned. Here k could be any integer between 1 and 7 (1 <= k <= 7).</li></ul> <p>When we say a byte in <em>mem </em>is poisoned, we mean one of these special values are written into the corresponding <em>shadow</em>.</p> <h4 class="wp-block-heading">Instrumentation</h4> <p>Compiler’s ASan instrumentation adds a runtime check to every memory instruction in our program i.e. before each memory access of size 1, 2, 4, 8, or 16, a function call to either <code>__asan_load(addr)</code><em> </em>or<code> __asan_store(addr)</code> is added.</p> <p>Next, it protects stack variables by inserting gaps around them called ‘redzones’. Let’s look at an example:</p> <pre class="wp-block-code"><code>int foo () { char a[24] = {0}; int b[2] = {0}; int i; a[5] = 1; for (i = 0; i < 10; i++) b[i] = i; return a[5] + b[1]; }</code></pre> <p>For this function, the instrumented code will look as follows:</p> <pre class="wp-block-code"><code>int foo () { char redzone1[32]; // Slot 1, 32-byte aligned char redzone2[8]; // Slot 2 char a[24] = {0}; // Slot 3 char redzone3[32]; // Slot 4, 32-byte aligned int redzone4[6]; // Slot 5 int b[2] = {0}; // Slot 6 int redzone5[8]; // Slot 7, 32-byte aligned int redzone6[7]; int i; int redzone7[8]; __asan_store1(&a[5]); a[5] = 1; for (i = 0; i < 10; i++) __asan_store4(&b[i]); b[i] = i; __asan_load1(&a[5]); __asan_load4(&b[1]); return a[5] + b[1]; }</code></pre> <p>As you can see, the compiler has inserted redzones to pad each stack variable. Also, it has inserted function calls to <code>__asan_store</code> and<code> __asan_load</code> before writes and reads respectively.</p> <p>The shadow memory for this stack layout is going to look like this:</p> <pre class="wp-block-code"><code>Slot 1: 0xF1F1F1F1 Slots 2, 3: 0xF1000000 Slot 4: 0xF1F1F1F1 Slots 5, 6: 0xF1F1F100 Slot 7: 0xF1F1F1F1</code></pre> <p>Here F1 being a negative value represents that all 8 bytes in qword are poisoned whereas the shadow value of 0 represents that all 8 bytes in qword are accessible. Notice that in the slots 2 and 3, the variable ‘a’ is concatenated with a partial redzone of 8 bytes to make it 32 bytes aligned. Similarly, a partial redzone of 24 bytes is added to pad the variable ‘b’.</p> <p>The process of protecting global variables is a little different from this. We’ll talk about it later in this blog post.</p> <p>Now, as we have looked at the memory mapping and the instrumented code, let’s dive into the algorithm.</p> <h4 class="wp-block-heading">ASan algorithm</h4> <p>The algorithm is pretty simple. For every read and write operation, we do the following:</p> <ul class="wp-block-list"><li>First, we find the address of the corresponding shadow memory for the location we are writing to or reading from. This is done by <code>asan_mem_to_shadow()</code>.</li><li>Then we determine if the access is valid based on the state stored in the shadow memory and the size requested. For this, we pass the address returned from <code>asan_mem_to_shadow()</code> to <code>memory_is_poisoned()</code><em>.</em> This function dereferences the shadow pointer to check the memory state.</li><li>If the access is not valid, it reports an error in the console mentioning the instruction pointer address, the address where the bug was found, and whether it was read or write. In our ASan library, we have a dedicated function <code>asan_report()</code> for this.</li><li>Finally, we perform the operation (read or write).</li><li>Then, we continue and move over to the next instruction.</li></ul> <p>Here’s a pictorial representation of the algorithm:</p> <figure class="wp-block-image size-large"><img fetchpriority="high" decoding="async" width="1024" height="775" src="https://blogs.coreboot.org/files/2020/08/asan_diagram-2-1024x775.png" alt="" class="wp-image-5084" srcset="https://blogs.coreboot.org/files/2020/08/asan_diagram-2-1024x775.png 1024w, https://blogs.coreboot.org/files/2020/08/asan_diagram-2-300x227.png 300w, https://blogs.coreboot.org/files/2020/08/asan_diagram-2-768x581.png 768w, https://blogs.coreboot.org/files/2020/08/asan_diagram-2-1536x1163.png 1536w, https://blogs.coreboot.org/files/2020/08/asan_diagram-2-2048x1550.png 2048w" sizes="(max-width: 1024px) 100vw, 1024px" /></figure> <p></p> <p>Note that whether access is valid or not, ASan never aborts the current operation. However, the calls to ASan functions do add a performance penalty of about ~1.5x.</p> <p>Now, as we have understood the algorithm, let’s look at the function<code> foo()</code><em> </em>again.</p> <pre class="wp-block-code"><code>int foo () { char a[24] = {0}; int b[2] = {0}; int i; __asan_store1(&a[5]); a[5] = 1; for (i = 0; i < 10; i++) __asan_store4(&b[i]); b[i] = i; __asan_load1(&a[5]); __asan_load4(&b[1]); return a[5] + b[1]; }</code></pre> <p>Have a look at the for loop. The array ‘b’ is of length 2 but we are writing to it even beyond index 1. </p> <p>As the loop is executed for index 2, ASan checks the state of the corresponding shadow memory for <code>&b[2]</code>. Now, let’s look at the shadow memory state for slot 7 again (shown in the previous section). It is <code>0xF1F1F1F1</code>. So, the shadow value for the location <code>b[2] </code>is <code>F1</code>. It means the address we are trying to access is poisoned and thus ASan is triggered and reports the following error in the console log:</p> <pre class="wp-block-code"><code>ASan: stack-out-of-bounds in 0x07f7ccb1 Write of 4 bytes at addr 0x07fc8e48</code></pre> <p>Notice that <code>0x07f7ccb1</code> is the address where the instruction pointer was pointing to and <code>0x07fc8e48</code> is the address of the location <code>b[2]</code>.</p> <hr class="wp-block-separator" /> <h4 class="wp-block-heading">ASan support for romstage</h4> <p>In the romstage, coreboot uses cache to act as a memory for our stack and heap. This poses a challenge when adding support for ASan to romstage because of two reasons.</p> <p>First, even within the same architecture, the size of cache varies across the platforms. So, unlike ramstage, we can’t enable ASan in romstage for all platforms by doing tests on a handful of devices. We have to test ASan on each platform before adding this feature. So, we decided to introduce a <a href="https://review.coreboot.org/c/coreboot/+/44258">new Kconfig </a><a rel="noreferrer noopener" href="https://review.coreboot.org/c/coreboot/+/44258" target="_blank">option </a><code>HAVE_ASAN_IN_ROMSTAGE</code> to denote if a particular platform supports ASan in romstage. Now, for each platform for which ASan in romstage has been tested, we’ll just select this config option. Similarly, we also introduced <code>HAVE_ASAN_IN_RAMSTAGE</code> to denote if a given platform supports ASan in ramstage.</p> <p>The second reason is that the size of a cache is very small compared to the RAM. This is critical because the available memory in the cache is quite low. In order to fit the <code>asan_shadow</code> section on as many platforms as possible, we have to make efficient use of the limited memory available. Thankfully, to a large extent, this problem was solved by our GCC patch which allowed us to append the shadow memory buffer to the region already occupied by the coreboot program. (I ran Jenkins builder and it built successfully for all boards except for the ones that hold either Braswell SoC or i440bx northbridge where the cache area got full and thus couldn’t fit the <code>asan_shadow</code> section.)</p> <p>In the first stage, we have enabled <a rel="noreferrer noopener" href="https://review.coreboot.org/c/coreboot/+/43604" target="_blank">ASan in romstage</a> for <a rel="noreferrer noopener" href="https://review.coreboot.org/c/coreboot/+/44282" target="_blank">QEMU</a>, <a rel="noreferrer noopener" href="https://review.coreboot.org/c/coreboot/+/44160" target="_blank">Haswell</a> and <a rel="noreferrer noopener" href="https://review.coreboot.org/c/coreboot/+/44159" target="_blank">Apollolake</a> platforms as they have been tested. </p> <p>Further, the results of Jenkins builder indicate that, with the current translation function, the support for ASan in romstage can be added on all x86 platforms except the two mentioned above. Therefore, I’ve asked everyone in the community to <a rel="noreferrer noopener" href="https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/MOPFDIMQ5WQLMI7FSBG7Z25HJP3JO55W/" target="_blank">participate</a> in the testing of ASan so that this debugging tool can be made available on as many platforms as possible before GSoC ends.</p> <hr class="wp-block-separator" /> <h4 class="wp-block-heading">Global variables</h4> <p>When we initially added support for <a rel="noreferrer noopener" href="https://review.coreboot.org/c/coreboot/+/42496" target="_blank">ASan in ramstage</a>, it wasn’t able to detect out-of-bounds bugs in case of global variables. After debugging the code, I found that the redzones for the global variables were not poisoned. So, I went through GCC’s ASan and Linux’s KASAN implementation again and realized that the way in which the compiler protects global variables was very much different from its instrumentation for stack variables.</p> <p>Instead of padding the global variables directly with redzones, it inserts constructors invoking the library function named<code> __asan_register_globals</code> to populate the relevant shadow memory regions. To this function, compiler also passes an instance of the following type:</p> <pre class="wp-block-code"><code>struct asan_global { /* Address of the beginning of the global variable. */ const void *beg; /* Initial size of the global variable. */ size_t size; /* Size of the global variable + size of the red zone. This size is 32 bytes aligned. */ size_t size_with_redzone; /* Name of the global variable. */ const void *name; /* Name of the module where the global variable is declared. */ const void *module_name; /* A pointer to struct that contains source location, could be NULL. */ struct asan_source_location *location; } </code></pre> <p>So, to enable the poisoning of global variables’ redzones, I created a function named <code>asan_ctors</code> which calls these constructors at runtime and added it to ASan initialization code for the ramstage. </p> <p>You may wonder why <code>asan_ctors()</code> is only added to ramstage? This is because the use of global variables is prohibited in coreboot for romstage and thus there is no need to detect global out-of-bounds bugs.</p> <hr class="wp-block-separator" /> <h4 class="wp-block-heading">Next steps..</h4> <p>In the third coding period, I鈥檝e started working on adding support for ASan to memory functions like memset, memmove and memcpy. I’ll push the patch on Gerrit pretty soon. </p> <p>Once, this is done, I’ll start writing documentation on ASan answering questions like how to use ASan, what kind of bugs can be detected, what devices are currently supported, and how ASan support can be added to other architectures like ARM or RISC-V.</p> <p>[<a rel="noreferrer noopener" href="https://review.coreboot.org/q/topic:%22ASan%22+(status:open%20OR%20status:merged)" target="_blank">ASan </a><a href="https://review.coreboot.org/q/topic:%2522ASan%2522+status:merged+author:harshit" target="_blank" rel="noreferrer noopener">patches</a>]</p> <p></p> </div> <footer class="entry-footer"> <span class="posted-on"><span class="screen-reader-text">Posted on </span><a href="https://blogs.coreboot.org/blog/2020/08/17/gsoc-address-sanitizer-part-2/" rel="bookmark"><time class="entry-date published" datetime="2020-08-17T07:23:29+00:00">August 17, 2020</time><time class="updated" datetime="2020-08-29T00:39:08+00:00">August 29, 2020</time></a></span><span class="byline"><span class="author vcard"><span class="screen-reader-text">Author </span><a class="url fn n" href="https://blogs.coreboot.org/blog/author/harshitsharma/">harshitsharma</a></span></span><span class="cat-links"><span class="screen-reader-text">Categories </span><a href="https://blogs.coreboot.org/blog/category/coreboot/" rel="category tag">coreboot</a>, <a href="https://blogs.coreboot.org/blog/category/gsoc/" rel="category tag">GSoC</a></span><span class="tags-links"><span class="screen-reader-text">Tags </span><a href="https://blogs.coreboot.org/blog/tag/asan/" rel="tag">ASan</a>, <a href="https://blogs.coreboot.org/blog/tag/gsoc/" rel="tag">GSoC</a>, <a href="https://blogs.coreboot.org/blog/tag/gsoc-2020/" rel="tag">GSoC 2020</a></span> </footer> </article> <article id="post-4993" class="post-4993 post type-post status-publish format-standard hentry category-coreboot category-gsoc tag-asan tag-gsoc tag-gsoc-2020"> <header class="entry-header"> <h2 class="entry-title"><a href="https://blogs.coreboot.org/blog/2020/07/16/gsoc-address-sanitizer-part-1/" rel="bookmark">[GSoC] Address Sanitizer, Part 1</a></h2> </header> <div class="entry-content"> <p>Hello everyone. My name is Harshit Sharma (hst on IRC). I am working on the project to add the “Address Sanitizer” feature to coreboot as a part of GSoC 2020. Werner Zeh is my mentor for this project and I’d like to thank him for his constant support and valuable suggestions.</p> <p>It’s been a fun couple of weeks since I started working on this project. Though I found the initial few weeks quite challenging, I am glad that I was able to get past that and learned some amazing stuff I’d cherish for a long time. </p> <p>Also, being a student, I find it incredible to have got a chance to work with and learn from such passionate, knowledgeable, and helpful people who are always available over IRC to assist.</p> <p>A few of you may already know about the progress we’ve made through Werner’s <a rel="noreferrer noopener" href="https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/PVAFQQZKOJXK26M44I7PEGNBJMWOUJ5J" target="_blank">message</a> on the mailing list. This is a much comprehensive report on the work we had done prior to the first evaluation period.</p> <hr class="wp-block-separator" /> <h4 class="wp-block-heading">What is Address Sanitizer ?</h4> <p><a href="https://github.com/google/sanitizers/wiki/AddressSanitizer" target="_blank" rel="noreferrer noopener">Address Sanitizer (ASan)</a> is a runtime memory debugging tool, designed to find out of bounds and use after free memory bugs. It is a part of toolset Google has developed which also includes Undefined Behaviour Sanitizer (UBSan), a Thread Sanitizer (TSan), and a Leak Sanitizer (LSan).</p> <p>This tool would help in improving code quality and thus would make our runtime code more robust.</p> <hr class="wp-block-separator" /> <h4 class="wp-block-heading">Compile with ASan</h4> <p>The firstmost task was to ensure that coreboot compiles without any errors after Asan is enabled. For this, we created dummy functions and added the relevant GCC flags to build coreboot with ASan. We also introduced a Kconfig option (currently only available on x86 architecture) to enable this feature. (Patch <a rel="noreferrer noopener" href="https://review.coreboot.org/c/coreboot/+/42271" target="_blank">[1]</a>)</p> <hr class="wp-block-separator" /> <h4 class="wp-block-heading">Porting code from Linux</h4> <p>The design of ASan in coreboot is based on its implementation in Linux kernel, also known as Kernel Address Sanitizer (KASAN). However, coreboot differs a lot from Linux kernel due to multiple stages and that is what poses a challenge. </p> <hr class="wp-block-separator" /> <h4 class="wp-block-heading">Design of ASan</h4> <p>ASan uses compile-time instrumentation that adds a run-time check before every memory instructions.</p> <p>The basic idea is to encode the state of each 8 aligned bytes of memory in a byte in the shadow region. As a consequence, the shadow memory is allocated to 1/8th of the available memory. The instrumentation of the compiler adds __asan_load and __asan_store function calls before memory accesses which seeks the address of the corresponding shadow memory and then decides if access is legitimate depending on the stored state. </p> <p>If the access is not valid, it throws an error telling the instruction pointer address, the address where a bug is found and whether it was read or write.</p> <hr class="wp-block-separator" /> <h4 class="wp-block-heading">Need for GCC patch</h4> <p>Unlike Linux kernel which has a static shadow memory layout, coreboot has multiple stages with very different memory maps. Thus we require different shadow offset addresses for each stage. </p> <p>Unfortunately, GCC presently, only supports using a static shadow offset address which is specified at compile time using -fasan-shadow-offset flag.</p> <p>So, we came up with a GCC patch that introduces a feature to use a dynamic shadow offset address. Through this, we enable GCC to determine shadow offset address at runtime using a callback function __asan_shadow_offset().</p> <p>Though we’ve presented <a href="https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550176.html" target="_blank" rel="noreferrer noopener">our patch</a> to GCC developers to convince them to include this change in their upcoming version, for now, ASan on coreboot only works if this patch is applied. (Patches <a rel="noreferrer noopener" href="https://review.coreboot.org/c/coreboot/+/42794/13" target="_blank">[2] </a>and <a rel="noreferrer noopener" href="https://review.coreboot.org/c/coreboot/+/43164/2" target="_blank">[3]</a>)</p> <hr class="wp-block-separator" /> <h4 class="wp-block-heading">Allocating and initializing shadow buffer</h4> <p>Instead of allocating a shadow buffer for the whole memory region, we decided to only define shadow memory for data and heap sections. Since we don’t want to run ASan for hardware mapped addresses, this way we save a lot of memory space.</p> <p>Once the shadow region is allocated by the linker, the next task is to initialize it as early as possible at runtime. This is done by a call to asan_init() which unpoisons i.e. sets the shadow memory corresponding to the addresses in the data and heap sections to zero.</p> <hr class="wp-block-separator" /> <h4 class="wp-block-heading">ASan support for ramstage</h4> <p>We decided to begin in a comparatively simpler stage i.e. ramstage. Since ramstage uses DRAM, the implementation is common across all platforms of a particular architecture. Moreover, ramstage provides enough room in the memory to place our shadow region.</p> <p>For now, we have only enabled this feature for x86 architecture and it is able to detect stack out of bounds and use after scope bugs. Though the patches are still in the review stage, we did a test on QEMU and siemens mc_apl3 (Apollo Lake based) and so far it looks good to us. (Patch <a rel="noreferrer noopener" href="https://review.coreboot.org/c/coreboot/+/42496/19" target="_blank">[4]</a>)</p> <hr class="wp-block-separator" /> <h4 class="wp-block-heading">Next steps..</h4> <p>In the second coding period, we’ve started working on adding ASan to romstage. I will push a change on Gerrit once we make some considerable progress.</p> <hr class="wp-block-separator" /> <p>We further encourage everyone in the community to review the <a rel="noreferrer noopener" href="https://review.coreboot.org/q/topic:%22ASan%22+(status:open%20OR%20status:merged)" target="_blank">patches</a> and test this feature on their hardware for better test coverage. The more feedback we get, the more are the chances to have a high-quality debugging tool.</p> </div> <footer class="entry-footer"> <span class="posted-on"><span class="screen-reader-text">Posted on </span><a href="https://blogs.coreboot.org/blog/2020/07/16/gsoc-address-sanitizer-part-1/" rel="bookmark"><time class="entry-date published" datetime="2020-07-16T10:12:35+00:00">July 16, 2020</time><time class="updated" datetime="2020-08-17T20:01:18+00:00">August 17, 2020</time></a></span><span class="byline"><span class="author vcard"><span class="screen-reader-text">Author </span><a class="url fn n" href="https://blogs.coreboot.org/blog/author/harshitsharma/">harshitsharma</a></span></span><span class="cat-links"><span class="screen-reader-text">Categories </span><a href="https://blogs.coreboot.org/blog/category/coreboot/" rel="category tag">coreboot</a>, <a href="https://blogs.coreboot.org/blog/category/gsoc/" rel="category tag">GSoC</a></span><span class="tags-links"><span class="screen-reader-text">Tags </span><a href="https://blogs.coreboot.org/blog/tag/asan/" rel="tag">ASan</a>, <a href="https://blogs.coreboot.org/blog/tag/gsoc/" rel="tag">GSoC</a>, <a href="https://blogs.coreboot.org/blog/tag/gsoc-2020/" rel="tag">GSoC 2020</a></span> </footer> </article> </main> </section> </div> <footer id="colophon" class="site-footer" role="contentinfo"> <div class="site-info"> <a href="https://wordpress.org/">Proudly powered by WordPress</a> </div> </footer> </div> </body> </html>