エンジニアと思われるものの備忘録

しがない学生の備忘録です

Pythonで型検査しようぜ

やりたいこと

  • Pythonのコードを書く際に型注釈と型検査を用いることで,実行前にバグなりそうなエラーを潰す
  • 他の人が読むとき処理を追いやすいコードを書く
  • 型の重要性を知ってもらう

背景

今はPythonでgRPCのapi書いたり, 機械学習のコードをぶん回したりしてるのでPython漬けの生活です.

「退屈なことはPythonにやらせよう」

なんて言われるぐらいには書きやすいPythonですが,しかし,書きやすさと読みやすさ, 安全性が比例するとは限りません.

OSSやプロダクトにおけるコードというのは書くことより読まれることの方が圧倒的に多いです. それなら多少の利便性は犠牲にしてもシンプルな文法や安全な規則で読みやすさや実行の安全性を担保するべきです.

その結果としてGoやRust, 少し異なりますがTypescriptなどが現在流行っているとも思っています.

例として次のようなPythonのコードを見てみます.

name = "hoge"

print(name)

name = 1

print(name)

こういうコードは割とよくあります.完全にnameが意味することが変わっています. 上記は1個目の代入文と2個目の代入文が近いのですぐに意味が書き換わっていることがわかりますが,プロダクトのコードだったら二つの代入文の間にたくさんの処理が挟まったり,関数内の副作用で書き換わる可能性もあります.

ではもう一つ例をみてみます

class A:
    def name(self):
        print("A")

class B:
    def name(self):
        print("B")


a = A()
a.name()

a = B()
a.name()

このコードが動くということがどれだけ恐怖なのかはGoのような静的型付け言語を書く人ならよく理解できるのではないでしょうか.

これはpythonrubyのような動的型付け言語でよくある問題です. こういった型の束縛を無視したコードは絶対に潰すべきです.

今回は可読性と実行時の安全性を担保するためにPythonにおける静的型検査と型注釈の導入について述べようと思います.

型とは

まずプログラミング言語における型とは一体なんでしょうか.

そもそもプログラムが扱う値というものはコンピュータから見ればただのメモリやハード上のバイト値です.

型はそのメモリ上に連続するバイトの塊の解釈の仕方を変えることで人間に扱いやすくするものという認識です.

0x01 => int: 1, char: 'a'

このような感じですね. 型というものがあるおかげで私たちはプログラムでより複雑かつ抽象的なロジックを記述できるようになりました.

型安全

型は現代の高級プログラミング言語における式評価において重要な意味を持ちます.

一つ例をあげてみます

#include <stdio.h>
#include <string.h>
int main(void) {
    int i = 1;
    char c = 'a';
    
    // int + char = ?
    printf("result = %d\n", i + c);

    // segmentation fault
    strlen(i);
}

このcのプログラムをコンパイルして実行してみます.

type_checker git:(feature/mypy) ✗ gcc type.c                                                                                                       
type.c:11:12: warning: incompatible integer to pointer conversion passing 'int' to parameter of type 'const char *' [-Wint-conversion]
    strlen(i);
           ^
/usr/include/string.h:82:28: note: passing argument to parameter '__s' here
size_t   strlen(const char *__s);
                            ^
1 warning generated.
type_checker git:(feature/mypy) ✗ ./a.out 
result = 98
zsh: segmentation fault  ./a.out

コンパイル自体はwarningが出ていましたが, 成功しています. しかし, 実行は途中でセグフォッています

まず, int + charの足し算が成立してしまうこと自体結構アレですね.

セグフォの原因はstrlenに渡したiがint型なのでstrlenではcharのポインタだと思っていてそのポインタ(おそらく 0x01)にアクセスしようとしたら当然権限外なので落ちたわけですね.

c言語はこのように暗黙の型変換や型における意味論の未定義動作から型安全な言語はありません. 型とはプログラミング言語の構文規則上は大丈夫でも, 式の意味を正しく評価するために存在しているわけです.

なんでもありにすると開発者も大変ですからね.

Pythonにおける型安全

ではPythonにおける型はどうなのでしょうか

Python は実行時に型の代入, 評価を行う動的型付け言語です.

最初に挙げたコードが動いてしまうことから不安はありますが, 次のようなコードはしっかり落ちます

Python 3.7.1 (default, Dec 14 2018, 13:28:58)
[Clang 4.0.1 (tags/RELEASE_401/final)] :: Anaconda, Inc. on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 1 + "hoge"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'str'

なのでpythonも変数の型束縛がないことを除けば, ほぼ型安全な言語だと言えます.

中間まとめ

ここで一旦今までのことをまとめてみます

  • 型はプログラムが構文的に正しくても式の意味が正しいかをチェックするための重要な要素(式における型の評価規則を定義したものを意味論という)
  • C言語のような言語は型安全ではない.
  • pythonは変数の束縛がないので若干怪しい部分もあるがほぼ型安全.しかし, インタプリタ言語なので実行時までそのエラーはわからない
  • ただし, 変数に型を指定することがないので可読性は低い

というわけで最初にも言ったように, 静的型検査とPython3.5から導入された 型注釈(Type annotation) を導入することによって以下のメリットを提供します

  1. 可読性の担保: 新しい開発者の参入障壁を下げることにも繋がります
  2. プログラマの意識改善(Pythonだからという理由で書き捨てのコードになっていい理由はない).
  3. 実行前に型エラーを検出することでデバッグの手間を減らす

実際に導入する

型注釈

Python3.5から次のような記法がサポートされるようになりました

def add(x: int, y: int) -> int:
    return x + y

引数の値と返り値の型を記述できます. これだけでもかなりコードは読みやすくなります.

しかし, 実行時に特に制限はかかっていないので上記のコードを次のように変更しても実行はできます

def add(x: int, y: int) -> int:
    # return x + y
    return "hoge"

if __name__ == '__main__':
    add(1, 1)

そこで mypy という型チェックツールを導入します

インストールは pip install mypy でOKです

先ほどの間違ったコードに対して検査をかけます

