<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>retrage.github.io</title><link>https://retrage.github.io/</link><description>Recent content on retrage.github.io</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Tue, 17 Sep 2024 17:00:00 +0900</lastBuildDate><atom:link href="https://retrage.github.io/index.xml" rel="self" type="application/rss+xml"/><item><title>Creating Custom Gemini Commands in Project IDX</title><link>https://retrage.github.io/2024/09/17/hacking-project-idx-ai-command-en.html/</link><pubDate>Tue, 17 Sep 2024 17:00:00 +0900</pubDate><guid>https://retrage.github.io/2024/09/17/hacking-project-idx-ai-command-en.html/</guid><description>&lt;p>Authors: &lt;a href="https://github.com/retrage">@retrage&lt;/a> &lt;a href="https://github.com/benevolent0505">@benevolent0505&lt;/a>&lt;/p>
&lt;p>&lt;strong>Translated by Gemini&lt;/strong>&lt;/p>
&lt;p>&lt;a href="https://idx.dev/">Project IDX&lt;/a> is an experimental development environment provided by Google that can be accessed via a web browser. Built on top of VS Code, one of its key features is the integration of Gemini for development assistance.&lt;/p>
&lt;p>In this article, we will introduce a method we&amp;rsquo;ve discovered to create custom Gemini commands in Project IDX, which is not documented in the official documentation.&lt;/p>
&lt;hr>
&lt;h2 id="gemini-integration-in-project-idx">Gemini Integration in Project IDX&lt;/h2>
&lt;p>In Project IDX, Gemini can be used to generate code, provide explanations, and more, similar to GitHub Copilot. While this functionality is integrated into Project IDX, it&amp;rsquo;s actually implemented as an extension plugin. Like regular VS Code extensions, Gemini plugin logs can be found at the following path:&lt;/p></description></item><item><title>Project IDXでカスタムのGeminiコマンドを作る方法を見つけた</title><link>https://retrage.github.io/2024/09/17/hacking-project-idx-ai-command.html/</link><pubDate>Tue, 17 Sep 2024 17:00:00 +0900</pubDate><guid>https://retrage.github.io/2024/09/17/hacking-project-idx-ai-command.html/</guid><description>&lt;p>著者: &lt;a href="https://github.com/retrage">@retrage&lt;/a> &lt;a href="https://github.com/benevolent0505">@benevolent0505&lt;/a>&lt;/p>
&lt;p>&lt;a href="https://idx.dev">Project IDX&lt;/a>とは、Googleが実験的に提供している、Webブラウザから利用できる開発環境である。VSCodeをベースとしており、Geminiを使った開発支援機能が統合されているのが売りの一つとなっている。&lt;/p></description></item><item><title>ARM64でptraceより2000倍以上速いシステムコールフック作った</title><link>https://retrage.github.io/2024/07/31/svc-hook.html/</link><pubDate>Wed, 31 Jul 2024 17:53:45 +0900</pubDate><guid>https://retrage.github.io/2024/07/31/svc-hook.html/</guid><description>&lt;p>元ネタ: &lt;a href="https://yasukata.hatenablog.com/entry/2021/10/14/145642">https://yasukata.hatenablog.com/entry/2021/10/14/145642&lt;/a>&lt;/p>
&lt;h2 id="せっかちな人向け">せっかちな人向け&lt;/h2>
&lt;ul>
&lt;li>ARM64向けの高速なシステムコールフックを作った&lt;/li>
&lt;li>マイクロベンチマークではptraceの2000倍以上、seccompの140倍程度高速&lt;/li>
&lt;li>コードはこちら: &lt;a href="https://github.com/retrage/svc-hook">https://github.com/retrage/svc-hook&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="zpolineとは">zpolineとは&lt;/h2>
&lt;p>USENIX ATC 2023において、zpolineというx86/Linux向けの高速なシステムコールフックが提案された[1]。これは、binary rewritingで2バイトの命令である &lt;code>syscall&lt;/code>や&lt;code>sysenter&lt;/code>を同じ2バイト命令である&lt;code>callq *%rax&lt;/code>に置き換えた上で0x0のアドレスにトランポリンを設置する、というものである。&lt;/p></description></item><item><title>今年の振り返り</title><link>https://retrage.github.io/2023/12/31/2023-review.html/</link><pubDate>Sun, 31 Dec 2023 21:39:31 +0900</pubDate><guid>https://retrage.github.io/2023/12/31/2023-review.html/</guid><description>&lt;p>今年もそろそろ終わりそうなので、何やったかを振り返ってみる。&lt;/p>
&lt;h2 id="aarch64-support-for-rust-hypervisor-firmware">aarch64 Support for Rust Hypervisor Firmware&lt;/h2>
&lt;p>~1月
Rust Hypervisor Firmwareはいままでx86_64でしか動かなかったが、Cloud Hypervisorがaarch64も対応するようになったので、aarch64の勉強も兼ねて実装した。去年の夏にPoCとして実装して、最終的に今年の1月にマージされた。すでにCIに組み込まれており、少しずつ改善のPRをもらいつつ、ある程度安定して動くようになった。
ちなみに、このaarch64対応を入れるためにマルチアーキテクチャ対応をした。これにより、その後RISC-V対応も比較的少ない労力で入るようになった。&lt;/p></description></item><item><title>OSはどうやってP-coreとE-coreを使い分けているのか</title><link>https://retrage.github.io/2023/08/20/intel-hfi.html/</link><pubDate>Sun, 20 Aug 2023 10:54:56 +0000</pubDate><guid>https://retrage.github.io/2023/08/20/intel-hfi.html/</guid><description>&lt;p>Alder Lake以降のIntel CPUでは、P-coreとE-coreの2種類のコアが搭載されている。
P-coreは性能重視、E-coreは省電力重視という位置づけで、OSがうまくこれらのコアを使い分けることで、消費電力と性能の両立が図られている。
ここまでの話は広く知られているが、実際にどのようにしてOSに対してコアの使い分けをさせているのかの実装レベルでの解説は (少なくとも日本語では) ほぼ存在しないようなので調べてみた。&lt;/p></description></item><item><title>VisionFive 2をJTAGデバッグ</title><link>https://retrage.github.io/2023/03/25/visionfive2-jtag-debugging.html/</link><pubDate>Sat, 25 Mar 2023 07:34:56 +0000</pubDate><guid>https://retrage.github.io/2023/03/25/visionfive2-jtag-debugging.html/</guid><description>&lt;p>VisionFive 2 (以下、VF2) はStarFive Technologyが開発したSBCである。名前からわかるように、RISC-VのSoCを搭載している。ここではVF2をJTAGデバッグする方法を簡単にまとめる。&lt;/p></description></item><item><title>2022年にやったこと</title><link>https://retrage.github.io/2022/12/31/2022-review.html/</link><pubDate>Sat, 31 Dec 2022 11:54:56 +0000</pubDate><guid>https://retrage.github.io/2022/12/31/2022-review.html/</guid><description>&lt;p>&lt;a href="https://twitter.com/retrage/status/1608981455182651392">https://twitter.com/retrage/status/1608981455182651392&lt;/a>&lt;/p>
&lt;p>こういう不安を感じたので、心の安寧を取り戻すために今月と今年に何をやったのかをまとめてみる。なお、自分の中で「取り組んでいることを話題にすると完成しなくなる」ジンクスがあるので、いまやっていることはここでは書かない。&lt;/p></description></item><item><title>Allwinner NezhaにJTAGで接続する</title><link>https://retrage.github.io/2022/01/16/allwinner-nezha-jtag.html/</link><pubDate>Sun, 16 Jan 2022 04:14:19 +0000</pubDate><guid>https://retrage.github.io/2022/01/16/allwinner-nezha-jtag.html/</guid><description>&lt;p>Allwinner NezhaはD1という64-bit RISC-VなSoCが載ったSBCである。Linuxがちゃんと動くRISC-Vマシンとしてはかなり安価なため一部で人気がある。
ここではこれにJTAGで接続してみた話をメモ程度に書いておく。なお、今回は接続してOpenOCDで認識できた程度でその先のGDBでのデバッグはできていない。&lt;/p></description></item><item><title>Apple File Systemの下にはEFI driverが埋まっている</title><link>https://retrage.github.io/2021/09/18/apfs-efi-jumpstart.html/</link><pubDate>Sat, 18 Sep 2021 17:41:01 +0000</pubDate><guid>https://retrage.github.io/2021/09/18/apfs-efi-jumpstart.html/</guid><description>&lt;h1 id="apple-file-systemの下にはefi-driverが埋まっている">Apple File Systemの下にはEFI driverが埋まっている&lt;/h1>
&lt;p>Apple File System (APFS)はAppleが自社製品向けに開発したファイルシステムである．APFSの仕様は公開されており以下で参照できる．&lt;/p></description></item><item><title>9pfsPkg: Network Boot from Bell Labs</title><link>https://retrage.github.io/2020/08/01/9pfspkg-en.html/</link><pubDate>Sat, 01 Aug 2020 16:15:51 +0000</pubDate><guid>https://retrage.github.io/2020/08/01/9pfspkg-en.html/</guid><description>&lt;p>I developed a Plan 9 file system (9P) client for UEFI to enable network booting from a commodity 9P server. By leveraging the simplicity and flexibility of 9P, the UEFI can do network boot from cloud storage without any effort. This blog post gives you a brief overview of 9pfsPkg.&lt;/p>
&lt;p>The source code, introduction slides, and presentation video are available at:&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://github.com/yabits/9pfsPkg">https://github.com/yabits/9pfsPkg&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://speakerdeck.com/retrage/network-boot-from-bell-labs">https://speakerdeck.com/retrage/network-boot-from-bell-labs&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://youtu.be/3PX19nWrygQ">https://youtu.be/3PX19nWrygQ&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="what-is-network-boot">What is Network Boot?&lt;/h2>
&lt;p>Network boot is a boot method which loading boot images over the network. To make this possible, the BIOS has its network stack.
There are two methods for network booting: PXE Boot and HTTP Boot.&lt;/p></description></item><item><title>UEFI向け9P File Systemを作ってクラウドからネットワークブートできるようにした</title><link>https://retrage.github.io/2020/06/15/9pfspkg.html/</link><pubDate>Mon, 15 Jun 2020 18:37:23 +0000</pubDate><guid>https://retrage.github.io/2020/06/15/9pfspkg.html/</guid><description>&lt;p>UEFI向け9P File Systemを実装した．
これにより9Pサーバからネットワークブートができるようになった．
さらにFUSEと組み合わせることで少ない労力で9Pサーバ経由で
クラウドからネットワークブートができるようになった．&lt;/p></description></item><item><title>Linux Kernel Library Nabla Containers Internals</title><link>https://retrage.github.io/2020/05/11/lkl-nabla-internals.html/</link><pubDate>Mon, 11 May 2020 18:51:01 +0000</pubDate><guid>https://retrage.github.io/2020/05/11/lkl-nabla-internals.html/</guid><description>&lt;p>This post describes the design and implementation of Linux Kernel Library Nabla Containers (LKL Nabla), Linux based unikernels as processes. The previous post introduces LKL Nabla and provides how to build and run. Since most of the unikernel work is done by frankenlibc LKL/musl, mainly focus on frankenlibc Solo5 port in this post.&lt;/p>
&lt;p>You can find LKL Nabla code at:&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://github.com/retrage/runnc/tree/lkl-musl">https://github.com/retrage/runnc/tree/lkl-musl&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://github.com/retrage/frankenlibc/tree/solo5">https://github.com/retrage/frankenlibc/tree/solo5&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="modifications-to-runnc">Modifications to runnc&lt;/h2>
&lt;p>Before diving into frankenlibc code, let’s take a look at the modifications to runnc.&lt;/p></description></item><item><title>EDK2におけるDebugPrintErrorLevel</title><link>https://retrage.github.io/2020/05/06/edk2-error-level.html/</link><pubDate>Wed, 06 May 2020 11:23:20 +0000</pubDate><guid>https://retrage.github.io/2020/05/06/edk2-error-level.html/</guid><description>&lt;p>EDK2のコードには&lt;code>DebugPrint()&lt;/code>が多く埋め込まれている．
この関数は第一引数に&lt;code>ErrorLevel&lt;/code>をとり，
ビルド時に与える&lt;code>PcdDebugPrintErrorLevel&lt;/code>を変えることによりデバッグ出力を制御できる．
この値は&lt;code>*.dsc&lt;/code>に以下のような記述をすることで設定できる．&lt;/p></description></item><item><title>Porting Linux to Nabla Containers</title><link>https://retrage.github.io/2020/04/18/lkl-nabla-en.html/</link><pubDate>Sat, 18 Apr 2020 17:10:13 +0000</pubDate><guid>https://retrage.github.io/2020/04/18/lkl-nabla-en.html/</guid><description>&lt;p>This is an introduction of Linux Kernel Library ported to Nabla Containers.&lt;/p>
&lt;p>&lt;a href="https://github.com/nabla-containers/runnc.git">runnc&lt;/a>
is an OCI runtime that runs process-level isolated unikernels.
It is built on the top of &lt;a href="https://github.com/Solo5/solo5">Solo5&lt;/a>,
a sandbox for unikernels, and several unikernels (MirageOS, IncludeOS, Rumprun) run on it.
The original runnc uses Rumprun, a NetBSD based unikernel.
However, as Docker is started from Linux,
it is needed to have system call level compatibility with Linux.
Therefore, I ported Linux Kernel Library (LKL) and musl libc to Solo5
and put together with runnc.&lt;/p></description></item><item><title>ccov: printfデバッグを支援するツール</title><link>https://retrage.github.io/2020/03/04/ccov-introduction.html/</link><pubDate>Wed, 04 Mar 2020 19:23:37 +0000</pubDate><guid>https://retrage.github.io/2020/03/04/ccov-introduction.html/</guid><description>&lt;p>ここではコードカバレッジ計測を元にしたprintfデバッグ支援ツールであるccovを作ったので紹介する．&lt;/p>
&lt;p>コードは以下で公開している．&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://github.com/retrage/ccov">https://github.com/retrage/ccov&lt;/a>&lt;/li>
&lt;/ul>
&lt;p>gcov, llvm-covなどはコードカバレッジを測定できるツールである．
これらは基本的にOS上で動き，簡単にコンパイラを入れ替えたりログを生成できること前提としている．
一方でOSや組み込みの開発ではデバッガが利用できずprintfデバッグをせざるを得ない場合がある．&lt;/p></description></item><item><title>Debugging OVMF with GDB</title><link>https://retrage.github.io/2019/12/05/debugging-ovmf-en.html/</link><pubDate>Thu, 05 Dec 2019 17:26:19 +0000</pubDate><guid>https://retrage.github.io/2019/12/05/debugging-ovmf-en.html/</guid><description>&lt;p>In this blog post,
I will describe how to debug OVMF using GDB
without any special tool unlike another post[1].&lt;/p>
&lt;h2 id="code-mapping-in-uefi">Code Mapping in UEFI&lt;/h2>
&lt;p>On x64 UEFI, it provides flat single address memory space
and place the firmware itself and UEFI images on the space
without any memory protection.
In this way, we can do source code level debugging
any UEFI code with debugger.
On OVMF, each feature is modularized
and the module is loaded as UEFI image.
BootServices is included in &lt;code>DxeCore.efi&lt;/code>,
loaded at boot time.&lt;/p></description></item><item><title>EFI_STATUSの値</title><link>https://retrage.github.io/2019/11/26/efi-status-code.html/</link><pubDate>Tue, 26 Nov 2019 09:40:56 +0000</pubDate><guid>https://retrage.github.io/2019/11/26/efi-status-code.html/</guid><description>&lt;p>毎回&lt;code>EFI_STATUS&lt;/code>の値を調べるのが手間なのでここでまとめておく．&lt;/p>
&lt;h2 id="tldr">TL;DR&lt;/h2>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th style="text-align: left">EFI_STATUS&lt;/th>
 &lt;th style="text-align: left">Value (64-bit)&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td style="text-align: left">EFI_SUCCESS&lt;/td>
 &lt;td style="text-align: left">0x0&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_LOAD_ERROR&lt;/td>
 &lt;td style="text-align: left">0x8000000000000001&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_INVALID_PARAMETER&lt;/td>
 &lt;td style="text-align: left">0x8000000000000002&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_UNSUPPORTED&lt;/td>
 &lt;td style="text-align: left">0x8000000000000003&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_BAD_BUFFER_SIZE&lt;/td>
 &lt;td style="text-align: left">0x8000000000000004&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_BUFFER_TOO_SMALL&lt;/td>
 &lt;td style="text-align: left">0x8000000000000005&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_NOT_READY&lt;/td>
 &lt;td style="text-align: left">0x8000000000000006&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_DEVICE_ERROR&lt;/td>
 &lt;td style="text-align: left">0x8000000000000007&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_WRITE_PROTECTED&lt;/td>
 &lt;td style="text-align: left">0x8000000000000008&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_OUT_OF_RESOURCES&lt;/td>
 &lt;td style="text-align: left">0x8000000000000009&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_VOLUME_CORRUPTED&lt;/td>
 &lt;td style="text-align: left">0x800000000000000a&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_VOLUME_FULL&lt;/td>
 &lt;td style="text-align: left">0x800000000000000b&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_NO_MEDIA&lt;/td>
 &lt;td style="text-align: left">0x800000000000000c&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_MEDIA_CHANGED&lt;/td>
 &lt;td style="text-align: left">0x800000000000000d&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_NOT_FOUND&lt;/td>
 &lt;td style="text-align: left">0x800000000000000e&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_ACCESS_DENIED&lt;/td>
 &lt;td style="text-align: left">0x800000000000000f&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_NO_RESPONSE&lt;/td>
 &lt;td style="text-align: left">0x8000000000000010&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_NO_MAPPING&lt;/td>
 &lt;td style="text-align: left">0x8000000000000011&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_TIMEOUT&lt;/td>
 &lt;td style="text-align: left">0x8000000000000012&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_NOT_STARTED&lt;/td>
 &lt;td style="text-align: left">0x8000000000000013&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_ALREADY_STARTED&lt;/td>
 &lt;td style="text-align: left">0x8000000000000014&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_ABORTED&lt;/td>
 &lt;td style="text-align: left">0x8000000000000015&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_ICMP_ERROR&lt;/td>
 &lt;td style="text-align: left">0x8000000000000016&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_TFTP_ERROR&lt;/td>
 &lt;td style="text-align: left">0x8000000000000017&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_PROTOCOL_ERROR&lt;/td>
 &lt;td style="text-align: left">0x8000000000000018&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_INCOMPATIBLE_VERSION&lt;/td>
 &lt;td style="text-align: left">0x8000000000000019&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_SECURITY_VIOLATION&lt;/td>
 &lt;td style="text-align: left">0x800000000000001a&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_CRC_ERROR&lt;/td>
 &lt;td style="text-align: left">0x800000000000001b&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_END_OF_MEDIA&lt;/td>
 &lt;td style="text-align: left">0x800000000000001c&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_END_OF_FILE&lt;/td>
 &lt;td style="text-align: left">0x800000000000001f&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_INVALID_LANGUAGE&lt;/td>
 &lt;td style="text-align: left">0x8000000000000020&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_COMPROMISED_DATA&lt;/td>
 &lt;td style="text-align: left">0x8000000000000021&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_HTTP_ERROR&lt;/td>
 &lt;td style="text-align: left">0x8000000000000023&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_NETWORK_UNREACHABLE&lt;/td>
 &lt;td style="text-align: left">0x8000000000000064&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_HOST_UNREACHABLE&lt;/td>
 &lt;td style="text-align: left">0x8000000000000065&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_PROTOCOL_UNREACHABLE&lt;/td>
 &lt;td style="text-align: left">0x8000000000000066&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_PORT_UNREACHABLE&lt;/td>
 &lt;td style="text-align: left">0x8000000000000067&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_CONNECTION_FIN&lt;/td>
 &lt;td style="text-align: left">0x8000000000000068&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_CONNECTION_RESET&lt;/td>
 &lt;td style="text-align: left">0x8000000000000069&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_CONNECTION_REFUSED&lt;/td>
 &lt;td style="text-align: left">0x800000000000006a&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_WARN_UNKNOWN_GLYPH&lt;/td>
 &lt;td style="text-align: left">0x1&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_WARN_DELETE_FAILURE&lt;/td>
 &lt;td style="text-align: left">0x2&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_WARN_WRITE_FAILURE&lt;/td>
 &lt;td style="text-align: left">0x3&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_WARN_BUFFER_TOO_SMALL&lt;/td>
 &lt;td style="text-align: left">0x4&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_WARN_STALE_DATA&lt;/td>
 &lt;td style="text-align: left">0x5&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td style="text-align: left">EFI_WARN_FILE_SYSTEM&lt;/td>
 &lt;td style="text-align: left">0x6&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;h2 id="edk2での定義">EDK2での定義&lt;/h2>
