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>GSoC – 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 » GSoC Tag Feed" href="https://blogs.coreboot.org/blog/tag/gsoc/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/4194" /><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-gsoc tag-4194 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>GSoC</span></h1> </header> <article id="post-8509" class="post-8509 post type-post status-publish format-standard hentry category-coreboot tag-gsoc"> <header class="entry-header"> <h2 class="entry-title"><a href="https://blogs.coreboot.org/blog/2023/11/16/updating-lz4-during-my-gsoc/" rel="bookmark">Updating LZ4 during my GSoC</a></h2> </header> <div class="entry-content"> <h3 class="wp-block-heading">Introduction</h3> <p>In this blog post, I will give an insight into my Google Summer of Code project, where I worked on coreboot. My target goals were updating compression and decompression algorithms LZ4 and LZMA to their newest version.</p> <p>In the whole process, I learned a lot about coreboot as an open-source community, and about GSoC, which could help students considering applying for a GSoC themselves.</p> <p>This blog won’t be addressing technical details, there will be a section at the end about my work and the results of it, but the rest of the blog will be a bit more meta.</p> <h3 class="wp-block-heading">What did I learn about open-source communities?</h3> <p>Before this project, I never contributed to any open-source project. My studies don’t involve much programming, therefore I’m not that professional, my programming skills are homebrewed. Now open source communities, especially as big as coreboot, really intimidated me (they still do somehow). There are many people, all of them probably better programmers than me, having more knowledge of the project as well. How could I help them with anything useful at all? And what if I push my first patch and it’s just embarrassing? Having a mentor helped, I think without someone to talk to, I would have never stuck my nose into any big open-source project.</p> <p>And all the people I met were very kind and helpful if needed. And I learned that critics, especially in text form, may sound harsher in my head than they are meant to.</p> <h3 class="wp-block-heading">Thoughts about Google’s Summer of Code</h3> <p>GSoC is a really good opportunity to get a feeling for working on open source. If you are a student searching for insight into open source, guided by a mentor, a GSoC project can be just right for you.</p> <p>But something I underestimated, was, how time-intensive such a project (even a medium one) is. I probably was too naive, but beforehand, I just talked myself into “Yeah this won’t be a problem, I can just work around two days a week for this, just shift stuff to other days.” Well, it turns out, that’s not how workload and mental load work. For me at least. I do work besides my studies and in the first weeks of GSoC, I was overwhelmed by the combination. Besides having fewer hours to do other things, just having more things to think about can be quite stressful under some conditions.</p> <p>GSoC allows you to stretch your project, so there is less work per week. In total, the project hours stay the same. This opportunity really helped me because I underestimated the load the weekly hours would apply.</p> <p>If I were to apply to GSoC again, I would double-check if such a commitment in terms of work is feasible for me. And that I would recommend to everyone thinking about applying. GSoC can be interesting and fun, but you need to be able to provide the time needed for the project.</p> <h3 class="wp-block-heading">What did I do and achieve?</h3> <p>I started my project by updating LZ4 code in coreboot. After that, I planned to move on to another compression algorithm, LZMA. My hopes were to increase the decompression speed and the compression ratio at the same time. Looking at the release notes for LZ4 since the version currently used by coreboot (spanning 8 years of releases), they stated an increase in speed and compression factor.</p> <p>To get an overview, I first searched for all places where LZ4 was used and checked the version which the code was from. I found out, that there are five files containing code from the LZ4 repository, where every file contains another subset of functions from the original file. 3 of these files were imported from LZ4 wrapper files.</p> <p>Then I fetched LZ4 code from the newest LZ4 release and merged it into the files where old LZ4 code was used. After merging, there were many LZ4 functions never used in our use case. Therefore I searched for each source file through each wrapper file to find out which functions were used and which I could remove. This way I could ensure there was no unused code in these files, providing a better overview</p> <p>After that, there still were many errors that needed to be resolved. That took the most time, being more complicated than I assumed. In the end, all tests passed, and building a rom and running it with QEMU worked just fine, my last ToDo was to test how much the new version was faster than the old if it was at all.</p> <p>Release notes stated many speed improvements, so I hoped this would show up after my work.</p> <p>The whole process took longer than I thought. Therefore I will miss the goal of updating LZMA. As I am writing this, my patch is open for review and I am in the process of creating statistics that may show that there is a speed improvement. If there is not, maybe there is no good reason to change to a newer LZ4 version. As one comment states, coreboot does require safe in-place decompression, which may be a problem with the new version and thus would have to be checked.</p> <p>My work is public on the coreboot Gerrit under this link <a href="https://review.coreboot.org/c/coreboot/+/77148">https://review.coreboot.org/c/coreboot/+/77148</a>. I do hope my patch will be merged, as I want to contribute to this project. But even if a merge may be rejected, that is part of open-source work too. I’ll try to improve on my next patch. This is my first open source contribution and it’s not perfect, but it certainly won’t be my last.</p> <h3 class="wp-block-heading">What could be done in the future?</h3> <p>As stated in a comment on my patch, in-place decompression is important for coreboot. There is a merged pull request from 2016 resolving that issue, but its functionality may have been lost in further development. Therefore, the new LZ4 version has to be checked for in-place safety.</p> <p>To tweak compression/decompression speeds and compression factor one might want to edit compression parameters. One could do this using a Kconfig entry.</p> <p>Also, it occurred that after building coreboot (running make in coreboot dictionary), when memory regions and sizes of the coreboot.rom are printed, there is no compression listed for the payload, even when it certainly has been compressed.</p> <h3 class="wp-block-heading">Statistics</h3> <p>I tested this on my laptop with KVM and QEMU, on an AMD® Ryzen 5 5500u. I changed my system’s CPU affiliation, to make 2 of my cores unused (they still got used, but not much, usually ~1%). Then I assigned these 2 CPUs to my VM to make different runs more comparable. Still, different runs got different timings, so I made 6 runs for the old LZ4 and the new LZ4 version each.</p> <figure class="wp-block-table"><table><thead><tr><th></th><th>Avg ramstage decompression time</th><th>Ramstage decompression time std dev</th><th>Avg payload decompression time</th><th>Payload decompression time std dev</th></tr></thead><tbody><tr><td>Current version</td><td>420µs</td><td>54µs</td><td>229µs</td><td>64µs</td></tr><tr><td>Updated version</td><td>520µs</td><td>113µs</td><td>219µs</td><td>4µs</td></tr></tbody></table></figure> <figure class="wp-block-table"><table><thead><tr><th></th><th>Ramstage compression ratio</th><th>Payload compression ratio</th></tr></thead><tbody><tr><td>Current version</td><td>1,507</td><td>1,452</td></tr><tr><td>Updated version</td><td>1,51</td><td>1,454</td></tr></tbody></table></figure> <p>These values indicate that there is a very small improvement in the compression ratio. Regarding decompression time, most tests have a relatively high standard deviation, which makes the results less statistically relevant. Ramstage decompression seems to have slowed down (~24%) while average payload decompression got 4-5% faster.</p> <p>All in all, these results are everything but exciting to me. Although a newer version may have other advantages, it seems that there is no decompression time improvement as I hoped and compression ratio improvements are so small, that they might not be noticeable.</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/2023/11/16/updating-lz4-during-my-gsoc/" rel="bookmark"><time class="entry-date published" datetime="2023-11-16T19:50:00+00:00">November 16, 2023</time><time class="updated" datetime="2023-11-16T20:21:14+00:00">November 16, 2023</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/pmacher/">Philipp Macher</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></span><span class="tags-links"><span class="screen-reader-text">Tags </span><a href="https://blogs.coreboot.org/blog/tag/gsoc/" rel="tag">GSoC</a></span> </footer> </article> <article id="post-7901" class="post-7901 post type-post status-publish format-standard hentry category-coreboot tag-flashrom tag-gsoc tag-gsoc-2022"> <header class="entry-header"> <h2 class="entry-title"><a href="https://blogs.coreboot.org/blog/2022/09/08/gsoc-optimize-erase-function-selection-wrap-up/" rel="bookmark">[GSoC] Optimize Erase Function Selection, wrap-up</a></h2> </header> <div class="entry-content"> <p>GSoC 2022 coding period is about to come to an end this week. It has been an enriching 12 weeks of reading old code, designing algorithms and structures, coding, testing, and hanging out over IRC! I’d like to take this opportunity to present my work and details on how it has impacted Flashrom. 🙂</p> <p>You can find the complete list of commits I made during GSoC with this <a rel="noreferrer noopener" href="https://review.coreboot.org/q/author:aarya.chaumal%2540gmail.com+topic:gsoc" target="_blank">gerrit query</a>. Some of the patches aren’t currently merged and are under review. In any case, you are most welcome to join the review (which will likely be very helpful for me).</p> <p class="has-medium-font-size"><strong>Definitions</strong></p> <p>Let me clarify some terminologies used hereafter</p> <ul class="wp-block-list"><li>Region: A list of contiguous addresses on the chip</li><li>Layout: List of regions</li><li>Locked region: There are some regions on the chip that cannot be accessed directly or in some cases cannot be accessed at all.</li><li>Page: The entire flash memory is divided into uniform pages that can be written on. You have to write on an entire page at once.</li><li>Erase block/sector: According to each erase function, flash memory is divided into regions (not necessarily uniform sized) that can be erased. You have to erase an entire erase block at once. So each erase function has a different erase block layout.</li><li>Sub-block: An erase block is a sub-block of another erase block if it is completely inside the latter.</li><li>Homogenous erase layout: All erase blocks in a layout are of uniform size. </li><li>Nonhomogenous erase layout: There might be erase blocks of varying sizes in this layout.</li></ul> <p class="has-medium-font-size"><strong>Need for this project</strong></p> <p>To change any 0 to a 1 in the contents of a NOR-flash chip, a full block of data needs to be erased. So to change a single byte, it is sometimes required to erase a whole block, which we’ll call erase overhead. Most flash chips support multiple erase-block sizes. Flashrom keeps a list of these sizes and ranges for each supported flash chip and maps them to internal erase functions. Most of these lists were sorted by ascending size. I added a simple test to ensure this and corrected the ones which gave errors.</p> <p>Earlier, Flashrom tried all available erase functions for a flash chip during writes. Usually, only the first function was used, but if anything went wrong on the wire, or the programmer rejected a function, it falls back to the next. As the functions are sorted by size, this results in a minimum erase overhead.</p> <p>However, if big portions of the flash contents are re-written, using the smallest erase block size results in transaction overhead, and also erasing bigger blocks at once often results in shorter erase times inside the flash chip.</p> <p>So in a nutshell, the erase function selection in Flashrom was sequential, i.e. they started from the function with the smallest erase block and moved to the next one only in case of an error. This was inefficient in cases where bigger chunks of the flash had to be erased.</p> <p class="has-medium-font-size"><strong>Current implementation</strong></p> <p>After rigorous discussion with my mentors and with the community, we decided on a look-ahead algorithm for selecting the erase functions or the erase blocks to be more precise. From the layout of erase blocks as seen by different erase functions, we make an optimal selection.</p> <p>We start with the first erase function (remember this erase function has the smallest erase blocks) and mark those blocks which lie completely inside the region to be erased. Then moving on to subsequent erase layouts and marking those erase blocks that have more than half of the sub-blocks marked and then unmarking the marked sub-blocks. Finally, erase all the marked erase blocks. This strategy ensures that if we have a large contiguous region to be erased then we would use an appropriately large erase function to erase it.</p> <p>The above-mentioned strategy had some challenges and required a few tweaks:</p> <ul class="wp-block-list"><li>The region to be erased may not be aligned to any erase blocks. This could be easily overcome by extending the ‘to be erased’ region to align it with some erase block.</li><li>The above solution of extending the region brought a new challenge – the newly aligned region might overlap with write-protected regions. In this case, the erase function would fail to erase the erase block containing this region.</li><li>It may happen that some erase functions are not supported by the programmer. This would lead to catastrophic failure. To this end, we thought of first getting a list of erase functions supported by the programmer and then running the algorithm on this subset of erase functions.</li></ul> <p>So with this, we were all set to begin the implementation of the algorithm. Or so I thought. Flashrom had stored information regarding the erase layout in a nested format which was very difficult to use so I had to flatten them out and fit them in a data structure that would give me quick information about sub-blocks as well. <strong>😮‍💨</strong></p> <p>For a better understanding of the algorithm, I made the following flowchart.</p> <figure class="wp-block-image size-large"><img fetchpriority="high" decoding="async" width="516" height="1024" src="https://blogs.coreboot.org/files/2022/09/Copy-of-algo-flowchart-516x1024.jpg" alt="" class="wp-image-7915" srcset="https://blogs.coreboot.org/files/2022/09/Copy-of-algo-flowchart-516x1024.jpg 516w, https://blogs.coreboot.org/files/2022/09/Copy-of-algo-flowchart-151x300.jpg 151w, https://blogs.coreboot.org/files/2022/09/Copy-of-algo-flowchart-768x1525.jpg 768w, https://blogs.coreboot.org/files/2022/09/Copy-of-algo-flowchart-773x1536.jpg 773w, https://blogs.coreboot.org/files/2022/09/Copy-of-algo-flowchart.jpg 801w" sizes="(max-width: 516px) 100vw, 516px" /></figure> <p class="has-medium-font-size"><strong>Testing</strong></p> <p>Testing on hardware is difficult because you need all the different chips and programmers and test on each one of them to be sure that your code is working correctly. On top of that, identifying all possible scenarios adds to the burden. This definitely takes a lot of time and effort and my mentors and the community is helping a lot with it. </p> <p>The current progress of testing can be seen <a href="https://review.coreboot.org/c/flashrom/+/66718">here</a>. Feel free to suggest more cases and help with the testing. It will definitely help a lot.</p> <p class="has-medium-font-size"><strong>Future work</strong></p> <p>Definitely, the code or algorithm isn’t fully optimized and can be improved further. Also one can fix the progress bar feature to Flashrom, which got broken due to my code😅. </p> <p class="has-medium-font-size"><strong>Acknowledgments</strong></p> <p>I’d like to thank Thomas Heijligen and Simon Buhrow for being excellent mentors, Nico for providing constant code reviews and giving regular inputs, and everyone in the Flashrom community for being helpful and friendly.</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/2022/09/08/gsoc-optimize-erase-function-selection-wrap-up/" rel="bookmark"><time class="entry-date published" datetime="2022-09-08T07:12:30+00:00">September 8, 2022</time><time class="updated" datetime="2022-09-08T07:12:32+00:00">September 8, 2022</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/light2802/">light2802</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></span><span class="tags-links"><span class="screen-reader-text">Tags </span><a href="https://blogs.coreboot.org/blog/tag/flashrom/" rel="tag">flashrom</a>, <a href="https://blogs.coreboot.org/blog/tag/gsoc/" rel="tag">GSoC</a>, <a href="https://blogs.coreboot.org/blog/tag/gsoc-2022/" rel="tag">GSoC 2022</a></span> </footer> </article> <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’t 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’t 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 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’ve 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> <article id="post-4839" class="post-4839 post type-post status-publish format-standard hentry category-coreboot tag-gsoc tag-gsoc-2019"> <header class="entry-header"> <h2 class="entry-title"><a href="https://blogs.coreboot.org/blog/2019/08/23/gsoc-wrap-up-for-adding-qemu-aarch64-support-to-coreboot/" rel="bookmark">[GSoC] Wrap-up for Adding QEMU/AArch64 Support to Coreboot</a></h2> </header> <div class="entry-content"> <p>Hello, I’m Asami. It is the time for the final evaluation of GSoC 2019 now. My project is adding QEMU/AArch64 support to coreboot. It would help developers for compatibility testing and make sure that changes to architecture code don’t break current implementations for ARMv8. </p> <p>Here is my work on Gerrit. <a href="https://review.coreboot.org/c/coreboot/+/33387">CL 33387</a> is the main patch for this project and it is successfully merged. We can now run coreboot on QEMU/AArch64.</p> <ul class="wp-block-list"><li><a href="https://review.coreboot.org/c/coreboot/+/31938">https://review.coreboot.org/c/coreboot/+/31938</a></li><li><a href="https://review.coreboot.org/c/coreboot/+/33287">https://review.coreboot.org/c/coreboot/+/33287</a></li><li><a href="https://review.coreboot.org/c/coreboot/+/33387">https://review.coreboot.org/c/coreboot/+/33387</a> (Main project)</li><li><a href="https://review.coreboot.org/c/coreboot/+/34250">https://review.coreboot.org/c/coreboot/+/34250</a></li><li><a href="https://review.coreboot.org/c/coreboot/+/34367">https://review.coreboot.org/c/coreboot/+/34367</a> </li><li><a href="https://review.coreboot.org/c/coreboot/+/34535">https://review.coreboot.org/c/coreboot/+/34535</a></li><li><a href="https://review.coreboot.org/c/coreboot/+/34774">https://review.coreboot.org/c/coreboot/+/34774</a> </li><li><a href="https://review.coreboot.org/c/coreboot/+/35022">https://review.coreboot.org/c/coreboot/+/35022</a> </li><li><a href="https://review.coreboot.org/c/coreboot/+/35024">https://review.coreboot.org/c/coreboot/+/35024</a></li></ul> <h2 class="wp-block-heading">What I’ve Done for My Main Project</h2> <p>Firstly I made a new directory qemu-aarch64 in src/mainboard/emulation/ and I was basically working on in it. In the bootblock stage, I have written custom bootblock code in assembly because an ARM virt machine doesn’t have SRAM, which means I had to relocate code inside ROM to DRAM during the first stage. I also made a memory layout with reference to <a href="https://github.com/qemu/qemu/blob/master/hw/arm/virt.c">the QEMU implementation.</a> In the romstage and the ramstage, I registered a custom handler for detecting DRAM size because AArch64 throws a Synchronous External Abort that happens when you try to access something that is not memory.</p> <p>I wrote documentation for how to use coreboot with QEMU/AArch64. Here is the page: <a href="https://doc.coreboot.org/mainboard/emulation/qemu-aarch64.html">https://doc.coreboot.org/mainboard/emulation/qemu-aarch64.html</a></p> <h2 class="wp-block-heading">Future Work</h2> <p>ARMv8 architecture has an integrated LinuxBios as a payload. However, I can’t run coreboot with it yet. It now causes an error while building. I also need to make sure that coreboot works well with ARM Trusted Firmware. So, I’d like to solve problems and I hope to see “Hello World” with LinuxBios.</p> <h2 class="wp-block-heading">Conclusion</h2> <p>I believe I almost succeed in my project. The main code has already merged and I also solved small problems found while working on the main project. The members of coreboot are really great and they, especially my mentor and reviewers, helped me a lot. It was not an easy project for me because I had never experienced to work on coreboot and I had to know the basic code flow of it. I’ve read much code and it made me grown up. Thank you all of the members for such an excellent time.</p> <h3 class="wp-block-heading">My Previous Blog Posts</h3> <ul class="wp-block-list"><li><a href="https://blogs.coreboot.org/blog/2019/06/16/gsoc-common-mistakes-for-beginners/">https://blogs.coreboot.org/blog/2019/06/16/gsoc-common-mistakes-for-beginners/</a></li><li><a href="https://blogs.coreboot.org/blog/2019/06/24/gsoc-debug-bootblock-stage-for-armv8-on-qemu/">https://blogs.coreboot.org/blog/2019/06/24/gsoc-debug-bootblock-stage-for-armv8-on-qemu/</a></li><li><a href="https://blogs.coreboot.org/blog/2019/07/17/gsoc-how-to-run-c-code-in-bootblock-stage-for-qemu-aarch64/">https://blogs.coreboot.org/blog/2019/07/17/gsoc-how-to-run-c-code-in-bootblock-stage-for-qemu-aarch64/</a></li><li><a href="https://blogs.coreboot.org/blog/2019/08/21/gsoc-how-to-use-arm-trusted-firmware-in-coreboot/">https://blogs.coreboot.org/blog/2019/08/21/gsoc-how-to-use-arm-trusted-firmware-in-coreboot/</a></li></ul> <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/2019/08/23/gsoc-wrap-up-for-adding-qemu-aarch64-support-to-coreboot/" rel="bookmark"><time class="entry-date published" datetime="2019-08-23T12:14:54+00:00">August 23, 2019</time><time class="updated" datetime="2019-08-23T21:48:42+00:00">August 23, 2019</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/d0iasm/">d0iasm</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></span><span class="tags-links"><span class="screen-reader-text">Tags </span><a href="https://blogs.coreboot.org/blog/tag/gsoc/" rel="tag">GSoC</a>, <a href="https://blogs.coreboot.org/blog/tag/gsoc-2019/" rel="tag">GSoC 2019</a></span> </footer> </article> <article id="post-4777" class="post-4777 post type-post status-publish format-standard hentry category-coreboot category-gsoc tag-gsoc tag-gsoc-2019"> <header class="entry-header"> <h2 class="entry-title"><a href="https://blogs.coreboot.org/blog/2019/08/22/gsoc-coreboot-coverity-final-update/" rel="bookmark">[GSoC] Coreboot Coverity, Final Update</a></h2> </header> <div class="entry-content"> <p>It is now the final week of GSoC, and it is time for me to write my final blog post. Over the past summer I have worked on fixing the <a href="https://scan.coverity.com/projects/coreboot">Coverity scan</a> issues in coreboot, with the goal of making the code base “Coverity clean”. This has involved writing a substantial number of patches, the vast majority of which are in coreboot, with a sprinkling in a few other projects:</p> <ul class="wp-block-list"><li><a href="https://review.coreboot.org/q/owner:jgarber1%2540ualberta.ca+repo:coreboot+before:2019-08-26+status:merged">146</a> patches in coreboot</li><li><a href="https://review.coreboot.org/q/owner:jgarber1%2540ualberta.ca+repo:flashrom+before:2019-08-26+status:merged">6</a> patches in flashrom</li><li><a href="https://chromium-review.googlesource.com/q/owner:jgarber1%2540ualberta.ca+status:merged+before:2019-08-26">6</a> patches in vboot</li><li><a href="https://chromium-review.googlesource.com/q/owner:jgarber1%2540ualberta.ca+status:merged+before:2019-08-26">3</a> patches in Chromium EC</li><li><a href="https://lists.infradead.org/pipermail/opensbi/2019-August/000350.html">4</a> patches in OpenSBI</li><li><a href="https://review.coreboot.org/q/owner:jgarber1%2540ualberta.ca+repo:em100+before:2019-08-26+status:merged">2</a> patches in em100</li><li><a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b9d1a8e9302e68ee03571a286aadeb8041e0b2ca">1</a> in the Linux kernel</li></ul> <p>At the time of writing, a few of my patches are still <a href="https://review.coreboot.org/q/owner:jgarber1%2540ualberta.ca+status:open+before:2019-08-26">under review</a> on Gerrit, so it is possible (and hopeful!) that this list will increase over the next few weeks.</p> <p>In total, these patches resolved 172 Coverity issue reports of actual bugs. However, Coverity also isn’t always right, and some issues weren’t actually problems that required patches. These issues, 91 in total, were either false positives or intentional and were ignored. At the moment, there are currently 223 remaining reports in the<a href="https://scan.coverity.com/projects/coreboot?tab=overview"> </a>issue tracker for coreboot. Despite being a substantial number, this is almost entirely composed of issues from third-party projects (such as OpenSBI or vboot, which probably shouldn’t be counted in the coreboot tracker anyway), and the AMD vendorcode. The original plan at the beginning of the summer was to work on the AMD vendorcode; however, after discussion with my mentors we decided to skip it, since with the upcoming deprecations for coreboot 4.11 it might not be around much longer. Aside from this, there are roughly 20 remaining issues, which mostly required refactoring or technical knowledge that I don’t have.</p> <p>With the summary out of the way, I’d like to give everyone a sample of the sort of bugs I’ve worked on during the project, and hopefully give advice for avoiding them in the future. Here is a list of the most common, nasty, or subtle types of bugs I’ve found over the summer.</p> <h4 class="wp-block-heading">Missing Break Statements</h4> <p>In switch statements in C, every case statement implicitly falls through to the next one. However, this is almost never the desired behavior, and so to avoid this every case needs to be manually terminated by a break to prevent the fall-through. This unfortunately is very tedious to do and is often accidentally left out. For a prototypical example, let’s look at <a href="https://review.coreboot.org/c/coreboot/+/32180">CB:32180</a> from the AGESA vendorcode.</p> <pre class="wp-block-preformatted">switch (AccessWidth) { case AccessS3SaveWidth8: RegValue = *(UINT8 *) Value; break; case AccessS3SaveWidth16: RegValue = *(UINT16 *) Value; break; case AccessS3SaveWidth32: RegValue = *(UINT32 *) Value; default: ASSERT (FALSE); }</pre> <p>In this switch there is a missing break after the <code>AccessS3SaveWidth32</code> case, which will then fall-through to the false assertion. Clearly not intentional! Other examples of this, though not as severe, can be found in <a href="https://review.coreboot.org/c/coreboot/+/32088">CB:32088</a> and<a href="https://review.coreboot.org/c/coreboot/+/34293"> CB:34293</a>. Fortunately, these errors today can be prevented by the compiler. GCC recently added the <code>-Wimplicit-fallthrough</code> option, which will warn on all implicit fall throughs and alert to a potentially missing break. However, some fall throughs are intentional, and these can be annotated by a <code>/* fall through */</code> comment to silence the warning. Since <a href="https://review.coreboot.org/c/coreboot/+/34297">CB:34297</a> and <a href="https://review.coreboot.org/c/coreboot/+/34300">CB:34300</a> this warning has been enabled in coreboot, so this should be the last we see of missing break statements.</p> <h4 class="wp-block-heading">Off-by-One Errors</h4> <blockquote class="wp-block-quote is-layout-flow wp-block-quote-is-layout-flow"><p>There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.</p><cite>Anonymous</cite></blockquote> <p>Everyone has been bitten by off-by-one errors. Let’s take a look at <a href="https://review.coreboot.org/c/coreboot/+/32125">CB:32125</a> from the Baytrail graphics code.</p> <pre class="wp-block-preformatted">static void gfx_lock_pcbase(struct device *dev) { const u16 gms_size_map[17] = { 0, 32, 64, 96, 128, 160, 192, 224, 256, 288, 320, 352, 384, 416, 448, 480, 512 }; ... u32 gms, gmsize, pcbase; gms = pci_read_config32(dev, GGC) & GGC_GSM_SIZE_MASK; gms >>= 3; if (gms > ARRAY_SIZE(gms_size_map)) return; gmsize = gms_size_map[gms]; ... }</pre> <p>Here we have an array <code>gms_size_map</code> of 17 elements, and a bounds check on the <code>gms</code> variable before it is used to index into the array. However, there’s a problem. The bounds check misses the case when <code>gms == ARRAY_SIZE(gms_size_map) == 17</code>, which is one past 16 – the index of the last array element. The fix is to use <code>>=</code> in the check instead of <code>></code>. This exact error when performing a bounds check is <em>very</em> common: see at least <a href="https://review.coreboot.org/c/coreboot/+/32244">CB:32244</a>, <a href="https://review.coreboot.org/c/coreboot/+/34498">CB:34498</a>, and <a href="https://chromium-review.googlesource.com/c/chromiumos/platform/vboot_reference/+/1752766">CL:1752766</a> for other examples.</p> <p>Another nasty place where off-by-one errors strike is with strings – in particular, when making sure they are null terminated. Here is <a href="https://review.coreboot.org/c/coreboot/+/34374">CB:34374</a> from the ACPI setup of the Getac P470.</p> <pre class="wp-block-preformatted">static long acpi_create_ecdt(acpi_ecdt_t * ecdt) { ... static const char ec_id[] = "\_SB.PCI0.LPCB.EC0"; ... strncpy((char *)ecdt->ec_id, ec_id, strlen(ec_id)); ... }</pre> <p>The problem is that <code>strncpy()</code> will only copy at most <code>strlen(ec_id)</code> characters, which excludes the null character. The author might have been thinking of the similar <code>strlcpy()</code>, which <em>does</em> explicitly null terminate the string buffer even if it never reaches a null character. In this case none of the string-copying functions are needed, since <code>ec_id</code> is a string buffer and so can be copied using a simple <code>memcpy()</code>.</p> <h4 class="wp-block-heading">Boolean vs Bitwise Operators</h4> <p>In C, all integers are implicitly convertible to boolean values and can be used with all boolean operators. While somewhat convenient, this also makes it very easy to mistakenly use a boolean operator when a bitwise one was intended. Let’s take a look at <a href="https://review.coreboot.org/c/coreboot/+/33454">CB:33454</a> from the CIMX southbridge code.</p> <pre class="wp-block-preformatted">void sb_poweron_init(void) { u8 data; ... data = inb(0xCD7); data &= !BIT0; if (!CONFIG(PCIB_ENABLE)) { data |= BIT0; } outb(data, 0xCD7); ... }</pre> <p>Here <code>BIT0</code> is the constant <code>0x1</code>, so <code>!BIT0</code> expands to 0, with the net effect of <code>data</code> being completely cleared, regardless of the previous value from <code>inb()</code>. The intended operator to use was the bitwise negation <code>~</code>, which would only clear the lowest bit. For more examples of this sort of bug, see <a href="https://review.coreboot.org/c/coreboot/+/34560">CB:34560</a> and <a href="https://github.com/riscv/opensbi/commit/3f738f5897a6694b8630d3a9c6751f49c3c7d540">OpenSBI 3f738f5</a>.</p> <h4 class="wp-block-heading">Implicit Integer Conversions</h4> <p>C allows implicit conversions between all integer types, which opens the door for many accidental or unintentional bugs. For an extremely subtle example of this, let’s take a look at <a href="https://github.com/riscv/opensbi/commit/5e4021a2f5ca346d1c12b80d346c1a2e7eb4b501">OpenSBI 5e4021a</a>.</p> <pre class="wp-block-preformatted">void *sbi_memset(void *s, int c, size_t count); void sbi_fifo_init(struct sbi_fifo *fifo, void *queue_mem, u16 entries, u16 entry_size) { ... sbi_memset(fifo->queue, 0, entries * entry_size); }</pre> <p>Do you see the problem? The issue is that <code>entries</code> and <code>entry_size</code> are both 16-bit integers, and by the rules of C are implicitly converted to <code>int</code> before the multiplication. An <code>int</code> cannot hold all possible values of a <code>u16 * u16</code>, and so if the multiplication overflows the intermediate result could be a negative number. On 64-bit platforms <code>size_t</code> will be a <code>u64</code>, and the negative result will then be sign-extended to a massive integer. As the last argument to <code>sbi_memset()</code>, this could lead to a very large out-of-bounds write. The solution is to cast one of the variables to a <code>size_t</code> before the multiplication, which is wide enough to prevent the implicit promotion to <code>int</code>. For other examples of this problem, see <a href="https://review.coreboot.org/c/coreboot/+/33986">CB:33986</a> and <a href="https://review.coreboot.org/c/coreboot/+/34529">CB:34529</a>.</p> <p>Another situation where implicit conversions strike is in error handling. Here is <a href="https://review.coreboot.org/c/coreboot/+/33962">CB:33962</a> in the x86 ACPI code.</p> <pre class="wp-block-preformatted">static ssize_t acpi_device_path_fill(const struct device *dev, char *buf, size_t buf_len, size_t cur); const char *acpi_device_path_join(const struct device *dev, const char *name) { static char buf[DEVICE_PATH_MAX] = {}; size_t len; if (!dev) return NULL; /* Build the path of this device */ len = acpi_device_path_fill(dev, buf, sizeof(buf), 0); if (len <= 0) return NULL; ... }</pre> <p>With the function prototype right there, the problem is obvious: <code>acpi_device_path_fill()</code> returns negative values in a <code>ssize_t</code> to indicate errors, but <code>len</code> is a <code>size_t</code>, so all those negative error values are converted to extremely large integers, thus passing the subsequent error check. During code review this may not at all be obvious though.</p> <p>Both these errors could be prevented using the <code>-Wconversion</code> compiler option, which will warn about all implicit integer conversions. However, there are an incredible number of such conversions in coreboot, and it would be a mammoth task to fix them all.</p> <h4 class="wp-block-heading">Null Pointers</h4> <p>Null pointers need no introduction – they are well known to cause all sorts of problems. For a simple example, let’s take a look at <a href="https://review.coreboot.org/c/coreboot/+/33134">CB:33134</a> from the HiFive Unleashed mainboard.</p> <pre class="wp-block-preformatted">static void fixup_fdt(void *unused) { void *fdt_rom; struct device_tree *tree; /* load flat dt from cbfs */ fdt_rom = cbfs_boot_map_with_leak("fallback/DTB", CBFS_TYPE_RAW, NULL); /* Expand DT into a tree */ tree = fdt_unflatten(fdt_rom); ... }</pre> <p>This code attempts to load a device tree from a location in the CBFS. However, <code>cbfs_boot_map_with_leak()</code> will return a null pointer if the object in the CBFS can’t be found, which will then be dereferenced in the call to <code>fdt_unflatten()</code>. On most systems dereferencing a null pointer will lead to a segfault, since the operating system has set up permissions that prevent accessing the memory at address 0. However, coreboot runs before the operating systems has even started, so there are no memory permissions at all! If <code>fdt_rom</code> is a null pointer, <code>fdt_unflatten()</code> will attempt to expand the device tree from whatever memory is at address 0, leading to who knows what problems. A simple null check will avoid this, but requires the programmer to always remember to put them in.</p> <p>Another common issues with null pointers is that even if you do a check, it might not actually matter if the pointer has already been dereferenced. For example, here is a problem with the EDID parser in <a href="https://review.coreboot.org/c/coreboot/+/32055">CB:32055</a>.</p> <pre class="wp-block-preformatted">int decode_edid(unsigned char *edid, int size, struct edid *out) { ... dump_breakdown(edid); memset(out, 0, sizeof(*out)); <code> </code> if (!edid || memcmp(edid, "\x00\xFF\xFF\xFF\xFF\xFF\xFF\x00", 8)) { printk(BIOS_SPEW, "No header found\n"); return EDID_ABSENT; } ... }</pre> <p>In this case the EDID is dumped doing the null pointer check, but at worst there should only be a wonky dump if <code>edid</code> is null, right? Not necessarily. Since dereferencing a null pointer is undefined behavior, the compiler is allowed to assume that <em>no null pointer dereferences occur in the program</em>. In this case, dereferencing the <code>edid</code> pointer in <code>dump_breakdown()</code> is an implicit assertion that <code>edid</code> is not null, so an over-zealous compiler could remove the following null check! This optimization can be disabled using <code>-fno-delete-null-pointer-checks</code> (which is done in coreboot), but does not prevent any problems that could have happened in the null dereference before the check took place. See this article in <a href="https://lwn.net/Articles/342330/">LWN</a> for details on how a vulnerability from this problem was dealt with in the Linux kernel.</p> <h4 class="wp-block-heading">Conclusion</h4> <p>C has always had the mantra of “trust the programmer”, which makes mistakes and errors very easy to do. Some of these errors can be prevented at compile time using compiler warnings, but many cannot. Coverity and other static analyzers like it are very useful and powerful tools for catching bugs that slip past the compiler and through peer review. However, it is no silver bullet. All of these errors were present in production code that were only caught after the fact, and there are certainly bugs of this sort left that Coverity hasn’t found. What do we do about them, and how can we ever be sure that we’ve caught them all? Today, there are new languages designed from the beginning to enable safe and correct programming. For example, <a href="https://github.com/coreboot/libgfxinit">libgfxinit</a> is written in SPARK, a subset of Ada that can be formally verified at compile time to avoid essentially all of the above errors. There is also the new <a href="https://github.com/oreboot/oreboot">oreboot</a> project written in Rust, which has similar compile time guarantees due to its extensive type system. I hope to see these languages and others increasingly used in the future so that at some point, this job will have become obsolete. 🙂</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/2019/08/22/gsoc-coreboot-coverity-final-update/" rel="bookmark"><time class="entry-date published" datetime="2019-08-22T02:45:08+00:00">August 22, 2019</time><time class="updated" datetime="2019-08-22T02:45:12+00:00">August 22, 2019</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/jwgarber/">jwgarber</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/gsoc/" rel="tag">GSoC</a>, <a href="https://blogs.coreboot.org/blog/tag/gsoc-2019/" rel="tag">GSoC 2019</a></span> </footer> </article> <article id="post-4794" class="post-4794 post type-post status-publish format-standard hentry category-coreboot tag-gsoc tag-gsoc-2019"> <header class="entry-header"> <h2 class="entry-title"><a href="https://blogs.coreboot.org/blog/2019/08/21/gsoc-how-to-use-arm-trusted-firmware-in-coreboot/" rel="bookmark">[GSoC] How to Use ARM Trusted Firmware in Coreboot</a></h2> </header> <div class="entry-content"> <p>Hello, I’m Asami. In this article, I’m going to talk about how to use ARM Trusted Firmware in coreboot for ARMv8 (AArch64). ARM Trusted Firmware provides a reference implementation of secure world software for Armv8-A and Armv8-M. You can see the code via <a href="https://github.com/ARM-software/arm-trusted-firmware">https://github.com/ARM-software/arm-trusted-firmware</a>.</p> <p>Trusted Firmware has 5 steps which are called as BL1, BL2, BL3-1, BL3-2, and BL3-3. BL1 step is similar to the bootblock stage and BL2 is similar to the romstage of coreboot. In the coreboot project, we only use the BL3-1 part that is expected to work on EL3 exception level. The code of BL3-1 will execute just after the ramstage and before the payload when we enable the Trusted Firmware.</p> <h2 class="wp-block-heading">How to enable Trusted Firmware</h2> <p>It’s very easy to enable Trusted Firmware on coreboot. You just need to ‘select ARM64_USE_ARM_TRUSTED_FIRMWARE’ in your Kconfig. If you want to run coreboot on QEMU/AArch64, you need to add the ‘select ARM64_USE_ARM_TRUSTED_FIRMWARE’ at src/mainboard/emulation/qemu-aarch64/Kconfig. The next step switches depending on the configuration at src/arch/arm64/boot.c. Here is the code to switch the next step:</p> <pre class="wp-block-code"><code>// src/arch/arm64/boot.c static void run_payload(struct prog *prog) { void (*doit)(void *); void *arg; doit = prog_entry(prog); arg = prog_entry_arg(prog); u64 payload_spsr = get_eret_el(EL2, SPSR_USE_L); if (CONFIG(ARM64_USE_ARM_TRUSTED_FIRMWARE)) arm_tf_run_bl31((u64)doit, (u64)arg, payload_spsr); else transition_to_el2(doit, arg, payload_spsr); }</code></pre> <h2 class="wp-block-heading">Why using Trusted Firmware</h2> <p>Coreboot for ARMv8 has 2 options to pass an execution from it to a payload. The first is passing execution to a payload directly and the second one is passing to the BL3-1 code before a payload. You always don’t have to use Trusted Firmware. However, you need to enable Trusted Firmware if you want to run Linux because it expects to work with PSCI. PSCI is an abbreviation of Power State Coordination Interface which is a standard interface for power management that can be used by OS vendors for supervisory software working at different levels of privilege on an ARM device. Coreboot doesn’t have the setup for PSCI but Trusted Firmware does.</p> <h2 class="wp-block-heading">Current Status</h2> <p>Unfortunately, QEMU/AArch64 in coreboot doesn’t support Trusted Firmware yet. It means we can’t run Linux with QEMU for ARMv8. I’m now trying to support Trusted Firmware for QEMU/AArch64.</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/2019/08/21/gsoc-how-to-use-arm-trusted-firmware-in-coreboot/" rel="bookmark"><time class="entry-date published" datetime="2019-08-21T13:07:07+00:00">August 21, 2019</time><time class="updated" datetime="2019-08-21T13:07:09+00:00">August 21, 2019</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/d0iasm/">d0iasm</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></span><span class="tags-links"><span class="screen-reader-text">Tags </span><a href="https://blogs.coreboot.org/blog/tag/gsoc/" rel="tag">GSoC</a>, <a href="https://blogs.coreboot.org/blog/tag/gsoc-2019/" rel="tag">GSoC 2019</a></span> </footer> </article> <article id="post-4771" class="post-4771 post type-post status-publish format-standard hentry category-coreboot category-grub2 category-gsoc tag-gsoc tag-gsoc-2019"> <header class="entry-header"> <h2 class="entry-title"><a href="https://blogs.coreboot.org/blog/2019/08/16/gsoc-coreboot-coverity-weeks-11-12/" rel="bookmark">[GSoC] Coreboot Coverity, weeks 11-12</a></h2> </header> <div class="entry-content"> <p>Hello again! For the past two weeks I have been working on Coverity issues in various third party repositories, notably <a href="https://scan.coverity.com/projects/flashrom?tab=overview">flashrom</a> and <a href="https://scan.coverity.com/projects/vboot?tab=overview">vboot</a>. The majority of issues in both repositories are now fixed, with the remaining ones mostly being memory leaks. Also, support for <a href="https://github.com/riscv/opensbi">OpenSBI</a> (a RISC-V supervisor binary interface) was recently added to coreboot, and Coverity picked up <a href="https://lists.infradead.org/pipermail/opensbi/2019-August/000350.html">several issues</a> in that. With one more week left in the summer, the plan now is to tidy up the last few remaining issues in vboot, and shepherd my still in-progress patches through review. As usual, you can see the current status of my patches on <a href="https://review.coreboot.org/q/owner:jgarber1%2540ualberta.ca">Gerrit</a>.</p> <p>Following up from my post last week about neutralizing the ME, this week I decided to try replacing SeaBIOS with GRUB. While originally designed as a bootloader, GRUB can be compiled as a coreboot payload, which removes the need of having a BIOS or UEFI interface at all. Not only does this mean having a legacy-free boot process, but GRUB also has an incredible amount of flexibility over the previous systems. For example, one problem with current full disk encryption schemes is that the bootloader must always remain unencrypted, since factory BIOS/UEFI implementations are unable of unlocking encrypted disks. By embedding GRUB in the coreboot image we can move it off the hard drive and avoid this problem entirely.</p> <p>With this in mind, I decided to try installing GRUB on a system with a single LUKS 1 partition formatted with Btrfs. (GRUB currently doesn’t support LUKS 2, which is what many distributions use by default.) This setup will require two configuration files: one embedded in the coreboot image with instructions on how to unlock the partition, and one on the hard drive for booting the kernel. The first configuration file has to be hand-written, while the second can be generated using <code>grub-mkconfig -o /boot/grub/grub.cfg</code>. The advantage of this two-stage system is that the first configuration file only has to be flashed once, and then all subsequent changes (e.g. adding kernel parameters) can be done with the system file. After tinkering around with the official GRUB <a href="https://www.gnu.org/software/grub/manual/grub/grub.html">documentation</a>, the <a href="https://www.coreboot.org/GRUB2">coreboot wiki</a>, and this <a href="https://bisco.org/notes/coreboot-on-the-x230/">blog post</a>, I pieced together the following bare-bones config file for the payload:</p> <pre class="wp-block-preformatted"># Tell GRUB where to find its modules set prefix=(memdisk)/boot/grub # Keep the same screen resolution when switching to Linux set gfxpayload=keep # I'm not exactly sure what these do, but they look important terminal_output --append cbmemc terminal_output --append gfxterm # Default to first option, automatically boot after 3 seconds set default="0" set timeout=3 # Enable the pager when viewing large files set pager=1 menuentry 'Load Operating System' { # Load the LUKS and Btrfs modules <code>insmod luks</code> <code>insmod btrfs</code> # <code>Unlock all crypto devices (should only be one)</code> <code>cryptomount -a</code> # <code>Load the system GRUB file from the first crypto device</code> <code>set root=(crypto0)</code> <code>configfile /boot/grub/grub.cfg</code> }</pre> <p>Using <code>menuconfig</code>, we can now configure coreboot to use GRUB as a payload.</p> <pre class="wp-block-preformatted">Payload ---> Add a Payload ---> GRUB2 ---> GRUB2 version ---> 2.04 ---> Extra modules to include in GRUB image (luks btrfs gcry_sha256 gcry_rijndael all_video cat) [*] Include GRUB2 runtime config file into ROM image (grub.cfg)</pre> <p>We need to add a few modules to the GRUB image to enable all the features we want: <code>luks</code> and <code>btrfs</code> are self-explanatory, <code>gcry_sha256</code> and <code>gry_rijndael</code> add support for SHA256 and AES (the default hash and cipher for LUKS), <code>all_video</code> adds support for more video and graphics drivers, and <code>cat</code> is useful for printing config files during debugging. We also set here the path to the above <code>grub.cfg</code> file, which by default is in the root of the coreboot tree.</p> <p>After flashing the new coreboot image, you will be greeted by two GRUB menus after booting: the above one for unlocking the partition, and then the system one for booting the kernel.</p> <p>The above GRUB config file is extremely basic, and although all advanced functionality can be done manually by dropping to the GRUB command line, this is very inconvenient. Let’s add two menu entries to the config file for shutting down and rebooting the system. Fortunately, this can be done without rebuilding the ROM from scratch. By default, the GRUB config file is stored as <code>etc/grub.cfg</code> in the <a href="https://www.coreboot.org/CBFS">CBFS</a> (coreboot file system), which is used to store objects in the coreboot image. We can print the layout of the CBFS using the <code>cbfstool</code> utility:</p> <pre class="wp-block-preformatted">$ cbfstool coreboot.rom print FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 58068 none cpu_microcode_blob.bin 0xe3c0 microcode 122880 none fallback/ramstage 0x2c440 stage 105072 none config 0x45f00 raw 488 none revision 0x46140 raw 674 none cmos.default 0x46440 cmos_default 256 none vbt.bin 0x46580 raw 1412 LZMA (3863 decompressed) cmos_layout.bin 0x46b40 cmos_layout 1808 none fallback/postcar 0x472c0 stage 18540 none fallback/dsdt.aml 0x4bb80 raw 15257 none fallback/payload 0x4f780 simple elf 470937 none etc/grub.cfg 0xc2780 raw 670 none (empty) 0xc2a80 null 7523608 none bootblock 0x7ef7c0 bootblock 1512 none</pre> <p>This shows all the objects located in the image, including the stages (bootblock, romstage, ramstage, and payload) and various other configuration files and binaries. Next, we extract the existing config file from this image:</p> <pre class="wp-block-preformatted">$ <code>cbfstool coreboot.rom extract -n etc/grub.cfg -f grub.cfg</code></pre> <p>Now add the following two entries to the end of the extracted file:</p> <pre class="wp-block-preformatted">menuentry 'Poweroff' { halt } menuentry 'Reboot' { reboot }</pre> <p>Now we delete the existing configuration file, and then add our new one back in:</p> <pre class="wp-block-preformatted">$ <code>cbfstool coreboot.rom remove -n etc/grub.cfg</code> $ <code>cbfstool coreboot.rom add -n etc/grub.cfg -f grub.cfg -t raw</code></pre> <p>That’s it! Flash back the new ROM, and you’re good to go.</p> <p>Even with these changes, we still have a very basic configuration file. For more advanced setups (such as booting from a live USB, LVM support, signing kernels with GPG, etc.) I recommend looking at the comprehensive <a href="https://notabug.org/libreboot/libreboot/src/master/resources/grub/config/menuentries/common.cfg">Libreboot </a>GRUB file and its <a href="https://libreboot.org/docs/gnulinux/grub_hardening.html">hardening guide</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/2019/08/16/gsoc-coreboot-coverity-weeks-11-12/" rel="bookmark"><time class="entry-date published" datetime="2019-08-16T03:08:55+00:00">August 16, 2019</time><time class="updated" datetime="2019-09-02T15:31:39+00:00">September 2, 2019</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/jwgarber/">jwgarber</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/grub2/" rel="category tag">GRUB2</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/gsoc/" rel="tag">GSoC</a>, <a href="https://blogs.coreboot.org/blog/tag/gsoc-2019/" rel="tag">GSoC 2019</a></span> </footer> </article> <nav class="navigation pagination" aria-label="Posts pagination"> <h2 class="screen-reader-text">Posts pagination</h2> <div class="nav-links"><span aria-current="page" class="page-numbers current"><span class="meta-nav screen-reader-text">Page </span>1</span> <a class="page-numbers" href="https://blogs.coreboot.org/blog/tag/gsoc/page/2/"><span class="meta-nav screen-reader-text">Page </span>2</a> <span class="page-numbers dots">…</span> <a class="page-numbers" href="https://blogs.coreboot.org/blog/tag/gsoc/page/6/"><span class="meta-nav screen-reader-text">Page </span>6</a> <a class="next page-numbers" href="https://blogs.coreboot.org/blog/tag/gsoc/page/2/">Next page</a></div> </nav> </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>