type_checker git:(feature/mypy) ✗ mypy example_type.py
example_type.py:3: error: Incompatible return value type (got "str", expected "int")

ちゃんと定義した返り値の型と違うと怒ってくれています

また, 次のような定義済み変数の型を書き換えてしまう現象もしっかり検出できます

class User:
    def __init__(self, name: str) -> None:
        self.name: str = name
    
    def change_name_type(self, id: int) -> None:
        self.name: int = id

if __name__ == '__main__':
    u: User = User("katsuya")
    u.change_name_type(1)
    print(type(u.name))
type_checker git: 
main.py:6: error: Incompatible types in assignment (expression has type "int", variable has type "str")

これで概ねやりたことは可能になりましたので今実装中のコードに入れたりしてみました. いい感じにやばそうなコードを検出してくれます.

小ネタとして関数ポインタのように引数を扱いたい場合はこんな感じで定義します

from typing import Callable
def load_network(scale: int) -> Callable[[tf.Tensor, bool, bool], tll.InputLayer]:
    if scale == 2:
        return network2
    elif scale == 4:
        return network4
    else:
        return network4

ただ, mypyは型注釈したコードのみを検出して評価するので型注釈のないコードで型エラーがあっても素通りしてしまいます. しっかりと開発者が型注釈を用いること前提です.

また, 型の不一致などがあっても, 実行自体はできてしまうため, デプロイ前には必ずmypyによる検査を挟んでエラーがあれば実行しないというようなスクリプトを組む必要があるでしょう.

所感

可読性と実行前に安全性を担保するためにmypyと型注釈の導入を試しましたがかなり良い感じだと思います.

あとは開発者やレビュアーが型注釈に対しての心構えを持つこととmypyを用いたデプロイフローを用意すればより堅牢なPythonアプリケーションを実装することができると思います.

参考文献

Go言語でつくるインタプリタを読み終えて,独自拡張した話

Go言語でつくるインタプリタを漸く読み終わりました.といっても実際には1月末には終わっていて単純に記事にするのを忘れていただけなんです.

実際にコードを書きながら読んでいたのですが,リポジトリのログを遡るとファーストコミットは2018/6/24になってました. およそ半年と1ヶ月ほどでしょうか.合間合間にすすめていたのですごい時間かかってますね.

でも本当に良い本でした. 本書でも述べられている通り,Brainf*ckとかじゃなく割とちゃんとした,でもそこまでヘヴィじゃない言語仕様のインタプリタフルスクラッチで作るというのは中々ありませんでしたから.

独自拡張の話

で,本題なんですが本書では最終的にハッシュと組み込み関数の実装で終わっています(付録としてマクロの実装もある)

その時点で動くプログラムはこんな感じ

let map = fn(arr, f) {
    let iter = fn(arr, accumulated) {
        if (len(arr) == 0){
            accumulated
        } else {
            iter(rest(arr), push(accumulated, f(first(arr))));
        }
    };
    iter(arr, []);
};
let a = [1,2,3,4];
let double = fn(x) { x * 2 };
map(a, double);

配列要素をmap関数で2倍ずつしていくというプログラムです. これでも結構プログラムっぽいですが,次のようなコードは動きません.

let fizzbuzz = fn(n) {
    for (let i=1;i<n+1;++i) {
        switch {
            case i % 3 == 0 && i % 5 == 0:
                puts("FizzBuzz");
                break;
            case i % 3 == 0:
                puts("Fizz");
                break;
            case i % 5 == 0:
                puts("Buzz");
                break;
        }
    }
};

fizzbuzz(15);

典型的なFizzBuzzです.このプログラムを動かすのに何が足りないかというと for文, switch case文, インクリメント演算子(++), バイナリ演算子(&&) です. あと % 演算子もなかった気がする

結構足りないですね.本のコードを写経して動きを理解するだけでもインタプリタの言語処理系の実装を理解するには十分だとは思いますが,折角なので以上の要素を頑張って実装してみました.

これらの要素を説明していくのに二段階に分けます.1つ目はASTの生成である構文解析と実際に処理を行う評価の部分です

For文

構文解析

まず, ASTの定義コードを示します

// ForExpression
// original expression
// for(<statement>;<expression>;<statement>) {
//     <Block Statements>
// }
type ForExpression struct {
    Token           token.Token // 'for token
    InitStatement   Statement   //
    FinishCondition Expression
    LoopStatement   Statement
    Consequence     *BlockStatement
}

初期化部分がstatementになっているのは let i = 1 みたいなのを許容したいからです. 逆に終了条件のところは必ず式にするように制限しています. ここはお好みで変更できるので実装者によるでしょう. ループ条件も初期化部分と同様です. 中括弧の中にはループ中に実行される文が配列で格納されます.

評価

func evalForExpression(node *ast.ForExpression, env *object.Environment) object.Object {
    forEnv := object.NewEnclosedEnvironment(env)
    initEvalResult := Eval(node.InitStatement, forEnv)
    var result object.Object
    if isError(initEvalResult) {
        return initEvalResult
    }

    for {
        isFinishObj := Eval(node.FinishCondition, forEnv)
        isFinish, ok := isFinishObj.(*object.Boolean)
        if !ok {
            return newError("finish condition is not boolean")
        }
        if !isFinish.Value {
            return result
        }
        result = evalBlockStatement(node.Consequence, forEnv)
        loopEvalResult := Eval(node.LoopStatement, forEnv)
        if isError(loopEvalResult) {
            return loopEvalResult
        }
    }
}

env変数はスコープ外の変数などを保持しているマップです. 先程のastで取得した初期化条件,終了条件ループ条件を元に実際にforループを回します. for文が終わった際にはresult変数に最後のループで実行された文の結果が格納されて返されます.

SwitchCase文

本書ではIf文を実装していますが,else ifのような無限に続けていく書き方はサポートしていませんでした.そちらを拡張しても良かったのですが折角なので綺麗に見えるSwitchCaseを実装してみました.

構文解析

まずはASTの定義を見ます

