New website: https://rhythm16.github.io 一路的故事是滿意外的，有天跟同學吃飯聊到了我讀的32bit x86架構的memory reference，又再一次提醒了我我對於64bit一無所知的事實。回家手癢google了"x86_64 memory reference"，前幾個搜尋結果是linux kernel的documentation，瀏覽了一下竟然發現有句話讀起來怪怪的： "16M TB" might look weird at first sight, but it's an easier to visualize size notation than "16 EB", which..(後省略) "easier"後面少了一個"way"啊！ 這在平常可能不算什麼，就少個字，也不至於影響閱讀，但我馬上想到了jserv教授之前在facebook發文提到了一個四歲小孩在爸爸工作時看到了kernel排版少了一個'='，爸爸就幫忙發了一個patch，也被接受了，說明這種重要的大專案連排版這種小錯也是要修正的。

New website: https://rhythm16.github.io I have always wondered how the linux kernel translates addresses to symbol names. This mechanism (called kallsyms) is used in multiple places in the kernel, for example in the panic() call the kernel prints out the call trace with function names and offsets with no problem at all, also the ftrace system is able to show the user all function names that the kernel has run, similarly, using kallsyms. This article written in Chinese explains the translation mechanism pretty well, and is worth a read if one is interested in knowing how it is done. However when discussing this topic with a professor, he asked me how I can find the raw bytes of the symbols used by kallsyms which are explained in the linked article above e.g. kallsyms_addresses and kallsyms_num_syms, etc. So, I set to find out where they are. It is unlikely for me and you to use the exact same kernel image, so the offsets and symbols won't be the same. Moreover, I'm using an ARMv8 image of linux version 5.4. From the article linked above we know that the kallsyms symbols are in the .rodata section, lets see where it is:

New website: https://rhythm16.github.io I think most people (even some computer science people, including me) only think of cryptocurrencies anytime when "blockchain" is mentioned. However I recently learned a bit about how git works internally and was very surprised by how similar it is to some of the bitcoin/blockchain concepts introductions that I have studied. So as a note and sharing of this interesting finding, in this article, I'm going to try to explain how git provides its fundamental functionalities, and hopefully if the reader is somewhat familiar with the basic blockchain concepts, can easily see what I claim in the title of the post. Blockchain knowledge is not required to understand this article, though. I'll be mostly talking about the git internals. Only basic git knowledge is assumed. Toy repo setup I'll setup a simple git repository for demonstration purposes, all commands in this article will be issued in the repo. Setup: # be sure to not be in a repository!

New website: https://rhythm16.github.io 本篇內容來自Paul E. McKenney的perfbook Appendix C "Why Memory Barriers"以及蜗窝科技網誌上的翻譯，快速地讀完一次之後覺得基本的原理了解了，不過說到細節還是有很多需要釐清的部分，所以想用自己的方式寫下來。內容會比原文少非常多，要完整的學習的話建議閱讀原文。 Ascii art generated by asciiflow. Stores 有時候很慢 這是對一個SMP系統的簡略想像: ┌───────┐ ┌───────┐ │ CPU 0 │ │ CPU 1 │

New website: https://rhythm16.github.io My notes for the Makefile file used by the make utility. Assignments The simplest = will expand recursively when the LHS is used a = "1" b = "2" c = $(a)3 # c is now "13"

New website: https://rhythm16.github.io 在讀作業系統、計算機結構等科目或是在學習程式的過程中，會讀到一個機制叫做"動態鏈接(dynamic linking)"，它可以使得多個程式共用函數，進而得到節省記憶體的效果。 一個例子就是C語言<stdio.h>中的 printf()，如果系統中所有要對終端輸出字串的程式都把printf的程式碼包含進原始碼再編譯，不僅會浪費磁碟空間（儲存了一大堆printf），程式同時執行時主記憶體也就被很多個printf函數所佔用。 所以說比較有效率的方式是讓系統的主記憶體只存著一份printf函數，其他所有程式要輸出字串時讓CPU跳到唯一存放printf的地方執行，結束再跳回原來的程式就行了。之所以叫做動態，就是因為程式編譯時，並不會知道所呼叫的函數在哪裡，無法在編譯時「鏈接」，只能在程式從硬碟載入記憶體時動態地在系統的幫助下完成鏈接。 鏈接(linking)是指讓一隻程式在呼叫函數或使用外部變數時知道要往哪裡找

