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 2019 – 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 2019 Tag Feed" href="https://blogs.coreboot.org/blog/tag/gsoc-2019/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/4220" /><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-2019 tag-4220 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 2019</span></h1> </header> <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-4818" class="post-4818 post type-post status-publish format-standard hentry category-bios category-coreboot category-firmware category-gsoc category-uefi tag-gsoc-2019"> <header class="entry-header"> <h2 class="entry-title"><a href="https://blogs.coreboot.org/blog/2019/08/22/gsoc-ghidra-firmware-utilities-wrap-up/" rel="bookmark">[GSoC] Ghidra firmware utilities, wrap-up</a></h2> </header> <div class="entry-content"> <p>Hi everyone. The official programming period for GSoC 2019 is now over, and it’s time for final evaluations. I will use this post to summarize what I’ve worked on this summer, as well as how to use the Ghidra plugin.</p> <p>The project is available on GitHub: <a href="https://github.com/al3xtjames/ghidra-firmware-utils">https://github.com/al3xtjames/ghidra-firmware-utils</a></p> <h3 class="wp-block-heading">Project details</h3> <p>In my <a href="https://docs.google.com/document/d/1IkZHA2lgUH2WHkMiSfr6Q99gskErfmU2cxxPJHZy0KY/edit?usp=sharing">initial project proposal</a>, I planned on writing various filesystem loaders (for hybrid PCI option ROMs, Intel flash descriptor images, coreboot File System images, and UEFI firmware volumes), a binary loader for legacy x86 PCI option ROMs, and a UEFI helper script. I ended up implementing all of these in the Ghidra plugin, and also worked on a UEFI Terse Executable binary loader. You can look at <a href="https://blogs.coreboot.org/blog/author/al3xtjames/">my previous blogposts</a> to see my progress throughout the summer.</p> <p>Here is a description of the components included in the project:</p> <p>FS loaders allow files stored within binary images to be imported directly into Ghidra. The following FS loaders are implemented in this project:</p> <p><strong>Hybrid PCI option ROM</strong></p> <p>Some PCI option ROMs may contain multiple executable ROMs. This is usually used to support multiple firmware types (e.g. a video card with legacy BIOS VGA support and UEFI Graphics Output Protocol support). The FS loader allows each embedded executable ROM image to be imported.</p> <p><strong>Intel firmware descriptor (IFD)</strong></p> <p>Recent Intel platforms have multiple regions on the SPI flash (used to store system firmware). The descriptor region describes the layout of these flash regions. The FS loader allows each flash region to be imported. Ghidra supports nested FS loaders, so other FS loaders (FMAP/CBFS or UEFI FV) can be used to parse certain regions, such as the BIOS region.</p> <p><strong>Flash Map (FMAP)</strong></p> <p>This is another standard for describing flash regions, used by coreboot and various Google devices. Like the IFD FS loader, this allows each defined flash region to be imported, and it can be used with other FS loaders (e.g. the COREBOOT region can be parsed with the CBFS loader).</p> <p><strong>coreboot File System (CBFS)</strong></p> <p>coreboot uses a simple file system to store independent binaries and data files. The CBFS loader can be used to import each CBFS file for analysis; for example, PCI option ROMs stored as CBFS files can be imported. Optional CBFS file compression (LZ4/LZMA) is supported.</p> <p><strong>UEFI firmware volume (FV)/firmware file system (FFS)</strong></p> <p>UEFI firmware images use firmware volumes for storing firmware files, which may consist of multiple sections. The UEFI FV FS loader allows UEFI firmware volumes to be imported, including embedded firmware files/sections.</p> <p>This project also implements a couple of binary loaders:</p> <p><strong>Legacy x86 option ROM</strong></p> <p>PCI option ROMs that target the x86 legacy BIOS contain a raw 16-bit executable image. They also have additional header fields, including a field with the entry point instruction. The binary loader resolves the entry point and specifies that 16-bit x86 disassembly should be used.</p> <p><strong>UEFI Terse Executable (TE)</strong></p> <p>UEFI binaries can use one of two executable formats: the Portable Executable (PE32) format (also used on Windows), and the Terse Executable (TE) format. Terse Executables are essentially simplified PE32 binaries – the numerous DOS/NT/optional headers are condensed into a single TE header, without any superfluous header fields. The binary loader resolves the entry point and defines memory blocks corresponding to the sections defined in the TE header.</p> <p>Finally, a helper script for assisting with the analysis of UEFI binaries is<br />included. The UEFI helper script does the following:</p> <ul class="wp-block-list"><li>Imports a UEFI data type library</li><li>Defines the entry point signature</li><li>Searches for known EFI GUIDs in the .data/.text segments</li><li>Attempts to locate global EFI table pointers (<code>gST</code>/<code>gBS</code>/<code>gRT</code>)</li><li>Attempts to perform propagation of some EFI types to called functions</li></ul> <h3 class="wp-block-heading">Project usage</h3> <p>Instructions for how to build and use the Ghidra plugin are included in the project’s README, but I’ll restate them here.</p> <h4 class="wp-block-heading">Building the plugin</h4> <p>Like other Ghidra plugins (and Ghidra itself), this project uses Gradle as the build system. Set the <code>GHIDRA_INSTALL_DIR</code> environment variable (point it to your Ghidra installation directory) and run <code>gradle</code> to build the plugin. Install the generated ZIP (in the <code>dist</code> directory) by selecting<br /><code>File > Install Extensions</code> in Ghidra, and then clicking the green plus icon.</p> <h4 class="wp-block-heading">Using the FS loaders</h4> <p>Load the specified input file into Ghidra (drag and drop or use <strong>File > Import File</strong>). Assuming the input file is supported by a FS loader, Ghidra should indicate that a container file was detected, and will allow you to batch import all enclosed files or view the file system.</p> <p>Note that Ghidra does support parsing nested filesystems with multiple FS loaders. For example, UEFI firmware volumes in the BIOS region of an Intel firmware image can be parsed by first importing the Intel firmware image and then importing the BIOS region (select <strong>Import</strong> or <strong>Open File System</strong> in the right-click menu).</p> <h4 class="wp-block-heading">Using the UEFI helper script</h4> <p>After loading a UEFI executable (PE32 or TE), you can run the UEFI Helper script from the <strong>Script Manager</strong> window (under <strong>Window</strong>). Select UEFIHelper.java and click the green “Run Script” button.</p> <p>Currently, the UEFI helper script assumes the entry point matches the standard driver/application signature (with <code>EFI_HANDLE</code> and <code>EFI_SYSTEM_TABLE *</code> parameters). SEC/PEI/SMM modules have different entry point parameters, which will have to be manually specified.</p> <h3 class="wp-block-heading">Future work</h3> <p>While my work for GSoC 2019 is complete, I think the following additions would be useful for this project (and UEFI reverse-engineering in general):</p> <p><strong>Processor module for disassembling <a href="https://vzimmer.blogspot.com/2015/08/efi-byte-code.html">EFI Byte Code</a> (EBC)</strong></p> <p>EFI Byte Code is a byte code format used for platform-independent UEFI applications/drivers. Ghidra currently doesn’t support the EBC virtual machine architecture. Fortunately, it is possible to add support for an architecture by creating a <a href="https://ghidra.re/courses/languages/html/sleigh.html">SLEIGH</a> processor specification.</p> <p><strong>Upstreamed Terse Executable loader</strong></p> <p>As previously described, TE binaries are very similar to PE binaries. Ghidra already has parsers for the data directory and section header structures, which are present in both PE and TE binaries. My TE loader had to reimplement these parsers, as the existing parsers depended on the NT header, which isn’t present in TE binaries. Removing the NT header dependency from the data directory/section header parsers would allow Ghidra’s existing parsers to be reused by the TE loader. This would also make it easier to upstream the TE loader.</p> <p><strong>Support for SEC/PEI/SMM modules (UEFI helper script</strong>)</p> <p>Instead of assuming the entry point parameters, the script could prompt the user to select the module type, or somehow retrieve the module type from the FFS header (if the FS loader was used).</p> <p><strong>Additional GUID heuristics (UEFI helper script</strong>)</p> <p>The script could locate calls to <code>EFI_BOOT_SERVICES</code>/<code>EFI_RUNTIME_SERVICES</code> functions with GUID parameters and automatically apply the <code>EFI_GUID</code> data type.</p> <p><strong>Protocol database (UEFI helper script)</strong></p> <p>Similar to the existing GUID->name database (imported from UEFITool), a database for mapping protocol definitions to the structure name could be created. The script could use this database to automatically apply the correct protocol structure type in calls to <code>LocateProtocol</code>/etc.</p> <p><strong>Very basic dependency graph (inspired by </strong><a href="https://github.com/LongSoft/UEFITool/issues/44"><strong>this UEFITool issue</strong></a><strong>) (UEFI helper script)</strong></p> <p>The script could locate all calls to protocol consumption/production functions in <code>EFI_BOOT_SERVICES</code> (such as <code>LocateProtocol</code>, <code>InstallProtocol</code>, etc) and use this to generate a basic overview of the protocols used by the current UEFI binary.</p> <h3 class="wp-block-heading">Acknowledgements</h3> <p>I would like to thank my mentors Martin Roth and Raul Rangel for their continued assistance during the past 12 weeks. This has been a great opportunity, and it certainly wouldn’t have been possible without their help. I look forward to contributing to coreboot and other related projects (including Ghidra) 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/2019/08/22/gsoc-ghidra-firmware-utilities-wrap-up/" rel="bookmark"><time class="entry-date published" datetime="2019-08-22T03:20:04+00:00">August 22, 2019</time><time class="updated" datetime="2020-07-29T05:48:04+00:00">July 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/al3xtjames/">al3xtjames</a></span></span><span class="cat-links"><span class="screen-reader-text">Categories </span><a href="https://blogs.coreboot.org/blog/category/bios/" rel="category tag">BIOS</a>, <a href="https://blogs.coreboot.org/blog/category/coreboot/" rel="category tag">coreboot</a>, <a href="https://blogs.coreboot.org/blog/category/firmware/" rel="category tag">firmware</a>, <a href="https://blogs.coreboot.org/blog/category/gsoc/" rel="category tag">GSoC</a>, <a href="https://blogs.coreboot.org/blog/category/uefi/" rel="category tag">UEFI</a></span><span class="tags-links"><span class="screen-reader-text">Tags </span><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> <article id="post-4759" class="post-4759 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/07/gsoc-coreboot-coverity-weeks-8-10/" rel="bookmark">[GSoC] Coreboot Coverity, weeks 8-10</a></h2> </header> <div class="entry-content"> <p>Hello everyone! Coverity has come back online again after its long upgrade, and with it a pile of new scan issues (over 100). I put aside a week to fix all the new issues in parts of the code base I had already worked through, and then spent the next two weeks finishing <code>soc</code> and the Cavium vendorcode. Referring to the <a href="https://scan.coverity.com/projects/coreboot?tab=overview">overview page</a>, there are now 300 scan issues left in the code base. While a considerable number, this consists almost entirely of patches still going through review, vboot, and the AMD vendorcode — everything outside of this is done. At this point, the plan at the beginning of the summer was to continue working on the AMD vendorcode, but after discussing with my mentors we have decided to do something else. The AMD vendorcode is extremely dense, and with the upcoming deprecations in 4.11 it may not be around for much longer. The plan now is to work on <a href="https://scan.coverity.com/projects/vboot?tab=overview">vboot</a> and the recently resurrected scan page for <a href="https://scan.coverity.com/projects/flashrom?tab=overview">flashrom</a>.</p> <p>Anyway, enough with the boring schedule stuff. I finally got around this week to wiping the ME on my T500, and like last time it was a lot more involved than I expected. Onwards!</p> <p>The <a href="https://en.wikipedia.org/wiki/Intel_Management_Engine">Intel Management Engine</a> (ME) is an autonomous coprocessor integrated into all Intel chipsets since 2006. Providing the basis for Intel features such as <a href="https://en.wikipedia.org/wiki/Intel_Active_Management_Technology">AMT</a>, <a href="https://mjg59.dreamwidth.org/33981.html">Boot Guard</a>, and Protected Audio Video Path (used for DRM), the ME has complete access to the system memory and networking. The ME runs continuously as long as the system has power, even if the computer is asleep or turned off, and on systems with AMT can even be accessed remotely. Naturally, this is an incredible security risk. On modern systems it is impossible to disable the ME completely, since any attempt to do so will start a watchdog timer that will shutdown the computer after 30 minutes. However, in older chipsets (such as the one in the T500), no such timer exists, allowing attempts to disable it entirely.</p> <p>The ME firmware is located in the SPI flash chip, which is divided into multiple regions. Using the coreboot utility <code>ifdtool</code>, we can analyze a dumped ROM to check the regions in the layout along with their offsets within the flash image.</p> <pre class="wp-block-preformatted">$ ifdtool -f layout.txt factory.rom File factory.rom is 8388608 bytes Wrote layout to layout.txt $ cat layout.txt 00000000:00000fff fd 00600000:007fffff bios 00001000:005f5fff me 005f6000:005f7fff gbe 005f8000:005fffff pd</pre> <p>These regions are as follows:</p> <ul class="wp-block-list"><li>Intel Flash Descriptor (<code>fd</code>) – Describes the layout of the rest of the flash chip, as well as various chipset configuration options. This <a href="https://blogs.coreboot.org/blog/2019/06/25/gsoc-ghidra-firmware-utilities-week-5/">blog post</a> by Alex James has further information about the IFD.</li><li>BIOS (<code>bios</code>) – Contains the factory BIOS. Normally this is the only part of the flash chip that you overwrite when installing coreboot.</li><li>Management Engine (<code>me</code>) – Firmware for the ME coprocessor, including a kernel (ThreadX on older models, MINIX 3 on newer ones), as well as a variety of other modules for network access and remote management.</li><li>Gigabit Ethernet (<code>gbe</code>) – Configuration for the Gigabit Ethernet controller, including the system’s MAC address.</li><li>Platform Data (<code>pd</code>) – Other miscellaneous data for the factory BIOS, which coreboot doesn’t use.</li></ul> <p>The IFD also contains read and write permissions for the rest of the flash chip, which we can analyze using <code>ifdtool</code>.</p> <pre class="wp-block-preformatted">$ ifdtool -d factory.rom ... FLMSTR1: 0x1a1b0000 (Host CPU/BIOS) Platform Data Region Write Access: enabled GbE Region Write Access: enabled Intel ME Region Write Access: disabled Host CPU/BIOS Region Write Access: enabled Flash Descriptor Write Access: disabled Platform Data Region Read Access: enabled GbE Region Read Access: enabled Intel ME Region Read Access: disabled Host CPU/BIOS Region Read Access: enabled Flash Descriptor Read Access: enabled Requester ID: 0x0000 ...</pre> <p>Unfortunately, ME write access is disabled for the host CPU, which prevents us from overwriting it using an internal flash — we’re gonna have to get out the external programmer. If you recall from last time, accessing the SOIC of the T500 required a laborious process of extracting the motherboard from the case, so this time I cut a little hole in the frame to make flashing easier. As it turned out, having this easy access port was very handy.</p> <figure class="wp-block-image"><img decoding="async" src="https://blogs.coreboot.org/files/2019/08/flash-1.jpg" alt="" class="wp-image-4765" /><figcaption>The old way.</figcaption></figure> <figure class="wp-block-image"><img decoding="async" src="https://blogs.coreboot.org/files/2019/08/hole-1-1.jpg" alt="" class="wp-image-4767" /><figcaption>The new — a bit hacky, but it works.</figcaption></figure> <p>After reading back the ROM image, I decided to use try using <a href="https://github.com/corna/me_cleaner">me_cleaner</a>, a tool for partially deblobbing the ME firmware on newer laptops, and for mine removing it entirely. Following the <a href="https://github.com/corna/me_cleaner/wiki/External-flashing">instructions</a> for an external flash, we use the <code>-S</code> flag to clean the firmware.</p> <pre class="wp-block-preformatted">$ python me_cleaner.py -S -O coreboot-nome.rom coreboot-orig.rom Full image detected Found FPT header at 0x1010 Found 13 partition(s) Found FTPR header: FTPR partition spans from 0xd2000 to 0x142000 ME/TXE firmware version 4.1.3.1038 (generation 1) Public key match: Intel ME, firmware versions 4.x.x.x The meDisable bit in ICHSTRP0 is NOT SET, setting it now… The meDisable bit in MCHSTRP0 is NOT SET, setting it now… Disabling the ME region… Wiping the ME region… Done! Good luck!</pre> <p>After wiping the image, we can use <code>ifdtool</code> again to see that the ME region has been completely erased.</p> <pre class="wp-block-preformatted">00000000:00000fff fd 00600000:007fffff bios 005f6000:005f7fff gbe 005f8000:005fffff pd</pre> <p>While this is the most sure-fire way to ensure the ME has been disabled, it’s not perfect — on boot the ME coprocessor will still attempt to read from its firmware in the flash region, and finding it not there will hang in an error state. However, it has been discovered through reverse engineering that Intel has incorporated various <a href="https://github.com/corna/me_cleaner/wiki/HAP-AltMeDisable-bit">bits</a> into the IFD that will disable the ME soon after boot. (One of these, the <a href="http://blog.ptsecurity.com/2017/08/disabling-intel-me.html">High Assurance Platform</a> “HAP” bit, was incorporated at the request of the US government, which also understands the security risks of an unfettered ME.) For my laptop, this consists of setting two bits in the <code>ICHSTRP</code> and <code>MCHSTRP</code>, which <code>me_cleaner</code> does by default. After enabling this, the ME should gracefully shutdown after boot, which hopefully will cause the fewest system stability issues.</p> <p>Finally after all that, let’s use <code>ifdtool</code> again to unlock all regions of the flash chip, which should ideally negate the need of ever doing an external flash again.</p> <pre class="wp-block-preformatted">$ ifdtool -u coreboot-nome.rom</pre> <p>Let’s write it! Unlike last time we write the entire image, not just the BIOS region.</p> <pre class="wp-block-preformatted">$ flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=4096 -w coreboot-nome-unlock.rom</pre> <p>Now the moment of truth. After hitting the power button … nothing. Gah.</p> <p>Well, not exactly nothing. The screen doesn’t turn on, but the CD drive is making noises, so it’s not completely dead. Hmmm, let’s try again, but this time only setting the disable bits without wiping the ME region. This can be done using the <code>-s</code> flag of <code>me_cleaner</code> (which incidentally has a bug that required a <a href="https://github.com/corna/me_cleaner/pull/288">small patch</a>).</p> <pre class="wp-block-preformatted">$ python me_cleaner.py -s -O coreboot-nome.rom coreboot-orig.rom</pre> <p>Reflashing again … same problem. Nothing.</p> <p>Not completely sure what to do and worried that the ME was actually needed to boot, I decided to flash a pre-compiled <a href="https://libreboot.org/docs/install/t500_external.html">Libreboot</a> image on the laptop, which has the ME disabled out of the box and should hopefully Just Work. … And it did! The computer booted gracefully into the OS with no glitches or stability issues that I could see. Perfect. So disabling the ME is technically possible, but how exactly do I do it? Asking around a bit on IRC, I was directed to the coreboot <code>bincfg</code> utility, which is capable of generating an ME-less IFD from scratch. Following this <a href="https://www.coreboot.org/Board:lenovo/x200#Without_ME_firmware_updates.2FAMT">similar guide</a> for the X200, I was able to piece together a complete ROM.</p> <p>First, we need to generate a new IFD. The <code>bincfg</code> directory contains configuration files for the X200, which we can fortunately re-use since the T500 has the same controller hub.</p> <pre class="wp-block-preformatted">$ bincfg ifd-x200.spec ifd-x200.set ifd.bin</pre> <p>This IFD comes with only three regions, and has the ME disable bits set by default.</p> <pre class="wp-block-preformatted">00000000:00000fff fd 00003000:007fffff bios 00001000:00002fff gbe</pre> <p>There are also configuration files for generating a new GbE region, but that requires certain fiddlings with the MAC address that I don’t know how to do — for now we can re-use the GbE from the old ROM, using <code>ifdtool</code> to chop it out.</p> <pre class="wp-block-preformatted">$ ifdtool -x coreboot-orig.rom File coreboot-orig.rom is 8388608 bytes Flash Region 0 (Flash Descriptor): 00000000 - 00000fff Flash Region 1 (BIOS): 00600000 - 007fffff Flash Region 2 (Intel ME): 00001000 - 005f5fff Flash Region 3 (GbE): 005f6000 - 005f7fff Flash Region 4 (Platform Data): 005f8000 - 005fffff $ mv flashregion_3_gbe.bin gbe.bin</pre> <p>Next, we place the IFD and GbE regions in a <code>blobs</code> directory in the root of the coreboot tree, and then direct the build system to use them when generating an image. Here are the <code>menuconfig</code> settings:</p> <pre class="wp-block-preformatted">General setup ---> [*] Use CMOS for configuration values ---> [*] Allow use of binary-only repository Mainboard ---> Mainboard vendor ---> Lenovo ---> Mainboard model ---> ThinkPad T500 ---> Size of CBFS filesystem in ROM (0x7fd000) Chipset ---> [*] Add Intel descriptor.bin file (blobs/ifd.bin) ---> [*] Add gigabit ethernet configuration (blobs/gbe.bin) ---> Protect flash regions ---> Unlock flash regions Devices ---> Display ---> Linear "high-resolution" framebuffer Payloads ---> Add a payload ---> SeaBIOS ---> SeaBIOS version ---> master</pre> <p>Note that since the ME and Platform Data regions have been deleted from the new layout, we can expand the CBFS to the entire <code>bios</code> size — <code>0x7fd000</code> bytes, nearly the entire flash chip. This will allow in the future installing bigger and more interesting payloads, such as <a href="https://www.gnu.org/software/grub/index.html">GRUB</a> or <a href="https://www.linuxboot.org/">LinuxBoot</a>.</p> <p>Finally, I wrote this new image to the flash chip. It worked. Huzzah!</p> <p>After installation, we can <a href="https://github.com/corna/me_cleaner/wiki/Get-the-status-of-Intel-ME">check the status</a> of the ME using <code>intelmetool</code>.</p> <pre class="wp-block-preformatted">$ sudo intelmetool -m Can't find ME PCI device</pre> <p>Perfect.</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/07/gsoc-coreboot-coverity-weeks-8-10/" rel="bookmark"><time class="entry-date published" datetime="2019-08-07T03:31:19+00:00">August 7, 2019</time><time class="updated" datetime="2019-08-07T03:31:22+00:00">August 7, 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-4754" class="post-4754 post type-post status-publish format-standard hentry category-coreboot category-gsoc category-tiano-core category-uefi tag-gsoc-2019"> <header class="entry-header"> <h2 class="entry-title"><a href="https://blogs.coreboot.org/blog/2019/07/31/gsoc-ghidra-firmware-utilities-week-10/" rel="bookmark">[GSoC] Ghidra firmware utilities, week 10</a></h2> </header> <div class="entry-content"> <p>As stated in last week’s blogpost, I have started working on the UEFI helper script (aptly named UEFIHelper). The aim of this script is to assist with reverse engineering UEFI binaries. Similar projects exist for IDA Pro, including <a href="https://github.com/snare/ida-efiutils">ida-efiutils</a>, <a href="https://github.com/danse-macabre/ida-efitools">ida-efitools</a>, and <a href="https://github.com/gdbinit/EFISwissKnife">EFISwissKnife</a>.</p> <h4 class="wp-block-heading">Background information</h4> <p>UEFI executables are either PE32(+) or <a href="https://blogs.coreboot.org/blog/2019/07/24/4743/">TE binaries</a>. The signature of the entry point function depends on the module type; some examples are PEI modules, DXE drivers, and UEFI applications. DXE drivers and standard UEFI applications use the following entry point function:</p> <pre class="wp-block-code"><code>EFI_STATUS _ModuleEntryPoint ( IN EFI_HANDLE ImageHandle, IN EFI_SYSTEM_TABLE *SystemTable );</code></pre> <p>Other types of modules (such as PEI modules and PEI/DXE core modules) may have different parameters and return types for the entry point function. Nevertheless, we’ll focus on the standard entry point for now. <code>ImageHandle</code> is a firmware-allocated handle for the current EFI application. <code>SystemTable</code> is a pointer to the <code>EFI_SYSTEM_TABLE</code> structure, which in turn has pointers to other EFI tables (such as <code>EFI_BOOT_SERVICES</code> and <code>EFI_RUNTIME_SERVICES</code>). These tables provide data structures and function pointers for standard UEFI functionality, such as getting/setting NVRAM variables, locating/installing UEFI protocols, loading additional UEFI images, rebooting the system, etc.</p> <p>UEFI’s extensibility is largely implemented through the use of protocols. Protocols are data structures used to enable communication between different UEFI modules, and can be identified by a GUID. A simplified example could be a a UEFI driver for a graphics card. It could support pre-boot graphics output by installing an implementation of the <a href="https://github.com/tianocore/edk2/blob/9344f0921518309295da89c221d10cbead8531aa/MdePkg/Include/Protocol/GraphicsOutput.h"><code>EFI_GRAPHICS_OUTPUT_PROTOCOL</code></a>, which could then be located and used by other UEFI applications and drivers for graphics output.</p> <h4 class="wp-block-heading">UEFIHelper progress</h4> <p><a href="https://github.com/tianocore/edk2/tree/d21e5dbbbf11589113d39619b3e01eb1e8966819/MdePkg/Include">MdePkg in EDK2</a> includes headers for core UEFI types and protocols. Given a parser configuration file, the C parser in Ghidra can be used to generate data type archives, which are used for storing type definitions in Ghidra. I used the MdePkg headers to generate UEFI data type archives for x86, x86_64, ARMv7, and ARMv8 (AArch64). UEFIHelper will automatically load the correct data type library for the current program’s architecture.</p> <p>UEFIHelper will search for known GUIDs in the .data segment of the current UEFI program and apply the <code>EFI_GUID</code> type definition. UEFIHelper will also fix the entry point function signature to match the standard entry point for UEFI DXE drivers and applications.</p> <div class="wp-block-image"><figure class="aligncenter"><img fetchpriority="high" decoding="async" width="2053" height="1053" src="https://blogs.coreboot.org/files/2019/07/1-1-1.png" alt="" class="wp-image-4755" /></figure></div> <div class="wp-block-image"><figure class="aligncenter"><img decoding="async" src="https://blogs.coreboot.org/files/2019/07/2-2-1.png" alt="" class="wp-image-4756" /></figure></div> <p>UEFIHelper is a part of the ghidra-firmware-utils extension, and is <a href="https://github.com/al3xtjames/ghidra-firmware-utils">available on GitHub as usual</a>. I will continue to work on UEFIHelper during the next week.</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/07/31/gsoc-ghidra-firmware-utilities-week-10/" rel="bookmark"><time class="entry-date published" datetime="2019-07-31T23:49:59+00:00">July 31, 2019</time><time class="updated" datetime="2020-07-29T05:48:04+00:00">July 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/al3xtjames/">al3xtjames</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>, <a href="https://blogs.coreboot.org/blog/category/tiano-core/" rel="category tag">Tiano Core</a>, <a href="https://blogs.coreboot.org/blog/category/uefi/" rel="category tag">UEFI</a></span><span class="tags-links"><span class="screen-reader-text">Tags </span><a href="https://blogs.coreboot.org/blog/tag/gsoc-2019/" rel="tag">GSoC 2019</a></span> </footer> </article> <article id="post-4743" class="post-4743 post type-post status-publish format-standard hentry category-firmware category-gsoc category-tiano-core category-uefi tag-gsoc-2019"> <header class="entry-header"> <h2 class="entry-title"><a href="https://blogs.coreboot.org/blog/2019/07/24/4743/" rel="bookmark">[GSoC] Ghidra firmware utilities, week 9</a></h2> </header> <div class="entry-content"> <p>Last week, I finished up my work on the UEFI firmware volume FS loader. This was the last FS loader I planned on writing for this project, so now it’s time to work on writing additional binary loaders and helper scripts to assist with UEFI reverse engineering. During the past couple of days, I’ve been working on a loader for Terse Executable (TE) binaries.</p> <p>For the most part, UEFI binaries are standard PE32(+) executables. Standard headers such as the DOS stub, COFF header, and image headers are present. In order to reduce the size of binaries required for UEFI Platform Initialization, the TE binary format was created. The TE header only includes the fields needed for execution, dropping unnecessary fields such as the DOS stub. TE binaries are otherwise similar to PE32 binaries. EDK2 has <a href="https://github.com/tianocore/edk2/blob/3806e1fd139775610d8f2e7541a916c3a91ad989/BaseTools/Source/C/Include/IndustryStandard/PeImage.h">additional documentation regarding the TE header</a>.</p> <p>Like the existing PE32 binary loader, the TE binary loader defines the program sections and defines the entry point function. It can be used in conjunction with the UEFI firmware volume FS loader to import TE image sections for analysis.</p> <div class="wp-block-image"> <figure class="aligncenter"><img decoding="async" src="https://blogs.coreboot.org/files/2019/07/2-1.png" alt=""/></figure></div> <div class="wp-block-image"> <figure class="aligncenter"><img decoding="async" src="https://blogs.coreboot.org/files/2019/07/3-3-1.png" alt="" class="wp-image-4751"/></figure></div> <div class="wp-block-image"> <figure class="aligncenter"><img decoding="async" src="https://blogs.coreboot.org/files/2019/07/4-1-1.png" alt="" class="wp-image-4752"/></figure></div> <p>The TE binary loader is included <a href="https://github.com/al3xtjames/ghidra-firmware-utils/commit/a458659ba90221d9f06c024f87d0f3962cc65cf3">in the latest commit in ghidra-firmware-utils</a>. As always, feel free to submit an issue report if you encounter any problems with it.</p> <h4 class="wp-block-heading">Plans for this week</h4> <p>I have started working on the UEFI helper script. This script aims to assist with UEFI reverse engineering by loading UEFI type definitions, defining GUIDs, and fixing the entry point.</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/07/24/4743/" rel="bookmark"><time class="entry-date published" datetime="2019-07-24T17:14:16+00:00">July 24, 2019</time><time class="updated" datetime="2022-07-14T11:44:52+00:00">July 14, 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/al3xtjames/">al3xtjames</a></span></span><span class="cat-links"><span class="screen-reader-text">Categories </span><a href="https://blogs.coreboot.org/blog/category/firmware/" rel="category tag">firmware</a>, <a href="https://blogs.coreboot.org/blog/category/gsoc/" rel="category tag">GSoC</a>, <a href="https://blogs.coreboot.org/blog/category/tiano-core/" rel="category tag">Tiano Core</a>, <a href="https://blogs.coreboot.org/blog/category/uefi/" rel="category tag">UEFI</a></span><span class="tags-links"><span class="screen-reader-text">Tags </span><a href="https://blogs.coreboot.org/blog/tag/gsoc-2019/" rel="tag">GSoC 2019</a></span> </footer> </article> <article id="post-4729" class="post-4729 post type-post status-publish format-standard hentry category-coreboot category-firmware category-gsoc category-uefi tag-gsoc-2019"> <header class="entry-header"> <h2 class="entry-title"><a href="https://blogs.coreboot.org/blog/2019/07/17/gsoc-ghidra-firmware-utilities-weeks-6-8/" rel="bookmark">[GSoC] Ghidra firmware utilities, weeks 6-8</a></h2> </header> <div class="entry-content"> <p>Hello everyone. It’s been a few weeks since I’ve written my last blog post, and during that time I’ve been working on the FS loader for UEFI firmware images. This FS loader aims to implement functionality similar to <a href="https://github.com/LongSoft/UEFITool">UEFITool</a> in Ghidra.</p> <p>As described in the previous blog post, Intel platforms divide the flash chip into several regions, including the BIOS region. On UEFI systems, the BIOS region is used to store UEFI firmware components, which are organized in a hierarchy. This hierarchy begins with UEFI firmware volumes, which consist of FFS (firmware file system) files. In turn, these FFS files can contain multiple sections. Firmware volumes can also be nested within FFS files. <a href="https://trmm.net/UEFI_notes">This helpful reference by Trammell Hudson</a> as well as <a href="http://opensecuritytraining.info/IntroBIOS_files/Day2_05_Advanced%20x86%20-%20BIOS%20and%20SMM%20Internals%20-%20UEFI%20RE.pdf">this presentation from OpenSecurityTraining</a> have some additional information regarding UEFI firmware volumes.</p> <p>For example, a UEFI firmware implementation could have a firmware volume specifically for the Driver eXecution Environment (DXE phase). Stored as FFS files, DXE drivers within the firmware volume could consist of a PE32 section to store the actual driver binary, as well as a UI section to store the name of the driver.</p> <p>So far, I’ve implemented basic firmware volume parsing in the FS loader; I’ve pushed this to the <a href="https://github.com/al3xtjames/ghidra-firmware-utils">GitHub repository</a>. Currently, this doesn’t handle FFS file or section parsing.</p> <div class="wp-block-image"><figure class="aligncenter"><img decoding="async" width="622" height="651" src="https://blogs.coreboot.org/files/2019/07/2.png" alt="" class="wp-image-4730" srcset="https://blogs.coreboot.org/files/2019/07/2.png 622w, https://blogs.coreboot.org/files/2019/07/2-287x300.png 287w" sizes="(max-width: 622px) 100vw, 622px" /></figure></div> <p>FFS file and section parsing is still a work-in-progress, but here’s a preview:</p> <figure class="wp-block-image"><img decoding="async" width="731" height="762" src="https://blogs.coreboot.org/files/2019/07/3.png" alt="" class="wp-image-4731" srcset="https://blogs.coreboot.org/files/2019/07/3.png 731w, https://blogs.coreboot.org/files/2019/07/3-288x300.png 288w" sizes="(max-width: 731px) 100vw, 731px" /></figure> <p>This is mostly complete, but there are still some nasty bugs related to FFS alignment that I’m working on fixing. My focus for this week is to finish up this FS loader.</p> <h4 class="wp-block-heading">Update (2019-07-19)</h4> <p>I have committed support for UEFI FFS file/section parsing in the GitHub repo. Please open an issue report if you encounter any issues with it (such as missing files/sections that UEFITool or other tools parse without issues).</p> <figure class="wp-block-image"><img loading="lazy" decoding="async" width="731" height="899" src="https://blogs.coreboot.org/files/2019/07/3-1.png" alt="" class="wp-image-4737" srcset="https://blogs.coreboot.org/files/2019/07/3-1.png 731w, https://blogs.coreboot.org/files/2019/07/3-1-244x300.png 244w" sizes="auto, (max-width: 731px) 100vw, 731px" /></figure> </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/07/17/gsoc-ghidra-firmware-utilities-weeks-6-8/" rel="bookmark"><time class="entry-date published" datetime="2019-07-17T23:29:21+00:00">July 17, 2019</time><time class="updated" datetime="2020-07-29T05:48:04+00:00">July 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/al3xtjames/">al3xtjames</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/firmware/" rel="category tag">firmware</a>, <a href="https://blogs.coreboot.org/blog/category/gsoc/" rel="category tag">GSoC</a>, <a href="https://blogs.coreboot.org/blog/category/uefi/" rel="category tag">UEFI</a></span><span class="tags-links"><span class="screen-reader-text">Tags </span><a href="https://blogs.coreboot.org/blog/tag/gsoc-2019/" rel="tag">GSoC 2019</a></span> </footer> </article> <article id="post-4726" class="post-4726 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/07/17/gsoc-how-to-run-c-code-in-bootblock-stage-for-qemu-aarch64/" rel="bookmark">[GSoC] How to Run C Code in Bootblock Stage for QEMU/AArch64</a></h2> </header> <div class="entry-content"> <p>Hi, I’m Asami. My project “adding QEMU/AArch64 support to coreboot” is making good progress. I’ve almost done to write porting code and I’m now writing a new tool to make a FIT payload for QEMU/AArch64. <a href="https://review.coreboot.org/c/coreboot/+/33387">Here</a> is my CL. In this article, I’m going to talk about how to run C code in the bootblock stage. </p> <p>The way to run C code before DRAM has been initialized is various in the coreboot project. The most famous and used in the x86 system is known as the Cache-As-Ram (CAR). CAR can be set up by 1. enable CPU cache 2. enable the ‘no eviction’ mode 3. change cache mode from write-through to write-back. ‘No-eviction’ means that the CPU doesn’t write any data to DRAM as long as the size of data is less than the CPU cache. Then, you can get all the data from the CPU cache. The implementation for CAR is <a href="https://github.com/coreboot/coreboot/blob/master/src/cpu/intel/car/non-evict/cache_as_ram.S">src/cpu/intel/car/non-evict/cache_as_ram.S</a>.</p> <p>Another way to run C code especially implemented in ARM system is relocating the bootblock code to SRAM. System on a Chip (SoC) has an ARM CPU and often includes SRAM as a cache. For example, QEMU VExpress machine has SRAM is located at 0x48000000 that we can know in <a href="https://github.com/qemu/qemu/blob/master/hw/arm/vexpress.c#L120">qemu/hw/arm/vexpress.c#L120</a>.</p> <p>However, what should the system that doesn’t have SRAM do? My target machine, QEMU virt machine, doesn’t have SRAM according to the implementation of <a href="https://github.com/qemu/qemu/blob/master/hw/arm/virt.c">qemu/hw/arm/virt.c</a>. In this case, should we initialize DRAM earlier? </p> <p>The answer is No but it’s only for my project. Because QEMU is not actual hardware so DRAM already works. I just need to relocate the bootblock code to DRAM directly. I believe that other ARM systems that have no SRAM should initialize DRAM earlier.</p> <p>You can see the relocation code in bootblock_custom.S under review. <a href="https://review.coreboot.org/c/coreboot/+/33387">https://review.coreboot.org/c/coreboot/+/33387</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/07/17/gsoc-how-to-run-c-code-in-bootblock-stage-for-qemu-aarch64/" rel="bookmark"><time class="entry-date published" datetime="2019-07-17T09:36:49+00:00">July 17, 2019</time><time class="updated" datetime="2019-07-17T09:36:51+00:00">July 17, 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> <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-2019/page/2/"><span class="meta-nav screen-reader-text">Page </span>2</a> <a class="page-numbers" href="https://blogs.coreboot.org/blog/tag/gsoc-2019/page/3/"><span class="meta-nav screen-reader-text">Page </span>3</a> <a class="next page-numbers" href="https://blogs.coreboot.org/blog/tag/gsoc-2019/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>