type SwitchStatement struct {
    Token      token.Token
    Expression Expression
    Case       []*CaseStatement
}

type CaseStatement struct {
    Token      token.Token
    Condition  Expression
    Statements []Statement
}

さて,Switch文はSwitchとCaseそれぞれに分けました. なぜこうしたかは若干おぼろげですが,確か一つの構造体に詰め込むと解析がすごい面倒くさいことになりそうだったからだと思います.すいません

で,解析処理は以下のようになります

func (p *Parser) parseSwitchStatement() ast.Statement {
    stmt := &ast.SwitchStatement{
        Token: p.curToken,
        Case:  []*ast.CaseStatement{},
    }
    if !p.peekTokenIs(token.LBRACE) {
        exp := p.parseExpression(LOWEST)
        stmt.Expression = exp
    } else {
        stmt.Expression = nil
    }
    p.nextToken()
    for !p.peekTokenIs(token.RBRACE) {
        p.nextToken()
        switch {
        case p.curTokenIs(token.CASE):
            s := p.parseCaseStatement()
            caseStmt, ok := s.(*ast.CaseStatement)
            if !ok {
                return nil
            }
            stmt.Case = append(stmt.Case, caseStmt)
        }
    }
    p.nextToken()
    return stmt
}

func (p *Parser) parseCaseStatement() ast.Statement {
    stmt := &ast.CaseStatement{
        Token:      p.curToken,
        Statements: []ast.Statement{},
    }
    p.nextToken()
    exp := p.parseExpression(LOWEST)
    stmt.Condition = exp
    if p.peekTokenIs(token.COLON) {
        p.nextToken()
    }
    for !p.peekTokenIs(token.BREAK) {
        p.nextToken()
        caseStmts := p.parseStatement()
        stmt.Statements = append(stmt.Statements, caseStmts)
    }

    return stmt
}

Switch文は switch <expression> { [case statement] } のようになっていて最初のexpressionに関してはあってもなくても良いです. 単純にGoっぽくしたくて入れました

case文はbreakなしだと終了の判定が若干面倒くさかったので甘えて入れました.それ以外は基本的にFor文やIf文と解析の手法は変わりません.

評価

func evalSwitchStatement(node *ast.SwitchStatement, env *object.Environment) object.Object {
    for _, c := range node.Case {
        conditionValue := Eval(c.Condition, env)
        condition, ok := conditionValue.(*object.Boolean)
        if !ok {
            return newError("case condtion value is not boolean. got=%T", conditionValue)
        }
        if condition.Value {
            var result object.Object
            for _, s := range c.Statements {
                result = Eval(s, env)
            }
            return result
        }
    }
    return nil
}

こちらの評価処理は全然難しくなかったです. C言語よろしく,Case文の条件を上から判定してマッチしていたらCaseAST内部のBlockStatementを評価していくという感じです.

その他の演算子

++ 演算子は上記のFizzBuzzのように ++<Integer Object> とするようにしています. 前置にした理由は後置にすると実質中置演算になって演算子の優先順位を考慮しなきゃいけなくて面倒くさかったからです.ごめんなさい

&& 演算子の解析もAST生成は既存のコードに条件を足すだけなので難しくありません

評価に関しては若干追加したので載せておきます.

func evalInfixExpression(operator string, left, right object.Object) object.Object {
    switch {
    case left.Type() == object.INTEGER_OBJ && right.Type() == object.INTEGER_OBJ:
        return evalIntegerInfixExpression(operator, left, right)
    case left.Type() == object.STRING_OBJ && right.Type() == object.STRING_OBJ:
        return evalStringInfixExpression(operator, left, right)
    case operator == "==":
        return nativeBoolToBooleanObject(left == right)
    case operator == "!=":
        return nativeBoolToBooleanObject(left != right)
    case operator == "&&" && left.Type() == object.BOOLEAN_OBJ && right.Type() == object.BOOLEAN_OBJ:
        return evalBinaryOperand(operator, left, right)
    case left.Type() != right.Type():
        return newError("type mismatch: %s %s %s", left.Type(), operator, right.Type())
    default:
        return newError("unknown operator: %s %s %s", left.Type(), operator, right.Type())
    }
}

この処理は中置演算式の評価部分ですが,&& の左辺右辺は絶対にBoolオブジェクトであると制限して評価します. あとは簡単で,

func evalBinaryOperand(operator string, left, right object.Object) object.Object {
    leftVal := left.(*object.Boolean).Value
    rightVal := right.(*object.Boolean).Value
    switch operator {
    case "&&":
        return &object.Boolean{Value: leftVal && rightVal}
    default:
        return newError("unknown operator: %s %s %s", left.Type(), operator, right.Type())
    }
}

こんな感じで実際の値を評価します. || 演算子とか足したければtokenを追加してcase文も追加すればOK % 演算子も追加しましたが他の +-*/ と同様なので省きます.

実際に実行してみる

これらを実装して,先程のFizzBuzzを実行してみると次のようになります

f:id:kk_river108:20190226114604p:plain

いい感じに出力されていますね. 最後のnullはputsの評価値を表示しているものです.

まとめ

非常に参考になり,翻訳も丁寧で原著のテンポの良い文章がそのまま楽しめた気がします. また,実際のコードもインタフェースを十全に使っているおかげで自前の拡張もかなりスムーズに行えました. 言語処理系を実際に作るというのは結構ハードルが高そうに見えますが,コンパイラとかはともかく,インタプリタは実装する言語でそのまま実行するので入門としてはかなり良い教材なのではないでしょうか?

作っている最中に普段「どうしてこんな構文なんだろ?」と思うプログラミング言語の仕様も実は実装者の苦悩の果に辿り着いたものなのだという一種の共感すら湧くようになりました.

皆さんも良ければインタプリタを作って見てください

最後に書籍のリンクと今回自分が実装したコードへのリンクを張っておきます.

github.com

Amazon CAPTCHA

2018年振り返り & 2019年で頑張ること & 退職エントリー

振り返りと豊富とお世話になったインターン先の退職エントリーをひとまとめにしました。

2018年