&lt;pre tabindex="0">&lt;code class="language-c:MdePkg/Include/Uefi/UefiBaseType.h:24" data-lang="c:MdePkg/Include/Uefi/UefiBaseType.h:24">///
/// Function return status for EFI API.
///
typedef RETURN_STATUS EFI_STATUS;
&lt;/code>&lt;/pre>&lt;pre tabindex="0">&lt;code class="language-c:MdePkg/Include/Base.h:959" data-lang="c:MdePkg/Include/Base.h:959">//
// Status codes common to all execution phases
//
typedef UINTN RETURN_STATUS;
&lt;/code>&lt;/pre>&lt;p>なので&lt;code>EFI_STATUS&lt;/code>は&lt;code>UINTN&lt;/code>である．
x64では&lt;code>UINTN&lt;/code>は&lt;code>UINT64&lt;/code>となっている．&lt;/p></description></item><item><title>OVMFのデバッグ</title><link>https://retrage.github.io/2019/11/05/debugging-ovmf.html/</link><pubDate>Tue, 05 Nov 2019 14:16:39 +0000</pubDate><guid>https://retrage.github.io/2019/11/05/debugging-ovmf.html/</guid><description>&lt;p>ここではgdbを用いたOVMFのデバッグ方法について説明する．
すでにOVMFのデバッグについて書かれた記事[1]が存在するが，
ここでは特別なツールなどは使わずに通常のgdbでOVMFをデバッグする．&lt;/p></description></item><item><title>LLVMのEFI Byte Codeバックエンドを作る</title><link>https://retrage.github.io/2019/07/20/llvm-backend-for-ebc.html/</link><pubDate>Sat, 20 Jul 2019 09:37:42 +0000</pubDate><guid>https://retrage.github.io/2019/07/20/llvm-backend-for-ebc.html/</guid><description>&lt;p>ここでは開発しているLLVMのEFI Byte Code (EBC)バックエンドの概要と
EBCバックエンド固有の問題などについてみていく．&lt;/p>
&lt;p>ソースコードは以下で公開している．&lt;/p></description></item><item><title>文鎮化したMinnowboardを復旧させる</title><link>https://retrage.github.io/2019/07/14/bricked-minnowboard.html/</link><pubDate>Sun, 14 Jul 2019 14:24:13 +0000</pubDate><guid>https://retrage.github.io/2019/07/14/bricked-minnowboard.html/</guid><description>&lt;p>MinnowboardはIntel Atomを搭載した
シングルボードコンピュータである．
Minnowboardを使った実験で誤ったファームウェアを書き込んでしまい
brick (文鎮化) させてしまったので
SPI Flashを外部から書き換えることで復旧させる．&lt;/p></description></item><item><title>ELVMのEFI Byte Codeバックエンドを作る</title><link>https://retrage.github.io/2019/07/13/elvm-ebc.html/</link><pubDate>Sat, 13 Jul 2019 17:23:26 +0000</pubDate><guid>https://retrage.github.io/2019/07/13/elvm-ebc.html/</guid><description>&lt;p>ここでは
&lt;a href="https://github.com/shinh/elvm">ELVM&lt;/a>
のEFI Byte Codeバックエンドについて紹介する．
特にELVM IRとEFI Byte Codeのsemantic gapに注目する．&lt;/p>
&lt;h2 id="efi-byte-codeについて">EFI Byte Codeについて&lt;/h2>
&lt;p>EFI Byte Code (EBC)はUEFI Specificationで定義されている
アーキテクチャ非依存なUEFI向けデバイスドライバのための仮想マシンである，
EBCの詳細については過去の記事である
&lt;a href="https://retrage.github.io/2018/11/11/efi-byte-code-myth.html">EFI Byte Code解説&lt;/a>
を参考にしたい．&lt;/p></description></item><item><title>Librarizing Linux kernel for Unikernels</title><link>https://retrage.github.io/2019/06/02/lkl-on-unikraft-en.html/</link><pubDate>Sun, 02 Jun 2019 19:35:32 +0000</pubDate><guid>https://retrage.github.io/2019/06/02/lkl-on-unikraft-en.html/</guid><description>&lt;p>I ported the Linux kernel to Unikraft as an external library.
This makes it possible to reuse the rich functions of the Linux kernel
for Unikernel with less functionality.
In this blog post, I describe the overview of the library.&lt;/p>
&lt;h2 id="background">Background&lt;/h2>
&lt;h3 id="linux-kernel-library">Linux Kernel Library&lt;/h3>
&lt;p>The Linux kernel is a well-maintained mature open source OS kernel.
Recently, there have been researches that propose reuse its components.
&lt;a href="https://github.com/lkl/linux">The Linux Kernel Library (LKL)&lt;/a>
is one of them, which uses the Linux kernel as a form of Library OS
with minimum modifications.
LKL is not currently official Linux project,
but it is actively being developed (v4.19 is latest).
Below is the architecture of LKL.&lt;/p></description></item><item><title>Linux kernelをUnikernelのライブラリ化する</title><link>https://retrage.github.io/2019/05/30/lkl-on-unikraft.html/</link><pubDate>Thu, 30 May 2019 23:26:23 +0000</pubDate><guid>https://retrage.github.io/2019/05/30/lkl-on-unikraft.html/</guid><description>&lt;p>Linux kernelをUnikraftのライブラリ化した．
これにより機能の少ないUnikernelの資源として
Linux kernelの持つ機能を利用することが可能となる．&lt;/p></description></item><item><title>正規表現からLLVM IRを生成する</title><link>https://retrage.github.io/2019/05/12/regex-to-llvm-ir.html/</link><pubDate>Sun, 12 May 2019 17:47:26 +0000</pubDate><guid>https://retrage.github.io/2019/05/12/regex-to-llvm-ir.html/</guid><description>&lt;h1 id="正規表現からllvm-irを生成する">正規表現からLLVM IRを生成する&lt;/h1>
&lt;p>正規表現は文字列マッチングなどに広く用いられている形式言語であるが，
等価な決定性有限オートマトン(DFA)に変換できることが知られている．
&lt;a href="https://github.com/google/redgrep">google/redgrep&lt;/a>
は与えられた正規表現から等価なDFAに相当するネイティブコードを
LLVMにより生成する．
ここではredgrepを改造して
正規表現からどのようなLLVM IRが生成されるのかをみてみる．&lt;/p></description></item><item><title>技術書典6で新刊「UEFI読本 GRUB編」を頒布</title><link>https://retrage.github.io/2019/04/13/efi-book2-ad.html/</link><pubDate>Sat, 13 Apr 2019 12:18:33 +0000</pubDate><guid>https://retrage.github.io/2019/04/13/efi-book2-ad.html/</guid><description>&lt;h1 id="技術書典6で新刊uefi読本-grub編を頒布">技術書典6で新刊「UEFI読本 GRUB編」を頒布&lt;/h1>
&lt;p>2019年4月14日に池袋サンシャインシティで開催される
技術書典6において「海洋軟件」として
新刊「UEFI読本 GRUB編」を頒布する。
既刊「UEFI読本 基礎編 Linux編」も基礎編を分離し
「UEFI読本 Linux編」として頒布する。
配置先は「う27」である。&lt;/p></description></item><item><title>LinuxにおけるEFI Variableをみてみる</title><link>https://retrage.github.io/2018/12/20/linux-efivars.html/</link><pubDate>Thu, 20 Dec 2018 10:09:49 +0000</pubDate><guid>https://retrage.github.io/2018/12/20/linux-efivars.html/</guid><description>&lt;h1 id="linuxにおけるefi-variableをみてみる">LinuxにおけるEFI Variableをみてみる&lt;/h1>
&lt;p>この記事は
&lt;a href="https://qiita.com/advent-calendar/2018/linux">Linux Advent Calendar 2018&lt;/a>
の20日目の記事として書かれた．
ここではLinux kerenlにおけるEFI Variableのコードをみていく．&lt;/p></description></item><item><title>ebcvm: A Usermode EFI Byte Code Virtual Machine</title><link>https://retrage.github.io/2018/12/19/introduction-to-ebcvm.html/</link><pubDate>Wed, 19 Dec 2018 00:00:00 +0000</pubDate><guid>https://retrage.github.io/2018/12/19/introduction-to-ebcvm.html/</guid><description>&lt;p>この記事は
&lt;a href="https://adventar.org/calendars/2915">自作OS Advent Calendar 2018&lt;/a>
の19日目の記事として書かれた．
ここでは，フルスクラッチで開発したEFI Byte Code Virtual Machineである
ebcvm[1]と開発したのELVMのEBCバックエンド[2]について紹介する．&lt;/p></description></item><item><title>EFI Byte Code解説</title><link>https://retrage.github.io/2018/11/11/efi-byte-code-myth.html/</link><pubDate>Sun, 11 Nov 2018 22:30:22 +0000</pubDate><guid>https://retrage.github.io/2018/11/11/efi-byte-code-myth.html/</guid><description>&lt;p>本記事は2018年11月10日に開催されたkernelvm 北陸 Part4において
発表した内容[10]をまとめたものである．
ここではUEFIの持つ独自のbyte codeであるEFI Byte CodeとそのVMについてみていく．&lt;/p></description></item><item><title>EFI stubなArch Linuxのインストール</title><link>https://retrage.github.io/2018/10/13/efi-stub-install.html/</link><pubDate>Sat, 13 Oct 2018 00:20:31 +0000</pubDate><guid>https://retrage.github.io/2018/10/13/efi-stub-install.html/</guid><description>&lt;p>QEMU上の仮想マシンにEFI stubなArch Linuxをインストールする。
ここでのホストはUbuntu 16.04.4 TLSとする。
なお[1][2][3][4]を参考にした。&lt;/p></description></item><item><title>技術書典5で「UEFI読本 基礎編 Linux編」を頒布</title><link>https://retrage.github.io/2018/10/01/efi-book-ad.html/</link><pubDate>Mon, 01 Oct 2018 03:28:10 +0000</pubDate><guid>https://retrage.github.io/2018/10/01/efi-book-ad.html/</guid><description>&lt;p>2018年10月8日に池袋サンシャインシティで開催される
技術書典5において「海洋軟件」として
「UEFI読本 基礎編 Linux編」を頒布する．
配置先は「お09」である．&lt;/p></description></item><item><title>LKL.js: Running Linux Kernel on JavaScript *Directly*</title><link>https://retrage.github.io/2018/07/25/lkl-js-en.html/</link><pubDate>Wed, 25 Jul 2018 20:29:00 +0000</pubDate><guid>https://retrage.github.io/2018/07/25/lkl-js-en.html/</guid><description>&lt;p>I ported Linux kernel directly on JavaScript.
In other words, I translated the Linux kernel to JavaScript using Emscripten,
and Unlike JSLinux, it runs without emulators.&lt;/p>
&lt;p>&lt;img src="https://retrage.github.io/img/lkl-js-architecture.png" alt="LKL.js Architecture">&lt;/p>
&lt;p>The following is the working repository.&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://github.com/retrage/linux/tree/retrage/em-v2">https://github.com/retrage/linux/tree/retrage/em-v2&lt;/a>&lt;/li>
&lt;/ul>
&lt;p>I published a demonstration site for LKL.js.
Please enable SharedArrayBuffer and try it out&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://retrage.github.io/lkl-js">LKL.js Demo&lt;/a>&lt;/li>
&lt;/ul>
&lt;p>I also published slides about LKL.js.&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://speakerdeck.com/retrage/lkl-dot-js-running-linux-kernel-on-javascript-star-directly-star">https://speakerdeck.com/retrage/lkl-dot-js-running-linux-kernel-on-javascript-star-directly-star&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="linux-kernel-library-lkl">Linux Kernel Library (LKL)&lt;/h2>
&lt;p>We use Linux Kernel Library (LKL) which makes the Linux kernel an anykernel.
LKL is a fork of torvalds/linux.
It is designed to put LKL specific code only in
&lt;code>arch/lkl&lt;/code> and runs without modifications of other code.
By this design, it makes easy to follow the mainline. (Currently v4.16)
Since LKL is anykernel, it runs on user space of
various OS such as Linux, FreeBSD, and Windows etc.&lt;/p></description></item><item><title>LKL.js: Linux kernelを直接JavaScript上で動かす</title><link>https://retrage.github.io/2018/07/21/lkl-js.html/</link><pubDate>Sat, 21 Jul 2018 15:30:00 +0000</pubDate><guid>https://retrage.github.io/2018/07/21/lkl-js.html/</guid><description>&lt;p>Linux kernelを直接JavaScript上で動かした．
つまり，JSLinuxのようにEmulatorをJavaScriptで作成し，
その上でLinuxを動かすのではなく，
JavaScriptで書かれたLinuxを生成し，それを動かす，ということである．&lt;/p></description></item><item><title>HiFive1でZephyr</title><link>https://retrage.github.io/2018/06/26/zephyr-on-hifive1.html/</link><pubDate>Tue, 26 Jun 2018 23:19:50 +0000</pubDate><guid>https://retrage.github.io/2018/06/26/zephyr-on-hifive1.html/</guid><description>&lt;p>HiFive1とは，SiFiveによって開発されたRISC-V搭載のArduino互換ボードである．
一方，Zephyrは，Linux Foundationにより開発が進められている組み込み向けOSである．
upstreamのZephyrはHiFive1に対応している．
ここでは，ZephyrをHiFive1向けにビルドしてみる．&lt;/p></description></item><item><title>RustでBrainfuck処理系を高速化して遊んでみる</title><link>https://retrage.github.io/2018/06/18/brainfuck-performance.html/</link><pubDate>Mon, 18 Jun 2018 22:37:02 +0000</pubDate><guid>https://retrage.github.io/2018/06/18/brainfuck-performance.html/</guid><description>&lt;p>Brainfuckとは&lt;code>&amp;gt;&amp;lt;+-.,[]&lt;/code>の8つの命令からなるプログラミング言語である．
実装が簡単であるために，すでに多くの言語によって実装がなされている．
ここでは，
&lt;a href="https://eli.thegreenplace.net/2017/adventures-in-jit-compilation-part-1-an-interpreter.html">Adventures in JIT compilation: Part 1 - an interpreter&lt;/a>
を参考にC++の実装をRustに移植し，そのパフォーマンスを計測し，比較をして遊んでみる．&lt;/p></description></item><item><title>8cc in Lazy K</title><link>https://retrage.github.io/2018/04/01/8cc-lazyk.html/</link><pubDate>Sun, 01 Apr 2018 21:17:53 +0000</pubDate><guid>https://retrage.github.io/2018/04/01/8cc-lazyk.html/</guid><description>&lt;p>本日は4月1日で，エイプリルフールの日である．
ただ，書いている現在は午後9時で，ちょっと嘘をつくには遅すぎる時間である．そこで，今回は何にも役に立たないものを作ってみようと思った．
そこで，表題の通り，Lazy Kで書かれた8ccを生成して遊んでみた．&lt;/p></description></item><item><title>Google V8 JavaScript EngineでのWebAssemblyのi32.addの実装を見てみる</title><link>https://retrage.github.io/2018/03/04/v8-wasm-i32add-internal.html/</link><pubDate>Sun, 04 Mar 2018 14:43:55 +0000</pubDate><guid>https://retrage.github.io/2018/03/04/v8-wasm-i32add-internal.html/</guid><description>&lt;p>WebAssembly(以下，wasm)については，既に多くの解説記事が存在するため，
wasmについての説明は割愛する．
ここでは，wasmがどのように実装され，実行されるのかを見ていく．
参照する実装はGoogle V8 JavaScript Engineの
&lt;code>1b254a25163fd84a7696ff62e87cb6dcde7e13f2&lt;/code>である．&lt;/p></description></item><item><title>Rustでcoreboot payload</title><link>https://retrage.github.io/2017/12/18/coreboot-ffi.html/</link><pubDate>Mon, 18 Dec 2017 23:28:27 +0000</pubDate><guid>https://retrage.github.io/2017/12/18/coreboot-ffi.html/</guid><description>&lt;p>この記事は&lt;a href="https://adventar.org/calendars/2282">自作OS Advent Calendar&lt;/a>
の19日目の記事として書かれた．
ここでは，corebootのpayloadをRustを使って作ってみる．
corebootはファームウェアなのでOSとは異なるが，そこはご愛嬌ということで．&lt;/p></description></item><item><title>Linux kernelの5-Level Paging有効化部分を読んでみる</title><link>https://retrage.github.io/2017/12/13/five-level-paging.html/</link><pubDate>Wed, 13 Dec 2017 20:22:09 +0000</pubDate><guid>https://retrage.github.io/2017/12/13/five-level-paging.html/</guid><description>&lt;p>この記事は&lt;a href="https://qiita.com/advent-calendar/2017/linux">Linux Advent Calendar&lt;/a>
14日目の記事として書かれた．
本記事ではLinuxにおける5-Level Paging(la57 paging)の実装を見ていく．&lt;/p>
&lt;h2 id="5-level-pagingとは">5-Level Pagingとは&lt;/h2>
&lt;p>これまで，x86_64では物理アドレス下位48bitのみが使用されてきた．
このため，64TiBの物理アドレス空間と256TiBの仮想アドレス空間に限られてきた．
Intelはこれを拡張し，物理アドレス下位56bitへと拡張させた．
これにより，4PiBの物理アドレス空間と128PiBの仮想アドレス空間が利用できるようになった．
この拡張に対応するため新たに導入されたのが，ここで紹介する5-Level Pagingである．
基本的な考え方は4-Level Pagingと同一であり，
PML4にさらに上位にPML5が追加された形となっている．&lt;/p></description></item><item><title>EFI stubなLinux kernelのヘッダ部分を見てみる</title><link>https://retrage.github.io/2017/12/09/efi-stub-header.html/</link><pubDate>Sat, 09 Dec 2017 00:12:14 +0000</pubDate><guid>https://retrage.github.io/2017/12/09/efi-stub-header.html/</guid><description>&lt;p>EFI環境においてLinux kernelの起動方法には
ブートローダを用いる方法とEFI stubの2通りがある．
EFI stubではbzImageに対してEFI Application相当のヘッダを付加することで
EFIから直接kernelを起動する．
ここでは，EFI stubなLinux kernelのヘッダが実際に見ることで
どのように直接起動できるようにしているかを見ていく．
実際の記事を書いたのが相当前なので，ここではLinux kernel 4.5を対象としている．&lt;/p></description></item><item><title>BitVisorのEFI向け VMM Loader(1st stage)のコードを読んでみる</title><link>https://retrage.github.io/2017/12/07/bitvisor-efi-loader.html/</link><pubDate>Thu, 07 Dec 2017 02:05:28 +0000</pubDate><guid>https://retrage.github.io/2017/12/07/bitvisor-efi-loader.html/</guid><description>&lt;p>この記事は
&lt;a href="https://qiita.com/advent-calendar/2017/bitvisor">BitVisor Advent Calendar&lt;/a>
7日目の記事として書かれた．
ここでは，BitVisorのEFI向け VMMLoader(1st stage)のコードを読んでみる．&lt;/p>
&lt;p>EFI Loaderのコードは
&lt;a href="https://bitbucket.org/bitvisor/bitvisor/src/34fa14de2421cd3564323eec998f8e0c465e99a0/boot/uefi-loader/loadvmm.c?at=default&amp;amp;fileviewer=file-view-default">&lt;code>boot/uefi-loader/loadvmm.c&lt;/code>&lt;/a>
にある．&lt;/p></description></item><item><title>Windows 10にEZP2010のドライバをインストール</title><link>https://retrage.github.io/2017/11/09/windows10-ezp2010-driver.html/</link><pubDate>Thu, 09 Nov 2017 02:13:21 +0000</pubDate><guid>https://retrage.github.io/2017/11/09/windows10-ezp2010-driver.html/</guid><description>&lt;p>EZP2010はAmazonなどで安価に販売されているROMライタである．
すでに公式のWebサイトが閉鎖されていたりして
Windows 10のドライバは公式には配布されていない．
Windows 7でのインストール手順を記している方がいらっしゃるが[1]，
この方法ではうまく動かなかった．
非常に汚い方法ではあるがメモ程度にやり方をまとめておく．&lt;/p></description></item><item><title>BitbucketとCircle CIでLatexする</title><link>https://retrage.github.io/2017/08/29/bitbucket-circleci.html/</link><pubDate>Tue, 29 Aug 2017 11:10:58 +0000</pubDate><guid>https://retrage.github.io/2017/08/29/bitbucket-circleci.html/</guid><description>&lt;p>前回からだいぶ空いてしまったが，小ネタを投下する．
以前に，
&lt;a href="http://retrage01.hateblo.jp/entry/2014/10/04/191435">Jenkins+Bitbucket(Git)でLaTeX&lt;/a>
という記事を書いた．
ここでは，CIを用いてlatexdiffによる差分Latexの生成，
コンパイル，Downloadsへのアップロード
を行うようなものを作ってみた．&lt;/p></description></item><item><title>ELVMのLLVM IRバックエンドをつくった</title><link>https://retrage.github.io/2017/03/25/elvm-llvm-ir.html/</link><pubDate>Sat, 25 Mar 2017 23:03:01 +0000</pubDate><guid>https://retrage.github.io/2017/03/25/elvm-llvm-ir.html/</guid><description>&lt;p>LLVMはよく知られてるコンパイラ基盤であり，
中間表現としてLLVM IRを持っている．
様々なところでこのLLVM IRが使われているが，
今まで触ってこなかったということもあり，
今回LLVM IRで何かしら遊んでみようと思っていた．&lt;/p></description></item><item><title>Zephyr上でBrainfuckを(一部)動かしてみる</title><link>https://retrage.github.io/2016/03/02/zephyr-brainfuck.html/</link><pubDate>Wed, 02 Mar 2016 02:26:07 +0000</pubDate><guid>https://retrage.github.io/2016/03/02/zephyr-brainfuck.html/</guid><description>&lt;p>ZephyrはLinux Foundationが発表したのRTOSである。
ただ触ってみただけでは面白くないので、
ここではZephyr上で動作するBrainfuckインタプリタを(一部)実装して動作させてみる。&lt;/p></description></item><item><title>OpenBSD vmmを動かしてみる</title><link>https://retrage.github.io/2016/02/17/vmm-introduction.html/</link><pubDate>Wed, 17 Feb 2016 11:48:38 +0000</pubDate><guid>https://retrage.github.io/2016/02/17/vmm-introduction.html/</guid><description>&lt;p>vmmはOpenBSD上で開発されているVMM(Virtual Machine Monitor)である。
ここではvmmを実際に動かしてその上でOpenBSDが動くことを確認する。&lt;/p></description></item><item><title>u8glibを使って画像をArduinoに接続したLCDに表示</title><link>https://retrage.github.io/2016/01/07/u8glib-image-arduino.html/</link><pubDate>Thu, 07 Jan 2016 01:19:53 +0000</pubDate><guid>https://retrage.github.io/2016/01/07/u8glib-image-arduino.html/</guid><description>&lt;p>タイトル通り、aitendoのFSTN液晶モジュールに画像を出力させてみました。&lt;/p>
&lt;p>FSTN液晶モジュールには8x8ピクセル単位で配列として画像の情報を送っていかなければいけないので手書きするのは面倒です。&lt;/p></description></item><item><title>BeagleBoneBlack上でUEFIを動かしてみる</title><link>https://retrage.github.io/2015/11/09/uefi-on-beagleboneblack.html/</link><pubDate>Mon, 09 Nov 2015 04:51:19 +0000</pubDate><guid>https://retrage.github.io/2015/11/09/uefi-on-beagleboneblack.html/</guid><description>&lt;p>BeagleBoneBlack(以下、BBB)実機上でUEFIを動かしてみます。&lt;/p>
&lt;p>前回の記事ではBeagleBoardでしたが、ここではBBBを扱います。&lt;/p></description></item><item><title>EDK2のクロスコンパイル</title><link>https://retrage.github.io/2015/11/08/cross-compile-edk2.html/</link><pubDate>Sun, 08 Nov 2015 02:34:57 +0000</pubDate><guid>https://retrage.github.io/2015/11/08/cross-compile-edk2.html/</guid><description>&lt;p>tianocore/edk2をx64上でARM向けにクロスコンパイルしてみました。&lt;/p>
&lt;p> ここでは、EDK2のリポジトリにあるBeagleBoardPkgをビルドしてみます。&lt;/p></description></item><item><title>QEMUでARM向けUEFIを動かしてみる</title><link>https://retrage.github.io/2015/11/08/uefi-for-arm-on-qemu.html/</link><pubDate>Sun, 08 Nov 2015 02:35:46 +0000</pubDate><guid>https://retrage.github.io/2015/11/08/uefi-for-arm-on-qemu.html/</guid><description>&lt;p>QEMUのBeagleBoardエミュレータでEDK2のBeagleBoardPkgを動かしてみます。&lt;/p>
&lt;p>BeagleBoardPkgはLinuxを起動するためのもののようですが、
とりあえず前回のビルドの成果物が動くことを確認したいだけなので、Linuxのブートイメージは作りません。&lt;/p></description></item><item><title>About</title><link>https://retrage.github.io/about/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://retrage.github.io/about/</guid><description>&lt;h1 id="akira-moroo">Akira Moroo&lt;/h1>
&lt;p>I am a software engineer.
I am also interested in operating systems, and compilers.
Previously I have researched in natural language processing, software engineering,
and firmware security, especially x86 and RISC-V.
You can find my e-mail address on the bottom of this page.&lt;/p>
&lt;h1 id="works">Works&lt;/h1>
&lt;ul>
&lt;li>&lt;a href="https://github.com/yabits/9pfsPkg">9pfsPkg&lt;/a>, 9P Client File System for UEFI&lt;/li>
&lt;li>&lt;a href="https://github.com/retrage/frankenlibc/tree/solo5">frankenlibc on Solo5&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://github.com/yabits/llvm">EFI Byte Code Backend for LLVM&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://github.com/uk-lkl">LKL on Unikraft&lt;/a>, Librarizing Linux Kernel for Unikernel&lt;/li>
&lt;li>&lt;a href="https://github.com/retrage/elvm/tree/retrage/ebc-v2">EBC Backend for ELVM&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://github.com/retrage/elvm/tree/retrage/rs">Rust Backend for ELVM&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://github.com/yabits/ebcvm">ebcvm&lt;/a>, EFI Byte Code Virtual Machine&lt;/li>
&lt;li>&lt;a href="https://retrage.github.io/lkl-js/">LKL.js&lt;/a>, Running Linux Kernel on JavaScript Directly&lt;/li>
&lt;li>&lt;a href="https://yabits.github.io/">yabits&lt;/a>, Yet Another UEFI coreboot Payload&lt;/li>
&lt;li>&lt;a href="https://github.com/retrage/elvm/tree/retrage/ll">LLVM IR Backend for ELVM&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://github.com/retrage/elvm/tree/retrage/lua">Lua Backend for ELVM&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://github.com/retrage/mruby/tree/retrage/mruby_on_efi_shell">mruby 1.2.0 on UEFI Shell&lt;/a>&lt;/li>
&lt;/ul>
&lt;h1 id="talks">Talks&lt;/h1>
&lt;ul>
&lt;li>&lt;a href="https://speakerdeck.com/retrage/practical-rust-hypervisor-firmware">Practical Rust (Hypervisor) Firmware&lt;/a> Kernel/VM Online Part 3, July 10, 2021&lt;/li>
&lt;li>&lt;a href="https://speakerdeck.com/retrage/bypassing-uefi-secure-boot-with-thin-hypervisor">Bypassing UEFI Secure Boot with Thin-Hypervisor&lt;/a> BitVisor Summit 9, November 30, 2020&lt;/li>
&lt;li>&lt;a href="https://speakerdeck.com/retrage/porting-linux-to-nabla-containers">Porting Linux to Nabla Containers&lt;/a> Container Runtime Meetup #2, August 22, 2020&lt;/li>
&lt;li>&lt;a href="https://speakerdeck.com/retrage/network-boot-from-bell-labs">Network Boot from Bell Labs&lt;/a> Kernel/VM Online Part 1, June 6, 2020&lt;/li>
&lt;li>&lt;a href="https://speakerdeck.com/retrage/llvm-backend-development-for-efi-byte-code">LLVM Backend Development for EFI Byte Code&lt;/a> Kernel/VM Tokyo 15, July 20, 2019&lt;/li>
&lt;li>&lt;a href="https://speakerdeck.com/retrage/efi-byte-code-virtual-machine-for-fun-and-profit">EFI Byte Code Virtual Machine for Fun and Profit&lt;/a> Kernel/VM Hokuriku Part 4, November 10, 2018&lt;/li>
&lt;li>&lt;a href="https://speakerdeck.com/retrage/lkl-dot-js-running-linux-kernel-on-javascript-star-directly-star">LKL.js: Running Linux Kernel on JavaScript *Directly*&lt;/a> Kernel/VM Tokyo 14, July 21, 2018&lt;/li>
&lt;li>&lt;a href="https://speakerdeck.com/retrage/wip-porting-lkl-to-bitvisor">[WIP]Porting LKL to BitVisor&lt;/a> Turing Complete FM Meetup, June 25, 2018&lt;/li>
&lt;li>&lt;a href="https://speakerdeck.com/retrage/uefiwotukuru">Making UEFI&lt;/a>(ja) osdev_moku2, March 24, 2018&lt;/li>
&lt;li>&lt;a href="https://speakerdeck.com/retrage/wasmdeyou-bu">Playing with WASM&lt;/a>(ja) Dentoo.LT #19, March 4, 2018&lt;/li>
&lt;li>&lt;a href="https://speakerdeck.com/retrage/brainf-star-ckfalsegao-su-hua-1">Optimizing BrainF*ck&lt;/a>(ja) Dentoo.LT #19, March 4, 2018&lt;/li>
&lt;li>&lt;a href="https://speakerdeck.com/retrage/elvmdellvm-ir">LLVM IR on ELVM&lt;/a>(ja) Dentoo.LAT #16, March 19, 2017&lt;/li>
&lt;/ul>
&lt;h1 id="publications">Publications&lt;/h1>
&lt;ul>
&lt;li>Hajime Tazaki, Akira Moroo, Yohei Kuga, and Ryo Nakamura, &amp;ldquo;How to design a library OS for practical containers?&amp;rdquo;, VEE, 2021 &lt;a href="https://dl.acm.org/doi/pdf/10.1145/3453933.3454011">PDF&lt;/a>&lt;/li>
&lt;li>Hajime Tazaki, Akira Moroo, Ryo Nakamura, &amp;ldquo;Jail to the Outside World: Revisit the Container Architecture&amp;rdquo;, USENIX OSDI, 2018&lt;/li>
&lt;li>Akira Moroo, &amp;ldquo;yabits: Yet Another UEFI coreboot Payload&amp;rdquo;, OSFC, 2018 &lt;a href="https://osfc.io/uploads/talk/paper/23/osfc2018.pdf">PDF&lt;/a>&lt;/li>
&lt;li>Akira Moroo, Akiko Aizawa, Takayuki Hamamoto, “Reranking-based Crash Report Deduplication”, SEKE, 2017 &lt;a href="https://ksiresearchorg.ipage.com/seke/seke17paper/seke17paper_135.pdf">PDF&lt;/a>&lt;/li>
&lt;/ul></description></item></channel></rss>