New website: https://rhythm16.github.io 原始的問題 故事是這樣的： 如果我們有個C函式庫，裡面有函數例如： /* cfunc.c */ void awesome_C_function() {

New website: https://rhythm16.github.io 在2011年7月以前，linux版本號有三個數字，例如2.6.39 其中 2 -> 主版本號 6 -> 副版本號，奇數為開發版本，偶數為穩定版本 39 -> 修訂版本號 2011/7/21，核心版本3.0釋出，Linus為了整齊把版本號換成兩個。

New website: https://rhythm16.github.io :::info 2020/11/25更新： 這篇對一半吧， 這篇比較完整，也比較正確 ::: 忘記在哪時候看到這篇(我有所不知的 static inline function)，讀完覺得頗有趣的，來記錄一下。 這篇是靠感覺打的，沒有實作跟去check組合語言，因為我覺得觀念對了，真的有不確定的地方再試就好。

New website: https://rhythm16.github.io 這是一本線上可取得的免費書籍，作者為趙炯博士，現為同济大学机械工程学院机械电子教研室副教授，可於作者網站 www.oldlinux.org 下載這本書 故事 這本書是2019二月同學介紹給我的，我甚至記得我們是晚上在學校福利社外面遇到。在回家後讀了序言和第一章我就知道一定要讀這本書。至於為什麼，是因為我一直對作業系統很有興趣，具體來說是想要知道一個OS到底是怎麼寫出來的，而好笑的是在學校修了作業系統之後這個問題完全沒有獲得解答。 如同書上序言所述，無論是大部分學校的OS課程，或者各種教作業系統的書，都只能直觀的描述OS的重點功能和概念，或者拿出幾行程式碼來討論。在沒有對整個code base有綜觀的理解的情況下學習起來容易有盲人摸象、浮沙築高臺的感覺，說難聽一點就是不知道實際上在幹嘛，而且抓不到整體的結構，更別說學到怎麼寫作業系統了。 所以我一頭栽進去，一千多頁的書不會幾週就讀完，我有空就幾頁幾頁的看。前三章是先備知識，不難，但讀了第四章，介紹x86架構我就知道要另外找其他資源加強，不然後面一定讀不下去，所以我暫時擱著這本，花了兩個月時間讀過⟪x86匯編語言 從實模式到保護模式⟫，把x86這個洞補起來。

在讀到Intel ME和AMD Security Technology之後順藤摸瓜，就看到了似乎在PC韌體界頗有名的漏洞[2, 3]，看了Positive Technologies(簡稱PT)的演講和說明之後實在還是摸不著頭緒。主要是因為我對ME內部的運作方式不是很熟悉(菜)。好在找到了Kakaroto的blog[1]，在讀過了幾遍之後，漏洞的大致輪廓逐漸清晰了些，紀錄一下。 對於不知道Intel ME的人，請先查閱參考資料或是Google，[1]中也有很好的說明。這篇的細節會參照[1]，我認為Kakaroto有些部分還是寫的有點難懂，所以我盡量用更明顯清楚的方式把關鍵處講出來。 值得注意的是Kakaroto在[1]中提到了他發現PT在Github上發布的PoC[4]和他們的演講[2, 3]對不上，攻擊手法不一樣，所以研究了PoC中到底在做什麼。這邊就不講他怎麼發現的了，直接說明他最後研究出的結果。 PoC針對的是Apollolake平台，演講是說Skylake平台 攻擊大致流程 Positive Technologies給出的PoC流程大概是：