1月 卒業論文で死にかけてた 2月 卒業論文で略 & インターン復帰した 3月 インターンでバリバリ開発してた 4月 同上 & 授業始まった & GoConにLTで参加した 5月 同上 6月 同上 7月 そろそろ授業に対してフラストレーションが溜まってきた 8月 インターン 9月 アドテクコンペとインターン 10月 内定決まった 11月 内定承諾した 12月 インターン退職した

研究の方は新しいテーマをずっと探していて調査しては探し直して調査しては探し直してを繰り返して未だに決まりきってはいません。 でも沢山論文は読んだし一個一個の読むスピードや単語の意味も大分わかってきたので無駄ではないと思っています。

インターンの方は1年9ヶ月もお世話になった3-shakeを退職しました。 3-shakeでは最初は機械学習のR&Dエンジニアとして入りましたがいつの間にかReckoner-CDPのバックエンドエンジニアとして集計基盤やサーバサイド、フロントエンドなんかもやったりしてました。おかげで1年9ヶ月でWeb開発の知識、スキルはかなり跳ね上がった気がします。

本当に3-shakeの皆さんにはお世話になりました

次どこいくの

CyberAgentさんのどこかのプロジェクトに内定者インターンとして関わる可能性が高いです。 つまり渋谷に通うことになるのですがあの人混みには未だに慣れません。豊洲の綺麗さと交換してほしい。

2019年はどうするの

とりあえずソフトウェアエンジニアとしてもっとスキルを磨きたいです。具体的にはCコンパイラの完成、アセンブラ、リンカの自作、AtCoderの継続参加でしょうか。 AtCoderは土日なかなか予定や他にやることが多くて時間を取れなかったので過去問解くだけでも毎週するようにしておきたいです。

あとは英語です。DMM英会話を申込もうと思ったのですがお金がないのでPodCastスクリプト見ながら発音して練習するというのを続けてみようと思います。

そんなわけで2019年もよろしくお願いします。

Goのプログラムで動的アップデートについてのトリビア

この記事は 

Go3 Advent Calendar 2018 - Qiita の21日目の記事にあたります。

アドベントカレンダーに参加するのは初めてのため、作法なので間違っているところがあったらすいません。

動的アップデート

動的アップデートという言葉をご存知でしょうか?ホットリロードだったりモンキーパッチだったり似たような意味で色々言い方があるかもしれませんがACMIEEEの論文を眺めているとDSU(Dynamic Software Update)と書いてることが多いです。

何をするかというと プログラムを中断させずにプログラムのアップデートを行う ことです。

具体的にはプロセスのメモリ空間を外部から書き換えて挙動を書き換えます。linuxにはlivepatchというツールがありますが、これはプロセスを指定し、アドレスを指定するとそのアドレスの値を書き換えることができます。要は黒魔術の一種です。

今回はGoで書かれたプログラムをGoでパッチ(厳密には違います)を書いて動的にプログラムの挙動を書き換える ということができるのかというのを検証してみます。

一般的な動的アップデートの手法

よく知られるDSUの手法を図に示します。

f:id:kk_river108:20181222003712p:plain

よくあるのが関数呼び出しで本来とは別の関数を呼び出すものです。

livepatchでは関数を呼び出したあと、直後のメモリ上の命令をjmp命令に書き換えてアップデート対象の関数アドレスに飛びます。 今回はこれを行います。

今回やってみるアップデートのフロー

  1. 自身を動的に書き換えるgoのプログラムを書く(アップデート対象のプログラム: target)
  2. 新しい関数を定義しただけのプログラムを書いてコンパイルする(パッチ: patch)
  3. targetはpatchのバイナリからアップデート対象となる関数のバイナリを抽出し、自身で呼び出している関数を書き変える

前提条件

  • 今回の記事における実験は全てgoコンパイラの最適化フラグはオフにしています。
  • os: ubuntu
  • go: 1.11
  • 関数の型はアップデート前とアップデート後で一致している

実装

以上の手順を行うコードを見ていきます。

target.go
package main

import (
    "fmt"
    "log"

    "github.com/Bo0km4n/lupus"
)

func f1() int {
    return 1
}

func main() {
    targetFunc := f1
    if err := lupus.PatchFunction(
        "/home/vagrant/go/src/github.com/Bo0km4n/lupus/example/patch",
        "main.f2",
        targetFunc,
    ); err != nil {
        log.Fatal(err)
    }
    fmt.Println(targetFunc())
}
patch.go
package main

func f2() int {
    return 2
}

func main() {
    f2()
}

targetのプログラムは普通なら1が表示されますが、patchを当てることにより2が表示されます。

f2のアセンブラはこのようになります

00000000004ce1c0 <main.f2>:
  4ce1c0:   48 c7 44 24 08 01 00    movq   $0x2,0x8(%rsp)
  4ce1c7:   00 00 
  4ce1c9:   c3                                       retq   

このバイト配列をうまいこと抽出して書き換えてあげればokです。あとこのアセンブラは後ほど関わってきますので少しだけ覚えていおいてください。

lupus.PatchFunction はgoのmonkeypatchライブラリを参考に関数の具体的な置き換えを行います。

PatchFunction

アップデートのロジックを順に追っていきます。

func PatchFunction(patchObjPath string, funcName string, target interface{}) error {
    elfFile, _ := open(patchObjPath)
    newFuncBytes := getFuncBytes(elfFile, funcName)
    newFuncBytes, err := writeFuncVal(newFuncBytes)
    if err != nil {
        return err
    }
    patchValue(reflect.ValueOf(target), newFuncBytes)
    return nil
}

まず、引数でもらったバイナリファイルを開いてElfファイルのセクションヘッダーを取れるようパースします。 open関数の中では goの debug/elf パッケージを用いてファイルを開いています。

getFuncBytes でセクションヘッダとシンボルテーブルからバイナリ内での対象の関数のアドレスを算出して関数の実体となるバイト配列を返しています。

writeFuncVal の内部でバイト配列をtmpファイルに書き出してファイルポインタをmmapシステムコールに渡してヒープ領域(多分)に確保します。 ここでnewFuncBytesを再代入しているのはwriteFuncVal実行後に返すバイト配列は中身は一緒ですがポインタが新しく確保したメモリのアドレスに書き換わっているからです。

つまり、関数の実行後にこの配列のアドレスにjmp命令でふっ飛ばせばokなわけです。

次の patchValue に新しい関数のバイト配列と対象となる関数を渡して実行するとメモリが書き換わります。

パッチのコア部分の実装

ではパッチでメモリを書き換える処理の実装について見てみます。

patchValue
func patchValue(target reflect.Value, replaceValue []byte) {
    if target.Kind() != reflect.Func {
        log.Fatal("Target has to be a Func")
    }
    replace(target.Pointer(), replaceValue)
}

ここで行うのはreflectパッケージで渡された関数ポインタがGoの関数であるかをチェックしているだけです。

replace
func replace(orig uintptr, replacement []byte) {
    replacePtr := *(*uintptr)(unsafe.Pointer(&replacement))
    jumpData := assembleJump(replacePtr)
    copyToLocation(orig, jumpData)
}

一行ずつ追っていきます。

replacePtrは先程確保したバイト配列のメモリ領域の先頭アドレスになります。

jumpDataは

func assembleJump(to uintptr) []byte {
    return []byte{
        0x48, 0xBA,
        byte(to),
        byte(to >> 8),
        byte(to >> 16),
        byte(to >> 24),
        byte(to >> 32),
        byte(to >> 40),
        byte(to >> 48),
        byte(to >> 56), // movabs rdx,to
        0xFF, 0xe2,     // jmp rdx
    }
}

このような処理を行い、

movabs rdx, to_address(バイト配列のアドレス)
jmp rdx

になる命令のバイト配列を示しています(ここはアーキテクチャ依存)。

最後にcopyToLocationでメモリ上の対象関数の命令を書き換えます。

func copyToLocation(location uintptr, data []byte) {
    f := rawMemoryAccess(location, len(data))

    page := rawMemoryAccess(pageStart(location), syscall.Getpagesize())
    err := syscall.Mprotect(page, syscall.PROT_READ|syscall.PROT_WRITE|syscall.PROT_EXEC)
    if err != nil {
        panic(err)
    }
    copy(f, data[:])
}

fはアップデート対象の関数が始まるアドレスから、パッチの長さ分のメモリ領域を取得します。 そして、対象のアドレスからpageサイズ分のアドレスを取得し、mprotectシステムコールを用いて4096バイト分(linuxのページサイズ)の権限を書き換えさせてもらいます。

これでメモリの書き換えと書き換え後の命令実行ができるようになりました。

最後にcopy関数で対象関数に入ったあと実行するはずだった命令の部分をjmp命令に書き換えて終わりです。

内部での関数呼び出し

今回のパッチは返す値を1から2にしただけです。 では次にこのような関数に処理を書き換えることにします。

func newFunc() int {
    fmt.Println("new func called")
    return 2
}

fmt.Printlnが追加されました。

これでパッチを当てようとしてみます。

すると。。。

unexpected fault address 0x7f0de5040fb0
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x1 addr=0x7f0de5040fb0 pc=0x7f0de5040fb0]

goroutine 1 [running]:
runtime.throw(0x4e4521, 0x5)
    /usr/lib/go-1.10/src/runtime/panic.go:616 +0x81 fp=0xc420041dc0 sp=0xc420041da0 pc=0x426ca1
runtime: unexpected return pc for runtime.sigpanic called from 0x7f0de5040fb0
stack: frame={sp:0xc420041dc0, fp:0xc420041e10} stack=[0xc420040000,0xc420042000)
000000c420041cc0:  000000000044a012 <runtime.writeErr+66>  0000000000000002
000000c420041cd0:  00000000004e4207  0000000000000001
000000c420041ce0:  0000000000000001  000000c420041d20
000000c420041cf0:  0000000000427758 <runtime.gwrite+280>  00000000004e4207
000000c420041d00:  0000000000000001  0000000000000001
000000c420041d10:  0000000000427758 <runtime.gwrite+280>  00000000004e4521
000000c420041d20:  000000c420041d70  0000000000427f0d <runtime.printstring+125>
000000c420041d30:  00000000004e4207  0000000000000001
000000c420041d40:  0000000000000001  00000000004e4207
000000c420041d50:  0000000000000001  00000000004e4207
000000c420041d60:  0000000000426bca <runtime.dopanic+74>  000000c420041d70
000000c420041d70:  000000000044baa0 <runtime.dopanic.func1+0>  000000c420000180
000000c420041d80:  0000000000426ca1 <runtime.throw+129>  000000c420041da0
000000c420041d90:  000000c420041db0  0000000000426ca1 <runtime.throw+129>
000000c420041da0:  0000000000000000  0000000000000005
000000c420041db0:  000000c420041e00  00000000004392f1 <runtime.sigpanic+529>
000000c420041dc0: <00000000004e4521  0000000000000005
000000c420041dd0:  000000c420041e10  00000000004a864c <github.com/Bo0km4n/lupus.patchValue+124>
000000c420041de0:  00007f0de5040fb0  000000c420000180
000000c420041df0:  0000000000001000  0000000000001000
000000c420041e00:  000000c420041e78 !00007f0de5040fb0
000000c420041e10: >00007f0de5061091  000000c420041e50
000000c420041e20:  0000000000000001  0000000000000001
000000c420041e30:  0000000000000013  00007f0de5061000
000000c420041e40:  0000000000001000  000000c420041e50
000000c420041e50:  00007f0de5074a20  00007f0de50b0440
000000c420041e60:  000000c420041e50  0000000000000001
000000c420041e70:  0000000000000001  000000c420041f78
000000c420041e80:  00000000004a9054 <main.main+356>  0000000000000000
000000c420041e90:  0000000000000047  00000000004e59cf
000000c420041ea0:  000000000000000c  00000000004bc0e0
000000c420041eb0:  00000000004ec218  0000000000000000
000000c420041ec0:  0000000000000000  000000c420041ef8
000000c420041ed0:  00000000004ec218  0000000000000010
000000c420041ee0:  00000000004c9040  00000000004ec218
000000c420041ef0:  000000c42000e320  0000000000000000
000000c420041f00:  0000000000000000  00000000004c9040
runtime.sigpanic()
    /usr/lib/go-1.10/src/runtime/signal_unix.go:395 +0x211 fp=0xc420041e10 sp=0xc420041dc0 pc=0x4392f1

見事にsegvりました。

結論から言うと今回の手法では 新しい関数内で関数を呼び出していた場合は無理 ということです。正確には無理ではないかもしれません

まず、アップデート後に呼び出すnewFuncのアセンブラを見てみます。

00000000004a9140 <main.newFunc>:
  4a9140:   64 48 8b 0c 25 f8 ff    mov    %fs:0xfffffffffffffff8,%rcx
  4a9147:   ff ff 
  4a9149:   48 3b 61 10              cmp    0x10(%rcx),%rsp
  4a914d:   0f 86 91 00 00 00     jbe    4a91e4 <main.newFunc+0xa4>
  4a9153:   48 83 ec 68           sub    $0x68,%rsp
  4a9157:   48 89 6c 24 60          mov    %rbp,0x60(%rsp)
  4a915c:   48 8d 6c 24 60           lea    0x60(%rsp),%rbp
  4a9161:   48 c7 44 24 70 00 00    movq   $0x0,0x70(%rsp)
  4a9168:   00 00 
  4a916a:   0f 57 c0                 xorps  %xmm0,%xmm0
  4a916d:   0f 11 44 24 38           movups %xmm0,0x38(%rsp)
  4a9172:   48 8d 44 24 38          lea    0x38(%rsp),%rax
  4a9177:   48 89 44 24 30         mov    %rax,0x30(%rsp)
  4a917c:   84 00                 test   %al,(%rax)
  4a917e:   48 8d 05 db 39 01 00     lea    0x139db(%rip),%rax        # 4bcb60 <type.*+0x12b60>
  4a9185:   48 89 44 24 38         mov    %rax,0x38(%rsp)
  4a918a:   48 8d 05 ef f3 04 00   lea    0x4f3ef(%rip),%rax        # 4f8580 <main.statictmp_1>
  4a9191:   48 89 44 24 40         mov    %rax,0x40(%rsp)
  4a9196:   48 8b 44 24 30          mov    0x30(%rsp),%rax
  4a919b:   84 00                 test   %al,(%rax)
  4a919d:   eb 00                   jmp    4a919f <main.newFunc+0x5f>
  4a919f:   48 89 44 24 48         mov    %rax,0x48(%rsp)
  4a91a4:   48 c7 44 24 50 01 00    movq   $0x1,0x50(%rsp)
  4a91ab:   00 00 
  4a91ad:   48 c7 44 24 58 01 00    movq   $0x1,0x58(%rsp)
  4a91b4:   00 00 
  4a91b6:   48 89 04 24              mov    %rax,(%rsp)
  4a91ba:   48 c7 44 24 08 01 00    movq   $0x1,0x8(%rsp)
  4a91c1:   00 00 
  4a91c3:   48 c7 44 24 10 01 00    movq   $0x1,0x10(%rsp)
  4a91ca:   00 00 
  4a91cc:   e8 1f ff fd ff          callq  4890f0 <fmt.Println>
  4a91d1:   48 c7 44 24 70 02 00    movq   $0x2,0x70(%rsp)
  4a91d8:   00 00 
  4a91da:   48 8b 6c 24 60           mov    0x60(%rsp),%rbp
  4a91df:   48 83 c4 68           add    $0x68,%rsp
  4a91e3:   c3                       retq   
  4a91e4:   e8 27 3d fa ff        callq  44cf10 <runtime.morestack_noctxt>
  4a91e9:   e9 52 ff ff ff         jmpq   4a9140 <main.newFunc>
  4a91ee:   cc                       int3   
  4a91ef:   cc                       int3   

先程見せたf1のアセンブラとはめちゃくちゃ違います。 ただfmt.Printlnを追加しただけなのに。

完全な憶測ですが、goのコンパイラ側がスタックの調整やGC関連の命令を埋め込んでいるのではないかと思います。 ただ埋め込むだけなのは良いですが、問題は jbe 4a91e4 <main.newFunc+0xa4> こんな感じの命令が散見されることです。

これらの命令は相対アドレスを参照しています。ここまで書けば あっ...(察し)ってなるでしょう。

当然先ほどの手法では上記のアセンブラをそのままヒープ領域に確保して書き込み実行します。 つまり jbe 4a91e4 <main.newFunc+0xa4> のようなアドレスをそのまま踏んでセグフォってしまうのです。

流石にこの辻褄あわせを行う気力もどうやれば上手くやれるかも思いつきませんでした。

まとめ

返す値をちょろっと変えるだけならパッチを当てることができましたが、関数呼び出しを加えるのは難しいことがわかりました。

今回の記事は研究の一貫で調べていたものが検証していく中でかなり難しいことだとわかり、一旦保留になったので供養の意味も込めて書かせていただきました。 動的アップデートはそこまでホットな研究テーマではありませんが低レイヤなシステムプログラミングやソフトウェア工学等の観点から議論されている面白いテーマでもあります。 よかったら調べてみてください。

今回の実験したコードは下記のリポジトリにあります。 そのうちREADMEに実行のしかたとか書き加えると思います。 github.com

参考文献

postd.cc

www.amazon.co.jp

Rustのモジュールシステムが厳格

goは1年半ぐらい結構書いてきて、シンタックスもそこまで複雑ではないので大分慣れてきた気がした。 なので最近はrustをちょくちょく書いてる。

今はgoで書いた8086のディスアセンブラをrustで少しずつ書き直そうと思ってる

github.com

クローラとかは若干飽きたため。monkeyインタプリタでもよかったけど、これは最近書いたばっかでしっかり記憶に残っちゃっているのでほぼ忘れたディスアセンブラにした。

で、rustはgoのパッケージシステムと似たようなモジュールシステムがある。というか書き方を見た感じC++とほぼ一緒なのだろうか。

rustのモジュールの切り方はgoのパッケージのように気楽に切ることはできない。なぜならimportに明確に親子関係が定められているから。

goの場合例えば下記のようなパッケージ構成のとき、

.
├── ast
│   ├── ast.go
│   └── ast_test.go
├── evaluator
│   ├── builtins.go
│   ├── evaluator.go
│   └── evaluator_test.go
├── lexer
│   ├── lexer.go
│   └── lexer_test.go
├── main.go
├── object
│   ├── environment.go
│   └── object.go
├── parser
│   ├── parser.go
│   ├── parser_test.go
│   └── parser_tracing.go
├── repl
│   └── repl.go
└── token
    └── token.go

当然だが、replパッケージからparser, astパッケージをimportできる。

しかし、rustのモジュールシステムの場合はそれができない。

例えばrustで以下のようにモジュールを切ってみる。

.
├── disassembler
│   ├── mod.rs
│   └── reader.rs
├── hoge
│   └── mod.rs
└── main.rs

disassemblerのreaderからhogeを参照しようとしてみる

コードは次のようになる

hoge/mod.rs

pub fn fuga() {
    println!("fuga");
}

disassembler/reader.rs

use std::vec::Vec;
mod hoge;
pub fn start(input: Vec<u8>) {
    hoge::fuga();
    let mut da: DisAssembler8086 = DisAssembler::new(input);
    println!("{:?}", da.body);
    da.dump_cur_token();
    da.next();
    da.dump_cur_token();
    while !da.is_end() {
        da.next();
    }
    da.dump_cur_token();
}
・・・
以下略

これをビルドしようとすると次のエラーが出る

error[E0583]: file not found for module `hoge`
 --> src/disassembler/reader.rs:2:5
  |
2 | mod hoge;
  |     ^^^^
  |
  = help: name the file either reader/hoge.rs or reader/hoge/mod.rs inside the directory "src/disassembler"

error: aborting due to previous error

For more information about this error, try `rustc --explain E0583`.

エラーの通り mod hoge とreader内で書くと src/disassembler/reader/hoge/mod.rssrc/disassembler/reader/hoge.rs を探そうとする。

つまり親ディレクトリを経由したmodの参照はできないということ(もし参照できる方法あったらすいません)。

これは同一階層でのディレクトリ同士では完全に実装が依存しないようになるので結構良い気がする。

まとめ

  • rustでモジュールを切るときは依存関係をちゃんと考えて切るようにしよう
  • 同一階層内で使いたい場合は同じディレクトリにファイルを分けるようにする

まだ全然知見がないけどgoとは全然違う厳しさがあるので面白い

Golangにおけるプロジェクトのレイアウトについて

僕がGolangを好きな理由はいくつかあるが、主なものは

  1. コードが皆フォーマッターによって大体綺麗になる
  2. 言語機能が充実しすぎていないので処理が追いやすい(コーディングする時不便に感じることもあるが、チームでの開発においては読まれる方を重視したほうが良い)
  3. サードパーティのライブラリの導入が非常に簡単(もちろんプロジェクトに導入するときは慎重に行うべき)

そんなGoだけど、プロジェクトを作る時にどうパッケージを切っていくか。これが以外と暗黙の了解みたいな感じになっている気がする。

APIであればMVCライクに切るか、最近だとクリーンアーキテクチャが自分の流行だ。

CLIツールやライブラリだとプロジェクトのルート直下にフラットにファイルが展開されているものもある。

ということで少し気になったのでGoでプロジェクトを作る時にデファクトとなるようなパッケージレイアウトはあるのか?もし、あるとしたらどういう風に切るのかを少し調べてみた。

まず golang project layout みたいな感じでググるとこのリポジトリが先頭にあがった。

GitHub - golang-standards/project-layout: Standard Go Project Layout

スターは4000近くもある。それなりに認知度が高いらしい。

READMEにはこのようにかかれている

これはGoアプリケーションプロジェクトの基本レイアウトです。 Goデベロッパーチームが定義した公式の標準ではありません。 ただ、このリポジトリの構成はGoエコシステムにおける共通の歴史的かつ新しいプロジェクトレイアウトパターンのセットです。 この切り方は、他のパターンよりも人気があります。 この構成ではいくつかの小さな拡張機能と、十分な大きさのプロダクションレベルでのアプリケーションに共通するいくつかのサポートディレクトリを備えています。

とのこと。確かにこの構成はよく見るような気がする。特にinternalパッケージとpkgパッケージは他のライブラリやツールでも頻繁に登場する。

READMEにはそれぞれこのように注釈されている

internal

内部でのみ使われるアプリケーションとライブラリコード。 これは、他の人のアプリケーションやライブラリでインポートさせたくないコードです。

/ internal / pkgディレクトリ(例:/ internal / pkg / myprivlib)に、実際のアプリケーションコードを書いて、/ internal / appディレクトリ(/ internal / app / myapp)で更に共有される。

共有の部分がいまいちピンと来ないけど、コアのコードやヘルパー的なコードはこの中で書こうということなのだろう。

pkg

外部アプリケーション(たとえば、/ pkg / mypubliclib)で使用できるライブラリコード。 他のプロジェクトは、pkg内のコードが動作することを期待してパッケージwpインポートするので、ここに何かを入れる前にしっかり考えてください:-)

また、ルートディレクトリに多くの非Goコンポーネントディレクトリが含まれていて、GopherCon EU 2018のインダストリアルプログラミングのベストプラクティスに記載されているように、さまざまなGoツールを簡単に実行できるように、Goコードを1か所にグループ化する方法です。

このプロジェクトレイアウトパターンを使用している人気のあるGoリポジトリを確認するには、/ pkgディレクトリを参照してください。 これは一般的なレイアウトパターンですが、普遍的に受け入れられているわけではなく、Goコミュニティの一部では推奨していません。

ふむふむ。基本的に外部で利用する時はこのpkgディレクトリが参照されることが多いということか。 試しにこの構成に心当たりのあるプロジェクトをいくつか挙げてみようと思う。

github.com

僕もよくお世話になっているkubernetesは今回のstandard repositoryに近い構成だ。internalパッケージはないが pkg, cmd, api等他のツールでもよく見るような構成になっている。

次は、、、といきたいとこだったんだけど、以外にもgo-awesome経由でリポジトリを漁っているとpkgディレクトリはあるけどinternalはない。みたいなケースが多くて探すのが疲れた。

go-awesomeに入っているツールやライブラリの構成を眺めていて思ったのはフラットな構成がかなり多いってことだ。勿論小さなプロジェクトであればそれでいいしわかりやすいから全然いいと思う。

他の大きなプロジェクトも名称等は違えど、役割として共通しているのだろうなっていうディレクトリが多かった気がする。

ちなみに英語であれば今回のプロジェクトのレイアウトについて論じているブログ等はある

medium.com

hackernoon.com

どっちも挙げている構成は最初に挙げたリポジトリと共通点が多い。ただ、Golangの公式からガイドライン等が発表されていないのであくまで全て非公式なものではある。 僕個人としては他のプロジェクトのコードを少し追いたい時などはこういう風に共通点があると非常に楽なので助かる。

まとめ

  • プロジェクトのレイアウトの切り方は大きなプロジェクトにおいては結構共通点が多い
  • でも明確にレイアウトのガイドラインが決定されているわけではないので好きにやればいい

Goのプロジェクト内でgRPCで自分で定義したprotoファイルをimportする

自分で作ったprotoファイルを他のprotoファイルから参照する時にハマったのでメモ

サンプルプロジェクトの構成

.
├── Makefile
├── team
│   └── handler
│       └── grpc
│           └── team
│               ├── team.pb.go
│               └── team.proto
└── user
    └── handler
        └── grpc
            └── user
                ├── user.pb.go
                └── user.proto

8 directories, 5 files

構成はクリーンアーキテクチャライクにしています

proto ファイル

userから

syntax = "proto3";

package user;


service UserAPI {
    rpc GetUsers(User) returns (Users) {}
    rpc Show(User) returns (User) {}
    rpc Delete(User) returns (Empty) {}
    rpc Invite(User) returns (Empty) {}
    rpc Activate(ActivateRequest) returns (ActivateResponse) {}
}

message User {
    int64 id = 1;
    int64 team_id = 2;
    string name = 3;
    string email = 4;
    string password = 5;
    bool isOwner = 8;
}



message ActivateRequest {
    string code = 1;
}

message ActivateResponse {
    string token = 1;
}

message Users {
    repeated User Users = 1;
}

message Empty {}

普通のprotoファイルです

次はteam

syntax = "proto3";
package team;
import "github.com/Bo0km4n/go-protobuf-ref-sample/user/handler/grpc/user/user.proto";
service TeamAPI {
}

message Team {
    int64 id = 1;
    string name = 2;
    user.Users users = 3;
}

message InviteRequest {
    string team = 1;
    string email = 2;
    string password = 3;
}

message ActivateRequest {
    string code = 1;
}

message ActivateResponse {
    string token = 1;
}

message Empty {}

userを内部で参照しています。

コンパイル

最初は以下のページを参考にコンパイルを行っていましたが生成されるpbファイルのimportパスが相対パスになっており go build 時に参照できません

qiita.com

そこで上記のように github.com/... のように通常のgoのimportパスと同様にすることでこの問題を解決します

ビルドに使用するmakefileをつぎのように書きました

PROTO_TARGETS = user team
PROJECT_PATH = github.com/Bo0km4n/go-protobuf-ref-sample 
proto: 
   @echo $(PROTO_TARGETS); \
      cd $$GOPATH/src; \
  for t in $(PROTO_TARGETS); do \
      echo "protobuf build ... $$t"; \
      protoc --go_out=plugins=grpc:. $(PROJECT_PATH)/$$t/handler/grpc/$$t/$$t.proto; \
  done

最初にechoしているのはしないと cd のせいなのか Nothing to done って言われるからです

上記のリンクではプロジェクトのルート以下のパスが生成されるimportパスになっていました。 つまり、$GOPATH/src で上記のビルドを行えば生成されるimportパスが正常になります。

実際に生成されたteamのpbファイルは次のようになります

// Code generated by protoc-gen-go. DO NOT EDIT.
// source: github.com/Bo0km4n/go-protobuf-ref-sample/team/handler/grpc/team/team.proto

package team

import proto "github.com/golang/protobuf/proto"
import fmt "fmt"
import math "math"
import user "github.com/Bo0km4n/go-protobuf-ref-sample/user/handler/grpc/user"

import (
    context "golang.org/x/net/context"
    grpc "google.golang.org/grpc"
)

// Reference imports to suppress errors if they are not otherwise used.
var _ = proto.Marshal
var _ = fmt.Errorf
var _ = math.Inf

// This is a compile-time assertion to ensure that this generated file
// is compatible with the proto package it is being compiled against.
// A compilation error at this line likely means your copy of the
// proto package needs to be updated.
const _ = proto.ProtoPackageIsVersion2 // please upgrade the proto package

type Team struct {
    Id                   int64      `protobuf:"varint,1,opt,name=id" json:"id,omitempty"`
    Name                 string     `protobuf:"bytes,2,opt,name=name" json:"name,omitempty"`
    Users                *user.Users `protobuf:"bytes,3,opt,name=users" json:"users,omitempty"`
    XXX_NoUnkeyedLiteral struct{}   `json:"-"`
    XXX_unrecognized     []byte     `json:"-"`
    XXX_sizecache        int32      `json:"-"`
}

... 以下省略

これでプロジェクトのビルドも上手くいきます

$GOPATH/src に移動するのは少々スマートではない気がしますが色々調べて他に良いやり方がなかったので今回は妥協しました

一応今回のサンプルをgithubにあげておきます

github.com