続くといいな日記

React の View / State 分離パターン

2026-02-01T22:37:13+09:00

React は昨今の Web アプリ開発において当たり前に使われるようになり、エコシステムも発展し続けている。そして、Web における DOM / JavaScript とどう付き合いつつ、モバイルアプリでは当たり前だった、フロントエンドとバックエンドがそれぞれ独立のライフサイクルを持ちつつ API 通信によってのみ繋がる世界を実現するかにおいて、一つの解となっている。一方で、動きのあるフロントエンドにおける永遠の課題が、ビューと状態管理をどう保守するかであり、React コミュニティも例に漏れず非常に苦心していて、さまざまな手法が提案されては立ち消えている。

さて、ビューと状態への付き合い方について僕もよく悩むわけだが、今回は僕がよく使っている独自のデザインパターンについて備忘録がてら紹介したいと思う。

ビューと状態管理

バックエンド開発では、ドメインロジックやデータ永続化が主たる関心事になるため、それらをどう認知負荷を抑えつつ変更容易性を保って管理するかが主眼となり、クリーンアーキテクチャなどのアーキテクチャパターンが幾つか提唱されている。一方、フロントエンド開発では大きく事情が異なる。フロントエンド開発において、アーキテクチャの関心事は大きく「ビュー」と「状態管理」の2つに集約される。というのは、ドメインロジックなどはセキュリティとフロントエンドの複数化などの観点からバックエンドに集約させておくのが良いため、逆説的にフロントエンドではドメインロジック自体はバックエンド API に委ねられ、代わりにユーザーの操作に対してリアルタイムに応答するUIの構築が中心となるからだ。結果として、フロントエンドのアーキテクチャはビューの描画と、それを駆動する状態の管理が主体となる。

ビューと状態管理において、重要なポイントは2つある。1つはビューと状態管理の分離、もう1つは情報の流れの方向性だ。

ビューと状態管理は、それぞれ異なる関心事を持っている。ビューは「何をどう描画するか」「どのイベントを受け付けるか」に関心があり、状態管理は「どのようなデータをどのような形式で保持するか」「ある操作に対して状態をどう遷移させるか」に関心がある。これらが分離されていないと、例えばUIのレイアウトに引っ張られて状態の保持形式を変える必要が生じ、状態が必要以上に肥大化して更新処理も複雑化したり、状態遷移のロジックを修正したいだけなのにJSXの構造を読み解く必要が出てきたりする。ビューと状態管理を分離し、両者の間に明確なインターフェースを設けることで、それぞれを独立して理解・変更・テストできるようになる。特に状態のプラクティスは必要最小限の情報を保持することにあるが、ビューと状態管理ロジックが密室に結合しているとこの原則が破られやすく、ビューの描画のための付随情報が状態に載ってしまうといった事が起こりやすい。これを防ぐには、ビューと状態管理のロジックを分離しつつ、それぞれの接続を行いやすくする工夫が重要となる。

また、ビューはユーザーのインタラクションに応じてイベントを発火し、イベントは状態を更新し、状態の変化はビューの再描画を引き起こすため、互いに作用し合う。この相互作用自体は避けられないものだが、情報が双方向に流れる設計になっていると、ある状態の変化がどこから引き起こされたのか、あるイベントが最終的にどの状態をどう変えるのかを追跡するのが困難になる。特にコンポーネントが成長するにつれ、イベントハンドラから直接状態を書き換えたり、描画の途中で副作用的に状態を更新したりといったショートカットが入り込みやすく、データの流れが絡み合っていく。これに対して、ビューのイベント発火 → 状態の更新 → 描画パラメータの算出 → ビューの再描画という流れを常に一方向に保つことで、データの因果関係を追跡しやすくなり、各段階の責務も明確になる。

React アーキテクチャの歴史

ビューと状態管理の分離と単方向データフローは React や Web 固有の話題ではなく、UI 開発で一般に研究されてきた分野で、MVVM やリアクティブプログラミングなど様々なアイデアが登場してきた。React フロントエンドアーキテクチャの分野でもそれらの研究の流れを汲みながら、React 登場時から活発に研究されてきた。

Facebook が React と共に2014年に提案した Flux アーキテクチャは、Action → Dispatcher → Store → View の単方向データフローを規定した。これにより、状態がどこで変更されるのかを予測可能にするという指針が React コミュニティに根付いた。

その思想を洗練させた Redux は、 The Elm Architecture（TEA）に着想を得て、単一ストアと Action / Reducer による状態管理を実現した。Redux は Action / Reducer / Store / Selector という責務分割を持ち、状態遷移を純粋関数として定義するという強力なモデルを提供した。一方で、アプリケーション全体の状態を一つのストアで管理する前提のため、ボイラープレートの多さやコンポーネントローカルな状態管理との棲み分けが課題となっていた。

Dan Abramov が2015年に提唱した Container / Presentational パターンは、コンポーネントを2つの役割に分離するアプローチだった。Container コンポーネントがデータ取得と状態管理を担い、Presentational コンポーネントが props を受け取って描画のみを行う。このパターンの本質的な利点は、ビューのインターフェースを props として明示することにあった。Presentational コンポーネントの props 型定義を見れば、そのビューが何を必要としているかが一目で分かる。また、状態管理ロジックをビューから切り離し、さらに再利用可能にするアイデアとして Higher-Order Components（HOC）や Render Props といったデザインパターンも登場した。HOC はコンポーネントを受け取って状態やハンドラを props として注入した新しいコンポーネントを返す関数であり、Redux の connect() が代表例だ。Render Props は状態やハンドラを引数に取る関数を props として受け取り、その戻り値を描画するパターンで、ロジックの提供側が描画方法を利用側に委ねることができた。いずれも状態管理ロジックを複数のコンポーネント間で共有しやすくなるという利点があった。

ただこれらはいずれも記述量とパフォーマンスのオーバーヘッドの問題に悩まされていた。React 16 で導入された Hooks は、これらの課題に対する転換点となった。今や当たり前となった useCallback や useMemo によってイベントハンドラや派生データの最適化が可能になり、useReducer によって外部ライブラリを必要とせず状態遷移を表現できるようになった。そして何より、カスタムフックによってビュー以外のロジックをコンポーネントの分割なしに切り出せるようになった。Hooks 以降も、 Headless Components によるロジックと見た目の分離を再利用目的で追求するパターンや、 XState のような状態機械ベースのアプローチ、 Zustand や Jotai のような軽量なストアライブラリによるコンポーネント横断の状態共有など、ビューと状態の分離、状態管理に関するさまざまな手法が発展し続けている。

これらの歴史を踏まえると、各手法は「ビューと状態の分離」「情報の一方向フロー」「責務の明確化」という共通の課題に取り組んできたことが分かる。一方で、これらのアプローチはアプリケーショングローバルな状態管理をどうするかという話と、ビューとそれ以外のロジックをどう分離するかという2つの別軸で議論が動いており、単一コンポーネントレベルでビューと状態管理をどう分離しつつ、単方向のデータフローを実現するかのデザインパターンは僕はあまりいいのが見つけられてなかった。特にフロントエンドアプリケーションではアプリケーション全体でのライフサイクルで動く状態というのはむしろ少なく、コンポーネント単位でのライフサイクルを持つ状態の方が多い。一方で Redux や Zustand といったライブラリをそこに使ってしまうのは、依存をアプリケーション全体に広げてしまい、過剰に感じる事が多かった。

View / State 分離パターン

そこで最近はグローバルなコンポーネントを超えた状態共有は Zustand などを併用しつつ、コンポーネント単位の細かい状態管理にはあえて Zustand などの状態管理を利用せず、React の標準 API を使った View / State 分離パターンを使って書く事が個人的には多くなってきた。View / State 分離パターンは、React コンポーネントを以下の4つのパーツで構築するデザインパターンだ:

State （状態）: 状態の保存形式と状態遷移を定義する。 useReducer で記述する。
Handler （ハンドラ）: イベントをハンドリングし、状態に対する更新アクションを発行する。 useCallback で記述する。
Selector （セレクタ）: 状態からビューの描画パラメータを計算する。必要に応じて useMemo を利用する。
View （ビュー）: ViewProps 型を受け取り、どの要素をどう描画し、どのイベントをハンドリングするかを定義する。JSX の本体。

State / Handler / Selector は useViewProps というカスタムフックにまとめ、コンポーネントは useViewProps の戻り値である ViewProps からビューを記述する。 useViewProps は MVVM における ViewModel に近い役割を果たしており、内部の状態をビューが消費可能な形に変換して提供する。これにより以下の単方向データフローを実現する:

具体的なコード例を見てみよう。フィルタ付き Todo リストを題材にする。まず、State として状態の型と reducer を定義する。状態は Todo の配列と現在のフィルタモードだけを保持し、ビューでの使いやすさなどとは切り離して最小限の情報に留めるのが大事だ:

type Todo = {
    id: number;
    text: string;
    done: boolean;
};

type Filter = 'all' | 'active' | 'completed';
const FILTERS: Filter[] = ['all', 'active', 'completed'];

type State = {
    nextId: number;
    todos: Todo[];
    filter: Filter;
};

type Action =
    | { type: 'add'; text: string; }
    | { type: 'toggle'; id: number; }
    | { type: 'remove'; id: number; }
    | { type: 'setFilter'; filter: Filter }
    | { type: 'clearCompleted' };

function reducer(state: State, action: Action): State {
    switch (action.type) {
        case 'add':
            return {
                ...state,
                nextId: state.nextId + 1,
                todos: [
                    ...state.todos,
                    { id: state.nextId, text: action.text, done: false },
                ],
            };
        case 'toggle':
            return {
                ...state,
                todos: state.todos.map((todo) =>
                    todo.id === action.id
                        ? { ...todo, done: !todo.done }
                        : todo,
                ),
            };
        case 'remove':
            return {
                ...state,
                todos: state.todos.filter((todo) => todo.id !== action.id),
            };
        case 'setFilter':
            return { ...state, filter: action.filter };
        case 'clearCompleted':
            return {
                ...state,
                todos: state.todos.filter((todo) => !todo.done),
            };
    }
}

次に ViewProps を定義する。ここがパターンの要だ。ビューが必要とする情報を型として明示する。状態の内部表現（ Todo[] と Filter ）がそのまま露出するのではなく、ビューにとって扱いやすい形に変換された値が並ぶ:

type Props = {
    initialFilter: Filter;
};

type ViewTodo = {
    id: number;
    text: string;
    done: boolean;
};

type ViewProps = {
    // Selector: 状態から導出されたビュー用データ
    filteredTodos: ViewTodo[];
    remainingCount: number;
    currentFilter: Filter;

    // Handler: ビューから発火されるイベント
    onAddTodo: (text: string) => void;
    onToggleTodo: (id: number) => void;
    onRemoveTodo: (id: number) => void;
    onChangeFilter: (filter: Filter) => void;
    onClearCompleted: () => void;
};

そして useViewProps で State / Handler / Selector を統合する:

function useViewProps({ initialFilter }: Props): ViewProps {
    // --- State ---
    const [state, dispatch] = useReducer(reducer, {
        nextId: 0,
        todos: [],
        filter: initialFilter,
    });

    // --- Handler ---
    const onAddTodo = useCallback((text: string) => {
        const trimmed = text.trim();
        if (trimmed === '') {
            return;
        }

        dispatch({ type: 'add', text: trimmed });

        // 追加した Todo が見えるよう、フィルタを 'all' に戻す
        if (state.filter !== 'all') {
            dispatch({ type: 'setFilter', filter: 'all' });
        }
    }, [state.filter]);

    const onToggleTodo = useCallback((id: number) => {
        dispatch({ type: 'toggle', id });
    }, []);

    const onRemoveTodo = useCallback((id: number) => {
        dispatch({ type: 'remove', id });
    }, []);

    const onChangeFilter = useCallback((filter: Filter) => {
        dispatch({ type: 'setFilter', filter });
    }, []);

    const onClearCompleted = useCallback(() => {
        if (!state.todos.some((t) => t.done)) {
            return;
        }

        dispatch({ type: 'clearCompleted' });

        // 完了済みを消した後に空リストが表示されるのを防ぐ
        if (state.filter === 'completed') {
            dispatch({ type: 'setFilter', filter: 'all' });
        }
    }, [state.todos, state.filter]);

    // --- Selector ---
    const filteredTodos = useMemo(() => {
        switch (state.filter) {
            case 'all':
                return state.todos;
            case 'active':
                return state.todos.filter((t) => !t.done);
            case 'completed':
                return state.todos.filter((t) => t.done);
        }
    }, [state.todos, state.filter]);

    const remainingCount = useMemo(
        () => state.todos.filter((t) => !t.done).length,
        [state.todos],
    );

    return {
        filteredTodos,
        remainingCount,
        currentFilter: state.filter,
        onAddTodo,
        onToggleTodo,
        onRemoveTodo,
        onChangeFilter,
        onClearCompleted,
    };
}

今回の例では useViewProps の中で State、Handler、Selector を一緒に定義しているが、これらをファイルに分割して定義してもいいだろう。コンポーネントの大きさによってそこは調節でき、まさに責務によって分けて定義できるのがこのパターンの魅力となる。また、分けて定義する事でビューに依存せずロジックをテストすることもできるようになる。

最後に、コンポーネント本体は useViewProps の戻り値からビューを記述するだけになる。ビューは ViewProps の中身だけを知っていればよく、状態がどう保存されフィルタリングがどう計算されているかを意識する必要がない:

const TodoList = (props: Props) => {
    const {
        filteredTodos,
        remainingCount,
        currentFilter,
        onAddTodo,
        onToggleTodo,
        onRemoveTodo,
        onChangeFilter,
        onClearCompleted,
    } = useViewProps(props);

    return (
        <div>
            <NewTodoInput onSubmit={onAddTodo} />

            <ul>
                {filteredTodos.map((todo) => (
                    <li key={todo.id}>
                        <input
                            type="checkbox"
                            checked={todo.done}
                            onChange={() => onToggleTodo(todo.id)}
                        />
                        <span>{todo.text}</span>
                        <button onClick={() => onRemoveTodo(todo.id)}>
                            削除
                        </button>
                    </li>
                ))}
            </ul>

            <footer>
                <span>{remainingCount} items left</span>
                {FILTERS.map(
                    (filterName) => (
                        <button
                            key={filterName}
                            disabled={currentFilter === filterName}
                            onClick={() => onChangeFilter(filterName)}
                        >
                            {filterName}
                        </button>
                    ),
                )}
                <button onClick={onClearCompleted}>
                    Clear completed
                </button>
            </footer>
        </div>
    );
};

ビューと状態の定義が非常に自明になっているのが見て取れると思う。素朴にコンポーネントを記述する場合、ビューと状態は密になり、それぞれが互いの事情を反映しがちになる。これは小さなコンポーネントであれば素早いコーディングの役に立つが、コンポーネントが大きくなるにつれコンポーネントの成長と可読性を妨げるようになる。View / State 分離パターンでは、View と State はそれぞれ独立して設計できるため、それぞれの責務とプラクティスにフォーカスしてコーディングを行える。これにより、状態設計時にこの状態がビューから見て使いやすいかを考える必要はないし、ビュー設計時に状態遷移をどのように起こすかに捉われずに済む。そしてその分離を保ち続けやすいのが、このパターンの第一の利点だ。

これにより、状態の保存形式は、正規化や最小性を重視して設計できる。たとえば、リストの選択状態を Set<string> で保持しつつ、ビューには isSelected: boolean のフラグとして渡すといった変換を Selector 層で行える。保存形式を変えてもビューに影響しないし、ビューの表示を変えても保存形式に影響しない。

また、コンポーネントのコードを読む際に、「今読んでいるのは State の定義なのか、Handler なのか、Selector なのか、View なのか」が構造的に明確になる。各パーツは独立して理解でき、全体のデータフローは一方向に保たれるため、コードの追跡が容易になる。これは認知負荷削減にもつながる。

さらにこれらのパーツが独立していることにより、ビューに触れずにテストも書ける。ビューと状態管理が一体化しているコードでは、ビューを含んでのテストが必要になるが、ビューのテストは書くのも保守するのも基本的に難易度が高くなりがちだ。View / State 分離パターンで書かれていれば、Selector / State / Handler はビューから切り離して定義できるため、ビューをテスト対象に含めなくてもいい。

また、React 標準 API だけで実現できるのでライトに使う事ができる。 useCallback、 useMemo をつけなければいけないのが少し煩わしいが、これも React Compiler が普及すれば大幅に記述量を削減して自然な記述のみで済むようになるんじゃないかと期待している。また、React Compiler を使わない場合でも、適宜省略可能な場合は省略して良いだろう。

注意点とプラクティス

View / State 分離パターンにより、素朴に React 標準 API だけでコンポーネントの保守性を向上できる。一方で、少しボイラープレート的な記述が増え、また間接参照が増えるため、単純で枯れたコンポーネントには過剰な対応になるかもしれない。このパターンはコンポーネントが成長していくことを前提としており、ボタンやアイコンのような、状態を持たないか極めて単純な状態しか持たないコンポーネントには useState で十分だろう。目安として、状態遷移が複数あり、ハンドラが3つ以上あるようなコンポーネントでこのパターンの恩恵が大きくなる。

また、このパターンで注意すべき点が、状態のライフサイクルとコンポーネントのライフサイクルが密結合になるという点だ。そのため、コンポーネントとライフサイクルが一致しない状態は別の管理方法をとった方が良い。例えば、アプリケーション全体や複数コンポーネント間での状態共有は、 Jotai や Zustand などのより状態管理に特化したライブラリの併用が必要になる。API 通信のキャッシュなどは専用の Tanstack Query なども検討が必要だろう。ただ、それらのライブラリからコンポーネントローカルに取得した値を useViewProps 内で扱うことで、両者を組み合わせて使うことは可能だ。

コンポーネントが大きくなったときの分割を考える際も注意が必要だ。この場合、 ViewProps の肥大化をトリガーにするのではなく、状態のライフサイクルに着目すると良い分割が進みやすい。たとえば、フォームの入力状態とモーダルの開閉状態はライフサイクルが異なるため、それぞれ別の useViewProps （あるいは別のコンポーネント）に分けることが自然な分割になる。

状態のライフサイクルは多くの場合コンポーネントに密接に関連したものになり、そのライフサイクルに注目してコード設計していくのは多くの場合いい設計をもたらすと経験的に思っている。一方で状態がコンポーネントと独立のライフサイクルを持っていることもあり、そのような場合にはこのデザインパターンの枠組みには当てはまらない。そこのバランスさえ注意すれば、多くのアプリケーションに適用できるパターンなんじゃないかなと思っているので、もし興味持ったらぜひ使ってみてほしい。

まとめ

View / State 分離パターンは、React コンポーネントを State / Handler / Selector / View の4つのパーツで構築し、 useViewProps カスタムフックによってビューと状態管理を分離するデザインパターンだ。このパターンにより、ビューと状態の定義を明示的に切り離す事ができ、それぞれの関心事にフォーカスしたコーディングを行いやすくなる。一方で、状態とコンポーネントのライフサイクルが一致する場合にのみこのパターンは使う事ができ、それ以外の場合は Zustand や Tanstack Query などとの併用を考える必要があるだろう。

このパターンを使い始めたのは実は結構前で、ずっと記事のネタとして眠っていてずっと記事を書きたいなあとは思っていたが時間が取れなかった。ただ、最近 Claude Code を調教するために記事を書く具体的な需要が出てきて、重い腰上げたって感じ。結構実感としては便利なパターンなんだけど、一方で状態のライフサイクルを見誤った時に結構逆撃を被ったりもして、まだちょっと慣れてないと感じる場面も多いので、もう少しプラクティスを貯めていきたいなあという感じでもある。フロントエンド開発は難しいね。てことで、今回はこれで。

Homebrew から Nix に移行する

2025-06-02T14:56:17+09:00

Homebrew は macOS における開発者の標準のパッケージマネージャだ。 Homebrew を使えば、殆どのパッケージの最新バージョンを brew install コマンドだけで簡単にインストールできる。一方で、バージョン固定が難しく、全て最新バージョンを追い続けるか、 Homebrew がサポートしているバージョンでないと使えない。開発環境では、プロジェクトによって異なるバージョンのツールを併用したい場面が多く、環境も分けたい場合が多い。また、パッケージの依存関係までバージョンを固定したい場合もある。そのような場面では、 Homebrew は不向きだ。

Nix は同じく、パッケージマネージャで、パッケージのバージョンを固定したり、環境を分けたりすることができる。特に、 Nix は、パッケージの依存関係を全て固定することができるため、開発環境を簡単に再現することができる。加えて、 Nix Darwin や Home Manager、 nix-direnv といったツールを使うことで、システム設定や設定ファイルまで加えて、より柔軟にパッケージ管理を行うことができる。また、 Nix が標準で提供するパッケージ群の数は、他より多く、これも一つ魅力と言えるだろう。

最近、 Homebrew から Nix に完全移行し、わりかし快適になったので、今回は Nix の機能の紹介と、 Homebrew からの移行方法を紹介する。

Nix の機能とエコシステム

Nix は、再現可能で宣言的なパッケージ管理を可能とするツールであり、エコシステムの総称ともなっている。 Nix では、

パッケージをインストールする CLI
それを活用しやすくするためのシェル
Nix とのやり取りを行うための Nix 言語
Nix 言語ライブラリ自体の依存管理機能 Flake

などの機能が提供されている。また、Nix 言語ライブラリにもユニークなパッケージがいくつかあり

Home Manager: ユーザの設定を Nix で管理するためのライブラリ
Nix Darwin: macOS の設定を Nix で管理するためのライブラリ。 Home Manager との連携機能もある
nix-direnv: ディレクトリ毎の設定を Nix で管理するためのライブラリ

などがある。これらを組み合わせることで、

Linux、macOS を始め、各種 OS でのプロビジョニングを宣言的に行う
開発リポジトリに、必要なパッケージ群を宣言し、開発チームメンバーで同じ開発ツールを共有する
一部プロジェクトで、少し古いバージョンのツールを使いたい場合、一部ディレクトリ下のバージョンのみ異なるもので固定して使う
他のディレクトリに影響を及ぼすことなく、一部ディレクトリで試しに一時的にツールをインストールして、試す

といったことが行えるようになる。

僕の場合は、MacBook のセットアップを Nix で行っていて、その全ソースは https://github.com/mizunashi-mana/dotfiles にある。中身では、Git や Fish、VSCode といった日頃使うツールのインストールとセットアップから、Finder の設定や CapsLock を Control キーにマッピングする設定など macOS で最初に行う設定などを書いていて、これ一発通せば開発環境が整うようにしている。慣れると割りかし簡単にセットアップでき、がんばって macOS と格闘しなくてもいいし、設定を変えてもすぐ元に戻せるため重宝している。

今回はこの内、 Nix Darwin、 Home Manager を使う場合の、macOS パッケージ管理を Homebrew から移行する方法を紹介する。

Nix への移行手順

移行手順は、大きく以下のステップで行うと良い:

Homebrew を Nix でセットアップ
シェル設定を Nix へ移行
Homebrew パッケージを Nix パッケージに移行
Nix へ設定を完全移行

というのは、いきなり全てを Nix へ完全移行するのは、パッケージ数によっては結構大仕事になるからだ。まず、一旦試しに使ってみるという面でも徐々に移行できると良いだろう。

1 の手順では、まず Nix をインストールし使い始めつつ、パッケージや設定ファイルの管理は今までと同じ方法でできる。
2 の手順で、シェルだけ Nix に完全移行することで、環境変数などのセットアップが済み、Nix パッケージを使い始める準備ができる。
3 の手順で、Homebrew から脱却し、パッケージ管理のみ Nix に移行できる。
4 の手順は、気が向けばだが、設定ファイルなども Home Manager の管理下に置いておくと、Nix だけでプロビジョニングできるようになり、互いの連携も Home Manager がいい感じにしてくれる。

この流れで移行すれば、段階的に少しずつパッケージを Nix に移行できる。では、具体的に移行手順を見ていこう。

Homebrew を Nix でセットアップ

まず、Nix をインストールする。インストールは、公式インストーラを使ってもいいが、非公式のインストーラを使うと、アンインストールが簡単にできるので、こちらを使うことをお勧めする。

Nix がインストールできたら、作業用のディレクトリを以下のように作る:

mkdir ~/workdir
cd ~/workdir

ここで、Nix の設定を行っていく。まず、 flake.nix を以下のように作成する:

{
    description = "A flake to provision my environment";

    inputs = {
        nixpkgs = {
            url = "github:nixos/nixpkgs?ref=nixos-unstable";
        };

        home-manager = {
            url = "github:nix-community/home-manager";
            inputs.nixpkgs.follows = "nixpkgs";
        };

        nix-darwin = {
            url = "github:LnL7/nix-darwin";
            inputs.nixpkgs.follows = "nixpkgs";
        };
    };

    outputs = {
        self,
        nixpkgs,
        home-manager,
        nix-darwin,
    }: {
        darwinConfigurations = {
            "my-macbook" = nix-darwin.lib.darwinSystem {
                # x86 macOS 使ってる場合は、"x86_64-darwin" を指定する
                system = "aarch64-darwin";

                modules = [
                    {
                        system = {
                            stateVersion = 5;
                        };
                    }
                    home-manager.darwinModules.home-manager
                ];
            };
        };
    };
}

この状態で、以下を実行する:

nix run nix-darwin -- switch --flake .

これにより、Nix Darwin と Home Manager の導入が完了する。と言っても、これを実行したところで、特にシステム設定が変わることも、パッケージ導入が行われることもない。この設定を元に、肉付けを行うことで、macOS のシステム設定やパッケージの導入を行うことができる。

まず、Homebrew の設定を行ってみる。 zoxide というツールを題材にしてみる。元々 zoxide を Homebrew でインストールしている想定で、以下のように flake.nix を編集する:

                        system = {
                            stateVersion = 5;
                        };
+
+                       homebrew = {
+                           enable = true;
+
+                           brews = [
+                               "zoxide"
+                           ];
+                       };
                    }
                    home-manager.darwinModules.home-manager

この状態で、

nix run nix-darwin -- switch --flake .

を実行すると、 zoxide が Homebrew 経由でインストールされる。現在インストールされている、Homebrew パッケージをこのように移していけば、Nix でひとまずパッケージ管理ができるようになる。

この状態でも、macOS の設定管理を Nix で行うことができる。例えば

                    {
                        system = {
                            stateVersion = 5;
+
+                           controlcenter = {
+                               BatteryShowPercentage = true;
+                           };
                        };

                        homebrew = {

と書いて、 nix run を実行すると、macOS のメニューバーでバッテリーのパーセンテージが表示されるようになる。他にも様々な設定が、 Nix Darwin のマニュアルから確認できる。

シェル設定を Nix へ移行

これまでの手順で、Homebrew パッケージを Nix 経由でインストールしたり、macOS の設定を Nix 経由で管理したりはできる。ただ、このままでは、開発環境の再現性の問題は解決しない。その為には、Homebrew パッケージから Nix パッケージに移行する必要がある。ただ、Nix パッケージを利用するには、Nix の環境変数をシェルに読み込む必要がある。

Bash や Zsh であれば、Nix Darwin がデフォルトで連携してくれるので問題ない。Fish を使っている場合は、連携を有効化する必要がある。Fish を使っている場合、 flake.nix を以下のように変える:

                                "zoxide"
                            ];
                        };
+
+                       programs.fish = {
+                           enable = true;
+                       };
                    }
                    home-manager.darwinModules.home-manager

この状態で nix run を実行すると、 /etc/fish/config.fish ファイルに Nix との連携用設定が書き込まれ、Nix パッケージのパスなどが環境変数に読み込まれるようになる。これで、Nix パッケージが Fish で使えるようになる。

これだけでも Nix パッケージは使えるようになるのだが、Home Manager との連携はされていないため、フルに恩恵を受けられない部分がある。例えば、この後 zoxide を Home Manager 管理に移行していくのだが、そこでシェルを Home Manager と連携しておくと、 zoxide とシェルの連携を Home Manager が自動で行ってくれる。他にも、追加の環境変数やエイリアス管理などを行ってくれるため、まずシェルを Home Manager とも連携しておくのをお勧めする。

Home Manager とシェルの連携は、例えば Fish の場合、 flake.nix を以下のように編集する:

            home-manager,
            nix-darwin,
        }:
-       {
+       let
+           # 設定するマシンのホスト名を指定
+           hostname = "my-macbook";
+           # 設定するマシンのユーザ名を指定
+           username = "my-username";
+           # x86 macOS 使ってる場合は、"x86_64-darwin" を指定する
+           system = "aarch64-darwin";
+           homedir = "/Users/${username}";
+
+           pkgs = import nixpkgs {
+               inherit system;
+           };
+       in {
            darwinConfigurations = {
-               "my-macbook" = nix-darwin.lib.darwinSystem {
-               # x86 macOS 使ってる場合は、"x86_64-darwin" を指定する
-               system = "aarch64-darwin";
+               "${hostname}" = nix-darwin.lib.darwinSystem {
+                   inherit system pkgs;

                    modules = [
                        {
...
                            };
                        }
                        home-manager.darwinModules.home-manager
+                       {
+                           home-manager.useGlobalPkgs = true;
+                           home-manager.useUserPackages = true;
+                           home-manager.users."${username}" = {
+                               home.stateVersion = "25.05";
+
+                               home.username = username;
+                               home.homeDirectory = homedir;
+
+                               programs.fish = {
+                                   enable = true;
+                                   shellInit = builtins.readFile ./init.fish;
+                               };
+                           };
+                       }
                    ];
                };
            };

そして、 init.fish ファイルを同じ場所に作成し、そこに Fish の設定を書く。それから、 nix run を実行すると、Fish の設定が Home Manager 経由で適用される。

Zsh の場合は programs.zsh を使って同様に、Bash の場合は programs.bash を使って同様に設定できる。詳しい設定方法は、 Home Manager のオプションマニュアルを参照すると良い。

Homebrew パッケージを Nix パッケージに移行

ここまでで、Homebrew パッケージを Nix パッケージに移行する準備が整うので、あとは順次移行しやすいものからパッケージ毎に移行していけばいい。 zoxide の場合は、以下のように flake.nix を編集する:

                            homebrew = {
                                enable = true;

-                               brews = [
-                                   "zoxide"
-                               ];
+                               brews = [];
                            };

                            programs.fish = {
...
                                    enable = true;
                                    shellInit = builtins.readFile ./init.fish;
                                };
+
+                               home.packages = [
+                                   pkgs.zoxide
+                               ];
                            };
                        }
                    ];

これで、 zoxide を Homebrew 経由のものから Nix パッケージのものに切り替えることができる。動作確認できたら、 brew remove zoxide で Homebrew 側のパッケージを削除しておくと良い。これで、 zoxide の Nix パッケージへの移行が完了する。このようにして、それぞれのパッケージを順次 Nix パッケージに移行していくことで、Homebrew から脱却してバージョンを固定し依存パッケージ込みで独立に管理できるようになる。

パッケージのバージョンは、 nix flake update を実行することで更新できる。これにより、 flake.lock ファイルが更新されるが、これをバージョン管理していくことで元のバージョンにすぐ戻せる。

Home Manager へ設定を完全移行

ここまでで、Homebrew パッケージを Nix パッケージに移行できた。あとは、設定ファイルなども Home Manager 経由で管理してしまうと、Nix だけでプロビジョニングできるようになる。例えば、 zoxide を Home Manager に完全移行する場合、次のように書く:

                                    shellInit = builtins.readFile ./init.fish;
                                };

-                               home.packages = [
-                                   pkgs.zoxide
-                               ];
+                               programs.zoxide = {
+                                   enable = true;
+                               };
                            };
                        }
                    ];

home.packages では指定したパッケージのバイナリが使えるだけだったが、 programs.zoxide を指定することで Home Manager が連携してるシェルで zoxide init を実行し、 z コマンドなどを使えるようにしてくれる。他にも git や ssh を設定ファイル込みで管理できたりする。Home Manager で設定できるツールは、 Home Manager のオプションマニュアルから確認できる。

後は段階的に移行していけば、macOS の設定と各パッケージの設定を Nix だけで管理できるようになる。一部 GUI アプリケーションは、Homebrew 経由で入れたほうが楽な場合もあるが、そこも Nix Darwin 経由で Homebrew パッケージを管理できるので、他のマシンへの移行も格段に楽になるだろう。

まとめ

今回は、Homebrew から Nix への移行方法を紹介した。Nix は、パッケージのバージョン固定や環境の分離が容易で、開発環境の再現性を高めることができる。Homebrew から Nix への移行は、段階的に行うことで、既存の環境を壊すことなくスムーズに行える。さらに、Nix のエコシステムを活用することで、macOS やツールの設定も一元管理できるようになり、ツールのバージョンも自由に戻せるようになる。移行はシェルの設定から始め、パッケージを順次 Nix に移行していくと良いだろう。

Nix、昔はかなり不安定でUX最悪みたいな感じだったが、ようやく色々時代が追いついてきたらしい。久しぶりに触ってみたけど、かなり快適に使えるようになってて、驚いた。 dotfiles も最近完全に Nix 移行して、手軽にいじれるようになって便利。興味持ったらぜひ使ってみてほしい。では、今日はこれで。

10G光インターネットを使う

2025-01-15T18:51:48+09:00

最近ネット回線を特に意味もなく10Gプランに変えてみたので、その備忘録。特にいくつか詰まる部分があったので、それを残しておく。

10GbE市販普及の背景

さて、インターネットが人類に欠かせない社会インフラとなってから、30年ぐらい経とうとしている。最近は、インターネットが関与しないサービス、全く利用しない人というのはほぼいないだろう。そのため、技術もそれに合わせて進歩してきている。例えば、インターネットの基盤だったIPプロトコルも、v4からv6への移行が着実に進みつつあり、Google先生が公開している IPv6使用状況データによると、45%のトラフィックがIPv6で行われるようになってきているようだ。また、ダイヤルアップ接続からADSL、光回線と物理的な配線状況も変わってきており、それに合わせて PPPoE ではなく IPoE での接続を提供するプロバイダも増えてきている。今や当たり前となった無線LANの技術も変わってきており、高密度環境を想定し、WPA3によるセキュリティ強化などを行なったWi-Fi 6 (IEEE 802.11ax)、Wi-Fi 7 (IEEE 802.11be) などの規格も登場している。イーサネットもトラフィックの爆増を見据えて、ギガビットイーサ (GbE) からテラビットイーサ (TbE) への領域に足を踏み出し始めていて、25Gイーサネットコンソーシアムが、800GbEの発表と共にイーサネットテクノロジーコンソーシアムに改名したのが進化の流れの速さを物語っているだろう。

このような状況で、今までデータセンターなど特別なトラフィック需要を持つ場所でしか使われてこなかった10ギガビットイーサネット、通称10GbEも、市販に降りてくるようになってきている。これは、もちろん光ネットワーク (PON) が、10G-EPON などのイーサネット基盤の登場と、家庭配線が10GBaseへ対応してきたことなどのインフラの一新が進んできたことも大きいが、ルータやWi-Fi規格などの市販ネットワーク機器が10GBaseの恩恵を受けられるようになってきたというのも大きいだろう。2025年現在、正直10GBaseはまだ若干早すぎる感は否めず、大体はどこかで1GBase止まりになる気はするが、それでも最新の機種は明確に10GbEを意識するようになってるんじゃないだろうか。

さて、僕は特に何も考えず惰性でビッグローブ光を使い続けてるんだが、ビッグローブ光が10Gプランを最近公開したので、そんなこんなでちょっと試してみるかということで1Gプランからの回線変更してみることにした。ついでにビッグローブ光はおそらく裏側はNTT フレッツ光で、10Gの場合はフレッツ光クロスをバックエンドに使ってると思われる [1]。ビッグローブ光がいいサービスかはノーコメントで。最終的にいくつかトラブルを踏んだが、まあ1日ネット使えなくなっただけで無事移行できた。ネット環境は確かにそれなりに快適にはなったが、そこに到達するには色々やる羽目にはなるのでそこら辺を書いておく。

10GbEに必要なもの

まず一つ言っておくことがある。それは、基本的に10Gプランというのは物好きが使うプランであるということ、そして10Gプランの恩恵を受ける場合はそれなりの投資が必要になるということだ。日本のインターネット回線業者というのは基本タチが悪いと僕は勝手に思ってるんだが、家庭用10GbEプランの話も例外ではないんじゃないだろうか。まるで回線業者の案内を見ると、10Gプランにすれば快適なインターネット速度が出せるように見えるが、そんなことはない。金が余っていて、なんとなく10Gでみたいな人はともかく、本気で回線速度を上げて10GbEの世界に踏み込みたい場合は回線を10Gにするだけではダメだ。単に余計に金がかかるだけだ。

10GbEに踏み込むには、基本始端から終端まで10GbE対応する必要がある。つまり、

ワイヤレスの場合

Wi-Fi 6E以上、せめてWi-Fi 6の無線LAN対応
2Gbps以上のトラフィックに対応できるコンピューティングリソース
無線LANルータWAN端子の10GbE対応
有線ケーブルの10GbE対応

有線の場合

10GbE対応のネットワークアダプタ
2Gbps以上のトラフィックに対応できるコンピューティングリソース
ルータWAN/LAN両端子の10GbE対応
有線ケーブルの10GbE対応

が揃ってる必要がある。具体的には、Wi-Fi 経由のタブレットで動画を見る時、10GbEの恩恵を受けるなら、

無線LANルータのWAN端子(インターネット端子)が、10GBase-T対応のもの (伝送速度 10GBps と書いてある場合もある)
- レンタルするONUによっては、5GBase-T、2.5GBase-T対応でも一部恩恵を受けられるかもしれない
無線LANルータが、IEEE 802.11ax以上対応のもの (Wi-Fi 6、Wi-Fi 6E と書いてある場合もある)
- 2025年1月現在、IEEE 802.11ax、IEEE 802.11beが該当する
- せめてIEEE 802.11ac (Wi-Fi 5)であれば、一部恩恵を受けられるかもしれない
タブレットの無線LANアダプタが、IEEE 802.11ax以上対応のもの
- せめてIEEE 802.11ac (Wi-Fi 5)であれば、一部恩恵を受けられるかもしれない
配線はカテゴリ6A以上のLANケーブルを使う
- せめてカテゴリ6であれば、一部恩恵を受けられるかもしれない
- なお、仕組み上基本カテゴリが高くなるほどケーブルは太くなるので、6Aで十分

で周りを固める必要がある。これらの条件が一部でも欠ける場合、正直1G回線でも大差はないだろう。ケーブル以外は大体それぞれここ数年で出てきたものなので、だいたい買い換える必要があるはずで、その投資額は万単位にはなるはずだ。回線料金の増加額がいくら小さく見えたところで、1G回線に比べて高くなる以上、投資額が見合ってるかはちゃんと考えたほうがいい。

ついでに、有線でPCなどに接続する場合も当然ネットワークアダプタ (NIC) が10GbE対応、具体的には10GBase-T対応してないと意味がない。また、ルータのLANポートも10GBase-T対応している必要がある。10GBase-T対応のNICは、当然PCIeスロット結構取るので、新しく買って刺すにしろPCのボードに空きスロットがそれなりにある必要がある。たまにSwitchのオンラインゲームの体験向上で10G回線勧めてる話見ることがあるが、SwitchのNICは1000Base-Tまでの対応なので、最大1GBpsまでだ。最大を常に出したいとかならともかく、基本1G回線で配線全部1000Base-T対応するぐらいでいいんじゃないかと思う。

今回僕は、

元々配線はカテゴリ6Aのでやってて（てかLANケーブルはカテゴリ6Aで統一してる）、
NECの無線LANルータは前のがそろそろサポート期間終わりそうだったのと、たまにハングするのがうざくて、ついでに Baffalo WXR-11000XE12 に乗り換え、
PCのNICも10GbE NIC買ってきて差し替え
スイッチハブは1000Base-Tのもの2個使ってたが、1個だけルータからの分岐ハブを10GBase-Tのものに買い換え、もう1個はまあいいやって思ってそのまま

をやって締めて10万ぐらいはかかってる気がする。端末はWi-Fi 6対応してる奴らと、対応してない奴らが半々って感じで、買い替えするまでは恩恵受けるのは半分ぐらいかなって感じ。ま、それでも1G回線よりは快適になったのでいいかなって感じ。ただ、これから契約する人は、ここまでの手間と費用かける価値があるかはちょっと考えたほうがいいんじゃないかとは思う。

IPoEとIPv6

さて、ここからは少し話が逸れるんだけど、ビッグローブ光の10GプランはIPv6オプションというものが強制させられるのでその話。これは僕は1Gプランの時から利用していたんだけど、今回ルータ買い換えるにあたって設定でちょっと手間取った部分なので。

ビッグローブ光には、IPv6オプションというのがある。従来はIPv4 PPPoEでのインターネット提供になるんだが、このオプションつけるとIPoE接続での提供になる。IPoEというのは、元々はIP over Ethernet の略で、単にイーサネット上でIP通信する、LANにおいて普通のネットワーク方式だ。じゃあ、なぜ元々それをインターネットでは使ってなかったのかという話なんだが、これはかなり日本の歴史の話になるので、今回は省略する。ひとまず押さえておいて欲しいのは、

現在のインターネット光回線基盤は、NTT フレッツが管理するIPv6ネットワーク網 (NGN網) を各社が共有して使っている
回線業者のいうIPv4 PPPoE、IPv6 IPoE接続というのは、正確にはNGN網を通してプロバイダ認証を受けつつ、インターネットとどう通信するかの方式を指す

ということだ。よくIPv6 IPoEはネイティブ方式とか言われてるのを見かけると思うが、あれはIPv6がNGN網でのネイティブの通信方式であり、さらに認証もプロバイダではなくNGN網内でやってくれるからで、つまりNGN網の仕組みで閉じているからだ。逆にIPv4 PPPoE、IPv6 PPPoEは、末端とプロバイダはPPPoE接続して、プロバイダが認証し、NGN網内やインターネット通信はIPv6でやるわけだから特殊ということであり、オーバヘッドも当然かかるし、プロバイダがボトルネックになるため色々不便になりやすいということだ [3]。なお、IP over EthernetはもちろんIPv4 over Ethernetも含むわけだが、上の事情からIPv4 over Ethernetは単にIPv6への変換コストがかかって特に嬉しみがないため提供されていない。そういうわけで、IPoEはIPv6前提の接続方式とかいう謎の説明が巷で流布しているワケだが、あれはネイティブにNGN網と接続するにはIPv6 over Ethernetである必要があり、IPv4 over Ethernetは使う意味がないためというのが正しい。

フレッツ光クロスは元々IPoE接続だけ先行して出しており、PPPoEの対応は後回しになった。それに関連してか分からないが、とにかく、ビッグローブ光 10Gプランでは、IPv6 IPoE必須になっている。ただ、これで困るのが、世界的にまだIPv4通信がインターネットの半分のトラフィックで使われているという事実だ。その背景にはもちろんクライアント側の対応が追いついていないというのもあるが、IPv6非対応のサービスが結構あるという側面がある。つまり、インターネットとのやり取りをIPv6通信のみに限定してしまうと、そういうサービスへの利用を阻害してしまうことになり、それが許容されるほどの状況ではないということだ。そこで、ネット回線各業者はそれぞれIPv4 over IPv6の整備をしているのが現状になる。つまり、末端からNGN網内に入るときと、NGN網からIPv4インターネットに出る時に、いい感じにIPv4への変換をかましつつ、NGN網上ではIPv6通信することでIPoE接続を実現しようというわけだ。ややこしいのが、IPoEの導入はNGN網という統一のものがある以上足並みが揃ったんだが、IPv4 over IPv6は技術がトラフィック品質というビジネス価値に直結するということ、元々IPv4 over IPv6標準規格が色々迷走していたことも相待って、足並みが揃わなかった。その結果、プロバイダ側で多数のIPv4 over IPv6方式が開発、運用され、ルータ側がなんとかそれに全て追従するという現状がある。さらに、もちろん接続するプロバイダで方式が違うわけなので、昨今のルータにはこの方式を自動判定する機能というのがついていて、回線業者の案内もこの自動判定機能に頼っているというのが現状になる。僕はこの辺正直詳しくないので詳細は話せないのだが、ビッグローブ光ではMAP-Eという規格をベースにした、独自の実装を使っている。これは、現在最も普及しているIPv4 over IPv6方式である、v6プラスという方式との互換実装らしい。

つまり、ビッグローブ光 10Gプランを使用してまともにインターネッツするには、最低でもIPv6対応と、ビッグローブ光IPv6オプション対応が必要になり、恩恵を受けるならさらに10GbE対応が必要になるということだ。もちろんこんな背景普通の人が知る由もないので、ビッグローブ光のCSからは各案内で「お使いのルータはMAP-E対応が必要になります」と連呼されることになる。しかも恐ろしいことに、MAP-E(ビッグローブ光IPv6オプション)対応しているかはルータのマニュアル・仕様を見ても分からない場合が多く、ファームウェアバージョンで左右されたりもするということになる。おそらくビッグローブ光CSも、ルータ側のCSも全容を把握してないだろうから、問い合わせても正確なところは分からないだろう [2]。そういう背景があるので、ビッグローブ光 10Gプランは割と上級者向けかもしれない。多分トラブルなくいくことを祈るか、ビッグローブ光が提供するレンタルルータを一時的に借りてそれで凌ぎつつ、自分のルータ買って接続できるか試してみるぐらいのリスクコントロールはしておいたほうがいいかもしれない。

WXR-11000XE12の設定

最後に備忘録的に、今回やったルータの設定も載せておく。上の背景の通りで、これ通りにやって1年後もちゃんと動くかは分からんが...。

まず、インターネット接続する前にルータのセキュリティ周りの設定だけ見ておく。マニュアルを見つつ、やっていく。WXR-11000XE12は、初期LAN側アドレスとして192.168.11.1を使う。セットアップツールダウンロードして立ち上げると、このアドレスをブラウザで立ち上げるんだが、ま最初から Wi-Fi か有線で LAN に繋いで、 http://192.168.11.1 叩けばいい。初期パスワードは、同梱された紙に書いてあるはずなので見ておくのがいいだろう。で、今回は

管理パスワード変更: 当然のこととして
WPA2 SSID無効化: 端末が対応してればWPA3だけで十分なので。電波干渉も減るし。なお、古い端末は古い認証にしか対応してないことあるので、その点は気をつけたほうがいい
各 SSID パスワード変更: これも当然。もし、WPA2、WPA残すなら、そのSSIDとWPA3でパスワード分けておいたほうが無難
EasyMesh無効化: 使わないので
WPS無効化: 使わないので。WPSはセキュリティ的に脆弱なので。まあでも使うやつは使うので、その点は気をつけて
AOSSボタン無効化: 使わないので。本体持ち上げようとした時、たまに間違えて押しちゃう
共有フォルダー機能無効化: やるとしてもLANにはやらせんだろ... ということで無効化

をやった。やるべきかは分からんけど、手癖みたいなもので。で、その後ルータ再起動しておく。

後は、回線工事終わったらONUの認証ランプがついてるかは確認しておく。これがついてない場合、回線工事がトラブってるか、回線がトラブってるか、ONUがトラブってる。その場合は頑張ってくれ。で、ONUとルータをLANケーブルで繋ぐ。ルータのLANケーブルはWAN端子に繋ぐ。これでちゃんとルータが認識されれば、ONU側のついてなかったランプ(僕の場合はUNIランプ)がつくはず。これで、ルータのインターネットランプもついて、インターネット接続が普通はできるようになる。

インターネット接続されたら、ファームウェアを最新に更新しておくと良い。インターネット接続できなかったら、Internet > IPv6 の設定を多分頑張って見直すことになる。今回僕はそんなことなかったけど、ルータ再起動、設定初期化、LANポートのケーブル一旦全部抜いてやってみるとかはやった方がいいかも。後、ステータス > ログってところを確認するのがいい。上で言ったように、基本的に昨今のルータはIPv4 over IPv6方式を自動判定する機能がついていて、今回のルータも自動判定がデフォルトになっている。で、その場合、ログには

Starting Internet@Start targeting address type is IPv6.

みたいなメッセージが出てるはず。もしちゃんと機能していれば、その後のどこかで

Confirmed MAP-E(V6OPTION).

みたいなメッセージが出てるはず。逆に失敗していたり、検出が誤動作してる場合はその旨のメッセージが出てるはずなので、そこから頑張って原因究明していくしかなさそう。その場合は辛いことになるだろうけど頑張ってくれって感じ。

で、それが上手くいけばそこで終わりかというと、微妙な話が待っている。というのは、このルータのIPv4 over IPv6モードはデフォルトで、LAN内はIPv6に対応しないようになっている。つまり

端末 <-IPv4-> ルータ <-IPv6 (IPv4 over IPv6)-> ONU <-IPv6 (IPv4 over IPv6)-> NGN <-IPv4-> インターネット

みたいな経路の通信しか許されない。そのため、アクセス先のサービスがIPv6対応していても、全部IPv4になってしまう。これを確認するには、

curl -v https://flets-east.jp

とかやってみるのがいい。フレッツのサイトはIPv6にしか対応してないので、アクセスできないはず。これでもまあIPoEの恩恵は受けられるが、IPv6で直通したほうが当然速い。そこで、LAN内でもIPv6を使うようにする。Internet > IPv6の設定で、「インターネット@スタートを使う」というオプションが選ばれてると思うが、その項目に付随して「IPv6ブリッジを許可する」というチェックがあるはず。これをオンにして再起動しておくと、IPv6対応してるサービスについては

端末 <-IPv6-> ルータ <-IPv6-> ONU <-IPv6-> NGN <-IPv6-> インターネット

となり、IPv6での直通になる。フレッツのサイトでも繋がるようになるはず。もちろん、端末がIPv6対応してればだけど。

まとめ

というわけで、10G回線普及の背景と、それにまつわるいろんな話、10G回線導入にあたって気をつけることなどをつらつら書いた。色々ハマりポイントあったが、これで次に同じことあっても、もうちょっとうまく対処できるといいなあ。後、10G導入する時は、ちゃんと投資に見合ってるか考えたほうがいいぞ、現場からは以上です。

なお、NGN周りの話は、JPNICの記事 https://www.nic.ad.jp/ja/newsletter/No70/0800.html が分かりやすいので興味あれば見てみるといいんじゃないだろうか。というわけで、今回はこれで。

[1]	https://join.biglobe.ne.jp/ftth/hikari/faq/faq-bh001.html?cl=faq-bh001 ら辺からの推測

[2]

これは実は実体験した。実は、元々NEC WG2600HP3というルータを使ってて、回線変更時もこれでいけるかなと思ってそのままにしてたんだが、結果的にうまくいかなかった。これをビッグローブ光に問い合わせたところ、NTT、NECへとたらい回しにされた挙句結局解決しなかった。原因は今も不明のままで、元々IPv6オプションで接続できてたので、新しいONUとの伝送速度面での食い合わせが悪かったんじゃないかとは思っている。ただ、このルータはビッグローブ光のFAQにも、NECのFAQにもIPv6オプションに対応していると案内されていたのに、双方のCSからMAP-E対応うまくできていないんじゃないかと言われた。ま、新しいルータ買っといてよかったって感じ。

[3]	元々の記事内容でPPPoEは廃れて、IPoEに全部寄せてくんじゃないかという話をしてたんだが、根拠としてた内容はPPPoEの廃止ではなくIPv4 PPPoEの廃止の話でそれを勘違いしていた。今の所、NGNでIPv6 PPPoE、IPv6 IPoEどちらかを捨てるという話は出ておらず、それぞれ長短あるためどちらも存続させるという話のようだ。申し訳ない

F-ing modules: 存在型によるモジュール基盤

2024-11-21T22:02:31+09:00

現代的なプログラムは、非常に複雑で規模の大きなものが多い。そのため、プログラムを構成する部品を適切に分割し、それぞれの部品を独立して開発することが重要である。昨今のプログラミング言語においても、そのような独立に部品を開発することを支援する機構は必要不可欠となっており、様々な機能が提案されている。ML系の言語に見られるようなモジュールシステムもその一つである。

通称 ML モジュールと呼ばれるその機構では、幾つかの関数や定数といったプログラム片、型定義などをまとめて構造化できるストラクチャ、ストラクチャの中身に対してアクセスするためのインターフェースとなるシグネチャ、受け取ったストラクチャを元にストラクチャを定義できるファンクタといった、プログラムを構造化するための非常に強力な概念を提供している。これらの概念により、ストラクチャによってプログラムを柔軟に構造化し、シグネチャによってプログラムの部品を抽象化し、ファンクタによってその部品に多相性を持たせ抽象性を高めるといったことが可能になる。

しかし、ML モジュールはその機能が強力ゆえに複雑であり、特に型システムとの連携を考えると、その実装は非常に困難である。そのため、ML モジュールに型システムと連携しやすく、実装しやすい形でどう意味論を与えていくか、ML モジュールが持つ機能的性質をどう説明していくかについては、多くの提案がなされてきた。F-ing modules もその一つで、この手法では System-Fω へのプログラム変換による意味論を与える。F-ing modules では、ML モジュールを基本的にはレコードで表現しつつ、抽象化機能のバックエンドを存在型による操作によって表現し、System-Fωの表現力の範疇で意味論の構築に成功している。これにより、今回紹介するSystem-Fωへのプログラム変換で ML モジュールを実装することも可能だし、System-Fωの型検査からリバースエンジニアリングして直接型システムによりモジュールシステムを実装することも可能となる。今回はこの F-ing modules について紹介する。

題材は以下:

Andreas Rossberg, Claudio Russo, and Derek Dreyer. 2014. F-ing modules. J. Funct. Prog. 24, 5 (September 2014), 529–607. https://doi.org/10.1017/S0956796814000264

なお、TLDI 2010 が初出なんだが、JFPの方がページ数が多く行間が比較的少ないのと、こちらの方が改訂版になるので、読むならこちらの JFP の方をお勧めする。

ML モジュールによる抽象化

まず前提として ML モジュールを少し紹介しておく。と言っても、実は僕もそこまで使用経験ないので、OCaml とか、SML とかのチュートリアル読んだり、実際触ってみた方がいいかもしれない。なお、僕は OCaml しか知らないので、構文は OCaml 寄りのものを使っていく。

プログラミングにおいて、整数集合、つまり重複のない整数の集まりを使ったアルゴリズムを実装するシチュエーションを考える。この場合、整数集合を表現するプログラム片を切り離し抽象化しておくことで、よりアルゴリズムの本質的な部分の実装に集中できる。その為、整数集合に関する部分を1つのモジュールとして実装したい。そのような場合に ML モジュールのストラクチャを使うことで、以下のように整数集合を表現するモジュールを定義できる:

module IntSet = struct
    type elem = int
    type t = elem list

    let empty = []
    let rec add (x, ys) = match ys with
        | [] ->
            [x]
        | y :: ys ->
            if x = y then ys
            else if x < y then x :: ys
            else y :: add (x, ys)
    let rec delete (x, ys) = match ys with
        | [] -> []
        | y :: ys -> if x = y then ys else y :: delete (x, ys)
    let rec member (x, ys) = match ys with
        | [] -> false
        | y :: ys -> x = y || (y < x && member (x, ys))
end

これはソート済みリストによる素朴な整数集合の実装で、 IntSet.t が整数集合を表すデータ型、 IntSet.empty が空集合、 IntSet.add が要素を追加する関数、 IntSet.delete が要素を削除する関数、 IntSet.member が要素が含まれるかを判定する関数になる。このモジュールを使うことで、整数集合に関する処理を抽象化し、他の部分と独立して開発することができるし、性能などの面で内部実装を変えたくなったら、それぞれのこちらのモジュールの実装だけを変えることで変更が可能になり抽象性を担保できる。

ところで、抽象性を担保できると言ったが、厳密にはこのプログラムでは抽象性、つまりこのモジュールの実装を他のモジュールに影響を与えずに変更できるという性質を壊してしまう可能性がある。例えば、 IntSet.t が int list であることが外部からも分かる為、それを前提としたプログラムをこのモジュールの外で書かれてしまうと、 IntSet.t を別のデータ型に変更する際変更がこのモジュールだけで閉じなくなってしまう。このような問題を解決する為、シグネチャを使用することができる。例えば、以下のように整数集合のシグネチャを付与できる:

module type INTSET = sig
    type elem = int
    type t

    val empty : t
    val add : elem * t -> t
    val delete : elem * t -> t
    val member : elem * t -> bool
end

module IntSet: INTSET = struct
    type elem = int
    type t = elem list

    let empty = []
    let rec add (x, ys) = match ys with
        | [] ->
            [x]
        | y :: ys ->
            if x = y then ys
            else if x < y then x :: ys
            else y :: add (x, ys)
    let rec delete (x, ys) = match ys with
        | [] -> []
        | y :: ys -> if x = y then ys else y :: delete (x, ys)
    let rec member (x, ys) = match ys with
        | [] -> false
        | y :: ys -> x = y || (y < x && member (x, ys))
end

通常シグネチャを指定する際は、 module IntSet: sig ... end = struct ... end という形で指定するのだが、今回は module type でシグネチャを作って指定している点と、 sig ... end の中で type t が具体的な型を伴っていない点がポイントとなっている。これによりストラクチャの外からは、 IntSet.t は何かしらの型であることは分かるが int list であることは分からず、 IntSet.add (1, IntSet.empty) のように使うことはできるが、 1 :: IntSet.empty のように使うことはできない。この型の隠蔽機能こそが、ML モジュールにおける抽象化の一つの真髄と言える。

さて、今は整数集合を考えているが、集合操作に依存したアルゴリズムというのは世の中に多く存在する為、より汎用的に任意の型に対してその要素を持つ集合操作を提供するようなモジュールを作りたいという場面もあるだろう。このような場合に、上記の実装を整数以外にも拡張することを考える。上記の実装において、整数に依存しているのは type elem と比較演算のみであり、これらを与えられれば整数以外の型にも拡張できる。このような拡張を可能にするために、ファンクタを使うことができる:

module type OrderedType = sig
    type t
    val compare: t * t -> int
end

module type Set = sig
    type elem
    type t

    val empty: t
    val add: elem * t -> t
    val delete: elem * t -> t
    val member: elem * t -> bool
end

module SetMake(Elem: OrderedType): Set with type elem := Elem.t = struct
    type elem = Elem.t
    type t = elem list

    let empty = []
    let rec add (x, ys) = match ys with
        | [] ->
            [x]
        | y :: ys ->
            let cmpXY = Elem.compare (x, y) in
            if cmpXY = 0 then ys
            else if cmpXY < 0 then x :: ys
            else y :: add (x, ys)
    let rec delete (x, ys) = match ys with
        | [] ->
            []
        | y :: ys ->
            let cmpXY = Elem.compare (x, y) in
            if cmpXY = 0 then ys else y :: delete (x, ys)
    let rec member (x, ys) = match ys with
        | [] ->
            false
        | y :: ys ->
            let cmpXY = Elem.compare (x, y) in
            cmpXY = 0 || (cmpXY > 0 && member (x, ys))
end

例えば、この SetMake ファンクタを使えば、先ほどまで実装していた IntSet は以下のようにして作ることができる:

module IntSet = SetMake(struct
    type t = int
    let compare (x, y) = y - x
end)

ファンクタをストラクチャをとってストラクチャを返すような、ストラクチャに限定した関数と思えば何となく捉えやすいと思うが、 Set with type elem := Elem.t については説明が必要だろう。まず、 module SetMake(Elem: OrderedType): Set = struct .. end という指定は可能である。しかし、その場合少し困ったことが起きる。というのは、 IntSet が Set シグネチャを持つ為、 IntSet.elem がどういう型なのか外部から分からず、 IntSet.add (1, IntSet.empty) のように使うことができなくなってしまう。今回隠蔽したいのはあくまで、 IntSet.t の型であり、 IntSet.elem の型ではないが、 elem はファンクタに渡されたストラクチャから決まる為ファンクタとしては具体的にどういう型であるとは言えないのだ。このような場合に、 Set with type elem := Elem.t と指定すると、 Set の type elem の定義を type elem = Elem.t に置き換えることができ、外部に Elem.t として公開することができる。これにより、 IntSet.elem が Elem.t であることが分かり、さらに Elem.t は int であることが公開されている為、推移的に IntSet.elem が int であることが外部からも分かるようになる。

このように抽象化機構とファンクタ機能を連携させることができるようになっており、非常に多様な抽象化を実現できるのが ML モジュールの特徴となる。

System-Fω

さて、この ML モジュールをどう形式的に捉えるかという話をしていきたいわけだが、その前にもう一個、今回意味論の土台となる System-Fω という体系も見ていく必要があるので、こちらも一応見ておく。

型付きラムダ計算には、幾つか主要な拡張が知られている。単純型付きラムダ計算をベースとして、高階型または総称型と呼ばれる型を加えた System-F、今回扱う System-F に型構築子と呼ばれる型を加えた System-Fω、System-Fωに依存型と呼ばれる型を加えた Calculus of Constructions (CoC) などがよく知られてるものだろう。ML 系の言語や Haskell では、高階型、型構築子相当の機能が言語中枢に組み込まれているため、その機能について議論するにはそれに見合う表現力を持つ体系が必要になる。ただ、依存型相当の機能は組み込まれていないと整理しても本質的に議論できることが多い。なので、System-Fωをモデルとして使った議論が多い。そういう意味で System-Fω 自体を知っておくのは ML 系言語での他の議論を理解する上でも有用だろう。

さて、今回の F-ing modules のフレームワークにおいては、実は System-F でも本質的な議論ができる。これは、今回重要なのが高階型と存在型の存在にあり、存在型は System-F の範囲で扱えるからだ。なので、System-Fω で議論するのは、そうしないと議論ができないからというよりは、ML 系言語のモデル基盤として System-Fω の表現力が必要であり、そっちに寄せておいた方がより実用的だからという理由からだ。そういう意味で、System-F の基本的な概念を押さえている人は、System-Fωの話は、こういう拡張があるんだなぐらいで捉えておいてもらっても問題ないだろう。

まず、今回プログラム変換対象として考える言語の構文は、以下になる:

System-Fω は種 (kind) $\kappa$ 、型 (type) $t$ 、式 (expression) $e$ の3つの構文要素を持つ。最後の $\Gamma$ は型環境で、System-Fω の直接の構文要素ではないが、この後必要になるので一緒に導入しておく。型、式はいいとして、種は見慣れない人もいるかもしれないが、型の型みたいなものだと思ってもらうのが良い。型と同じく、動的意味論には影響を与えないが、型システムに影響を与え、型構築操作に対する安全性を担保するために使われる。存在型、レコードは、この後紹介する型システムと簡約システムを見てもらうのがいいと思うが、通常の System-Fω にはない構文要素になる。ただ、この存在型、レコードの部分は関数型、多相型で模倣可能であり、なんら表現力を変えるわけではないので、表現力が同じ言語体系という意味で今回この存在型、レコード込みの言語を System-Fω と呼んでいる。

さて、次に型システムを見ていく。System-Fω の型システムは、種付け (kinding) $\Gamma \vdash \tau: \kappa$ 、型等価性 (type equivalence) $\Gamma \vdash \tau_1 \equiv \tau_2: \kappa$ 、型付け (typing) $\Gamma \vdash e: \tau$ の3要素からなる。この内まず型付けから見ていく:

幾つかの場所で種付けの検査が前提にあることが分かる。これは、型構築の安全性を検査するのと同時に、型付けされる型が型の種を持つこと、つまり $\Gamma \vdash e: \tau$ ならば $\Gamma \vdash \tau: \mathrm{T}$ であることを担保するために指定されている。また、1規則だけ型等価性の検査が前提にある規則がある。これは型キャストの規則であり、型構築子を含む型を正規化した型に変換することをこの規則によって許容している。それぞれの規則の詳細は今回は本題ではないので省略する。System-F、レコード、存在型の規則については、多分 TaPL とかに書いてあるのでそっち参照してもらえると [1]。てことで、次は種付けを見ていく:

式の導入を持つ型は型の種がつく。後は型変数と、型構築子、型構築それぞれで種がつくって感じ。最後に型等価性を見ていく:

α-等価性 (alpha-equivalence)、つまり束縛変数の違いを除く構文的等価性、対称性 (symmetric)、推移性 (transitive)、合同性 (congruence) を載せる規則突っ込んで、最後がβη-等価性 (beta-eta-equivalence)。強正規化で判定可能な範囲のいつものやつ [2]。

で、この型判定通る範囲で、今回の System-Fω は以下の値 (value) を持つ:

動的意味論どう定義するかは諸派あるだろうけど、今回は題材に倣ってコンテキストベースの1ステップ簡約システムで定義すると以下になる:

ま、今回動的意味論そこまで詳しく踏み込まないが、ML モジュールの動的意味論はこれベースで定義されるので、一応ということで。今回理論的な話は抜きなので、自然意味論とかの方が意味掴みやすいかもだけど、本題じゃないし、まいいでしょ。動的意味論については、System-F 踏襲という感じではあるので、こっちも詳しくは TaPL とか参照してもらうのが良さそう [1]。

なお、この後のために、いくつか略記法を導入しておく:

シグネチャのモデル化

さてここからが本題。問題は ML モジュールの本質をどう System-Fω に埋め込んでいくかということだが、その前に議論しやすいように ML モジュールに構文を与えておく:

$M$ がモジュール、 $S$ がシグネチャの構文要素になる。種や型、式の詳細は今回興味がなく、System-Fω レベルで表現できるものなら何詰め込んでもいい。雰囲気として、前に出したファンクタによる IntSet モジュール定義の例をこの構文で書いてみると、大体以下の感じ:

{
    sig OrderedType = {
        type t: *;
        val compare: ...;
    };

    sig Set = {
        type elem: *;
        type t: *;
        val empty: ...;
        val add: ...;
        val delete: ...;
        val member: ...;
    };

    module SetMake = fun Elem: OrderedType => {
        module X = {
            type elem = Elem.t;
            type t = ...;
            val empty = ...;
            val add = ...;
            val delete = ...;
            val member = ...;
        };
    }.X :> Set where type elem = Elem.t;

    module IntSet = {
        module X1 = {
            type t = ...;
            val compare = ...;
        };

        module X2 = SetMake X1;
    }.X2;
}

なお、OCaml の元の構文と比べて少し冗長なところがあると思う。ただ、表現力はそこまで落ちてないことが分かると思う。これらの構文をベースに以下のような拡張を考えると、上の構文が結構現実的な要素を備えていることは分かるんじゃないだろうか:

let 宣言なども ML モジュールベースで考えることができ、中々強力な機能拡張が考えられる。さて、問題はこれらの構文に対して、意味付けをどのようにして与えていくかだ。全体の意味付けを考える前に、まずはシグネチャに対する意味付けを考えていく。シグネチャの意味付けは実は System-Fω の型のうち、以下の要素により捉えることができる:

無名の3つは、原子シグネチャ (atomic signature) と呼ばれる。それぞれ値宣言、型定義、シグネチャ定義それぞれに名前付けする部分を除いた機能をレコード型でモデル化している。例えば、値宣言から名前付けする部分を抜くってことは、つまりその値がどういう型を持つかって情報に着目するわけで、これを静的意味論でモデル化するということは、使われてる型が妥当かどうかを System-Fω の型システムでチェックできるようにするということ。なので、 $[\tau]$ はその型を情報として持つレコード型にしてやれば、レコード型の妥当性を調べることがその無名の値宣言の妥当性を調べることと同じになる。レコードにしているのは、普通の型と無名値宣言を区別するためなので、レコードである必要性はあまりないが、そんな感じで System-Fω の型システムを通して、それぞれの宣言が妥当であることを確認できるようにうまく埋め込んでいくのが原子シグネチャの考え方になる。型定義、シグネチャ定義はちょっと複雑だけど、こいつらは実際の値を持たないので、値は自明に作れるようにしつつ、型の部分だけ妥当性を調べるようにできなきゃいけないので、ちょっとハック的な構成になっている。つまり、 $\tau$ が $\kappa$ で種付けされるのを System-Fω の 型付け でどうチェックするかという話なんだけど、それを多相的な恒等関数ならどんな型に対しても値作れるよねっというのを利用して、

\Gamma \vdash (\Lambda t: (\kappa \to \star)\ldotp \lambda x: t\; \tau\ldotp x): \forall t: (\kappa \to \star)\ldotp t\; \tau \to t\; \tau

の型付け調べれば、 $\Gamma \vdash \tau: \kappa$ の種付け調べたのと同じになるよねみたいな発想でやってく感じ [3]。シグネチャ宣言の方もそんな感じのハックを使ってチェックすることになる。

これらの原子シグネチャをラベル付けて結合していったのが、ざっくりストラクチャのシグネチャのモデルという感じ。で、型パラメータで多相化されたモジュールからモジュールを生成するのがファンクタという感じになる。で、 $\Sigma$ は大体そんな感じになるんだけど、シーリング、つまり型の隠蔽は存在型で表現するようにしてて、その隠蔽付きのモジュールのモデルが $\Xi$ になる。多分ざっくり説明するより、どうモデルに着地させていくか見ていった方がいいと思うので、シグネチャの意味付けを見ていく。シグネチャは以下で定義される $\Gamma \vdash S \rightsquigarrow \Xi$ によって意味付けされる:

シグネチャパスの意味付けはパスの意味付けをそもそも説明してないのでちょっといきなり難易度高いと思うが、そもそもシグネチャパスとはどういうものかというと、他のモジュールで宣言されているシグネチャにアクセスする式のこと。で、 $\Gamma \vdash P: [= \Xi] \rightsquigarrow e$ という判定の詳細は後ほど触れるが、これが意味するのはこのパスが $\Xi$ をモデルに持つシグネチャの宣言、つまりそのモデルである $[= \Xi]$ を参照するパスで、そのシグネチャ宣言が妥当であるということを意味している。静的意味論の中の存在であるシグネチャの妥当性を調べるのに、なぜ式が出てくるかというと少し前で触れたように今回は式の型付けにより、静的意味論も調べていくから。つまり式自体は自明なもの、つまり恒等関数で意味のないものだが、その型付けの過程で種付けなどを通ることにより妥当性を調べる。つまりは、最初の判定はシグネチャパスが $\Xi$ のモデルを持つシグネチャ宣言を指すパスならば、 $\Xi$ をモデルに持つシグネチャとして扱おうという感じ。

次もやっぱりまだ説明してないのであれだが、宣言群の意味付けをこの後別途与えるので、その意味付けをそのままシグネチャの意味付けとして扱うという感じ。ま、これは後で宣言群の意味付け見た方が分かりやすいと思うので、今はそんな感じで認識してもらうのがいいだろう。

次はファンクタシグネチャの意味付けだが、ファンクタは多相的なモジュールからモジュールへの関数になるので、その引数のシグネチャ、返り値のシグネチャがどうなるかからファンクタシグネチャのモデルが決まる。ただし、2点特徴があり一つが多相パラメータを引数のシグネチャの抽象性から決める点、そして返るシグネチャが引数のシグネチャに依存する点が通常の多相関数型に比べて特殊になる。これはファンクタへの適用を見てもらわないとちょっと説明しにくいのだが、ML モジュールでのファンクタ適用というのは、通常の多相関数、ジェネリック関数などのように型パラメータを別途与えてそこから具体化を行うというような機能は持ち合わせておらず、適用するモジュールのラベルから適当に型パラメータ部分におく型が類推されることになる。また、受け取ったモジュールへのアクセス状況によって返り値のモジュール・シグネチャも決まってくるわけだ。例えば、 SetMake の例で言うと、 elem ラベルは受け取った Elem モジュールの t ラベルに依存すると言う感じだ。つまり、ML モジュールは、表層的にはどうラベル付けされているか、意味論的にはどうモジュールへのアクセスが行われるかによって、ファンクタがどう振る舞うべきか、もっと言うとモジュール全体がどう振る舞うべきかが決まってくるデザインになっている。これが一つ ML モジュールが通常の関数型プログラミング言語の機能と異なる点であり、その表現力の所以となってる点だろう。

最後にシグネチャの制約だが、これは $S$ の中の $\overrightarrow{X}$ でアクセスした型宣言の内容に $T$ と等価であると言う制約をかけたシグネチャになる。なお、 $l_X$ は $X$ に対応する一意な System-Fω のラベルになり、 $X$ の System-Fω での変換先ということになる。気持ち的には $\overrightarrow{X} = X_1 X_2 X_3$ だとすると、 $S.X_1.X_2.X_3$ が抽象的な型宣言かつ $T$ と種が合うかを調べ、 $S.X_1.X_2.X_3 = T$ みたいな制約を $S$ に追加する感じか。ただ等価制約は一度しか付けられない事からも、意味付け方法的にも、シグネチャのうちまだ型が明示されていない部分を具体的に明示するという感じの方が近いかもしれない。

さて、後回しにした宣言群の意味付けも見ていく。宣言群もシグネチャと同じく $\Xi$ でモデル化する。宣言群は以下で定義される $\Gamma \vdash D \rightsquigarrow \Xi$ によって意味付けされる:

値宣言は無名値宣言のモデルにラベルをつける、型定義は無名型定義のモデルにラベルをつける、シグネチャ定義は無名シグネチャ定義にラベルをつけるというのが基本になる。ただし、型宣言は具体的な型に言及できないものとして、存在型を導入しそれにより無名型定義を作る。 $\Gamma \vdash T: \kappa \rightsquigarrow \tau$ 、 $\Gamma \vdash K \rightsquigarrow \kappa$ は、パス以外は今回の本題じゃないので、必要に応じて与えられてるものとする。

また、モジュール宣言は基本的に指定されてるシグネチャのモデルが名前付け以外の部分のモデルとなるはずで、それにラベル付けすれば基本モデルになる。ただ、抽象化部分、つまり存在型をフラットにするため外に出している。このフラット化は、ネストしたモジュール宣言へのアクセスと、トップレベルのモジュールに対してのアクセスで抽象化のモデルの相違を招き、非自明なものになる。ただ、実はこのフラット化が一つ F-ing modules のキモの部分になっており、このフラット化によって宣言されたモジュールに対しての抽象化された部分に対してのアクセスを、元来のラベルへの依存を示す依存型による表現ではなく、存在型によって表現できるようになる点が一つ利点になる。題材に分かりやすい例と参考文献が載ってるので、詳細はそっち見てもらうといいと思う。ま、パッと見モデルとしては少し気持ち悪い感はあるが、これを存在型のスコープが抽象化のスコープのモデルになってると捉えると少し納得しやすいかもしれない。トップレベルのモジュールはその中の抽象型のスコープはそのモジュール内に閉じているが、ネストしたモジュールの場合はそのモジュールを含むモジュールのスコープになるという感じか。そのスコープの中で抽象化される型は共有され、その範囲で共通のものとして使えるという感じだ。

シグネチャ展開、空シグネチャはそのままなのでいいだろう。結合も割とそのまま。1個目の宣言群に依存させて、2個目の宣言群が妥当であれば、そのまま結合させる。この際抽象化のスコープをやっぱりそれぞれフラット化して全体にするという感じ。ただこの際、1個目の宣言のラベルを変数としても使えるように、2個目の宣言群チェックの際環境に入れてる。ここで、 $x_X$ は $X$ に対応する一意な System-Fω の変数になる。ML モジュールの変数 $X$ に対応するものが、System-Fω ではラベル $l_X$ と変数 $x_X$ 2つあることに注意。基本はラベル $l_X$ が変換先なのだが、モジュールの内部を読み込んで使えるようにしてる場合は変数 $x_X$ も変換先に追加され、その変数を通してもアクセスできるようになるという感じだ。

ストラクチャ・ファンクタの埋込方法

さて、ここまでは ML モジュールのドメインというべき、シグネチャのモデルについて見てきた。ここからが本題で、モジュール本体、つまりストラクチャ・ファンクタをどうモデル化していくかも見ていくことにしよう。モジュールは $\Xi$ を型に持つ System-Fω の式によって意味付けされることになる。その意味付けは、以下で定義された $\Gamma \vdash M \rightsquigarrow e: \Xi$ によって行われる:

変数の解決はいいだろう。また、定義群に対しての意味付けはシグネチャでの宣言群の意味付けと同じように、後で与えたものを流用する。次にモジュールへの射影だが、これも単純に射影元のモジュールを表すレコードから、該当する部分を射影する、ただし抽象化部分について存在型の除去と導入操作で外に出すということを行う。これもいいだろう。ファンクタも、単にファンクタシグネチャの意味付けに倣って、存在型パラメータを多相パラメータに変換し、そのパラメータに依存させた返るモジュールのモデルによる、多相関数を作るだけという感じ。

さて、問題になるのが最後の2つだ。両方見慣れぬ仮定が載ってると思う。まず、ファンクタへの適用から見ていこう。 $X_1$ 、 $X_2$ それぞれまず環境からシグネチャモデルを引っ張ってくるのはいい。その後、そいつらを突っ込んでる謎の仮定がなんだという話になる。ファンクタシグネチャの説明で少し触れたのだが、ML モジュールのファンクタ適用は、多相関数への適用という形になるにも関わらず型パラメータ指定という概念がない。代わりに型パラメータは適用するモジュールのラベルから自動的に判定される。この自動判定の機能を請け負うのが、この謎の判定になる。詳細は後で見るとして、読み方としては、 $\Sigma_2$ と $\exists \overrightarrow{t: \kappa}\ldotp \Sigma_2'$ をマッチングさせると、型パラメータ $\overrightarrow{t: \kappa}$ として、 $\overrightarrow{\tau}$ が選ばれ、またサブタイプを反映させるための式が $e$ になるという感じ。この $e$ は今回はサブタイプ考えないので実はなくてもいいが、入れといた方が色々拡張しやすいので入れている感じになる。ま、ようは抽象化部分のマッチングも兼ねたサブタイプの導出という感じになるだろう。後は、ファンクタのモデルである多相関数に、マッチングさせた型を適用し、サブタイプ反映させたモジュールのモデルを適用するという感じになる。

シーリングも、マッチングとサブタイプ関係に合う範囲でシグネチャの制限を入れれるようになっていて、シーリング元のシグネチャモデルと、シーリングするシグネチャのモデルでマッチングさせて、抽象化する部分の型を見つけ、その部分を存在量化して抽象化するという形になる。

マッチングは具体的には、以下のように定義できる:

と言っても単に与えられた型で置き換えてサブタイプ関係満たすかチェックするだけだが。もちろん、どういう型を与えればマッチング満たすかはこっちで考えなきゃいけない。ここら辺のアルゴリズムは今回触れないが、題材に完全性の証明付きで載ってるので、そっち見てもらうのがいいだろう。

サブタイプ関係もそこまで複雑なものではない。まず最初に触れておくのが、 $[\Xi]$ という表記で、これは $\{\mathit{sig} = \lambda x: \Xi\ldotp x\}$ の略記になる。つまり、 $[= \Xi]$ の自明な導入形式。そこだけ抑えれば最初の3つはいいだろう。値宣言のサブタイプは、型同士のサブタイプ定義して入れることで拡張の余地などもある。構造家シグネチャのサブタイプは、ラベルの順番変えたり、ラベルを少なくするみたいなのを許容しつつ、さらにラベル付けされてる中身のシグネチャもサブタイピングできるという感じ。ファンクタシグネチャのサブタイプは、関数型サブタイプよろしく、引数部分と返り値部分でそれぞれ逆のサブタイプ入れれる感じだ。ただ、ただの関数型と違う部分が、引数の抽象型をマッチングにより具体化できるという部分だ。これにより、わざわざ型制約とか書かなくても、いい感じにマッチングで具体化をしてくれ、使い勝手が上がることになる。抽象シグネチャのサブタイプは、抽象型の一部をマッチングで具体化できるみたいな感じになる。そんな感じで、ファンクタ適用時などは、いい感じに具体化する部分を選びながら、抽象型の一部をパラメータに変換したりサブタイピングで変換したりして、類推をしてくれるような設計がされている。

後は定義群の意味付けを見れば、F-ing modules の全体が完成する感じだ。定義群も $\Xi$ を型に持つ System-Fω の式によって意味付けされる。具体的には、以下の $\Gamma \vdash B \rightsquigarrow e: \Xi$ によって意味付けされる:

まず、 $[e]$ 、 $[\tau: \kappa]$ だが、これは $[\tau]$ 、 $[= \tau: \kappa]$ の導入形式で、それぞれ $\{\mathit{val} = e\}$ 、 $\{\mathit{type} = \Lambda t: (\kappa \to \star)\ldotp \lambda x: t\; \tau\ldotp x\}$ の略記となる。また、 $\Gamma \vdash E \rightsquigarrow e: \tau$ 、 $\Gamma \vdash T \rightsquigarrow \tau: \kappa$ も、パス以外は必要に応じて与えられてるものとする。

この前提で、最後以外の規則はいいと思う。触れておくとしたらモジュール定義の $\mathrm{NotAtomic}(\Sigma)$ ってやつかなと思うが、これは要は原子シグネチャ以外ですよってこと。つまり、無名の値宣言だけを引っ張ってくるとかそういうことはできないって感じ。ま、これは無名値宣言の構文とかが与えられているわけではないわけで、構文としてはあくまでモジュールっていうのは構造化されたものかファンクタだと思うので、いいかなと思う。それが意味論段階で限定されるのはちょっと気持ち悪いかもだけど。ただ、射影とかで引っ張ってくるものが型宣言のものか、モジュールかみたいな区別って、ラベルの名前空間でも分けない限り構文的には区別つけられないので、しょうがないと思う。名前空間分けてる言語もあるけど、その分命名の自由度は下がるので賛否あるかなと思う。

さて、問題はモジュールの結合だが、これがなんでこんな複雑になってるかだが、実はあんまり本質的な話じゃない。結合する際に、ラベル被り考慮したりとか、一回 unpack してから pack することになり、その際ラベルアクセスで一番最後の定義だけ引っ張ってくることになるので、それに合わせたシグネチャを作らなきゃいけないとかで複雑化している。 $\mathrm{Comb}$ がそういうシグネチャをいい感じに作ってくれる関数になってて、結合するもののうちどちらの定義を使うか、その定義のシグネチャは何かをラベル毎に返してくれるので、それによって結合したモジュールとシグネチャを作ってくという感じ。こんな感じでモジュールの意味付けができる。

最後に残ってるパスの意味付けを見ていく。

パスの意味付けは、モジュール中、型中、式中、それぞれで定義されることになるが、まずモジュール中の場合は普通のモジュールの意味付けと基本同じだが、シグネチャ内に抽象型が使われてないことが要求され、その保証のもとで unpack して抽象型を捨てた部分を持ってくるということをする。これだけを見ると、パスでは抽象型を持つモジュールにアクセスできないため、そのような外部モジュールを使う方法がないように見える。しかし、抽象型含むモジュールを一回モジュール定義で変数に束縛すると、その抽象スコープがモジュール内に広がるということを利用して、モジュール定義と組み合わせればパスによりアクセスができるので、問題がない。これは、外部モジュールは一回インポート文でインポートしてから使う言語が多いことを考えれば、技術的な制約にはあまりならないだろうし、一回一回 unpack するよりインポート文でまとめて unpack させた方が色々扱いやすいことも考えると理にかなってるんじゃないだろうか。型中、式中での使用もモジュール中での使用とあまり変わらず、それぞれ型定義、値定義に限定して、型定義の場合は型の妥当性だけ判定、値定義の場合は定義元の指揮を参照するという形になる。

以上が F-ing modules による、ML モジュールの意味付けになる。

ファンクタと透明性

さて、ML モジュール全体をどう意味付けしていくかを、今回見てきたわけだが、実はこの意味論は OCaml などの ML モジュールの意味論と若干ズレる部分がある。以下の OCaml プログラムを見てみる:

module type AbsSig = sig
    type absT
    val sampleV: absT
    val sampleF: absT -> absT
end

module SampleFun(Arg: sig end): AbsSig = struct
    type absT = int
    let sampleV = 1
    let sampleF = fun argX -> argX
end

module SampleArg = struct end

module SampleFunApp1 = SampleFun(SampleArg)
module SampleFunApp2 = SampleFun(SampleArg)

let _ = SampleFunApp2.sampleF SampleFunApp1.sampleV

これは妥当な OCaml プログラムになる。ところで、このプログラムは F-ing module でどうモデルが作られるかを少し見てみよう。まず、今回与えた ML モジュールの構文で書き直してみると、以下のようになる:

{
    sig AbsSig = {
        type AbsT: *;
        val SampleV: AbsT;
        val SampleF: AbsT -> AbsT;
    };

    module SampleFun = fun Arg: {} => ({
        type AbsT = int;
        val SampleV = 1;
        val SampleF = λ argX: int. argX;
    } :> AbsSig);

    module SampleArg = {};

    module SampleFunApp1 = SampleFun SampleArg;
    module SampleFunApp2 = SampleFun SampleArg;

    val Result = SampleFunApp2.SampleF SampleFunApp1.SampleV;
}

さて、この内 Result を抜いたところのモデルがどうなるかを見てみる:

注目したいのが、 SampleFunApp1 と SampleFunApp2 のモデルがそれぞれ別の存在量化されてる点。これにより Result は、 $t_3$ と $t_4$ が等しいという情報が取れないため、適用の型付けができず、モデル化できない。つまり、OCaml のモジュールと意味論が異なることになる。

実は今回の F-ing modules は、Standard ML の意味論に寄せたものになっている。Standard ML では、ファンクタによって作られる抽象モジュールは、毎回新規に生成されたような動きをする。つまり、今回のようにファンクタ適用する度に新たに抽象化が行われる。それが、存在量化が関数型の中で $\Sigma_1 \to \exists t: \kappa\ldotp \Sigma_2$ のように行われることに表れている。一方 OCaml は、抽象化がファンクタの外側で行われるような意味論、つまり $\exists t: \kappa\ldotp \Sigma_1 \to \Sigma_2$ のようなモデルの与え方の方が近い [4]。前者を生成的 (generative)、後者を適用的 (applicative) であると、題材では区別しており、後者にも対応するような意味付けも紹介されている。今回は導入だけに留めておくが、気になる人は題材の適用的ファンクタのとこを見てみるといいだろう。

まとめ

というわけで、存在型を使って System-Fω の範囲で ML モジュールの意味付けを行ってくフレームワーク、F-ing modules の紹介だった。F-ing modules は、ML モジュールの抽象型の共有を、アクセス方法でそのままモデル化するのではなく、抽象型の共有範囲と共有される情報を存在型でうまくモデル化してやることで、依存型などを使わずうまく意味付けを行っているのが面白いとこかなと思う。

また、System-Fω でモデル化できるということは、その逆に System-Fω の一部機能を ML モジュールで代替できるということで、結構その辺の関係性元にレコードベースの言語デザイン考える時とか参考になるんじゃないかなと思ってたりする。多相関数への適用を、ラベルベースでマッチング駆使してやるとか、結構面白い部分だと思うんだよね。

それはそれとして、明らかに1記事の分量じゃなかった感ある。ま、System-Fω の導入から始めればそうなっちゃうよな。もうちょっと細切れに出せれば良かったが、ある程度できちゃうとそういうの考えるのめんどくってこうなっちゃった。て感じで、久しぶりに書いた記事がめちゃ長くなっちゃったけど、何か参考になればって感じです。この量でも、全然触れられてない重要な部分とかあるので、興味ある人は是非 Rossberg 先生の元論文読んでみてくれ。てわけで、今回はこれで。

[1]	(1, 2) TaPL とは、「Types And Programming Languages」またはその和訳「型システム入門 −プログラミング言語と型の理論−」のこと。僕は読めてないどころか持ってもいないので、実は載ってないかもしれない。その時はごめん、別文献当たってくれ。

[2]	今回レコード型が順序付きなんだが、動的意味論考えると順序付きにする必要はなく、通常は順序なしで考える。ただ、そこら辺考え出すと少し面倒で、今回は本題じゃないので順序付きにしている。

[3]	この手の話だと割と有名な方法。自明な関数便利。

[4]	あんまり適用的ファンクタも OCaml の意味論も理解できてないが、適用的ファンクタでは OCaml の意味論を説明できないような気がしている。例えば、 `module SampleFunApp2 = SampleFun(SampleArg)` を `module SampleFunApp2 = SampleFun(struct end)` にするとコンパイル通らなくなるわけだが、そこって適用的ファンクタの意味論だとコンパイル通るはずだよねみたいなとこ。そこら辺どういう話になってるのか、僕の理解が間違ってるのかは気になってる。

Firefish のインストール方法

2023-12-06T20:53:49+09:00

Fediverse は ActivityPub により接続されたサーバ群によるネットワークである。ActivityPub は短文投稿、画像・動画共有、ファイル共有などを可能とする、HTTP 上でコンテンツ共有・発信を可能とするソーシャルネットワークプロトコルだ。W3C 勧告であることもあって今や多くの実装が存在しサーバも世界中に多数立っている。

さて今回はその中で、Firefish という実装についての紹介と、自分で作っている Debian 向けの Firefish パッケージの導入方法について宣伝も兼ねて説明していく。なお、これは現時点での話で、Fediverse はかなり栄枯盛衰が激しいので、1年後には役に立たなくなってるかもしれない。ま、あくまで参考程度にしてくれって感じ。

なお、この記事は

の6日目掲載記事となる。他の記事も Fediverse に関しての生の体験満載となっていて、色々面白いと思うので、ぜひ覗いてみて欲しい。

他の実装との比較

ActivityPub 対応のサーバは結構最近多いが、僕の周りで主流なのは以下:

Mastodon: https://joinmastodon.org/: 定番サーバ。AGPLv3 の OSS。サーバサイドはメインは Rails、ストリームサーバだけ Node.js 上で Express で書かれてる。Web クライアント側は React で書かれてる。クライアント側の事実上の API 標準になっているぐらいには、利用率が高い気がする。結構思想が強めで、分散 SNS の急先鋒という感じ。良くも悪くも機能のバランスは良く、安定性も高い印象はある。
Misskey: https://misskey-hub.net/: もう一つの定番サーバ。AGPLv3 の OSS。サーバサイドは Nest.js、Web クライアントは Vue で書かれてる。思想より、結構機能重視みたいなところがあり、いろいろ面白い機能を試しては載せていってるところに、マストドンなどにはない面白さを感じてるユーザが多そうだ。ただ、開発コミュニティが結構日本寄りということがあって、海外での利用率は低め。また、安定性も少し落ちる印象がある。それから、Mastodon API との互換がないため Mastodon 用アプリが使えなく、また Misskey 用のアプリもあまりないという面もあり、Web UI を利用してるユーザが多い。
Pleroma: https://docs-develop.pleroma.social/: 個人サーバ立てる時人気のサーバ。AGPLv3 の OSS で、サーバサイドは Phoenix、Web クライアントは Vue で書かれてる。他のサーバに比べて軽いというのと、Web クライアントとサーバサイド実装が完全に分かれており、クライアント実装もいくつかあってカスタマイズしやすいこと、Mastodon API とある程度互換がありアプリが流用しやすいことが特徴的。ただ、大型サーバではあまり用いられてるのを見ない気がする。
Akkoma: https://akkoma.social/: Pleroma のフォーク。あまりよく知らないが、時折使ってる人はいそう。Pleroma にない機能が載ってたり、逆に Pleroma にはあるけど Akkoma にはない機能もあったりするみたいな噂。
Firefish: https://joinfirefish.org/: Misskey のフォークで、AGPLv3 の OSS。フォーク当時は Calckey という名前だったが、改名された。今回紹介するソフトウェアで、僕の個人鯖で使っている。

なお、これらは主に短文投稿 SNS 用途という感じだが、他に WordPress のプラグイン経由での発信、PeerTube、Lemmy などの短文投稿以外に特化したソフトウェアなどもある程度シェアを占めているようだ。

これらの中で Firefish の立ち位置は、Mastodon と Misskey の中間のような感じで、Misskey の便利な機能を取り入れつつ、Mastodon API も搭載していて Mastodon 用のクライアントアプリを使える [1] のが特徴という感じになる。個人的に重宝してるのは、Web UI の見やすさとカスタム絵文字だろうか。UI でいうと、具体的には分散 SNS らしく発信元のソフトウェア情報が簡単に確認できるため、相手がどういう機能に対応してるソフトを使ってるか反応する前に予測できたり、設定から好みに合わせて UI 調整できたりって感じ。

僕は Fediverse に来てから、 Vivaldi Social という Vivaldi が運営する Mastodon 鯖にしばらくいた後、Mastodon でおひとり様自己運営鯖を立ててそこに移り、その後 Firefish にソフトウェア変更を行なって3ヶ月経ったぐらいという感じの変遷をしてる。そこまでまともに比較してないのだけど、Mastodon から Firefish に切り替えた理由は、Mastodon はサービスが3つありおひとり様としては管理コストが大きかった [2] のと、Ruby、Node.js 双方のメンテが必要で、メモリも結構サービス自体が食ってくるというのが不満で、そこが改善されてる点で選んでるという感じ。Firefish は Node.js サーバ一つの管理をすればよく、メモリも Mastodon 時代は3サービスそれぞれがそれなりに食ってる状況から大体メモリ消費量半減で管理できるようになった。ただし、ジョブキューの並列数を減らしたりもしたのでここは単純な比較ができなくて眉唾部分もあるかも。とりあえず、現状の Firefish 運用で僕はそれなりに満足しているという感じ。

deb の作成

そんな Firefish だが、インストールにはちょっと難がある。Firefish は一部サーバライブラリを Rust 化しているのだが、このビルドにかなりリソースが必要になる。一部インストール方法の紹介では、ビルド用に CPU リソースを増やしましょうなどと書かれているぐらいだ。さらにこのビルドが遅いため、オンプレ直置き、直ビルドで運用している鯖ではアップデートでの停止時間がそれなりに必要となる。Docker を使えばこの点は解決するが、Docker はそれなりにオーバーヘッドがかかり、運用にも手間がかかる。おひとり様としては、ある程度ルーズに、消費リソースも抑えつつ、ソース管理はいい感じの機構に任せたい。

そこで、僕は deb パッケージを GitHub Actions で作成し、ソースインストール・更新などは Debian 上で apt 経由で行えるようにしている。ソースは https://github.com/mizunashi-mana/firefish-dist-pkg。GitHub Actions 上で前もって npm パッケージ、Rust ソースのビルドなどを行なっておき、それを deb アーカイブにまとめておいて、鯖上には deb をダウンロードして apt 経由でインストールするという感じだ。ついでに、systemd service を付属させたりして、更新時にサービス停止と再起動が行われるようにしたり、サンドボックス機能でセキュリティを強化したり、キャッシュファイルなどの置き場をソースから切り離したりしている。

deb のパッケージ構成用ファイル群は https://github.com/mizunashi-mana/firefish-dist-pkg/tree/v1.0.5%2Brc-d202312060003%2Brelease/deb/files らへんにあって、主なファイルとしては

control: deb パッケージのメタ情報。Firefish の依存パッケージである ffmpeg、libvips を指定して、標準リポジトリから自動でインストールされるようにしていたりする。
rules: deb パッケージのビルドルール。deb パッケージ作成時のタスク内容を記述している。
service: systemd service ファイル。deb パッケージ作成時に deb パッケージに含める。サンドボックス機能をいい感じに有効化したり、書き込み可能なパスなどを制限することで、Firefish に脆弱性などがあった場合の影響を抑えられるようにしている。

みたいな感じ。ま、この辺の詳細は Debian メンテナー用ガイドらへんを参照してくれ。

このパッケージをインストールすると、

/var/lib/firefish/live: Firefish のソース群が置かれる。Firefish は、 ./files に画像ファイルなどを置くがこのパッケージではそこを /var/lib/firefish/files へのリンクとしていて実際の書き込みはそっちに行われるため、 /var/lib/firefish/live は完全にリードオンリーでソースファイルのみが置かれる感じになる。また、Firefish は ./.config/default.yml を設定ファイルとして参照するが、これも Debian の設定ファイルのディレクトリ構成に合わせて /etc/firefish/config.yml へのリンクとしていて、 /etc/firefish 以下のファイルをいじればいいようにしている。
/var/lib/firefish/files: 上述の通り、S3 ストレージを設定していない場合のデフォルトの画像ファイル、キャッシュファイルなど置き場。
/var/lib/firefish/work: Firefish の実行ユーザのホームディレクトリで、npm などが色々ファイルを生成する場合に使われる。
/etc/firefish: Firefish の設定ファイル置き場。
/lib/systemd/system/firefish.service: systemd サービスファイル。上記のファイルがインストールされるところ。

などが作成される。またこれらのファイルは新しい deb ファイルをインストール際自動で更新される (設定ファイルなどは更新するか聞かれる) ようになる。実際これを使って3ヶ月ぐらい運用しているが、結構便利。更新もコマンド一発でできるし。あまり真面目にメンテはしてないが、よかったら使ってみてくれって感じ。

インストール方法

では、deb ファイルを使う場合のオンプレ直置きでの Firefish インストール方法を、具体的に1から説明していく。今回は Debian 12 (bookworm) での説明になるが、Ubuntu でも大体同じような感じでできるはず。

Debian 12 を ISO インストーラを使ってインストールし、SSH でログインできるようにし、ファイアウォールなどは設定済みの状態を前提にする。これはそれぞれのホスティングサービスによりいい感じのやり方があると思うので、それぞれ調べて欲しいが、 Mastodon のマシン設定ガイドらへんも参考にするのがいいんじゃないだろうか。僕の場合は、さくら VPS で Debian 12 の標準イメージを使い Debian をインストールした後、

SSH 用の公開鍵を入れて、SSH サーバで攻撃トラフィック低減のためのポート変更と Pubkey 認証以外の無効化を実行。
fail2ban を入れ、sshd 用の設定を有効化。
nftables でファイアウォール設定。

をしている。nftables で Mastodon のマシン設定ガイドと同等のものを設定するには、

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0;

        # The default policy of inbound is dropping.
        policy drop;

        # Allow all loopback (lo0) traffic and drop all traffic to local addresses that doesn't use lo0
        iif lo accept;
        ip saddr 127.0.0.0/8 iif != lo reject;
        ip6 saddr ::1/128 iif != lo reject;

        # Accept all established inbound connections
        ct state { established, related } accept;

        # Allow HTTP and HTTPS connections from anywhere (the normal ports for websites and SSL).
        tcp dport { 80, 443 } accept;

        # Allow SSH connections
        # The -dport number should be the same port number you set in sshd_config
        ct state new tcp dport 22 accept;

        # Allow ping
        icmp type echo-request accept;
        ip protocol ipv6-icmp accept;

        # Allow destination unreachable messages, especially code 4 (fragmentation required) is required or PMTUD breaks
        icmp type destination-unreachable accept;

        # Log iptables denied calls
        limit rate 5/minute burst 5 packets log prefix "nftables denied: " level debug;
    }

    chain forward {
        type filter hook forward priority 0;

        # The default policy of forward is dropping.
        policy drop;
    }

    chain output {
        type filter hook output priority 0;

        # Allow all outbound traffic - you can modify this to only allow certain traffic
        policy accept;
    }
}

を /etc/nftables.conf に書き込んで (SSH ポート番号 22 の部分は変更している場合は正しいポートに直す必要がある)、 systemctl restart nftables すればいいだろう。若干、icmpv6 パケット全許可だったりするのが気になるが、ひとまずはこれでいいんじゃないだろうか。Ubuntu の場合は ufw とか使うのが普通だと思うので、そっちを使うのが良さそう。

またドメインの取得と設定も前提にする。僕は Cloudflare Registrar 経由でドメインを買い、そのサブドメインに A レコードと AAA レコードを生やしている。まこの辺はいい感じのサービス見つけるなり、上級者向けだが自分で DNS サーバ立てるなりしてくれ。

その前提で、まず Node.js v20 インストール用の準備をしておく。https://github.com/nodesource/distributions#installation-instructions に沿って、インストールを進めていく。具体的には、

sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://deb.nodesource.com/gpgkey/nodesource-repo.gpg.key | sudo gpg --dearmor -o /etc/apt/keyrings/nodesource.gpg
NODE_MAJOR=20
echo "deb [signed-by=/etc/apt/keyrings/nodesource.gpg] https://deb.nodesource.com/node_$NODE_MAJOR.x nodistro main" | sudo tee /etc/apt/sources.list.d/nodesource.list
sudo apt update

を実行する [3]。

次に、Firefish のデータベース用に Redis と PostgreSQL をインストールして起動しておく:

sudo apt install -y redis-server postgresql-15
sudo systemctl restart redis-server
sudo systemctl restart postgresql
sudo systemctl enable redis-server # 再起動時に自動起動するようにする
sudo systemctl enable postgresql # 再起動時に自動起動するようにする

そして、Firefish データベース用の PostgreSQL ユーザとデータベースを作成する:

sudo -u postgres createuser firefish-user --pwprompt
sudo -u postgres psql -c "CREATE DATABASE firefish OWNER 'firefish-user' ENCODING 'UTF-8';"

次に、Firefish パッケージをダウンロードして、インストールする。https://github.com/mizunashi-mana/firefish-dist-pkg/releases からインストールしたいバージョン、基本は最新の自分が使っているディストリビューション用の deb ファイルをダウンロードして、apt 経由でインストールする。具体的には、https://github.com/mizunashi-mana/firefish-dist-pkg/releases/tag/v1.0.5%2Brc-d202312060003%2Brelease の Debian bookworm 用の deb をインストールする場合は

curl -L https://github.com/mizunashi-mana/firefish-dist-pkg/releases/download/v1.0.5%2Brc-d202312060003%2Brelease/debian-bookworm-amd64_firefish.deb --output firefish.deb
sudo apt install -y ./firefish.deb

すればいい。後は設定を弄って、Firefish の立ち上げを行う。設定は /etc/firefish/config.yml を編集する。まず、ドメイン部分を正しいものに修正する:

- url: https://example.com/
+ url: https://<使うドメインをここに書く>/

それから PostgreSQL の設定を修正する。データベース名、ユーザ名、パスワードを先程作成したものに修正する:

  db:
      host: localhost
      port: 5432
      #ssl: false
      # Database name
      db: firefish

      # Auth
-     user: example-firefish-user
-     pass: example-firefish-password
+     user: firefish-user
+     pass: <先程設定したパスワードをここに書く>

      # Whether disable Caching queries
      #disableCache: true

後は適宜弄りたい設定があったらいじる。個人的に、Redis の prefix を設定しておくのがおすすめだ。これは新たに Redis を使う他のサーバが生まれた時に同居させやすいからだ。ま、そういう予定がなければ特に弄らなくてもいいだろう。ここまで出来たら、Firefish を起動する:

sudo systemctl restart firefish
sudo systemctl enable firefish # 再起動時に自動起動するようにする

次に Firefish の管理者ユーザを作成しておく。これは後ででもいいが、セキュリティ的にはここで作っておくのが安全だ。SSH でポートフォワーディングして、ブラウザから作成するのがおすすめだ。まずサーバ内でなく手元で以下を実行して、ポートフォワーディングを行う:

ssh -L 3000:localhost:3000 <接続先ホスト>

これにより、http://localhost:3000 にブラウザでアクセスすると、Firefish の管理者ユーザ作成画面が立ち上がる。後はユーザ名とパスワードを入力して、管理者ユーザを作成する。このユーザで以降投稿などができるようになる。

次に、リバースプロキシの用意と TLS 化を行う。ここら辺は、レジストラサービスに付随していたりもするので、そっちを使う場合は不要になる。自前で用意する場合は、まず Nginx のインストールを行う:

sudo apt install -y nginx

その後、以下のような設定を /etc/nginx/sites-available/firefish.conf に書き込む:

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

upstream firefish {
    server localhost:3000 fail_timeout=0;
}

proxy_cache_path
    /var/cache/nginx/firefish
    levels=1:2
    keys_zone=cache_firefish:16m
    inactive=720m
    max_size=1g
    use_temp_path=off
    ;

server {
    listen 80;
    listen [::]:80;
    server_name <使うドメインをここに書く>;

    root /var/www/html/firefish;

    location /.well-known/acme-challenge/ {
        allow all;
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    # TLS 設定をした後、以下のコメントアウトを外す
    listen 127.0.0.1:443;
    # listen 443 ssl http2;
    # listen [::]:443 ssl http2;
    # ssl_certificate     /path/to/fullchain.pem;
    # ssl_certificate_key /path/to/privkey.pem;

    server_name <使うドメインをここに書く>;

    # You can use https://ssl-config.mozilla.org/ to generate your cipher set.
    # We recommend their "Intermediate" level.
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305;
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;
    ssl_session_tickets off;

    keepalive_timeout    70;
    sendfile             on;
    client_max_body_size 99m;

    gzip on;
    gzip_disable "msie6";
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6;
    gzip_buffers 16 8k;
    gzip_http_version 1.1;
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml image/x-icon;

    proxy_redirect off;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

    # For WebSocket
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;

    location / {
        proxy_pass http://firefish;

        # Cache settings
        proxy_cache cache_firefish;
        proxy_cache_lock on;
        proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
        add_header X-Cache $upstream_cache_status;
    }
}

それから、キャッシュ用のディレクトリ作成と、Nginx 設定の有効化を行う:

sudo mkdir -p /var/cache/nginx
sudo chown www-data:www-data /var/cache/nginx
sudo ln -s /etc/nginx/sites-available/firefish.conf /etc/nginx/sites-enabled/firefish.conf
sudo rm -rf /etc/nginx/sites-enabled/default # デフォルトの設定を無効化
sudo systemctl restart nginx
sudo systemctl enable nginx # 再起動時に自動起動するようにする

次に TLS 証明書をインストールする。証明書をどっかで買ってる場合は、それをダウンロードしてくる。証明書に拘りがなく、とりあえず TLS 化だけしたい場合は、Let's Encrypt を利用するといいだろう。ここでは、Let's Encrypt を使う場合の設定を説明する。まず、certbot をインストールして、証明書発行を行う:

sudo apt install -y certbot python3-certbot-nginx
sudo certbot certonly --nginx -d <使うドメインをここに書く> --post-hook "systemctl reload nginx"
sudo systemctl enable certbot.timer # 証明書の自動更新を有効化する

TLS 証明書をダウンロードしたら、Nginx の設定ファイルを修正して、TLS 証明書を読み込むようにする:

-     # TLS 設定をした後、以下のコメントアウトを外す
-     listen 127.0.0.1:443;
-     # listen 443 ssl http2;
-     # listen [::]:443 ssl http2;
-     # ssl_certificate     /path/to/fullchain.pem;
-     # ssl_certificate_key /path/to/privkey.pem;
+     listen 443 ssl http2;
+     listen [::]:443 ssl http2;
+     ssl_certificate     /etc/letsencrypt/live/<使うドメインをここに書く>/fullchain.pem;
+     ssl_certificate_key /etc/letsencrypt/live/<使うドメインをここに書く>/privkey.pem;

上記は Let's Encrypt の証明書を使う場合だが、独自の証明書を使う場合はその証明書の秘密鍵と中間証明書のパスを設定するようにする。そして、Nginx を再起動する:

sudo systemctl restart nginx

ここまで上手くいったら、ブラウザで https://<使うドメイン>/ にアクセスして、Firefish の画面が表示されることを確認する。これで、Firefish のインストールは完了となるはず。後は、更新があったらまた deb をダウンロードしてきて、 sudo apt install -y ./firefish.deb で更新できる。

うまく行かなかったら、その時はまあ頑張ってくれ。鯖缶工場という分散 SNS のサーバ管理者の寄合所帯があるので、そこに助け求めると誰かが助けてくれるかもしれない。

まとめ

というわけで、Firefish の紹介と、そのインストール方法を紹介した。多分、あまり Firefish を直でインストールする系の記事はないと思うので、それを放流しておくのも兼ねてという感じ。何かの参考になれば。

この先、deb 配布を真面目にメンテしていくかは分からないが、ひとまず自分で使ってるので僕が Firefish ユーザを辞めない限りは続けていくんじゃないだろうか。何か要望があれば、言って貰えばすぐ対応できるものなら対応するかもしれない。というわけで、今回はそんな感じで。

[1]	使えると言っても若干更新が追いついていなかったり、対応が不完全だったりするので、完全に Mastodon 用のクライアントアプリが使えるというわけではない。また、Mastodon 用のクライアントアプリを使う場合、Firefish 用の機能を使えない場合があるので注意が必要。

[2]	逆に大手だとそれぞれでスケーリングできるので、サービス分かれてる方が嬉しいかもしれない。

[3]	たまにインストール方法が変わってることがあるので、nodesource の README の方をまずは参照して欲しい。

2023/10 時点の Fediverse の状況

2023-10-29T13:45:15+09:00

Fediverse は、W3C 勧告の ActivityPub を主要なプロトコルとした、リソース共有を相互に行う Web 上の分散ネットワークである。昨今の騒動で分散 SNS としてそれなりの人口を抱えており、僕は今年の2月ぐらい移住していて、かれこれ8ヶ月になる。

さて、Fediverse はオープン規格で構成されているため、基本的なデータは割と簡単に手に入れることができる。今回は、そのデータをちょっと整理して、現状の Fediverse の状況を見てみようと思う。

インスタンスごとの情報をとる

Fediverse 上で情報集める方法は幾つかあるが、ネットワーク内のノード、つまりサーバ単位で情報を集めるには以下が使える:

nodeinfo: https://nodeinfo.diaspora.software/: Fediverse でサーバの実行状態を公開する標準的な方法を目指した規格。JLD の拡張で、 /.well-known/nodeinfo というエンドポイントに JSON リソースリンクを公開し、そのリンク先に定められた形式でメトリクスを出すという形。ソフトウェア情報、登録機能が解放されているか、ユーザ数、投稿数などが取れる。
manifest.json: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json: PWA に対応しているサーバでは、それ用のマニフェストファイルに色々特定の形式で情報を載せている。ここから、サーバ名や説明などが取れる。
Mastodon Instance API: https://docs.joinmastodon.org/methods/instance/: Fediverse では Mastodon API が割と事実上の標準となっているところがあり、Mastodon API と互換のある形式で API 公開してるところも多い。そういうところなら、対応していれば Mastodon Instance API で nodeinfo 以上の情報が取れる。具体的には、 nodeinfo で取れる情報に加えて、対応言語、連絡先、サーバ名、サーバのルール、連合先ホストなど。
OGP (Open Graph Protocol): https://ogp.me/: Web で事実上の標準となっている、Web ページのメタ情報の規格。サーバ名や説明などが取れる。

他にもソフトウェア固有のものがいくつかあるが、全般的に取れるのはこんぐらいだろう。今回はこのうち、 nodeinfo と Mastodon Instance API の連合先ホスト一覧をとる機能のみを使っていく。具体的に見ていこう。

まず、 nodeinfo だが、これは /.well-known/nodeinfo から以下のような JSON を取ってくる:

{
    "links": [
        {
            "rel": "http://nodeinfo.diaspora.software/ns/schema/2.1",
            "href": "https://ff.mizunashi.work/nodeinfo/2.1"
        },
        {
            "rel": "http://nodeinfo.diaspora.software/ns/schema/2.0",
            "href": "https://ff.mizunashi.work/nodeinfo/2.0"
        }
    ]
}

/.well-known/nodeinfo には links フィールドに nodeinfo リソース URL の配列を公開することになっている。配列の要素は rel 要素にスキーマ、 href 要素にリソース URL を書く。 nodeinfo は現在 1.0、1.1、2.0、2.1 が出ており、1.x と 2.x は一部フィールドは互換がないが、基本的にはフィールド追加が主になる。なお、リソース URL は /nodeinfo/<version> みたいな形式になってるソフトは多いが、基本どういう URL であっても良い。 /nodeinfo/<version>.json みたいな URL で公開してるとこも多い。

nodeinfo リソースの内容は、 http://nodeinfo.diaspora.software/ns/schema/2.1 を見てもらうのがいいかもしれないが、一応見ておくと、以下のような情報が取れる:

{
    "version": "2.1",
    "software": {
        "name": "firefish",
        "version": "1.0.4-beta31",
        "repository": "https://codeberg.org/firefish/firefish",
        "homepage": "https://joinfirefish.org/"
    },
    "protocols": [
        "activitypub"
    ],
    "services": {
        "inbound": [],
        "outbound": [
            "atom1.0",
            "rss2.0"
        ]
    },
    "openRegistrations": false,
    "usage": {
        "users": {
            "total": 3,
            "activeHalfyear": 1,
            "activeMonth": 1
        },
        "localPosts": 436,
        "localComments": 0
    },
    "metadata": {
        "nodeName": "Mizunashi Social",
        "nodeDescription": "Mizunashi Mana のおひとり様サーバです。日本国法を遵守して、運用していく所存です。",
        "maintainer": {
            "name": "Mizunashi Mana",
            "email": "contact@mizunashi.work"
        },
        "langs": [],
        "tosUrl": null,
        "repositoryUrl": "https://codeberg.org/firefish/firefish",
        "feedbackUrl": "https://codeberg.org/firefish/firefish/issues",
        "disableRegistration": true,
        "disableLocalTimeline": false,
        "disableRecommendedTimeline": true,
        "disableGlobalTimeline": false,
        "emailRequiredForSignup": false,
        "searchFilters": false,
        "postEditing": true,
        "postImports": true,
        "enableHcaptcha": false,
        "enableRecaptcha": true,
        "maxNoteTextLength": 3000,
        "maxCaptionTextLength": 1500,
        "enableTwitterIntegration": false,
        "enableGithubIntegration": false,
        "enableDiscordIntegration": false,
        "enableEmail": true,
        "enableServiceWorker": false,
        "proxyAccountName": null,
        "themeColor": "#31748f"
    }
}

これは僕の Firefish というソフトウェアの鯖での実際の値なのだが、ソフトウェア情報とか、アカウント登録解放してるかとか、ユーザ数・投稿数などが JSON フィールドで公開されている。なお、 metadata フィールドにも色々書いてあるが、これはソフトウェア独自拡張で、それぞれのソフトウェアに依るという感じ。今回の分析は、基本この拡張以外の情報だけを見ていくという感じ。拡張の方はちょっと対応状況が悪いので、もうちょっと別の情報源当たった方がいいかなという感じ。

さて、Fediverse は広大なネットワークでノードも大小ある。そのため、ノードが特定できた場合に情報を取得する方法があっても、そもそもノードを見つけなければ意味がない。そこでノードの探索方法も重要になる。ノードの探索は多分確立した方法はないが、対応状況が現状一番良いのは Mastodon Instance API の連合先一覧取得、 /api/v1/instance/peers だと思われる。対応状況は後でみるが、こいつもそこまで対応状況が良いとは言えず、大手の Lemmy、 PeerTube といったソフトウェアは独自の API を叩くしかないという状況だ。今回は対応してるとこのみ探索してるが、その内もうちょっと個々の API 当たれるようにはしてみたいとは思っている。さて、具体的な方法だが、 /api/v1/instance/peers を叩くと以下のような JSON が返ってくるので、これを取るだけ:

[
    "ff.mizunashi.work",
    "misskey.io",
    "mastodon.social"
]

それぞれはホスト名になっており、ここの連合先をさらに辿っていけば、ひとまず Fediverse の大部分は網羅できるだろうというわけだ。

情報取得精度と対応状況

というわけで、実際に nodeinfo と peers API から情報収集を行うクローラーを書いた: https://github.com/mizunashi-mana/fediverse-stats

最初のインスタンスホストを与えれば、大体一日かけて Fediverse 上のデータを集めてくれる。10/22 時点での情報取得状況は以下だった:

取得状況	ホスト数	割合
成功	23813	30.43%
失敗	54451	69.57%

辿った先の半数以上のホストでは情報取得に失敗したが、23813件分のインスタンス情報は集まったらしい。情報取得失敗理由についてもう少し見てみると以下のようになった:

失敗理由	ホスト数	割合
アドレス解決失敗	19105	35.09%
nodeinfo 404 Not Found	9584	17.60%
TLS 証明書検証失敗	6104	11.21%
TCP 接続未達	5680	10.43%
タイムアウト (10sec)	4233	7.77%
無効な HTTP ステータス	3747	6.88%
nodeinfo の形式違反	1981	3.64%

アドレス解決失敗は一時的なものか一時的なものかの判別は困難だが、ほとんどは恒久的なものだろう。TLS 証明書検証失敗や、TCP 接続未達についても同じことが言える。というわけで半分はおそらくインスタンスが既に閉鎖していることによるものだと思われる。nodeinfo の HTTP ステータスコード違反、形式違反については数が多くて全部は見れていないが、こちらも基本的にインスタンスが既に閉鎖していて別のサービスに置き換わっていることによるものが多そうだ。ただ、一部 nodeinfo を公開していない独自インスタンスがあったり、全体に SSO 認証を敷いているサーバがあったりするようだ。もう少し今後詳細を調べていきたいが、ひとまずそこまで大きく逃しているノードは無いように思える。

一応上位の有名サーバが情報取得済みの対象に含まれていることも確認しておく。ユーザ数上位10件は以下のようになっている:

URL	ソフトウェア	ユーザ数	月間活動ユーザ数	連合数
https://egirls.gay/	misskey	1234567890	不明	2617
https://mastodon.social/	mastodon	1644665	283606	63812
https://pawoo.net/	mastodon	925128	49238	37460
https://daystorm.netz.org/	mastodon	479002	479003	不明
https://mstdn.jp/	mastodon	401999	38723	60633
https://misskey.io/	mastodon	399443	不明	22124
https://joindiaspora.com/	diaspora	316111	74	不明
https://baraag.net/	mastodon	293188	37530	26857
https://mastodon.cloud/	mastodon	273693	7552	47955
https://pravda.me/	mastodon	223407	52550	5224

Mastodon 鯖に限って言えば、大体 https://mastodonservers.net/servers/top の通りかなと思うので、おそらくそこまで大きな取りこぼしはないと思われる。なお、基本的に今回使う数値は自己申告制なので、悪意ある実装には弱い。実際上の数値はトップの https://egirls.gay/ と4位の https://daystorm.netz.org/ は数値が明らかにおかしいため、この後の分析では除外している。他にも詳しく見てみたら除外した方がいい数値はあるかもしれない。ま、そういうわけなので、あくまで参考程度に留めてくれという感じ。

数値取得の対応状況だが、項目毎に見てみると以下のようになる:

項目	対応ホスト数	対応ホスト割合
ソフトウェア名	23811	99.99%
ソフトウェアバージョン	23795	99.92%
ソフトウェアリポジトリ	1963	8.24%
ユーザ登録解放状況	23803	99.95%
ユーザ数	23163	97.27%
半年間活動ユーザ数	17675	74.22%
月間活動ユーザ数	17782	74.67%
ローカル投稿数	22889	96.12%
ローカルコメント数	8031	33.73%
連合ホスト数	14970	62.86%

nodeinfo/1.0 の時点で必須だった、ソフトウェア名、ソフトウェアバージョン、ユーザ登録解放状況は総じて対応状況が良い。また、ユーザ数、投稿数は必須ではないが公開してくれてるとこが多い。ただ、半年間活動 (アクティブ) ユーザ数、月間活動ユーザ数、コメント数は対応が少し悪い。nodeinfo/2.1 から入ったソフトウェアリポジトリもまだまだ対応してるとこは少ないという感じだ。連合ホスト数は、nodeinfo では対応してなくて、peers API からカウントして出している。これはいわば Mastodon Instance Peers API に対応してたかどうかの数になる。こちらも半数以上は対応してるが対応状況は良くはないということになる。なお、連合ホスト数には罠があり、大体それぞれのホストで連合先のソフトウェアにはホストと同じソフトウェアが使われているという偏りがある。そのため、Lemmy、PeerTube といったソフトウェアのネットワークは取りこぼしが発生している可能性が高く、逆に言えば Mastodon Instance Peers API に対応している範囲のネットワークしか拾えていないため対応状況が半数超えてるように見えているという可能性がある。その辺は将来的に少し改善していきたいところだが、ひとまず今回はこのデータを元に見ていく。

Fediverse の状況

ではそれぞれの数値を見ていこう。まず、総計値は以下のようになる:

項目	総計
インスタンス数	23811
ユーザ数	11555114
半年間活動ユーザ数	3364984
月間活動ユーザ数	1333071
ローカル投稿数	1164902338
ローカルコメント数	25175892

もちろん対応状況がまちまちなので、これらは確度の低い最低値ぐらいの認識でいるのがいいだろう。人口としてグローバルで1000万というのは、X が3億、YouTube が20億、Facebook が30億という数値から見るとまだやっぱり規模としては小さい [1]。またこの中にはかなり休眠ユーザもいるはずだ。月間活動ユーザ数は対応してない大規模インスタンスもいくつかいるので、おそらくこれよりは多いはずだが、それでも桁として変わることはないだろうから実質稼働しているユーザは数百万程という感じだろう。こちらは Facebook が2600万、X が 4500 万らしい [1] ので、やはり規模の桁は違うものの規模としては追いつける余地は十分ありそうだ。というわけで、現状ユーザ規模としては大手と比べるとまだまだだが、小さすぎるというわけでもなさそうという感じ。

次にそれぞれの分布を見てみる。まずインスタンス毎のユーザ数分布を見てみる:

この分布図は、数値を昇順に並べた場合に、横軸の割合の位置にいる数値が縦軸に対応する。見方としては、例えば横軸50の位置の縦軸数値が3だが、これは昇順に並べた場合に真ん中の位置にいる数値が3、つまり中央値は3であるということを意味する。ここから、大体中央値がユーザ数3ぐらい、75%ぐらいのインスタンスはユーザ数10以下のインスタンスという感じになる。75%を超えた辺りから結構ユーザ数が増加するという感じで、1/4程が盛況という感じのようだ。逆に1/4はおひとり様という感じっぽい。次にインスタンス毎の投稿数分布を見てみる:

ユーザ数分布に比べてインスタンス毎に数が結構違うっぽい。中央値は200ぐらいで、75%のインスタンスは投稿数2000以下のようだ。思ったより廃人やボットは少ないかもしれない。大半は、程々の投稿を抱えてるって感じっぽい。次にインスタンス毎の連合数分布を見てみる:

75%以上のインスタンスは、連合数100以上という感じっぽい。ユーザ数の分布で見た通り、基本的におひとり様かある程度のユーザ規模のインスタンスが多いので、フォロー・フォロワー数もある程度の規模のインスタンスが大半という感じなのだろう。最後にインスタンス毎の月間活動ユーザ数分布を見てみる:

この数値はソフトウェアにより対応状況が悪いというのはあるが、ユーザ数分布に比べて冬眠ユーザ、仮想ユーザを除いた数値が見れるのでより実態に近しい数値分布として使えるだろう。これを見ると、半分以上のインスタンスは実質1ユーザということになる。また75%でも4ユーザ以下しか稼働していないようだ。

次にソフトウェア毎のシェア率を見ていこう。まずインスタンス数のシェア率を見てみる:

Mastodon が圧倒的だが、その次が WordPress なのは結構意外だ。WordPress には ActivityPub プラグインがあり、ブログ投稿を Fediverse に配信してくれる。その機能使ってる WordPress 鯖もそれなりにいるっぽい。その後は、Misskey、PeerTube、Pleroma、Lemmy となるようで、この段階でインスタンスの75%以上となるようだ。この辺が大体人気のソフトウェアになるようだ。これはインスタンス数シェアになるので鯖管理人から見た視点になるが、ユーザ視点で言うとユーザ数シェアで見るのが良いだろう。というわけで、ユーザ数シェアも見てみる:

こちらでも Mastodon が圧倒的で、Lemmy、Misskey、Diaspora が続くようだ。ここから、ユーザのうち10人中7人は Mastodon を使っており、残り2人は Lemmy か Misskey、Diaspora のどれか、残り1人はそれ以外のソフトウェアを使っていると言う感じになる。インスタンス数シェア上位だった WordPress、Pleroma が姿を消し、代わりに Lemmy が大きく順位を上げ、Diaspora も躍り出ているという感じだ。WordPress、Pleroma は基本小規模インスタンスで使われることが多いので、ユーザ数シェアで見ると姿を消してしまっている。Diaspora は実はユーザ数で見るとシェアが大きいように見えるが、実はここに関しては JoinDiaspora というインスタンスのユーザがメインになっていて、ここは閉鎖に向かっており投稿を含むほぼ全ての機能が停止されていてユーザも活動していないという状況のようだ。なので、実質 Mastodon、Lemmy、Misskey がユーザから見て認知されてるソフトウェアということになるだろう。なおこれはグローバルで見てるが、日本語投稿が多いインスタンスとかに限定するともう少し変わってくるかもしれない。ただ、そこの判定は地味にめんどいので今回は見てない。

さて、ソフトウェアのシェアはおひとり様か開いたインスタンスかなどのインスタンスの属性によりかなり変わる。そちらも少し見てみる。まず、アカウント登録を解放しているかどうかでのインスタンスシェアを見てみる:

半分以上がアカウント登録を開放していない閉じたインスタンスで、開いたインスタンスは40%にも満たない。まずアカウント登録を開放しているオープンインスタンスでのソフトウェアシェアを見てみる:

Mastodon が相変わらず圧倒的だが、オープンインスタンスではユーザシェアと似たようなシェア傾向にあり、WordPress の代わりに Lemmy、Misskey が上位に入っている。また、個人的に意外だったが Pleroma、GoToSocial も割とシェアとしてはある程度あるようだ。逆に稼働ユーザ1のアカウント登録を開放していないインスタンス、通称おひとり様インスタンスでのシェアは以下のようになる:

こちらも Mastodon が圧倒的だが、それ以降はオープンインスタンスとかなり顔ぶれが変わり、Pleroma、PeerTube、Owncast で75%になるようだ。なお、今回おひとり様の判断は正確にはアカウント登録を開放しておらず、稼働ユーザ数1または稼働ユーザが取れなかったところはユーザ数5以下で判定しているので、正確におひとり様判定できているかは少し怪しい。これは Misskey などでは稼働ユーザ数の対応状況が悪くかつ仮想ユーザが生えてくることがあるためという感じだ。なので、まあそこまで確度は高くない。

最後にもう少し詳しいバージョン情報込みのソフトウェアシェアを見てみる。まずインスタンス数シェアから:

思ったよりみんなバージョン更新ちゃんとやってるようで、Mastodon 最新版のシェアが一番大きく、基本他のインスタンスも4系を使ってるところが多いようだ。ユーザ数シェアも見てみると、以下のようになる:

Mastodon 4系、Lemmy 0.18、Misskey (io版)、JoinDiaspora で使われてるバージョンが基本的なシェアを占める。特にユーザの40%以上は Mastodon 4.2 を使ってるっぽいので、その UI 前提という感じっぽい。そこは Fediverse 上での体験の前提として押さえておくのがいいかもしれない。

まとめ

というわけで、ひとまず Fediverse の各数値について並べてみた。分かることは中々少ないが、ひとまず Mastodon がソフトウェアシェアにおいて圧倒的であること、Fediverse の参加インスタンスは小規模インスタンスメインであることは読み取れる。とはいうものの信頼性に怪しい数値はやはりあるし、もうちょっと数値収集や情報源の拡張には改善の余地がありそうだ。

Fediverse は日々その姿を変えているし、この数値も半年後には大きく変わっているかもしれない。ただ、技術屋としてはオープン規格で色々やりやすく、実験場としての魅力は申し分ないし、SNS としても最近困ることがなくなってきた。むしろ日々色んなところで実験が生まれ、色々体験も変わってくるところはそこを楽しめる人にとっては面白い環境だと思う。結構これからが楽しみだ。

ま、今回の数値が何かの参考になればというわけで、今回はこれで。

ボックスタイプとCSSレイアウト

2023-10-08T22:40:38+09:00

さて、

<div>デザインにおいて、<div style="text-decoration: underline;">レイアウト</div>は重要な要素だ。</div>

という HTML 片が、基本的なブラウザでどう表示され、それがどういう原理からくるものか分かるだろうか？そして、それが意図に反した表示になっている場合に、意図通りに直すことはできるだろうか？これに対して明確な答えを持っている人は、この記事に書いてあることを既に理解しているであろうから引き返してなんら問題はない。

結論から言えば、これは

<div>デザインにおいて、<span style="text-decoration: underline;">レイアウト</span>は重要な要素だ。</div>

と書くのが一つ意図通りの HTML 片だったということになる。 div タグの代わりに、 span タグを使っているところが異なる。実は最初に提示した HTML 片は、基本的なブラウザでは「デザインにおいて、」の後と、「は重要な要素だ。」の前に改行が入るようレンダリングされる。対して、 span タグを使用すると、一行にそのまま表示される。部分的に下線をつけるためだけに div タグを使っていたつもりが、なぜかレイアウトにまで影響を与えていてしまったということだ。

この結果を引き起こす仕様はごく単純なもので、CSS を日頃触ってる人には常識ではあると思うのだが、少なくとも僕は CSS に真面目に入門するまではどういうことが起きているのかまるで分からなかった。今回は、この CSS を触ってる人には常識であろう、しかし CSS を使い慣れていない人には知らない人も多いと思われる CSS レイアウトの基本について見ていこうと思う。

通常フロー

「CSS レイアウト入門 | MDN」という素晴らしい入門サイトがあるので、そっち見てもらった方がいいかもしれんが、ひとまず基本から。

Web コンテンツは、コンテンツ内容を表す構造化データ HTML、そしてその構造化データの見た目、つまり配置と装飾を司る CSS で基本的に構成されている。JavaScript やその他の Web API により、ブラウザ上でコンテンツを動的に弄る術も発展しており、昨今は JavaScript から動的にコンテンツ生成する技法が主流になりつつはあるが、そこでも基本的にはコンテンツデータを HTML 片で、配置と装飾は CSS 片でが主流である。CSS というと装飾機能というイメージを持つ人は多いかもしれないが、Web コンテンツとしてはコンテンツ配置も CSS に分離されている。単に HTML 要素に対してデフォルトの配置が決まっているだけで、やろうと思えば自由に配置を弄れる。

CSS において配置を制御する最も基本的な方法が、 display プロパティによるページレイアウトである。 display プロパティは HTML 要素に対して、大きく2種類のレイアウト設定を行える:

通常フローでの要素の振る舞い (display-outside): レイアウト方法はいくつか種類があるが、その内通常フロー (normal flow)、またはフローレイアウトと呼ばれるデフォルトで採用されるレイアウト上で、その要素がどう振る舞うかを指定する。
内側でのレイアウト方法 (display-inside): その要素の子要素に対してどういうレイアウト方法を適用するかを指定する。

正確には他にもいくつかの設定を指定可能だが、そこは今回は触れない。display-outside には、後述する block、 inline の2種類が指定できる。また、display-inside にはフローレイアウト flow の他いくつかのレイアウト方法を指定できるが、ひとまず flow のみ見ていく。これら2つを組み合わせて、例えば display-outside block、display-inside flow の場合 display: block flow; のように指定する。

さて、CSS のレイアウトは基本的には何種類かのボックスを要素ごとに発行し、それぞれのボックスのコンテキストに従って配置を決めていく。フローレイアウトにおいては、基本的には、 block は垂直方向への配置、 inline は水平方向への配置を行う指定になる。では、その詳細を見ていこう。

まず、 display: block flow; が指定された要素は、ブロックボックスというボックスを発行する。ブロックボックスは、CSS 上でブロックレベルボックスと呼称されるものの性質を持ち、かつブロックコンテナボックスと呼ばれる性質も持つもののことだ。ブロックレベルボックスの性質として、コンテナボックス内に配置されると水平方向に伸びスペースを占有する。また、ブロックコンテナボックスの性質から、中に複数のブロックレベルボックスまたは複数のインラインレベルボックスを配置できる。つまり、その要素の外側、親要素から見た時の性質としては水平方向のスペースを占有して垂直方向に配置されるボックスとして振る舞い、要素の内側に配置される子要素からは垂直もしくは水平方向への要素配置空間を提供するボックスとして振る舞うということになる。

具体例を見る前に display: inline flow; の方も見ておこう。こちらの場合はインラインボックスというボックスを発行する。インラインボックスは、インラインレベルボックスというものの性質を持ち、かつ内側の配置方法もインライン形式を取るものになる。インラインレベルボックスの性質から、水平方向にボックスが配置される。また、インライン形式での配置により、中の要素はさらに行ボックスというものに分割される。分割は要素が水平方向になるべくはみ出ないかつ、いっぱいいっぱいになるように行われ [1]、水平方向に収まらない行ボックスは次の行に回されることで配置が行われる。

なお、ブロックボックス、インラインボックスは、適宜自動で生成されることもある。例えば、次の例を見てみよう:

<div style="display: block flow;">
    この HTML 片では、
    <div style="display: block flow;">ブロックボックス</div>
    と
    <div style="display: inline flow;">インラインボックス</div>
    が双方生成されます。
</div>

この場合まず、一番外側の div 要素でブロックボックスが発行され、その中身がそのボックスに配置されることになる。そして、ブロックコンテナボックスの性質として、ブロックレベルボックスが一つでも含まれるブロックコンテナボックスでは、全ての要素がブロックレベルボックスに配置されるよう、自動でブロックボックスが発行される。具体的に上の例では、以下のようなブロックボックス生成が行われる:

この場合、「<div style="display: block flow;">ブロックボックス</div>」がブロックレベルボックスであるため、他のテキストノードも含めた要素は、それぞれ必要に応じて自動生成されたブロックボックス内に配置される。さらに、ブロックレベルボックスを含まないブロックコンテナボックス内のテキストノードは、自動生成されたインラインボックスに配置される。これにより、次のようなインラインボックス生成が行われる:

もう一つ例を見ておこう。

<div style="display: block flow;">
    水平方向に収まらない
    <div style="display: inline flow;">インラインレベルボックス</div>
    は、複数の
    <div style="display: inline flow;">行ボックス</div>
    に分割され、必要に応じて垂直方向への移動を挟みながら水平方向に並べられます。
</div>

に対して、以下のようなインラインボックス生成が行われる:

さらに水平方向に収まらない部分は、行ボックス分割がおき、必要に応じて垂直方向への移動がおきる:

これが通常フローでの配置の基本となる。

HTML 要素のボックスタイプ

さて、CSS のデフォルトのレイアウト方法、通常フローもしくはフローレイアウトでは、ブロックボックス、インラインボックスの発行を指定することで配置方法を制御できることは分かってもらえただろう。これにより、最初の例はある程度説明がつく。つまり、

<style>
    div {
        display: block flow;
    }
    span {
        display: inline flow;
    }
</style>
<div>デザインにおいて、<div style="text-decoration: underline;">レイアウト</div>は重要な要素だ。</div>
<div>デザインにおいて、<span style="text-decoration: underline;">レイアウト</span>は重要な要素だ。</div>

という解釈が行われる仕組みがあれば、 div タグを使った場合と span タグを使った場合のレイアウトの違いについて説明がつく。実はまさに、HTML Standard と CSS3 の CSS デフォルト値から、以上の挙動と同じになることが説明できる。

まず、CSS3 では display プロパティの初期値は、 inline となることが決められている [2]。つまり、通常明示的に display プロパティを書かない場合、 display: inline; と書くのと同じ挙動になることになる。 display: inline; は詳細は後述するが、 display: inline flow; の省略形となる。よって上の例は、 span についてはわざわざ display: inline flow; と指定しなくても良いことになる。また、HTML Standard には HTML 要素に対するデフォルトのスタイルシートが規定されており [3]、以下の要素はデフォルトで display: block; が指定されている:

html
body
address
blockquote
center
dialog
div
figure
figcaption
footer
form
header
hr
legend
listing
main
p
plaintext
pre
search
xmp

display: block; は display: block flow; と書くのと同じ挙動になる。これらの仕様から最初に提示した振る舞いが起きることになる。

その他のレイアウト

最後に、display プロパティについてもう少し詳細を見ておこう。display-outside についてはもう見たわけだが、display-inside は flow の他にいくつかレイアウト方法を指定できる。他に指定できる種類は以下だ:

flow-root: ブロックコンテナボックスを、独自の配置空間で発行し、そこに子要素を配置する。flow と異なるところは、例え display-outside で inline が指定されていようとブロックコンテナボックスが発行されるところだ。
flex: フレックスボックスという特殊なボックスを発行し、独自のレイアウト方法を取る。詳しくは、フレックスボックス入門ガイドを見てもらうのが良いだろう。
grid: グリッドボックスという特殊なボックスを発行し、独自のレイアウト方法を取る。詳しくは、グリッド入門ガイドを見てもらうのが良いだろう。
table: table タグと同様のレイアウトを取る。これは今回は詳しくは触れない。中々使う機会もないだろう。
ruby: ruby タグと同様のレイアウトをとる。これは今回は詳しくは触れない。中々使う機会もないだろう。

これらと display-outside の組み合わせで display プロパティを指定する。なお、CSS2 との互換性と省略のため、省略形が規定されている。それぞれ次のようになる:

省略形	新しい値
display: inside;	display: inside flow;
display: block;	display: block flow;
display: flow-root;	display: block flow-root;
display: inline-block;	display: inline flow-root;
display: flex;	display: block flex;
display: inline-flex;	display: inline flex;
display: grid;	display: block grid;
display: inline-grid;	display: inline grid;
display: ruby;	display: inline ruby;
display: table;	display: block table;
display: inline-table;	display: inline table;

特に inline-block、つまり inline flow-root は通常フローでも重宝される display 指定で、例えば次のような配置を実現できる:

<div style="display: block flow;">
    インラインブロックを使用することで、
    <div style="display: inline flow-root;">
        <div style="display: block;">ブロック1</div>
        <div style="display: block;">ブロック2</div>
    </div>
    のようにインラインレベルでブロックを二重に並べたりできます。
</div>

単純にインラインボックスの中にブロックボックスを配置する、つまり

<div style="display: block flow;">
    インラインブロックを使用することで、
    <div style="display: inline flow;">
        <div style="display: block flow;">ブロック1</div>
        <div style="display: block flow;">ブロック2</div>
    </div>
    のようにインラインレベルでブロックを二重に並べたりできます。
</div>

というような書き方では、内部のブロックは横一杯に広がってしまう。しかし、 inline flow-root では独自の配置空間を作ることにより、外側から見たらインラインレベルボックスとして、内側から見たらブロックコンテナボックスとして振る舞えるようになる。つまり、その行の部分的な要素でありながら、内部にボックスを配置できるような振る舞いを持たせることができる。この辺の詳細を正確に知りたい場合は、CSS2 の幅・高さ計算などの仕様を見てもらうのがいいだろう。なお、 inline flow-root をデフォルトの挙動として持つ HTML 要素として、

input
button

がある。これらの振る舞いの違いやデフォルト値によって、現在の HTML の Web ブラウザでの描画配置は形作られている。

まとめ

というわけで今回は、CSS の基礎ではあるが、日頃触ってない人にはあまり知られていない通常フローの配置について紹介した。通常フローでは、ブロックボックスとインラインボックスという基本的なレイアウト要素がある。また、それぞれの区分けは HTML 要素ごとにデフォルト値が決まっており、明示的に指定しない場合はその HTML の意味論に沿った配置がされる。あくまでデフォルト配置なので、配置のために HTML の意味論に反した使い方をするより、HTML の意味論に沿った使い方をしつつ明示的に配置方法を CSS で変更するのがいいだろうが、デフォルトの挙動を把握することは HTML の意味論の理解にも繋がりやすいだろう。

実はここら辺のレイアウトがちゃんと HTML / CSS で切り離されたのは結構最近だったりするし、CSS3 の display 2値指定も取り扱ってる文献はまだまだ少ない。なので、それらを整理して理解する良い機会となった。ま、何かの参考になれば嬉しい。では、今回はこれで。

[1]	`word-break` プロパティなどにより、ある程度分割の戦略は制御できる。

[2]	https://www.w3.org/TR/css-display-3/#propdef-display

[3]	https://html.spec.whatwg.org/multipage/rendering.html#rendering

アーカイブ済み ActivityPub サーバの実装

2023-09-09T18:06:22+09:00

Fediverse は ActivityPub をしゃべるサーバを基本単位とした分散型 SNS ネットワークである。ActivityPub は W3C が勧告する分散型 SNS の標準プロトコルで、ActivityStreams というデータフォーマットプロトコルを元に、SNS 上のコンテンツを HTTP 上で JSON を通してやり取りする通信方法を規定する。サーバ実装も多様化しているが、基本的には ActivityStreams の方に拡張を加えた ActivitiyPub と、WebFinger と呼ばれるアカウントに対して紐づけるリソース URL を HTTP で発信するプロトコルへの対応、そしてクライアント用 API を用意しているものが多い。

さて、分散型 SNS は変化が早く、各サーバの寿命も短い傾向にある。運営の完全撤退の場合もあるが、サーバソフトウェアの変更や、並走して動かしていたサーバをどちらかに統一したい場合など、管理上の都合で一部サーバを停止することもよくある。しかしそうなった場合、リンク先が機能しなくなり引用文献などが参照できなくなる他、ユーザIDから情報が辿れなくなってしまい参照性が失われやすい。

丁度、僕も Mastodon から Firefish というソフトウェアへの移行を目指しており、最近、幾つか Fediverse インスタンスのアーカイブ方法について研究してみていた。今回は Fediverse の技術的な概要と研究した内容について紹介したいと思う。

Fediverse を支えるプロトコル

Fediverse で基本となるプロトコルは、ActivityPub と呼ばれるものである。ActivityPub では、actor と呼ばれるリソースから activity と呼ばれるメッセージを配信したり、逆に actor が activity を受信することで、Fediverse 上のコンテンツをやり取りする。actor はメッセージ受信用リソース inbox とメッセージ送信用リソース outbox を持っており、これらのリソースから HTTP GET メソッドでメッセージを取得、POST メソッドでメッセージを送信する。 W3C の ActivityPub recommendation から図を借りると、

のようなイメージとなる。

例えば、Mastodon の公式アカウントの actor リソースは、 https://mastodon.social/users/Mastodon という URI に置かれている。アクセスするには、

$ curl -qsSL 'https://mastodon.social/users/mastodon' -H 'Accept: application/activity+json' | jq
{
    "@context": [
        "https://www.w3.org/ns/activitystreams",
        ..
    ],
    "id": "https://mastodon.social/users/Mastodon",
    "type": "Person",
    "following": "https://mastodon.social/users/Mastodon/following",
    "followers": "https://mastodon.social/users/Mastodon/followers",
    "inbox": "https://mastodon.social/users/Mastodon/inbox",
    "outbox": "https://mastodon.social/users/Mastodon/outbox",
    "featured": "https://mastodon.social/users/Mastodon/collections/featured",
    "featuredTags": "https://mastodon.social/users/Mastodon/collections/tags",
    "preferredUsername": "Mastodon",
    "name": "Mastodon",
    "summary": "<p>Free, open-source decentralized social media platform.</p>",
    "url": "https://mastodon.social/@Mastodon",
    ...
}

のように、 Accept ヘッダに application/activity+json をつけて HTTP GET メソッドでアクセスを行う必要がある。このように、ActivityPub では基本的に JSON-LD と呼ばれる JSON 形式の上で構造化データを表現する形式を採用しており、MIMEタイプ application/activity+json のデータとして Web 上でやり取りを行う。ただ、ActivityPub 自体はそのデータをどうやり取りするかを主に定義しており、データの意味論や形式の標準は ActivityStreams に切り出されている。actor リソースが持つ基本的な情報は、以下の通り:

inbox リソース: inbox リソースは actor が受け取った activity のコレクションを表すリソース。ActivityPub では、actor の inbox フィールドにその URI が指定されているのが基本的な制約になる。inbox リソースはクライアント向けに GET メソッドでアクセスされると activity コレクションを返し、連合サーバからは POST メソッドで activity を受け取るようになっている必要がある。ただ、GET メソッドの方は対応してるソフトはあんまりないが。なお、連合を拒否するには POST に対して 405 を返すのがいいらしい [1]。
outbox リソース: outbox リソースは actor が発信してる activity のコレクションを表すリソース。ActivityPub では、actor の outbox フィールドにその URI が指定されているのが基本的な制約になる。outbox リソースは連合サーバ向けに GET メソッドでアクセスされると activity コレクションを返し、クライアントからは POST メソッドで配信する activity を受け取るようになっている必要がある。ただ、こちらはあまり実際に使ってるソフトはいなくて対応状況も悪い。まあ、GET メソッドの方は大体対応している気はするが。
followers リソース: 該当の actor をフォローしている actor のコレクションを表すリソース。ActivityPub では、actor の followers フィールドにその URI が指定されているのが基本的な制約になる。
following リソース: 該当の actor がフォローしている actor のコレクションを表すリソース。ActivityPub では、actor の following フィールドにその URI が指定されているのが基本的な制約になる。

他にも作成日、名前、アイコン画像などが載せられるが、まあその辺の詳細は ActivityStreams の規格を覗いてもらうのがいいだろう。他に、Mastodon や Misskey などの各ソフトウェアで独自の拡張も加えていたりする。例えば、Mastodon にはディレクトリ掲載の可否を示す discoverable というフラグを追加していたり、Misskey では猫かどうかを示す isCat というフラグが追加されていたりする。Mastodon の拡張は https://docs.joinmastodon.org/spec/activitypub/ に、Misskey の拡張は https://misskey-hub.net/ns.html にそれぞれ記載されているので、参考にしてみるのがいいだろう。

この actor が持っている inbox、outbox にデータを送り合うことで、Fediverse 上でのコンテンツ共有が行われる。基本的には、連合してるサーバ同士で発信するデータを互いに送信先に inbox に POST で突っ込むのが通例だ。なお、あまり使われてなさそうだが、outbox リソースを定期的に監視することでもデータを追えはする。なので実は ActivityPub では push 型、つまり送信したいデータを送信先に投入するだけでなく、pull 型、受信側が送信元を定期的に監視することでもデータを受信できる。この際配信される情報は2つある。1つはコンテンツそのもの、もう1つがそのコンテンツに対する操作、例えばコンテンツ作成や編集、削除などである。この2つを合わせたものが activity と呼ばれ、この activity をやり取りすることでコンテンツ共有が行われる。例えば、Mastodon iOS アプリがリリースされた旨の投稿作成 activity を見てみると、

$ curl -qsSL 'https://mastodon.social/users/Mastodon/statuses/109831774267343989/activity' | jq
{
    "@context": [
        "https://www.w3.org/ns/activitystreams",
        ...
    ],
    "id": "https://mastodon.social/users/Mastodon/statuses/109831774267343989/activity",
    "type": "Create",
    "actor": "https://mastodon.social/users/Mastodon",
    "published": "2023-02-08T23:44:35Z",
    "to": [
        "https://www.w3.org/ns/activitystreams#Public"
    ],
    "cc": [
        "https://mastodon.social/users/Mastodon/followers"
    ],
    "object": {
        "id": "https://mastodon.social/users/Mastodon/statuses/109831774267343989",
        "type": "Note",
        "summary": null,
        "inReplyTo": null,
        "published": "2023-02-08T23:44:35Z",
        "url": "https://mastodon.social/@Mastodon/109831774267343989",
        ...
        "content": "<p>Today we&#39;ve released a new update to our iOS app! It brings an improved sign-up flow, home screen widgets, and many accessibility improvements.</p><p><a href=\"https://apps.apple.com/us/app/mastodon-for-iphone-and-ipad/id1571998974\" target=\"_blank\" rel=\"nofollow noopener noreferrer\" translate=\"no\"><span class=\"invisible\">https://</span><span class=\"ellipsis\">apps.apple.com/us/app/mastodon</span><span class=\"invisible\">-for-iphone-and-ipad/id1571998974</span></a></p>",
        ...
    }
}

といった感じだ。activity リソースが持つ基本的な情報は、以下:

種別: Create、 Update、 Delete、 Follow などのコンテンツに対する操作の種別。activity の type フィールドに指定する。
コンテンツ: 操作対象のオブジェクト。 Note、 Image、 Audio など色々な種別を持つ。activity の object フィールドに指定する。
配信先: activity の配信先。actor のリソース URI を指定できる他、https://www.w3.org/ns/activitystreams#Public のような特別な配信先の URI などが指定できる。配信形式によって activity の to、 bto、 cc、 bcc、 audience フィールドに指定する。

こんな感じの情報を Fediverse では送り合ってるわけだ。まあ、送受信はもう少し色々面倒があるんだが、今回はそこには立ち入らない。

さて、このように actor リソースを中心に、ActivityPub は回ってる。ただ、問題はこの actor リソースの場所を共有する方法である。URI を直接共有してもいいが、Fediverse ではアカウント ID を別途発行し、それを元に actor リソースを特定する方法が取られている。これは、アカウントリソースを ActivityPub 前提にしないためだろう。このアカウント ID から actor リソースの特定方法を提供するプロトコルが WebFinger と呼ばれるものになる。WebFinger は、 /.well-known/webfinger という URI に、クエリパラメータ付きで HTTP GET アクセスをすると、そのパラメータにあったリソース URI を JSON 形式で返してくるという割と単純なもの。例えば、 @Mastodon@mastodon.social のリソースをクエリするには、

$ curl 'https://mastodon.social/.well-known/webfinger?resource=acct:Mastodon@mastodon.social'
{
    "subject": "acct:Mastodon@mastodon.social",
    "aliases": [
        "https://mastodon.social/@Mastodon",
        "https://mastodon.social/users/Mastodon"
    ],
    "links": [
        {
            "rel": "http://webfinger.net/rel/profile-page",
            "type": "text/html",
            "href": "https://mastodon.social/@Mastodon"
        },
        {
            "rel": "self",
            "type": "application/activity+json",
            "href": "https://mastodon.social/users/Mastodon"
        },
        {
            "rel": "http://ostatus.org/schema/1.0/subscribe",
            "template": "https://mastodon.social/authorize_interaction?uri={uri}"
        },
        {
            "rel": "http://webfinger.net/rel/avatar",
            "type": "image/png",
            "href": "https://files.mastodon.social/accounts/avatars/000/013/179/original/b4ceb19c9c54ec7e.png"
        }
    ]
}

のようにする。WebFinger では

resource: WebFinger リソースの URI。Fediverse では、 acct URI スキームが使われることが多い。actor リソース URI を直接使える実装も多い。
rel: オプションで、リソース URI の制限を指定できる。

のパラメータを受け取り、MIMEタイプ application/jrd+json の JSON データを返す。レスポンスは cross origin でも受け付けられるよう、 Access-Control-Allow-Origin: * をつけることが要求されていて、

subject: WebFinger リソースの一意な URI。Fediverse では基本 acct URI スキームが使われる。
aliases: オプションで指定される、他にリソースを特定するために使える URI。
properties: オプションで指定される、付加情報。
links: WebFinger リソースに紐づくリソースへのリンク。Fediverse では、HTML リソース、ActivityPub actor リソース、OStatus と呼ばれる ActivityPub の前身の購読リソース、アバター画像のリソースなどがリンクされてることが多い。

などが返ってくる。この WebFinger は各 ActivityPub 実装に付随している。Fediverse 上の UI では、アカウント ID のドメインに対してクエリがかけられ、上記情報から actor リソースを特定し、actor リソースからアカウント情報を引っ張ってくるという感じになる。

静的な ActivityPub サーバ

さて、ActivityPub のコンテンツ共有を除き、WebFinger から actor リソースの特定を行うまでは、単純な GET メソッドの連鎖によって行うことができる。実際、Mastodon や Misskey などに、擬似的にアカウントを作って認識させるだけなら、静的なサイトで十分可能だ。もちろん、これだと POST メソッドで inbox に activity を投入することなどはできないため、コンテンツ配信はできないが、逆に言えばコンテンツ配信しないサーバ、例えばアーカイブ済みのサーバを建てることはできる。これによりバックエンドをオブジェクトストレージにすることなども視野に入れることができ、サーバ運営の費用と手間を抑えることも期待できる。

ま、実際に見てみるのが早いと思うので、Cloudflare Pages でちょっと規格から外れる部分はあるが、Mastodon や Misskey で問題なく認識される擬似的な ActivityPub サーバを立ててみる。この擬似的なサーバはアカウントを一つしか持つことができない。これは、WebFinger がクエリパラメータによりリソースを認識するという問題によるものだ。ここに関してはリダイレクタを挟むなり、今回のようにクエリパラメータガン無視で一意なリソースを返すなどの工夫をする必要がある。その制約さえ許容すれば Cloudflare Pages で擬似的なサーバを立てられる。

まず、特別なリソースをいくつか用意しておく:

$ cat static/empty-collection.json
{
    "@context": "https://www.w3.org/ns/activitystreams",
    "id": "https://virtual-ap-demo-mizunashi-work.pages.dev/static/empty-collection.json",
    "type": "Collection",
    "totalItems": 0,
    "items": []
}
$ cat static/empty-ordered-collection.json
{
    "@context": "https://www.w3.org/ns/activitystreams",
    "id": "https://virtual-ap-demo-mizunashi-work.pages.dev/static/empty-ordered-collection.json",
    "type": "OrderedCollection",
    "totalItems": 0,
    "orderedItems": []
}

これは空のコレクションを表すリソース。とりあえず、 actor が認識されればいいので、 inbox、 outbox、 following、 followers など ActivityPub で必要とされるコレクションリソースには適宜上記のリソースを埋めておく。その為のもの。今回は、 virtual-ap-demo-mizunashi-work というプロジェクト名で Cloudflare Pages にプロジェクトを作ったので、それに合わせた id を指定する。その辺は試す環境に合わせて変えるのがいいだろう。次にこれを元に actor リソースを作る:

{
    "@context": [
        "https://www.w3.org/ns/activitystreams",
        {
            "manuallyApprovesFollowers": "as:manuallyApprovesFollowers",
            "alsoKnownAs": {
                "@id": "as:alsoKnownAs",
                "@type": "@id"
            },
            "movedTo": {
                "@id": "as:movedTo",
                "@type": "@id"
            }
        },
        {
            "toot": "http://joinmastodon.org/ns#",
            "featured": {
                "@id": "toot:featured",
                "@type": "@id"
            },
            "featuredTags": {
                "@id": "toot:featuredTags",
                "@type": "@id"
            },
            "discoverable": "toot:discoverable",
            "devices": {
                "@type": "@id",
                "@id": "toot:devices"
            },
            "suspended": "toot:suspended"
        }
    ],
    "id": "https://virtual-ap-demo-mizunashi-work.pages.dev/static/users/virtual-acct.json",
    "type": "Person",
    "following": "https://virtual-ap-demo-mizunashi-work.pages.dev/static/empty-ordered-collection.json",
    "followers": "https://virtual-ap-demo-mizunashi-work.pages.dev/static/empty-ordered-collection.json",
    "inbox": "https://virtual-ap-demo-mizunashi-work.pages.dev/static/not-found.json",
    "outbox": "https://virtual-ap-demo-mizunashi-work.pages.dev/static/empty-ordered-collection.json",
    "featured": "https://virtual-ap-demo-mizunashi-work.pages.dev/static/empty-ordered-collection.json",
    "featuredTags": "https://virtual-ap-demo-mizunashi-work.pages.dev/static/empty-collection.json",
    "preferredUsername": "virtual-acct",
    "name": "Virtual User",
    "summary": "A virtual user of @mizunashi_mana@mstdn.mizunashi.work. Anyone cannot follow me.",
    "url": "https://virtual-ap-demo-mizunashi-work.pages.dev/index.html",
    "manuallyApprovesFollowers": false,
    "discoverable": true,
    "published": "2023-08-07T00:00:00Z",
    "devices": "https://virtual-ap-demo-mizunashi-work.pages.dev/static/empty-collection.json",
    "movedTo": "https://mstdn.mizunashi.work/users/mizunashi_mana",
    "tag": [],
    "attachment": []
}

これを static/users/virtual-acct.json においておく。さらに、 .well-known/webfinger に、

{
    "subject": "acct:virtual-acct@virtual-ap-demo-mizunashi-work.pages.dev",
    "aliases": [
        "https://virtual-ap-demo-mizunashi-work.pages.dev/index.html",
        "https://virtual-ap-demo-mizunashi-work.pages.dev/static/users/virtual-acct.json"
    ],
    "links": [
        {
            "rel": "http://webfinger.net/rel/profile-page",
            "type": "text/html",
            "href": "https://virtual-ap-demo-mizunashi-work.pages.dev/index.html"
        },
        {
            "rel": "self",
            "type": "application/activity+json",
            "href": "https://virtual-ap-demo-mizunashi-work.pages.dev/static/users/virtual-acct.json"
        }
    ]
}

という JSON ファイルをおく。後は、 index.html を内容適当で作っておいておき、GitHub にアップして、Cloudflare Pages の GitHub connector で接続してプロジェクトを作って @virtual-acct@virtual-ap-demo-mizunashi-work.pages.dev で検索すると、 @mizunashi_mana@mstdn.mizunashi.work に引越し済みのユーザを確認することができるだろう。コードの全貌は https://github.com/mizunashi-mana/virtual-ap-demo.mizunashi.work において実際にデプロイしてあるのでぜひ試してほしい。

Fediverse 上のソフトはこのアカウント ID を次の手順で辿ることが期待される:

まず、 https://virtual-ap-demo-mizunashi-work.pages.dev/.well-known/webfinger?resource=acct:virtual-ap-demo-mizunashi-work.pages.dev にアクセスして、WebFinger リソースを取得し、 rel=self の actor リソース URI https://virtual-ap-demo-mizunashi-work.pages.dev/static/users/virtual-acct.json を入手する。
次に、 https://virtual-ap-demo-mizunashi-work.pages.dev/static/users/virtual-acct.json にアクセスして actor リソースを入手する。この際、適宜 following、 followers フィールドから空のコレクションリソースにアクセスしたり、 movedTo からこの actor が引越し済みで引越し先は https://mstdn.mizunashi.work/users/mizunashi_mana であることなどを知る。
必要な情報を自身のデータベースに登録し、ユーザ情報を検索結果として表示する。

ま、多少複雑だが、こんぐらいできれば引越し済みアカウントは別にネット世界から抹消しなくても残せるというわけだ。

archivedon

さて、上記のようにリソースをリンクだけ書き換えて単に JSON ファイル化して、いい感じに配置していけば、配信しない ActivityPub サーバは作れる。ただ、どうせなら、旧 URL からの参照性を残したり、WebFinger でマルチアカウント対応ぐらいはできるようにしておきたい。なので、そこら辺だけはうまくできるように、後アーカイブ済みリソースを閉じる予定のサーバから簡単に作れるようなソフトを Rust で書いてみた。コードは、 https://github.com/mizunashi-mana/archivedon にある。

ここまでの話を踏まえれば、やってることはそこまで難しくない。このサーバ、archivedon が提供する機能は大きく3つ:

static リソースファイルのサービング: これは単純に指定のデータディレクトリの ./static をそのままサーブするだけ。ここだけ、どっかのオブジェクトストレージでサービングさせることも可能。内容をどう配置するかは後述する。
WebFinger、nodeinfo などの情報生成: WebFinger リソースについては上記の通り。resource、rel パラメータを受け取り、いい感じの JSON を返す。内容はデータディレクトリの ./webfinger ディレクトリから取得する。内容をどう配置するかは後述する。後、Misskey や Firefish などのソフトでは、nodeinfo というリソースにも対応しておくと、サーバ情報をそこから取得していい感じに付加情報として表示してくれる。これも生成するようにしている。
旧 URI からのリダイレクト: 指定のデータディレクトリの ./map ディレクトリにリダイレクト情報がある場合は、それを元にリダイレクトを行う。内容をどう配置するかは後述する。

後は、Misskey、Firefish 辺りはホームページのメタ情報などもスクレイピングしてきたりするので、トップページの HTML サービング機能などもつけている。使い方は、https://github.com/mizunashi-mana/archivedon/releases からバイナリ落としてきて、

archivedon serve --port 3333 --resource-dir ./resource --expose-url-base https://archivedon.mizunashi.work/

みたいな感じでいい感じに resource ディレクトリ作って、いい感じにドメイン発行とかして、いい感じに downstream 設定すれば立つ。ま、静的ファイルサービングするだけの HTTP サーバなので、データベースとかもいらんし、キャッシュとかは nginx とか downstream 側でよしなにやってくれという感じ。static リソースも基本オブジェクトストレージに載せられるなら、downstream 側でそっちに振り分ければ archivedon は well known リソースのサービングとリダイレクタとしての役割だけでよくなり、さらにメンテが楽になるだろう。

それから、サーバがサーブするリソースを、稼働している ActivityPub サーバからスクレイプして作る機能も載せている。データベースからさらって作る方が効率は良いが、それだと結構公開リソースかどうかの判別で事故りそうだったのと、かなり実装依存になりそうだったのであえて避けた。代わりに HTTP リクエストで fetch しまくるので、リソースファイルの作成がかなり遅く、サーバ側にも負荷がかかる。あまり大規模なサーバではお勧めできない。やることは、

{
    "static_base_url": "https://archivedon.mizunashi.work/static/",
    "accounts": [
        "@mizunashi_mana@mstdn.mizunashi.work"
    ]
}

みたいな JSON ファイルを input.json として作り、

archivedon-fetch --input input.json --output resource --fetch-outbox

みたいな感じで実行すると、 accounts で指定されたアカウントIDから、WebFinger を経由して actor リソースを取得し、inbox、outbox などの諸々を空のコレクションリソースに、他も書き換えが必要なところは書き換えつつ、必要ないところはそのまま残しつつでリソースファイルを作成して ./resource/static 以下においたり、 ./resource/map にリダイレクトマップを作ったり、 ./resource/webfinger に WebFinger リソースを作ったりしてくれる。後、 --fetch-outbox を指定しておくと、同じ要領で outbox の activity を辿り投稿リソースなどに対しても同じようなことをしてくれる。後はまあ、修正することがあったら、単なる JSON ファイルなので手動で手を加えたりすることもできるだろうという感じ。

Content-Type などが多少規格から外れてる部分があるのと、WebFinger が受け取れるパラメータが acct URI にしか対応してないみたいな問題はあるが、実用上はそこまで問題ないんじゃないかなという感じ。ひとまず Mastodon、Firefish などでは認識されるよう頑張った。

まとめ

というわけで、Fediverse を支えるプロトコルの、主に情報取得部分特化での簡単な紹介と、その部分を利用して割りかし静的なアーカイブ済みサーバ専用ソフトの仕組み紹介をした。ひとまずこれ使ってアーカイブしていきつつ、Mastodon から Firefish へ完全にお引越ししようかなという感じ。

やっぱ完全に諸々持ち越せないのが Fediverse ではちょっと辛いな、そこはもうちょっとプロトコルレベルで考慮があっても良かったのではというのはあるが、ま認証というのは色々技術的に難しい問題なのでしょうがないね。アーカイブは notestock に頼るというのも一つの手だが、notestock が滅びる可能性は十分あるし、コードが公開されてて、割りかし自分の裁量でアーカイブ物の調整がしやすいものが欲しかったので、割と満足。後、ActivityPub の諸々についてちょっと知識がついて、解像度が上がった。これを機に、Fediverse の諸々を触ってみてもいいかなと思ったりしたが、ま時間はないですね。では、今回はこれで。

[1]	https://www.w3.org/TR/activitypub/#delivery

malloc と併用可能なアロケータを作る

2023-09-01T12:09:26+09:00

大規模で、ユーザ入力などの外部要因により左右されるプログラムでは、動的なメモリ管理が必要になる場合が多い。特に GC が普及した今日では、多くのプログラムにおいて基本的な機能と言えるだろう。このメモリ管理の機構として、多くのプログラミング言語実装では libc の malloc / free がデファクト的に使われている。一般に、プログラムの動的なメモリの割り当てと解放を抽象化した機構はメモリアロケータ、または単にアロケータと呼ばれる。libc malloc はその標準的なものとして、システムアロケータと呼ばれたりする。特に、ほとんどの環境では libc のデファクト標準で glibc が使われることから、glibc malloc が事実上の標準システムアロケータであると言ってよいだろう。このため、libc malloc は数多くのライブラリやプログラミング言語ランタイムで使われている。

さて、そんな glibc malloc だが、汎用性を重んじて作られているため、メモリ管理に少し手を加えたい場面ではパフォーマンス面とのバランスも考えると適さない場合もある。そのような場合に一からアロケータを作成したい場合もあるが、既存資産の相互運用も考えると malloc 互換の API を用意する、もしくは glibc malloc と併用可能にしたい場合もある。特に、libc が静的にリンクされる場合のことなども考えると、glibc malloc と併用可能な状況を作ることが望ましい場合がある。しかし、アロケータを glibc malloc と併用可能にするには多少テクニックが必要だ。今回は、x86 64bit Linux 環境で、glibc malloc と併用可能なアロケータを実装するテクニックについて紹介する。

glibc malloc の実装

まずは基本的なところから。さて、そもそも何気なく使われている malloc / free だが、この中身はどうなっているのだろう？ glibc malloc の役割は、大雑把には、

必要に応じたヒープ領域の拡張: メモリ管理で主に使われる領域を足りなくなったら必要に応じて OS に拡張してもらう。
使用可能な領域からのメモリ領域の切り出し: まだ使用していない領域を管理し、そこから要求された分を切り出して必要に応じてヘッダ情報を載せアプリケーション側に管理を委譲する。これは誤解している人が多いと思うが、一般的にアロケータの「メモリ割り当て」と呼ばれる動作は、実際の物理メモリへの新たなデータ書き込みを伴うものでないことが多い。これについては詳しくは後述するが、一般的にアロケータの役割は実際のメモリデータ管理と配置というよりは、メモリ番地の空き管理と予約に近い。予約済みのものをアプリケーション側に提供し、後はよしなに利用してくれ、利用終わったら言ってくれたら必要に応じて掃除して空室としてまた予約可能にしとくよという感じだろう。
使用終了した領域を使用可能にする: アプリケーション側から使用終了の告知があった領域を、必要に応じて後処理をし、使用可能な領域に戻す。

の3つだ。では、それぞれ少し詳しく見ていこう。

まず、そもそもだが、現代的なアーキテクチャと OS では仮想メモリという仕組みのサポートがある。通常私たちが触っているメモリの番地とは仮想的なものであり、実際の物理的なメモリにアクセスする際は CPU が OS の変換テーブルを使って実際の対応する物理メモリ番地に変換してからアクセスを行う。仮想メモリの番地は、物理的なメモリに必ずしもマッピングされているとは限らないし、物理的なメモリに連続して配置されているとも限らない。現代的にはページング方式という仮想メモリ領域の物理メモリへの展開方法が多くの場合採用されており、ざっくばらんによくある説明として、仮想メモリ空間をページという小さな固定サイズの単位に分解して、実際にデータ置かれてるページだけを物理メモリに連続してマッピングさせるというものだ。まあ、この辺の詳細は気が向いたらまた別に書くかもしれないが、詳細に立ち入るとそれだけで2、3個記事が書けるので、今回は大枠そんな感じの仕組みになってることさえ抑えて貰えばよいだろう。詳しく知りたければ「詳解Linuxカーネル」とかを読んでもらうのがいいんじゃないだろうか。とりあえず、このような仕組み上仮想メモリは物理メモリと同じサイズである必要はないし、使用領域を連続させる必要もない。

さて、ではプログラム実行時に私たちがいじっているメモリについてだが、まず Linux ではプロセス毎にそれぞれ仮想メモリ空間を作っており、その空間の中でもレイアウトを決めている。仮想メモリ空間のサイズは、アーキテクチャが扱える最大サイズが基本で、つまり 32bit アーキテクチャなら 2^32B = 4GB、64bit アーキテクチャなら 2^64B = 16EB となる [1]。ただ、この内カーネルの使用領域があるため、実際にユーザ空間で自由に使用できるのは x86 32bit では 3GB まで [2]、x86 64bit では通常 128TB まで (一部 64PB までいけるものもある) [3] となる。このユーザ空間の領域もある程度配置場所が決まっている。基本的には、まずプロセス管理用のデータや静的に確保されたデータ領域が置かれた後、それ以降が動的に管理されるメモリ領域となる。動的に管理される領域は中間に mmap と呼ばれるシステムコールによるメモリマッピング領域が置かれ、それより手前がヒープ領域、それ以降がスタック領域となる。よくある図で書くと以下のようになる:

プロセスのユーザ空間メモリレイアウト配置

ヒープ領域は sbrk というシステムコールにより program break を移動させることで使える領域が拡張され、動的なメモリオブジェクトが置かれる。スタックはサブルーチンの呼び出し時に stack pointer が移動することで拡張され、サブルーチンの制御情報が書かれる。メモリマッピング領域は mmap システムコールが呼び出された時に必要に応じて拡張され、ファイルのメモリへのマッピング、もしくは動的なメモリオブジェクトがページ単位で置かれる。glibc malloc がメモリ割り当てに使うのはこの内ヒープ領域とメモリマッピング領域になる。

glibc malloc は大雑把には、 malloc 時要求サイズに対する閾値で切り出し元の領域を変える。要求サイズが閾値以下であれば、そのサイズに合う切り出し領域をヒープ領域から見つけてきて返し、閾値より大きければ mmap を使ってメモリマッピング領域にページ単位で割り当てる。ヒープ領域が足りなければ、 sbrk システムコールによって program break を移動させる。 mmap での割り当てはページ単位になるので、あまりにも割り当てサイズが小さいとメモリ領域を無駄に消費してしまうことになる。なので、全て mmap で凌ぐのはメモリ容量が増えた現代でも割と愚策。では、逆になぜ全部ヒープ領域でやらないかだが、その前にざっくりヒープ領域の管理アルゴリズムの概要を見ていこう。

さて、サイズに合う切り出し領域をヒープ領域から見つけてきて返すというのは、言うのは簡単だが実際に実装する際はいくつかステップが必要だ。まず、どの領域が既に使用済みで、どこからどこまでが使用可能かを特定する必要がある。ただ、私たちは数個のレジスタに記録した情報だけからこれを探さないといけない。愚直にはこの特定作業は、使用箇所をメモっておいてその使用箇所を先頭から調べていけば良い。実際初期の glibc malloc はそんな感じのことをしていたらしい。ただ、現代はメモリはギガ単位が普通であり、メモリ割り当ての度にそんなことをしてるとプログラムの実行速度にかなり影響が出る。そこで近代では、ある程度のサイズ毎にリストを作り、そこにそのサイズ毎の空きブロックをぶら下げておきそれをメモリ割り当ての際は返し、返却されたらまたリストにぶら下げると言うことをしている。これによりわざわざ全ての使用箇所を線形探索する必要はなくなるわけだ。ただ、可能性のある全サイズでリストを作るのはそれはそれでメモリ管理的に無駄が大きい。特に再利用される可能性のあるブロックのサイズというのはある程度傾向があり、ある程度大きくなってくるとサイズはかなりばらけてくる。そこで、再利用される可能性の高いある程度小さいブロックはヒープ領域でリストに紐づけて管理し、ある程度大きいブロックは mmap で OS に要求して直接取ることで両方使用可能領域の線形探索を避けることができる。またこれは断片化の回避にもつながる。単純にヒープ領域を先頭から切り出して割り当て、いらなくなったら解放といったことをやっていると、メモリの使用可能領域はかなり穴ボコ状態になって、連続した領域のサイズが限られてくる。その為、メモリの空きは 1G あるのに、1kB の連続領域はない為割り当てができないといったことになりかねない。小さいサイズのブロックの割り当て領域をある程度決めて整理した割り当てができればこのような状況を比較的回避しやすくなる。これが、ヒープ領域とメモリマッピング領域が併用されている理由になる。ここら辺の詳細は、kosaki さんの malloc の旅というスライドが大変分かりやすい。参考にすると良いだろう。

mmap と無名マッピング

さて、glibc malloc がヒープ領域とメモリマッピング領域を併用して動的なメモリ管理を行なってることは分かった。問題はこの glibc malloc のメモリ管理を邪魔しない形で、新たにメモリ管理機構を載せるにはどうすればいいかだ。ヒープ領域を使ってしまうと、諸に glibc malloc のメモリ管理と色々衝突してしまうことになる。今回紹介する方法は、簡単にはヒープ領域はダメでもメモリマッピング領域で mmap から領域取得する分には glibc malloc の動きを阻害することがないので、 mmap で独自のヒープ領域を切り出してこようというものだ。その話に入る前に、 mmap の無名マッピングと呼ばれる機能についてもう少し詳しく見ておく。これは、glibc malloc の mmap による領域確保でも使われている機能になる。

mmap システムコールは基本的にファイルをメモリにマッピングすることを想定して作られたシステムコールだ。有名どころで言うと、共有ライブラリの読み込みが mmap により行われる。しかし、動的メモリ管理における需要を受けて、ファイルに紐づかないマッピング領域作成モード、 MAP_ANONYMOUS が導入されて以来こちらもかなり色々な場面で利用されるようになっている。 mmap は作成するマッピングに対して幾つかモードを指定できる。 MAP_ANONYMOUS、無名モードはそのモードの中の一つだ。glibc malloc が mmap でメモリ割り当てを行う際は、当然その領域はファイルには紐づかないので無名モードで領域が確保されることになる。

mmap システムコールは、以下の API を持つ [4]:

void *mmap(void addr, size_t length, int prot, int flags, int fd, off_t offset);

一つ目の addr はマッピングする領域のヒントとなるアドレスを受け取る。アドレスが NULL なら適当なアドレスを持ってくるし、 NULL でないならその周辺から切り出してくる。 length は領域のサイズになる。 prot、 flags は後述する。 fd は、マッピング元のファイルディスクリプタで、無名モードの場合は -1 を渡す。 offset はマッピング元ファイルのオフセットを指定でき、無名モードの場合は 0 を渡す。 flags では、マッピングモードのビット集合を指定する。詳細は、マニュアルを見てもらいたいが、今回扱いたいものだけ紹介しておくと、

MAP_PRIVATE: 他プロセスと共有しないマッピング領域を、遅延書き込み (copy-on-write) で作成する。プライベートモードで作成された領域は、 mmap 完了時は物理メモリには載らず、仮想メモリ上での予約のみがされた状態になる。そして、初回アクセス時ページフォールト例外を受けて初めて物理領域へのページ登録が起こる。なお、単に読み込みアクセスだけを行う場合は特殊な0埋め領域を参照するようになっており、書き込みアクセス時初めて専用の物理メモリスペースが確保される。これが遅延書き込みの機能になる。
MAP_ANONYMOUS: 無名モードを指定するフラグ。このモードの場合、ファイルには紐づかず、単なるメモリ領域として使用できる。
MAP_FIXED: addr 引数で指定されたアドレスについて、ヒントではなく正確にそのアドレスを始点とする領域を確保する。ただし、 addr 引数はページサイズできちんとアラインされてる必要があり、またアーキテクチャによっては他にも条件が科されることがあり移植性はあまりよくない。そのため、あまり使用は推奨されていない。

のようなフラグやその他色々が指定できる。 prot はマッピング領域の保護権限を指定する。アクセス権限を与えない PROT_NONE、もしくは以下による空でないビット集合を指定できる:

PROT_EXEC: 実行可能。バッファオーバーフローなどを利用してこの領域に意図しない書き込みをされたりすると、セキュリティホールの元となるのでこの権限を設定する領域の管理には注意が必要。
PROT_READ: 読み込み可能。
PROT_WRITE: 書き込み可能。

glibc malloc では、 MAP_ANONYMOUS|MAP_PRIVATE モードで、かつ PROT_READ|PROT_WRITE 権限の領域確保が使われている [5]。同じように無名モードで mmap で確保された領域を使えば、glibc malloc の管理機構に迷惑をかけることなく独自の動的なメモリ領域を確保できる。

ただ、課題もある。ヒープ領域は仮想メモリアドレスにおいては連続的であるため、それを利用したアドレス計算テクニックなどが使えるが、 mmap で随時メモリ領域をメモリマッピング領域に確保していく場合、常に連続的に領域を拡張できるとは限らない。なぜなら、glibc malloc などが確保した領域が間に挟まってくるかもしれないからだ。今回紹介するのは、この問題を PROT_NONE 権限でのメモリマッピングにより回避する方法だ。

PROT_NONE 権限で mmap を実行すると、アクセス権限を持たないメモリマッピング領域が確保される。これは、物理メモリへの参照を持たずアクセスするとエラーが起きる一見役に立たない機能に見えるが、あることに応用ができる。それは、仮想メモリアドレスの予約である。つまり、事前に PROT_NONE 権限である程度の仮想メモリ領域を mmap しておけば、その仮想メモリのアドレスは使用済みとなり、それ以降の mmap で使用されることはないというわけである。この予約は、 munmap しない限り解除されない。また、メモリの権限は mprotect システムコール、または mmap 時 MAP_FIXED モードを指定してそのアドレスへの上書きマッピングを行うことで更新できる。つまり、事前に PROT_NONE で膨大なメモリ領域を予約しておき、その後随時必要になったら mprotect で PROT_READ|PROT_WRITE 権限を付与した領域を増やしていくことで、program break 移動により拡張できるヒープ領域と同じような管理を行うことができるということだ。仮想メモリは 64bit 環境であれば物理メモリより通常かなり空間が大きいので、4分の1ぐらい予約しておいても支障はほとんどない。予約しても単にアドレスが他で使えなくなるだけで物理メモリに載るわけでもないし、残りの4分の3は自由に使えるわけで、例えば 64bit だと 32TB の仮想メモリ領域を予約領域として、残りの 96TB の仮想メモリ領域を他のメモリ管理機構が自由に使える。これで問題が出るサーバは普通ないだろう。これを利用することで、新たなヒープ領域を作るメモリ管理を2重に独立した領域で作ることができるというわけだ。

これは実は Go 言語の 64bit 向けのランタイムで使われてる手法で、これにより cgo などで glibc malloc との共存ができるようになっている。32bit でこの方法を使うと流石に少し支障が出てしまうのが難点なのと、Linux での実装とアーキテクチャのメモリ管理機構の仕組みに強く依存しているので移植性が悪いという問題はあるが、64bit のアーキテクチャで広く流通している x86 64、ARM64 ではこの手法が使え、Windowsでも Win API で似たような機能が搭載されているため大体の範囲で適用でき、しかも既存の仕組みをあまり壊さずそこまで複雑な手段を必要とせず使える点が有用だ。

実装してみる

実際に、簡単なアロケータを上の手法を使って Rust で実装してみる。まず、 mmap のラップ API を用意しておく:

mod sys {
    use std::{error::Error, ptr::NonNull};

    pub type AnyNonNull = NonNull<libc::c_void>;

    /// ページサイズを取得する。mmap で確保する領域はこのページサイズの倍数になってる必要がある。
    pub unsafe fn get_pagesize() -> Result<usize, Box<dyn Error>> {
        let pagesize = libc::sysconf(libc::_SC_PAGE_SIZE);
        if pagesize < 0 {
            Err(std::io::Error::last_os_error().into())
        } else {
            Ok(pagesize as usize)
        }
    }

    /// 仮想メモリ空間の一部を長さ分だけ予約する。
    pub unsafe fn reserve(len: usize) -> Result<AnyNonNull, Box<dyn Error>> {
        let ptr = libc::mmap(
            std::ptr::null_mut(),
            len,
            libc::PROT_NONE,
            libc::MAP_ANONYMOUS | libc::MAP_PRIVATE,
            -1,
            0
        );
        if ptr == libc::MAP_FAILED {
            Err(std::io::Error::last_os_error().into())
        } else {
            Ok(NonNull::new_unchecked(ptr))
        }
    }

    #[derive(PartialEq, Eq, PartialOrd, Ord, Clone, Copy, Debug)]
    pub enum CommitStrategy {
        Mprotect,
        MmapFixed,
    }

    /// 予約された領域の一部を使用できるようにする。
    pub unsafe fn commit(
        addr: AnyNonNull,
        len: usize,
        prefer_strategy: CommitStrategy,
    ) -> Result<CommitStrategy, Box<dyn Error>> {
        if prefer_strategy <= CommitStrategy::Mprotect {
            // mprotect は Linux 4.9 以上でないと使えない。
            let result = libc::mprotect(
                addr.as_ptr(),
                len,
                libc::PROT_READ | libc::PROT_WRITE,
            );
            if result == 0 {
                return Ok(CommitStrategy::Mprotect);
            }
        }

        // MAP_FIXED での上書きマッピングは本来非推奨。
        // ただ、mprotect が使えない環境は存在するのでフォールバックしておく。
        let ptr = libc::mmap(
            addr.as_ptr(),
            len,
            libc::PROT_READ | libc::PROT_WRITE,
            libc::MAP_ANONYMOUS | libc::MAP_PRIVATE | libc::MAP_FIXED,
            -1,
            0,
        );
        if ptr == libc::MAP_FAILED {
            Err(std::io::Error::last_os_error().into())
        } else {
            Ok(CommitStrategy::MmapFixed)
        }
    }

    #[allow(unused)]
    #[derive(PartialEq, Eq, PartialOrd, Ord, Clone, Copy, Debug)]
    pub enum DecommitStrategy {
        Mprotect,
        MmapFixed,
    }

    /// 予約された領域の一部の使用をやめる。予約されたままだが、物理メモリへのマッピングは解かれる。今回は使用しない。
    #[allow(unused)]
    pub unsafe fn decommit(
        addr: AnyNonNull,
        len: usize,
        prefer_strategy: DecommitStrategy
    ) -> Result<DecommitStrategy, Box<dyn Error>> {
        if prefer_strategy <= DecommitStrategy::Mprotect {
            let result = libc::mprotect(
                addr.as_ptr(),
                len,
                libc::PROT_NONE,
            );
            if result == 0 {
                return Ok(DecommitStrategy::Mprotect);
            }
        }

        let ptr = libc::mmap(
            addr.as_ptr(),
            len,
            libc::PROT_NONE,
            libc::MAP_ANONYMOUS | libc::MAP_PRIVATE | libc::MAP_FIXED,
            -1,
            0,
        );
        if ptr == libc::MAP_FAILED {
            Err(std::io::Error::last_os_error().into())
        } else {
            Ok(DecommitStrategy::MmapFixed)
        }
    }

    /// 仮想メモリ空間の一部を使用可能な状態で切り出す。
    pub unsafe fn alloc(len: usize) -> Result<AnyNonNull, Box<dyn Error>> {
        let ptr = libc::mmap(
            std::ptr::null_mut(),
            len,
            libc::PROT_READ | libc::PROT_WRITE,
            libc::MAP_ANONYMOUS | libc::MAP_PRIVATE,
            -1,
            0,
        );
        if ptr == libc::MAP_FAILED {
            Err(std::io::Error::last_os_error().into())
        } else {
            Ok(NonNull::new_unchecked(ptr))
        }
    }

    /// マッピング済みの領域のマッピングを解除する。新たに alloc / reserve で使用できるようになる。
    pub unsafe fn release(addr: AnyNonNull, len: usize) -> Result<(), Box<dyn Error>> {
        let result = libc::munmap(addr.as_ptr(), len);
        if result != 0 {
            Err(std::io::Error::last_os_error().into())
        } else {
            Ok(())
        }
    }
}

libc crate を通してシステムコールを今回使う範囲で使いやすいように呼んでる。ま、それぞれの詳細はシステムコールのマニュアルを読んでもらうとして、基本的な用途は以下の感じ:

get_pagesize: ページサイズを取得する API。reserve や commit、 alloc を呼ぶ際、指定する長さがページサイズでアラインされてる、つまりページサイズの倍数になっている必要があるため、その計算のために用意している。
reserve: 最初に glibc malloc のメモリ管理と独立した連続領域の予約を行うための API。アクセス権限はなく、物理メモリにもマッピングされないが指定した長さ分仮想メモリアドレスが予約された領域の先頭のポインタが返ってくる。
commit: 予約した領域を使う際に、物理メモリへのマッピングを行えるようにする API。 MAP_PRIVATE での予約なので、遅延書き込み、つまり書き込みが起こるまで実際には独自の物理メモリへのマッピングは起きないが、気分的にはメモリ割り当てのような立ち位置。なお、通常は mprotect を使うのだが、 mprotect は Linux 4.9 で導入された割と新参のシステムコールなので広く使われてる言語では移植性などを考え mmap の MAP_FIXED モードへのフォールバックが用意されているか、Go ではそっちしか使ってないみたいな状況。今回は、 mprotect が使えるならそっちを使う、使えないなら以降は MAP_FIXED を使うという小細工を施せるようにしている。なお、厳密には mprotect のエラーコードをちゃんとみて、対応してない場合のエラーコードのみフォールバックを発動させるのがお行儀が良い。
decommit: 今回は色々実装が面倒なので使用しないが、 commit した領域の物理メモリへのマッピングを解除する、つまり使わなくなった領域をメモリに載せるのをやめる API。呼んで直後にマッピングが解除されるとは限らないが、少なくともページの追い出しで優先的に追い出されるようにはなる。 commit と同じようなフォールバックを設けている。
alloc: 一旦予約するステップを踏まないで、直接メモリ領域を使用可能状態で確保する API。今回のアロケータ実装では、glibc malloc に少しならって、小さいブロックは連続領域に、ある程度大きいブロックはページサイズでアラインしてこの alloc で直接確保するようにする。
release: reserve や alloc で確保した領域を解放し、その仮想メモリアドレスを再度利用できるようにする API。今回は alloc で確保した領域のみに使用する。

これらの API を使って、簡単なシングルスレッドのみ対応のアロケータを作ってみる。今回実装するアロケータの概要は以下のようになる:

1kB 以下のブロックは連続領域に確保しサイズのクラス毎にリストで管理、それ以外のブロックは alloc、 release で管理する。
ブロックにはヘッダを付け、連続領域に確保した場合はブロックサイズのクラス、それ以外の場合はブロックサイズを持っておく。

まず幾つかパラメータを宣言しておく:

const MAX_HEAP_SIZE: usize = 2 << 40;
const SUBHEAP_COUNT: usize = 7;

const fn block_size_of_subheap(class_of_subheap: usize) -> usize {
    2 << (class_of_subheap + 3)
}

const MAX_BLOCK_SIZE: usize = block_size_of_subheap(SUBHEAP_COUNT - 1);

/// * `alignment` - A power of 2.
const fn aligned_size(original: usize, alignment: usize) -> usize {
    let mask = alignment - 1;
    original + (original.reverse_bits() & mask)
}

MAX_HEAP_SIZE は今回はお遊びなので適当に大きな値を設定している。プロダクションに載せる際は、ちゃんと物理メモリの上限を取ってきてそこから数値を決めるのがいいんじゃないだろうか。 SUBHEAP_COUNT はサイズのクラス分けの数を表している。流石に全てのサイズに対してフリーリストを作るのは色々無駄なので、通常サイズをクラス分けしてある程度無駄が生じるのを許容してフィットするクラスの最大サイズで領域確保が行われる。今回もそれに倣い、ブロックサイズ $m$ に対して $2^{(c_m - 1)} < m \leq 2^{c_m}$ を満たす $c_m$ を $m$ のクラスと考え、 $2^{c_m}$ サイズのブロックとして確保する。ここら辺は、例えば Go だと 64 個ぐらいクラスがあり、クラス分けももう少し工夫してある。サイズからのクラスの特定に要する時間とよく使われるサイズ種別への対応のバランスを取るのが大事。 block_size_of_subheap はクラスの最大ブロックサイズを返す。 MAX_BLOCK_SIZE は連続領域に確保されるブロックの最大サイズとなる。 aligned_size はユーティリティで、 original <= x * alignment となる最小の x を計算する。主にページサイズの倍数となるようサイズ調節するのに使用する。

次にアロケータ用のデータ構造を定義する:

pub struct Allocator {
    // immutable
    pagesize: usize,
    heap_end: sys::AnyNonNull,

    // mutable
    free_lists: [*mut FreeHeader; SUBHEAP_COUNT],
    active_heap_end: sys::AnyNonNull,
    commited_heap_end: sys::AnyNonNull,

    prefer_commit_strategy: sys::CommitStrategy,
}

struct Header {
    size_or_class_of_subheap: usize,
}

struct FreeHeader {
    #[allow(unused)]
    header: Header,
    next: *mut FreeHeader,
}

impl Allocator {
    pub unsafe fn init() -> Result<Self, Box<dyn Error>> {
        let pagesize = sys::get_pagesize()?;
        assert!(MAX_HEAP_SIZE % pagesize == 0);

        let heap_begin = sys::reserve(MAX_HEAP_SIZE)?;
        let heap_end = NonNull::new_unchecked(heap_begin.as_ptr().add(MAX_HEAP_SIZE));
        let free_lists = [std::ptr::null_mut(); SUBHEAP_COUNT];

        Ok(Self {
            pagesize,
            heap_end,
            free_lists,
            active_heap_end: heap_begin,
            commited_heap_end: heap_begin,
            prefer_commit_strategy: sys::CommitStrategy::Mprotect,
        })
    }

    ...
}

アロケータは主に、フリーブロックのリストと、連続領域の使用済み地点を持つ。

free_lists がフリーブロックのリストで、 free されたブロックはここに追加され、次回の alloc で再利用される。リストは、生ポインタ使った単方向リストで実装している。この辺は、Rust 標準アロケータに頼らないで、かつメモリレイアウトを簡潔にするため。

active_heap_end は現在使用している領域の最後を表す。この地点からなら新たにブロック用に切り出しが可能。ただ、 active_heap_end はページサイズでアラインされてるとは限らないので、実際に commit でアクセス権限をつけてる領域とはズレてる可能性がある。 commit が完了してる地点を表すのが commit_heap_end。ブロック用に切り出す領域がまだコミット済みじゃない領域まで必要とする場合は、まずその領域分ページサイズアラインされた領域を commit し、その後使用する分だけ切り出すことになる。

アロケータ初期化の時点では、まず連続領域用の仮想メモリアドレスの予約が走り、空のフリーリストと空の連続領域からスタートとなる。その後の割り当て alloc と解放 free の実装は以下のようになる:

impl Allocator {
    pub unsafe fn alloc<T: Sized>(&mut self) -> Result<NonNull<T>, Box<dyn Error>> {
        self.alloc_by_size(size_of::<T>())
    }

    pub unsafe fn alloc_by_size<T>(&mut self, len: usize) -> Result<NonNull<T>, Box<dyn Error>> {
        if len <= MAX_BLOCK_SIZE {
            for class_of_subheap in 0..SUBHEAP_COUNT {
                if len <= block_size_of_subheap(class_of_subheap) {
                    return self.alloc_on_subheap(class_of_subheap);
                }
            }
            self.alloc_on_subheap(SUBHEAP_COUNT - 1)
        } else {
            self.alloc_on_external(len)
        }
    }

    pub unsafe fn free<T>(&mut self, ptr: NonNull<T>) -> Result<(), Box<dyn Error>> {
        let allocated_ptr = (ptr.as_ptr() as *mut libc::c_void)
            .offset(- (size_of::<Header>() as isize));
        let allocated_ptr = NonNull::new_unchecked(allocated_ptr as *mut Header);

        let size_or_class_of_subheap = allocated_ptr.as_ref().size_or_class_of_subheap;
        if size_or_class_of_subheap <= MAX_BLOCK_SIZE {
            let class_of_subheap = size_or_class_of_subheap;
            self.free_on_subheap(allocated_ptr, class_of_subheap)
        } else {
            let size = size_or_class_of_subheap;
            self.free_on_external(allocated_ptr, size)
        }
    }
}

基本的にどちらもブロックサイズが連続領域のブロックの最大サイズ以下かで分岐し、それぞれの処理を行う。連続領域以外での処理の方が簡単なので、まずそっちを見ておく:

impl Allocator {
    ...

    unsafe fn alloc_on_external<T>(&mut self, len: usize) -> Result<NonNull<T>, Box<dyn Error>> {
        let allocated_size = aligned_size(len + size_of::<Header>(), self.pagesize);
        let mut allocated_ptr: NonNull<Header> = sys::alloc(allocated_size)?.cast();
        *allocated_ptr.as_mut() = Header {
            size_or_class_of_subheap: allocated_size,
        };
        Ok(allocated_ptr.cast())
    }

    unsafe fn free_on_external(&mut self, addr: NonNull<Header>, size: usize) -> Result<(), Box<dyn Error>> {
        sys::release(addr.cast(), size)
    }

    ...
}

ヘッダつけてページアラインしたサイズの領域を sys::alloc で確保して返し、ヘッダからサイズ特定して sys::release で解放してるだけ。ま、こっちはいいだろう。連続領域での確保の方は以下のようになる:

impl Allocator {
    ...

    unsafe fn alloc_on_subheap<T>(&mut self, class_of_subheap: usize) -> Result<NonNull<T>, Box<dyn Error>> {
        match NonNull::new(self.free_lists[class_of_subheap]) {
            None => {
                let allocated_ptr = self.extend_active_heap_end(class_of_subheap)?;
                let allocated_ptr: NonNull<libc::c_void> = allocated_ptr.cast();
                Ok(NonNull::new_unchecked(allocated_ptr.as_ptr().add(size_of::<Header>()) as *mut T))
            }
            Some(free_ptr) => {
                self.free_lists[class_of_subheap] = free_ptr.as_ref().next;
                let used_ptr: NonNull<libc::c_void> = free_ptr.cast();
                Ok(NonNull::new_unchecked(used_ptr.as_ptr().add(size_of::<Header>()) as *mut T))
            }
        }
    }

    unsafe fn free_on_subheap(&mut self, addr: NonNull<Header>, class_of_subheap: usize) -> Result<(), Box<dyn Error>> {
        let mut addr: NonNull<FreeHeader> = addr.cast();
        addr.as_mut().next = self.free_lists[class_of_subheap];
        self.free_lists[class_of_subheap] = addr.as_ptr();
        Ok(())
    }

    ...
}

こっちは、クラスのフリーリストに再利用可能なブロックがあればそれを使い、なければ使用可能領域を必要なだけ広げて切り出すのが割り当てになり、フリーリストに単に繋げるのが開放になる。更新処理でのロックなどは取ってないので、シングルスレッド専用。マルチスレッド対応する際は、排他処理以外にも色々考えるべきことがあるので、今回は考えないことにしておく。最後に使用可能領域の拡張は、以下のようになる:

impl Allocator {
    ...

    unsafe fn extend_active_heap_end(&mut self, class_of_subheap: usize) -> Result<NonNull<Header>, Box<dyn Error>> {
        let allocated_size = size_of::<Header>() + block_size_of_subheap(class_of_subheap);
        let new_active_heap_end = NonNull::new_unchecked(self.active_heap_end.as_ptr().add(allocated_size));
        if self.heap_end < new_active_heap_end {
            return Err(format!("Failed to extend heap size.").into());
        }

        if self.commited_heap_end < new_active_heap_end {
            let committed_size = aligned_size(
                new_active_heap_end.as_ptr().offset_from(self.active_heap_end.as_ptr()) as usize,
                self.pagesize,
            );
            self.prefer_commit_strategy = sys::commit(self.commited_heap_end, committed_size, self.prefer_commit_strategy)?;
            self.commited_heap_end = NonNull::new_unchecked(self.commited_heap_end.as_ptr().add(committed_size));
        }

        let mut allocated_ptr: NonNull<Header> = self.active_heap_end.cast();
        self.active_heap_end = new_active_heap_end;

        *allocated_ptr.as_mut() = Header {
            size_or_class_of_subheap: class_of_subheap,
        };
        Ok(allocated_ptr)
    }
}

まずヘッダ付きの領域サイズを計算し、コミット済みの領域が足りなければまず追加のコミットを行う。その後、使用可能領域を広げその領域をブロック用の領域として返す。こんな感じで glibc malloc と併用可能な自前アロケータを実装できる。全体のコードは、https://github.com/mizunashi-mana/sample-alloc-by-freelist においておいた。今回の例だとそもそも連続領域は実は必要ないので、あくまで参考用という感じではある。

まとめ

というわけで、 mmap の MAP_PRIVATE|MAP_ANONYMOUS モードを利用した glibc malloc と併用可能な動的メモリ管理の実装方法について紹介した。仮想メモリ空間が少し小さい 32bit 環境では別の方法を考えた方がいいだろうが、x86 64、ARM64 環境の Linux であればこの方法で問題は起きないだろう。もちろん、連続空間がそもそも必要ないアロケーションアルゴリズムも世の中には色々あるので、その際はアドレスの予約までしないで mmap で適宜領域を広げていっても良い。言語のランタイムを独自で作る場合はメモリ配置を工夫するだけでパフォーマンスが強く改善する場合もあるし、glibc malloc はメトリクスが少ないので独自にメトリクスを仕込みたい場合もある。そういった場合にアロケータを自作することは、よくあるだろう。その際にこの手法が役に立てば幸いだ。

これまであまり malloc の裏側がどうなってるのかなどあまり気にしたことなかったし、OS が頑張ってどうにかしてくれてるだろうぐらいに考えていたので、結構中身がデータ構造による工夫でどうにかなっていることが知れてよかった。おかげで動的メモリ管理については結構解像度上がった感がある。この辺は普段のプログラミングとか GC 作りとかにも応用していきたいなという感じ。ま、この辺最大限頑張ろうと思うとアーキテクチャ毎に工夫が必要になり、結構泥臭い部分も多いが。では、今回はこれで。

[1]	正確には 16EB まで仮想メモリアドレスとして使える 64bit アーキテクチャは稀で、大体は 48bit、つまり 256TB ぐらいまでが限界になる。これは 64bit フルサポートは実益がないのに対して、アドレス変換テーブルの保存が大変だから。まあ、ただ 256TB までのサポートだと最近微妙になってきつつあったので、57bit、128PB サポートのものも出てきつつあるようだ。

[2]	https://elinux.org/images/b/b0/Introduction_to_Memory_Management_in_Linux.pdf

[3]	https://www.kernel.org/doc/html/v5.8/x86/x86_64/mm.html

[4]	https://www.man7.org/linux/man-pages/man2/mmap.2.html

[5]	https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=d0bbbf371048ee8aa8a30c03b189cb268b8ad9e4;hb=HEAD#l2420

Systemd ユニットのセキュリティスコアを改善する

2023-08-06T14:25:05+09:00

systemd は Linux の標準的なシステム・サービスマネージャで、sysvinit の代替の init プロセスとなることを目指して開発されたソフトウェアである。長らく色々論争が行われ、紆余曲折はあったものの、現在ではほとんどの Linux ディストリビューションが標準的に init として採用している。SysV のサービスが秘伝の起動スクリプトにより管理されてきたのに対して、systemd ではサービスを記述するユニットファイルによりサービスを管理する。黎明期は systemd の方は様子見で、SysV 用の起動スクリプトだけを提供するプロジェクトも多かったが、現在は systemd ユニットを標準的に提供するプロジェクトも増えている。

さて、サービスを管理する上で重要なことの一つがセキュリティだ。サービスは基本的に長期間動くプロセスで、権限も大きく、他のサービスとの連携も行われる。そのため、外部からの攻撃にも晒されやすく、セキュリティホールにもなりやすい。もちろん、サービスコードそのものが万全なセキュリティを搭載しているのも重要だが、万全のセキュリティというものは存在しないため、サービスマネージャにおいてもあるサービスへの攻撃の防御と影響範囲の最小化を事前に行っておくのが良い。systemd はそのための機能をいくつか提供している。今回は、その機能を使用したユニットのセキュリティ改善方法を紹介する。

systemd によるセキュリティスコア

systemd にはセキュリティ機能の解析と、スコア評価を行う機能が提供されている:

$ systemd-analyze security systemd-resolved
NAME                                                        DESCRIPTION                                                                                         EXPOSURE
✓ SystemCallFilter=~@swap                                     System call allow list defined for service, and @swap is not included
✗ SystemCallFilter=~@resources                                System call allow list defined for service, and @resources is included (e.g. ioprio_set is allowed)      0.2
✓ SystemCallFilter=~@reboot                                   System call allow list defined for service, and @reboot is not included
✓ SystemCallFilter=~@raw-io                                   System call allow list defined for service, and @raw-io is not included
✗ SystemCallFilter=~@privileged                               System call allow list defined for service, and @privileged is included (e.g. chown is allowed)          0.2
...
✗ UMask=                                                      Files created by service are world-readable by default                                                   0.1

→ Overall exposure level for systemd-resolved.service: 2.1 OK 🙂

ロード済みのユニットに対して、 systemd-analyze security <ユニット名> の形で実行すると、セキュリティ設定の有効可否と設定レベルを出してくれる。レベルは 0 - 10 の間でつけられ、レベルが小さいほどセキュリティ機能の有効度が高く、レベルが大きいほど改善の余地があるということになる。

基本的にはこれを見ながら、バツマークがついてるところの中でスコアが高いものから対応していくのが良い。もちろん、何も考えずに設定を入れてもだめで、サービスコードとの兼ね合いを見ながら必要だと思われる設定だけをつけていけば良い。では、具体的にそれぞれ指摘される設定をそれぞれ見ていこう。

systemd のセキュリティ機能

systemd のセキュリティ機能は、概ね3種類ある:

サンドボックス化: サービスのプロセス専用の隔離リソースを作り、影響が他のサービスや関係ないリソースに及ばないようにする機能。
制限: サービスに不要なリソースへのアクセスを制限することで、影響を最低限に抑える機能。
デフォルト挙動改善: 影響が大きい機能のデフォルトの挙動を、セキュリティ的に望ましい方向に改善する機能。

基本的に外部からの攻撃というものは、典型的なパターンがある:

意図しないコード実行やリソース作成を行う
情報を集め、攻撃者に送信し、さらに意図しないコード実行やリソース作成を行う
マルウェアやランサムウェアを埋め込み、外部へのさらなる攻撃への中継点にしたり、アクセスできるリソースの改変を行い不正な取引の材料にしたりする

逆に言えば、意図しないコード実行やリソース作成をしても情報を集められない、攻撃者に情報を送れないといった状況を作ったり、アクセスできるリソースを制限することで攻撃の影響範囲はかなり抑えられるということだ。つまり、サンドボックス化により他のリソースから隔離し、さらにできることを必要な範囲だけに制限することにより、典型的な攻撃は防御できる。もちろん、サービス自体やそこからアクセスが必要なリソースに脆弱性がありそれにより十分広い影響が出ることはあるため、サービスマネージャのセキュリティ機能だけに頼るのは問題だが、サービスのセキュリティに関して強力な補佐とはなるだろう。

では、それぞれ詳細を見ていく。まず、サンドボックス機能のスコアが高いものから:

PrivateNetwork

専用のネットワーク名前空間を作り、それを使う。このオプションを有効にすると、ネットワークアクセスが内外問わず完全に遮断される。外部ネットワークへのアクセスなどを特にしないサービスでは、有効にしとくと良いだろう。これを有効化しておけば、ほとんどの攻撃から防御できるだろう。ただ、ネットワークアクセス自体は必要なサービスも多いことから、このオプションを有効にできるサービスはかなり限られるだろう。

マニュアル: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#PrivateNetwork=

PrivateDevices

専用の /dev マウンティングを行い、基本的な擬似デバイスだけを見えるようにする。これにより、物理デバイスやシステムデバイスなどは見えなくなり、攻撃を受けても取得できる情報が限定される。物理デバイスやシステムデバイスにアクセスするようなサービスは限られる為、基本的には有効にしておくのが良いだろう。

マニュアル: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#PrivateDevices=

PrivateMounts

マウント名前空間が専用に作成され、サービスが作成したマウントポイントがホストからは見えなくなる。これによりサービスが攻撃を受けて不正なマウントポイントを作成してしまったとしても、他のサービスには全く影響が出なくなるし、逆に他のサービスからサービスのマウントポイントが攻撃されることもなくなる。基本的に、そもそもマウントポイントを作成されるサービスは限られるため、マウント権限自体を無効化しとくのがいいだろうが、その上でだったり、他のサービスとマウントポイントを共有することがない場合は、このオプションを有効化しておくのがいいだろう。

マニュアル: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#PrivateMounts=

PrivateTmp

専用の一時ディレクトリ用ファイル名前空間を作り、それを使う。これにより、他のプロセスの一時ファイルを一時ディレクトリ経由で弄ることができなくなる。一時ディレクトリを利用したサービスロジックは、TOCTOU に関する問題を利用したセキュリティホールを持ちやすい為、攻撃対象になりやすい。また、他プロセスと一時ディレクトリを共有する必要は通常ないため、基本的には有効化しておくのが良いだろう。

マニュアル: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#PrivateTmp=

PrivateUsers

サービス専用のユーザ名前空間を作り、root ユーザと実行ユーザだけがそのままマッピングし、他のユーザは nobody ユーザとしてマッピングした上で使う。これにより、リソースに対して紐づくユーザ情報が取得できないようになる。他ユーザと連携することがなければ、基本的に有効化しておくのがいいだろう。

マニュアル: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#PrivateUsers=

KeyringMode

セッションキーリングの設定制御を行う。 KeyringMode=inherit を指定する場合は、特別なキーリング設定は行わず、カーネルのデフォルト動作が適用される。 KeyringMode=private を指定する場合は、専用のセッションキーリングが作成され、どのユーザキーリングにもリンクされない。 KeyringMode=shared を指定する場合は、 private と同様専用のセッションキーリングが発行されるが、実行ユーザのキーリングにはリンクされる。デフォルトでは、 private が指定されており、基本的にはここから変更する必要はないだろう。キーリングで管理される認証情報を他のサービスと共有することは、他のサービスが攻撃を受けた時重大な被害が及びかねない。基本的には他のサービスと切り離しておくべきだろう。

マニュアル: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#KeyringMode=

RootDirectory / RootImage

RootDirectory は chroot を使ってサービスのルートディレクトリを指定したディレクトリに変えることで、そのディレクトリより上位のディレクトリへのアクセスをファイルシステム上できなくする。RootImage はさらに、ディレクトリの代わりにデバイスノードを指定することでそのデバイスノードの隔離されたファイルシステムを使うようにする。

ファイルは重要なリソースで、それ故に攻撃対象になりやすい。ディレクトリトラバーサルなどの脆弱性をサービスコードが持っていると、他サービスやシステムリソースなどへのアクセスもできてしまい、それにより重大な結果をもたらす恐れもある。これを避ける根本的な手段は、そもそも他サービスやシステムリソースにファイルシステム上辿り着けないようにするのが一番良い。その時に出番となるオプション。ただ、流石にルートディレクトリを変えてしまうと、動的ライブラリの解決なども出来なくなるので、セキュリティ的に強力な反面運用は難しい。まあ、可能なら設定しておくぐらいでいいだろう。

マニュアル:

次に制限のための機能を見ていく:

User / DynamicUser

このオプションは使ってる人も多いだろう。User オプションはサービスの実行ユーザを指定するオプション。DynamicUser も実行ユーザをルートユーザと異なるユーザにできるオプションで、こちらは有効にすると実行のたびに専用のユーザとグループを動的に作成して割り当ててくれる。

さて、systemd のサービスはデフォルトではルートユーザで動く。ルートユーザは様々な特権的権限を持っており、全てのディレクトリへアクセスできるし改変もできる。権限を他のユーザに付与したりすることも可能だ。逆に言えばこのユーザが乗っ取られると大変なことになる。またルートユーザの証跡は追いにくく、いつ何をそのサービスがしたのかも分からなくなりがちだ。そこで、サービスの実行専用ユーザを作成し、実行に必要な最小限の権限だけを与えて実行ユーザとすることで、そのサービスが攻撃者に乗っ取られても影響範囲を抑えることができ、また何をされたかの証跡が追いやすくなる。基本的にどちらかのオプションを使うことで、ルートユーザでのサービス実行は避けるのが良いだろう。

マニュアル:

RestrictNamespaces

アクセス可能な名前空間機能の種類を指定する。せっかくサンドボックス機能で名前空間を分離しても、他の名前空間が触れては意味がない。そこでこのオプションを併用することで、隔離をより強固にできる。名前空間管理機能に触るサービスは限られるだろうから、基本的には RestrictNamespaces=true で全ての種類について有効化しておくのが良いだろう。もし、名前空間管理機能にアクセスする場合も、必要な種類のみホワイトリスト形式で除外しておくのが良いだろう。

マニュアル:

RestrictAddressFamilies=~AF_(INET|INET6)

IPv4 / IPv6 ソケットの作成を制限する。基本的に攻撃に持続性を持たせるには、リモートアクセスが必須となる。そうなると、攻撃元でリモートアクセス用のエンドポイントを作るか、攻撃先にリモートアクセス用のエンドポイントを作るかしかない。その一方が封じられることは、セキュリティの向上につながるだろう。もしサービスが IP ソケット作成を必要としないなら、指定しておくのが良いだろう。

マニュアル:

ProtectControlGroups

cgroup を読み込み専用にし、書き込みを無効化する。cgroup を変更できると、他サービスからリソースを奪ったり、保護機能を無効化したりできる。基本的なコンテナ管理サービス以外で cgroup の書き込み権限は必要ないだろうから、指定しておくのがいいだろう。

マニュアル: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectControlGroups=

ProtectKernelModules

カーネルモジュールの読み込みを無効化する。カーネルモジュールによるカーネル機能の拡張は、サービス提供者だけでなく、攻撃者にとっても強力な助っ人となり得る。カーネルモジュールの読み込みが必要なサービスは限られるだろうから、基本的には有効化しておくのがいいだろう。

マニュアル: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectKernelModules=

ProtectKernelTunables

カーネル変数を読み込み専用にし、書き込みを無効化する。カーネル変数の変更は、カーネルの重要な保護機能を無効化したり、攻撃に利用できるような機能の有効化に繋げられかねない。また、基本的に実行時に変更を必要とすることはないため、有効化しておくのが良いだろう。

マニュアル: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectKernelTunables=

ProtectKernelLogs

カーネルログのリングバッファを読み書きする権限を無効化する。カーネルログを取得すると、ホストの情報を取得し、さらなる攻撃に繋げられかねない。基本的にカーネルログを読み書きするサービスは限られるだろうから、有効化しておくのが良いだろう。

マニュアル: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectKernelLogs=

ProtectClock

サービスが、ハードウェアクロック、システムクロックの変更をできなくするオプション。時間に関する判定をバグらせるとセキュリティホールにつながることも多い。特にタイムスタンプを任意に固定できれば、攻撃の幅が広がることもある。まあ基本的にクロックを変更するサービスはあまりないと思うし、攻撃手段として利用できなくしておくのに越したことはないだろうから、基本的には有効にしておくのが良いだろう。

マニュアル: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectClock=

ProtectHome

サービスから、 /home、 /root、 /run/user を見えなくする、または読み込み専用にするオプション。 ProtectHome=true と指定した場合、これらのディレクトリをサービス用の名前空間から隔離し、サービスから見えないようにする。 ProtectHome=read-only と指定した場合、これらのディレクトリを読み込み専用でマウントする。 ProtectHome=tmpfs と指定した場合、一時ディレクトリとしてこれらのディレクトリを読み込み専用で作り、サービスからは実際のディレクトリではなく一時ディレクトリの方を参照するようにする。基本的にはサービスが実行時に書き込みを行うのは、実行時ディレクトリ、状態ディレクトリ、またはキャッシュディレクトリであるべきであり、ホームディレクトリを参照するべきではない。基本的に多くのサービスは、実行時のデータディレクトリを指定できる場合が多い。それらの機能を通してホームディレクトリ以外を実行時ディレクトリとして選べるなら、書き込み可能な範囲を押さえ、他のユーザへの影響をなくすためにも有効化しておくのが良いだろう。なお、たまにホームディレクトリが全く存在しないと立ち上がらないサービスもあるため、その場合は一時ディレクトリによるマウントを指定しておくのが良いだろう。

マニュアル: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectHome=

ProtectSystem

システムディレクトリを読み込み専用でマウントし、書き込みを禁止するオプション。 ProtectSystem=true の場合 /usr とブートローダのディレクトリが、 ProtectSystem=full の場合さらに /etc ディレクトリが読み込み専用でマウントされる。 ProtectSystem=strict の場合は、API 用の /dev、 /proc、 /sys 以外のディレクトリが全て読み込み専用でマウントされる。これは後述する ReadWritePaths で例外を設定できる。また、読み込み専用でマウントされる対象はあくまでホストのディレクトリであり、 PrivateTmp などのサンドボックス機能で生成されるサービス専用のマウントポイントは書き込み可能のまま維持される。ウイルスをインストールするにしろ、他のサービスを攻撃するにしろ、システムディレクトリに書き込みを行うことは攻撃の基本的な手段だ。よって、書き込み可能なディレクトリを少なくしておくことは、重要なセキュリティ施策になる。また、書き込みが起こるディレクトリを把握しておくことは、各サービスが攻撃を受けた時の影響範囲を把握する上で重要だ。基本的には有効にしておき、例外を ReadWritePaths にホワイトリスト形式で追加するのが良いだろう。

マニュアル: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectSystem=

NoNewPrivileges

プロセスが execve を通して新たに特権を取得することを無効化する。これは、プロセスが特権昇格をできないようにする基本的な方法だ。これにより、攻撃による被害拡大を抑えることができる場合が多い。基本的には指定しておくのが良いだろう。

マニュアル: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#NoNewPrivileges=

ProtectProc

プロセスのメタ情報の可視、不可視を制御する。 ProtectProc=noaccess を指定する場合、他のプロセスの情報を /proc ディレクトリから取得できなくなる。 ProtectProc=invisible を指定する場合、実行ユーザではない他のユーザにより実行されているプロセスの情報は隠され、取得できないようになる。 ProtectProc=ptraceable を指定する場合、 ptrace による他プロセス情報の取得を制限する。 ProtectProc=default を指定する場合、プロセスメタ情報へのアクセス、可視性は特に制限されない。プロセス情報取得は、攻撃者にどのようなサービスが動いているか知る機会を与え、さらなる被害拡大を招きかねない。基本的に他のサービスのプロセス情報を取得する必要があるサービスは限られるだろうから、 ProtectProc=invisible または ProtectProc=noaccess を指定しておくのが良いだろう。

マニュアル: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectProc=

RestrictSUIDSGID

SUID、SGID 権限をファイルまたはディレクトリに設定するのを拒否する。SUID、SGID は、サービス自体に課せられた特権の制約を無視して、攻撃者が特権を行使するかなり大きなセキュリティホールとなりうる。実行時に SUID、SGID 権限を指定するサービスはほぼないだろうし、あったとしたらそれは代替案を探すべきだろう。なので、基本的には有効化しておくのが良いだろう。

マニュアル: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#RestrictSUIDSGID=

RestrictAddressFamilies=~AF_PACKET

デバイスドライバレベルでの生パケット送受信用ソケット作成を制限する。生パケットレベルでの送受信は攻撃者が既存のファイアウォールルールなどを回避しながら、データ送受信を行う手段となりうる。生パケット送受信用ソケット作成を行うサービスはかなり限られるだろうから、指定しておくのが良い。

マニュアル:

SystemCallArchitectures

後述の SystemCallFilter でフィルタするシステムコールの対象アーキテクチャを指定する。ネイティブのアーキテクチャを対象とする場合は、 SystemCallArchitectures=native と指定する。このオプションを指定しないと、 SystemCallFilter が効かない為、基本的に指定しておくべきだろう。また、ネイティブアーキテクチャ以外を指定する必要が生じる場面は普通なく、下手に範囲を広げるとフィルタリングを回避する穴を作りかねない。 SystemCallArchitectures=native の指定を基本的に入れておくのがいいだろう。

マニュアル: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#SystemCallArchitectures=

SystemCallFilter=~@debug

システムコールの内、デバッグ、パフォーマンス計測機能に関するものの使用を禁じるオプション。もしこれらのシステムコールが呼び出された場合、サービスは SIGSYS シグナルと共に終了することになる。対象のシステムコール一覧は、 systemd-analyze syscall-filter @debug で見ることができる。 ptrace、 perf_event_open などが対象。これらのシステムコールは、サービスの情報を詳細に取得し、攻撃者が被害を拡大させるための分析手段として使用できる。基本的に入れておくのが良いだろう。もし、デバッグ機能が必要だとしても、必要なシステムコールだけホワイトリストで追加し直すのが良い。具体的には、

SystemCallFilter=~@debug
SystemCallFilter=ptrace

と書くことで、デバッグ機能のうち、 ptrace システムコールだけを有効化することができる。必要なくなったら無効化しておくのが良いだろう。

マニュアル:

SystemCallFilter=~@swap

システムコールの内、スワップデバイスの有効化、無効化に関するものの使用を禁じるオプション。対象のシステムコール一覧は、 systemd-analyze syscall-filter @swap で見ることができる。主に swapon、 swapoff の2つが対象。スワップデバイスの無効化は、メモリ不足を生じさせ、全体的なシステムの不具合を生じさせる手段になる。ファイアウォールなどがメモリ不足で落ちれば、ホストの保護は大幅に低下するだろう。スワップデバイス制御を行うサービスはかなり限られるだろうから、基本的に入れておくのが良いだろう。

マニュアル:

SystemCallFilter=~@clock

システムコールのうち、システムクロックの制御に関するものの使用を禁じるオプション。対象のシステムコール一覧は、 systemd-analyze syscall-filter @clock で見ることができる。主に adjtimex、 settimeofday などが対象。時間に関する判定をバグらせるとセキュリティホールにつながることも多い。クロック制御を行うサービスはかなり限られるだろうから、基本的に入れておくのが良いだろう。

マニュアル:

SystemCallFilter=~@mount

システムコールのうち、ファイルシステムのマウント制御に関するものの使用を禁じるオプション。対象のシステムコール一覧は、 systemd-analyze syscall-filter @mount で見ることができる。主に mount、 chroot などが対象。ファイルシステムのマウントは、ファイルスプーフィングの手段に使える。マウント制御を行うサービスはかなり限られるだろうから、基本的に入れておくのが良いだろう。

マニュアル:

SystemCallFilter=~@module

システムコールのうち、カーネルモジュールのロード制御に関するものの使用を禁じるオプション。対象のシステムコール一覧は、 systemd-analyze syscall-filter @module で見ることができる。主に init_module、 delete_module などが対象。カーネルモジュールのロードを開放することは、攻撃者に被害拡大の手段を与えることも多い。カーネルモジュールのロードが必要なサービスはかなり限られるだろうから、基本的に入れておくのが良いだろう。

マニュアル:

SystemCallFilter=~@raw-io

システムコールのうち、低レベルの I/O ポートにアクセスするものの使用を禁じるオプション。対象のシステムコール一覧は、 systemd-analyze syscall-filter @raw-io で見ることができる。主に ioperm、 pciconfig_read などが対象。通常は他のシステムコールで代用可能で、カーネルがよしなにやってくれるものを使う方が良い。わざわざ使わないものの使用を解禁し、攻撃者に情報を取得する手段を提供する必要はないため、基本的に入れておくのが良いだろう。

マニュアル:

SystemCallFilter=~@reboot

システムコールのうち、再起動に関するものの使用を禁じるオプション。対象のシステムコール一覧は、 systemd-analyze syscall-filter @reboot で見ることができる。主に reboot、 kexec_load などが対象。再起動を攻撃者に許すと、カーネルモジュールの読み込みをより柔軟にできるようにしたり、再起動直後のセキュリティ保護が万全でない状態を攻撃対象にされかねない。再起動を行うサービスはかなり限られるだろうから、基本的に入れておくのが良いだろう。

マニュアル:

IPAddressAllow / IPAddressDeny

IP パケットの送受信において、許可するアドレス、拒否するアドレスを指定する。IPv4、IPv6 アドレスを、直接またはレンジで指定できる。 IPAddressAllow が優先となる。特別な識別子がいくつか用意されており、

any は 0.0.0.0/0 ::/0 のエイリアス
localhost は 127.0.0.0/8 ::1/128 のエイリアス
link-local は 169.254.0.0/16 fe80::/64 のエイリアス
multicast は 224.0.0.0/4 ff00::/8 のエイリアス

としてそれぞれ機能する。ホワイトリストとして使う際は、 IPAddressAllow にリストを指定し、 IPAddressDeny=any も合わせて指定する。ブラックリストの場合は、 IPAddressDeny だけ指定する。使うネットワークが限られているサービスについては、わざわざサービス側に IP フィルタの仕組みを用意しなくても、この機能を使うことでフィルタリングが可能だ。また、攻撃に持続性を持たせるためには、基本的にネットワーク通信は必須であり、その送受信を封じることは強力なセキュリティ保護となる。ネットワーク通信を行わない場合は、 IPAddressDeny=any を指定しておき、リモートアクセスを完全に無効化しておくのが良いだろう。

マニュアル: https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#IPAddressAllow=ADDRESS%5B/PREFIXLENGTH%5D%E2%80%A6

DeviceAllow

デバイスノードに対するアクセス制御を指定する。アクセスを許可するデバイスとその読み込み (r)、書き込み (w)、作成 (m) を許可するかを指定する。物理デバイスに対するアクセスを PrivateDevices で全て無効化している場合は、特に気にしなくていいだろう。デバイスへの直接のアクセスを提供することは、様々なセキュリティ保護を回避しつつ、影響の大きな攻撃を成立させる手段となりうる。もし、物理デバイスに一部でもアクセスが必要な場合は、必要なアクセスのみを指定するのが良いだろう。

マニュアル: https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#DeviceAllow=

NotifyAccess

systemd のサービスステータス通知へのアクセスを制御する。このオプションはデフォルトで無効化されているため、通常気にすることはないだろう。必要な場合は、必要な範囲のステータス通知だけを受け取るようにしておくのが良いだろう。

マニュアル:

SystemCallFilter=~@privileged

システムコールのうち、特権が必要なものに関するものの使用を禁じるオプション。対象のシステムコール一覧は、 systemd-analyze syscall-filter @privileged で見ることができる。対象には、 @swap、 @clock などを始め、キャパビリティを必要とするものは全部含まれる。流石にキャパビリティを1つ2つ必要とするサービスは普通にあるため、純粋にこのオプションを有効化できない場面もあるだろう。ただ、特権を必要とするシステムコールは影響力が強いからこそ特権が必要となっているため、セキュリティ的にサービスが必要とする特権は把握しておいた方が良いだろう。その意味でも、基本的にはこのオプションを指定しておいて必要となるシステムコールはホワイトリスト形式で指定しておくのが良いだろう。

マニュアル:

SystemCallFilter=~@resources

システムコールのうち、リソースや実行計画の変更に関するものの使用を禁じるオプション。対象のシステムコール一覧は、 systemd-analyze syscall-filter @resources で見ることができる。主に setrlimit、 setpriority などが対象。これらのシステムコールによるリソースの占有設定などはシステム全体に悪影響を与える手段となりうる。リソースや実行計画の変更は、重要なサービスのパフォーマンスを確保するのに必要な場合もあるため、完全無効化は難しい場面もあるかもしれないが、基本的に設定しておいて許可するものだけをホワイトリスト形式で指定しておくのが良いだろう。

マニュアル:

RestrictRealtime

リアルタイムスケジューリングの有効化を無効にする。スケジューリングの設定は、CPUリソースを占有することによる他サービスの不調を招く手段となりうる。スケジューリング設定は、重要なサービスのパフォーマンスを確保するのに必要な場合もあるが、もし必要ないなら基本指定しておき、必要なものだけにスケジューリング設定を解放しておくのが良いだろう。

マニュアル: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#RestrictRealtime=

SystemCallFilter=~@obsolete

システムコールのうち、使用されないもの、非推奨のもの、未実装のものの使用を禁じるオプション。対象のシステムコール一覧は、 systemd-analyze syscall-filter @obsolete で見ることができる。主に create_module、 gtty などが対象。これらのシステムコールを必要とする状況はほぼないだろうから、このオプションは基本指定しておくのが良いだろう。

マニュアル:

SystemCallFilter=~@cpu-emulation

マニュアル:

RestrictAddressFamilies=~AF_NETLINK

Service may allocate netlink sockets (ref: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#RestrictAddressFamilies=)

SupplementaryGroups

Service runs with supplementary groups (ref: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#SupplementaryGroups=)

LockPersonality

パーソナリティ、つまりカーネル実行ドメインの変更を無効化する。パーソナリティの指定はあまりテストされておらず脆弱性の元になりかねない。またほとんどのサービスで必要となることはないだろうから、基本的に指定しておくのが良いだろう。

マニュアル: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#LockPersonality=

MemoryDenyWriteExecute

書き込み可能かつ実行可能なメモリマッピングを作成したり、既存のメモリマッピングを実行可能になるよう変更することを禁じるオプション。外部からの影響が大きいリモートコード実行の脆弱性は、動的に実行可能コードを埋め込んだり、変更したりできることに起因することが多いため、このオプションはそのような脆弱性をついた攻撃からの保護において有用だ。ただ、JIT 方式を採用しているようなランタイムなどは、その仕組み上そもそも動的に実行可能コードを変更することにより動くため、そのようなランタイムを採用しているサービスではこのオプションは有効化できない。そういう場合以外は基本的に有効化しておくのが良いだろう。

マニュアル: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#MemoryDenyWriteExecute=

Delegate

リソース制御の分割委任を有効化する。適切なリソースの設計と委任設定がされていれば問題ないが、その適切な管理は複雑で難しく、またほとんどのサービスでは必要ないことから、特に有効化する必要はないだろう。また、デフォルトで無効化されているため、基本的に気にする必要はないだろう。

マニュアル:

ProtectHostname

ホスト名、ドメイン名の名前空間を専用に作成し、さらに変更できないようにする。ホスト名の解決は、基本的にどのドメイン解決より優先される為、ホスト名変更はスプーフィング攻撃などを行う手段として機能しやすい。ホスト名の変更が必要なサービスはかなり限られるだろうから、基本的には有効化しておくのがいいだろう。

マニュアル: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectHostname=

RestrictAddressFamilies=~AF_UNIX

UNIX ソケットの作成を制限する。UNIX ソケットは外部からのリモートアクセスには直接利用できないが、他のサービスからのデータ通信を、サンドボックス機能などを回避して行う手段となりうる。もしサービスが UNIX ソケット作成を必要としないなら、指定しておくのが良いだろう。

マニュアル:

ProcSubset

プロセス管理と情報取得用の /proc ファイルシステムへのアクセスを制限する。 ProcSubset=pid を指定した場合、 /proc にプロセス情報は置かれず PID 毎のディレクトリだけが生成される。 ProcSubset=all を指定した場合、通常の挙動になる。 ProtectProc が指定されていれば、デフォルトの挙動でもそれほど大きな問題にはならないと思われるが、 ProcSubset=pid でサービスが問題なく動くなら、指定しておく分にはその方が良いだろう。

マニュアル: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProcSubset=

最後に挙動改善機能:

CapabilityBoundingSet

キャパビリティ境界を設定するオプション。execve 実行時に引き継げるキャパビリティを指定する。任意コード実行のセキュリティホールがあった時に、本体プロセスのキャパビリティが引き継げてしまうと、被害が広がってしまう可能性がある。キャパビリティ境界はデフォルトでは全てのキャパビリティが引き継がれるが、基本的には引き継がなくていいケースが多い。その場合、 CapabilityBoundingSet= と指定することで全てのキャパビリティの引き継ぎを無効化できる。また、引き継ぐ必要がある場合も、引き継ぐ必要があるものをホワイトリストで指定しておいた方が良い。その場合は必要なキャパビリティを明示的に指定しておくのが良いだろう。

マニュアル:

AmbientCapabilities

キャパビリティ環境を設定するオプション。キャパビリティ環境は、特権ユーザにより実行されたプロセスでなくても、キャパビリティを与える手段の一つ。特権を行使できるようにすることは攻撃の被害を深刻なものにする可能性があるため、使用を避けるようにするのがよい。デフォルトで指定なしなため、基本的には特に何もしなくても良いと思うが、もしキャパビリティ環境が必要な場合は必要なキャパビリティだけを指定するのが良いだろう。

マニュアル:

RemoveIPC

サービス停止時ルートユーザ以外の実行ユーザ、グループが持つ IPC オブジェクトを破棄する。IPC オブジェクトを持続的に保持することは、攻撃者が持続的な攻撃を行う手段となりうる。また、サービス終了後も保持し続ける必要はない場合が多い。そのため、基本的には有効化しておくのが良いだろう。

マニュアル: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#RemoveIPC=

UMask

ファイル作成時の権限マスク。指定されたマスクの部分の権限は取り除かれた状態でファイル、ディレクトリが作成される。デフォルトは 0022 であり、この場合グループ、その他のユーザの書き込み権限は取り除かれる。この場合、他のユーザからも作成されたファイルの読み取りは可能なため、他のサービスが攻撃された際、攻撃の余波を受ける可能性がある。作成されたファイルを他のユーザと共有する必要がないサービスは多いため、 0077 を指定し実行ユーザのみに権限を与えるのが望ましい。また、もしファイルの共有が必要な場合は、共有用のグループで共有の範囲を絞っておくのが良いだろう。その場合は 0027 でグループのみ参照権限を与えるのが良いだろう。

マニュアル:

その他の有用な機能

さて、 systemd-analyze security では提示されないが、他にも幾つかセキュリティ的に有用な機能がある。それらも紹介しておこう:

PrivateIPC

専用の IPC 名前空間を作成し、他のサービスの IPC 空間から隔離するサンドボックス化機能。他のサービスの IPC オブジェクトへの攻撃を避けられる他、名前競合によるクラッシュを避けるという効果も得られる。他のサービスと IPC オブジェクトを共有しないといけないサービスは稀なため、基本的には有効化しておくのが良いだろう。

ReadWritePaths

ProtectSystem を有効化する場合、一時ディレクトリなどの一部のディレクトリを除いて、ファイルシステムが読み込み専用となる。しかし、実行時データを作成し、書き込むのはサービスの基本的な動作であり、一部ディレクトリに書き込みを許可したい場合はあるだろう。その場合、 ReadWritePaths にホワイトリスト形式でパスを指定することで、そのパスについては書き込みも許可される。また、このパス指定により、サービスが書き込みが起こるパスも明示され分かりやすくなるだろう。基本的には、 ProtectSystem と併用し、書き込みが起こるパスはホワイトリスト管理しておくのが良いだろう。

マニュアル: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ReadWritePaths=

今後の systemd バージョンアップで、他にも機能が随時追加、改善されていくだろう。また、サービス自体も機能が改善されていく。それに合わせて定期的に systemd-analyze security によりセキュリティ機能の見直しを図っていくのが、セキュリティにおいて重要となるだろう。

まとめ

というわけで、systemd におけるセキュリティ機能の紹介を行った。systemd にはサンドボックス化や機能制限によるセキュリティ向上のための機能と、セキュリティ機能有効化状況の評価機能が備わっている。それらを有効に活用することで、一般のサービスはもちろん、あまり使われていないセキュリティ的に多少不安があるサービスの運用リスクもある程度緩和できるだろう。

なお、昨今は OCI、主に Docker によるサービス管理も主流になりつつあり、systemd でサービスを運用する機会もなくなりつつあるかもしれない。ただ、 Docker などでも事情は同じで、サンドボックス化の強化や機能制限によるセキュリティ向上はやっておいた方がいいだろうし、そうなった時バックにあるものはほぼ systemd のバックで使われてるものと同じになってくる。逆に言えば今回紹介した機能と同じような機能が Docker 側にも用意されている。Docker の場合はある程度サンドボックス化がデフォルトでなされた状態と言えなくもないが、隔離されたコンテナの中に閉じた攻撃は可能であり、また特権利用によるホストの攻撃などの事例もいくつか上がっている。追加の保護施策は有用であり、今回紹介した項目は応用できるだろう。

ここら辺はインターネットに晒されるよく分からない有象無象を動かす人が多くなった時代としては、割と有用だと思うんだが、世間にはあまり知られてなさそうだなあと感じる。 systemd-analyze security でスコア改善するのは割とゲーム感覚でできておすすめなので、まみんなもぜひやってみてくれという感じ。では、今回はこれで。

Ansible の変数を CUE で記述する

2023-06-18T17:07:03+09:00

Ansible や Kubernetes などのオーケストレーションツールでは、タスクやサービスの記述は再利用可能にしておきつつ、設定を別途記述することである程度カスタマイズできるようにすることがよくある。さらに、設定ファイルは環境毎に一部設定を変えたり、一部を使い回したりと、柔軟に組み合わせて管理がしたいことがある。Ansible や Kubernetes ではそれぞれ専用の機能が用意されている。しかしながら、これらの機能はそこまで設定の組み合わせについてのサポートが手厚いわけではなく、また設定に対してのスキーマ管理などもないため設定が自らの手で管理しきれなくなることが多い。つまり、設定の更新忘れや記述漏れが発生したり、しばらく触らないでいるとどこをどういじればいいか分からなくなるのだ。その結果、デプロイ作業が恣意的なものになりがちで、手元でテストでしても本番でミスるとかいうことにつながりがちだ。

そこで僕は最近、設定ファイルを CUE で記述しマージはそっち任せにして、そこから生成したものを使うということをやってる。今回は、Ansible の設定管理を題材にその方法を紹介する。

Ansible と変数

Ansible 使ってる人には説明の必要もない気がするが、一応前提の共有から。Ansible では、構成の宣言によってデプロイタスクを定義して実行する。この構成の宣言を部分的にグループ化する機能も、Ansible では幾つか提供されている。例えば、Ansible では変数を Jinja テンプレートで使用することで、外部から注入された変数によってタスクを調整することができる。さらに、そういう変数をインベントリグループ毎に設定し、マージする機能も提供している。

例えば、

prod:
    children:
        public_prod:
            hosts:
                public-prod001.private:

というようなインベントリを記述すると、 public-prod001.private というホストが all、 prod、 public_prod というグループに所属することになる。このグループそれぞれで変数を設定でき、

public_prod
prod
all

の優先順位で、変数が統合されて使われる。これらの変数は、 group_vars/ というディレクトリに、 <グループ名>.yml でおけば自動で読み取られる。例えば、 group_vars/all.yml に

app_version: '1.0.0-rc'
env: local

worker_process: 100
resolver: '8.8.8.8'

group_vars/prod.yml に

app_version: '1.0.0'
env: production

group_vars/public_prod.yml に

worker_process: 1024

public_domain: example.com

などと記述した場合、 public-prod001.private のデプロイ時には、

app_version: '1.0.0'
env: production

worker_process: 1024
resolver: '8.8.8.8'

public_domain: example.com

という変数群が使用されることになる。この機能を使用することで、開発環境と本番環境で異なる設定を部分的に使用する場合は環境毎にグループを作ってそこの変数で設定、アプリケーション毎に異なる設定を部分的に使用する場合はアプリケーション毎にグループを作ってそこで設定と言ったことができる。

この機能はシンプルで、多くの需要を満たせる反面、ミスに繋がりやすく、またあまりにグループ構成を複雑化しすぎると変数管理が手に負えなくなる面もある。あまり複雑なグループ構成を採用するなと言う話ではあるのだろうが、以下の場面においてより柔軟な設定管理をしたい時はあるだろう:

一部のアプリケーションで共通の設定を使いたい。
ある設定と別の設定を連動させたい。
あるタスクの設定を、一部は環境毎に、一部はアプリケーション毎に設定したい。

このような時に、上記のグループ機能を純粋に使うと、かなりグループ構成が複雑になりメンテを楽にするための共通化などがメンテの足を引っ張ることになる時がある。つまり、あるタスクの設定をどこに書き、それがどのホストに対して使われる設定なのか把握するのがかなり困難になるのだ。このような状況だと大規模なリファクタリングなど怖くて行えない。またマージ機能はその性質上、デフォルト値を与えつつ必要な場合は明示的に指定を書くと言ったパターンが頻出するが、その時にあるホストに対して最終的にどの値が使われるかが把握しにくい。

もう一つの課題が、どういう変数が設定ができるかの管理方法だ。Ansible では変数はタスクやテンプレートなどの随所で使用されるわけだが、そうなるとどの変数はどういう値を設定すべきで、どの設定は必須なのかみたいな情報を探すのは割と一苦労で取りこぼしなども出てきてしまう。そういうのを一元的に確認したいことがよくあるのだ。ドキュメントに残すと言うのは一つの方法だが、何の検証もされないドキュメントはタイポなどのミスを生みがちで、また陳腐化もしやすく、ドキュメントを参照しても一元的な確認ができないと言う本末転倒な事態を招きかねない。

僕は一時期これらの課題に対して、JSON schema で設定できる変数をまとめ陳腐化を防ぎつつ、タスクの書き方を工夫することで設定の分離もなんとか管理できるようにして、凌いでいた。ただこれも結構課題があり、特に JSON schema がマージとの相性が悪いこと、マージ機能が貧弱なためにタスクを複雑化させるのは割と本末転倒感があることなどから、代替策を探していた。最近はこれらの課題は大体 CUE 言語使えば解決できることが分かってきたので、CUE で書くようにしている。

CUE 言語のモデル

CUE 言語は、公式サイトではデータ検証言語と紹介されている。基本的には、YAML や JSON などと同じデータ記述が想定された言語なのだが、データ検証を記述できること、データのマージについて標準的なサポートがあること、豊富なテンプレート記述ができることなどが異なる点だ。特徴的なのが、データ検証とマージに関する機能で、型、制約と値の間に束をモデルとした順序を設け、その順序による階層に違反しないかの検証をデータ検証として採用しつつ、マージもその階層に沿って行う。これにより、柔軟にデータを分割しつつ、結合的で交換的で冪等で安全なデータの結合を実現する。まあ、言葉で説明しても想像しにくいと思うので、実際の例を見ていく。

CUE 言語を試すだけなら、オンラインで試せる。手元で試したい場合は、https://cuelang.org/docs/install/ を見ながら cue コマンドを入れ、CUE ファイルを作り cue eval --all <file> で CUE ファイルの評価ができる。例えば、

sample_string: string
sample_string: =~"^[a-z]{3}_[a-z]{2}$"
sample_string: "abc_de"

は、

1	sample_string: "abc_de"

に評価される。 string は文字列型、 =~"^[a-z]{3}_[a-z]{2}$" は正規表現制約、 "abc_de" は文字列リテラルになる。これらの間には順序関係があり、 string より =~"^[a-z]{3}_[a-z]{2}$" の方が大きく、 =~"^[a-z]{3}_[a-z]{2}$" より "abc_de" の方が大きい。これらの中で一番大きいのが "abc_de" なため、これが sample_string の値として採用されている。CUE 言語の値のマージにおいては、値間の順序だけが大事なので、以下も同じ結果になる:

sample_string: =~"^[a-z]{3}_[a-z]{2}$"
sample_string: "abc_de"
sample_string: string
sample_string: "abc_de"

つまり、どの宣言を先に持ってきても良いし、同じ宣言が複数出てきても良い。これが交換的で冪等であると言うことだ。また、一部を別の変数に括り出すことも可能だ。例えば

sample_string1: sample_string2
sample_string1: sample_string3

sample_string2: string
sample_string2: =~"^abc_[a-z]{2}$"

sample_string3: =~"^[a-z]{3}_de$"
sample_string3: "abc_de"

は、

sample_string1: "abc_de"
sample_string2: =~"^abc_[a-z]{2}$"
sample_string3: "abc_de"

に評価される。 =~"^abc_[a-z]{2}$" より "abc_de" の方が大きくこれが最大の要素であるため、 sample_string1 はこの値になる。マージは結合的であるため、どこを括り出しても結果は変わらない。一方で順序関係による階層が作れないようなものは、データ検証段階で弾かれる。例えば、

sample_ill: string
sample_ill: int

は、 conflicting values string and int というエラーが報告され、評価されない。マージにおいて大事なのは、順序による階層に違反してないか、そして順序関係から導かれる最小上界が何であるかだけということになる。ところで今までは最小上界がマージする対象の中に入っている例を見てきたが、必ずしも最小上界は記述された値の中にあるとは限らない。例えば、

sample_obj1: sample_obj2
sample_obj1: sample_obj3

sample_obj2: sample_string1: "str1"
sample_obj2: sample_string2: "str2"

sample_obj3: sample_string2: string
sample_obj3: sample_string3: "str3"

は、

sample_obj1: {
    sample_string1: "str1"
    sample_string2: "str2"
    sample_string3: "str3"
}
sample_obj2: {
    sample_string1: "str1"
    sample_string2: "str2"
}
sample_obj3: {
    sample_string2: string
    sample_string3: "str3"
}

に評価される。CUE 言語はもちろん構造体をサポートしている。 a: b: string という記述は a: { b: string } と言う記述の略記であり、

sample_obj1: sample_obj2
sample_obj1: sample_obj3

sample_obj2: sample_string1: "str1"
sample_obj2: sample_string2: "str2"

sample_obj3: sample_string2: string
sample_obj3: sample_string3: "str3"

は、

{
    sample_obj1: sample_obj2
    sample_obj1: sample_obj3

    sample_obj2: { sample_string1: "str1" }
    sample_obj2: { sample_string2: "str2" }

    sample_obj3: { sample_string2: string }
    sample_obj3: { sample_string3: "str3" }
}

と記述するのと等しい。つまり、 sample_obj1 は { sample_string1: "str1" }、 { sample_string2: "str2" }、 { sample_string2: string }、 { sample_string3: "str3" } の最小上界を値に持つと言うことであり、その値が { sample_string1: "str1", sample_string2: "str2", sample_string3: "str3" } であるということになる。構造体の順序については少々複雑なので後で詳しく触れるが、基本的にはこのようにフィールドそれぞれをマージするような挙動をする。

この機能はかなり強力であり、今回のように一部の値を先行して埋めその際データ検証が通るようにしたい、複数の部分的なスキーマを統合したいなどといったデータ記述のマージに関する複雑な需要がありかつデータ検証も行いたいような場合にかなり効力を発揮する。さらに CUE 言語には、フィールドの内包表記、文字列に対するパラメータの差し込み、条件分岐といった多少複雑なテンプレート機能をサポートしており、これもデータ記述の統合に力を貸してくれるだろう。詳細は、 CUE 言語の式に関するドキュメントを見てもらうのがいいだろう。

さて、データ記述が分けられるとくれば、ファイル分割によりファイルシステムに沿ったデータ記述の断片管理をしたいというのも需要の一つだ。CUE 言語では、ディレクトリレイアウトと連動可能なモジュールシステムを備えており、ファイル分割もサポートしている。ディレクトリレイアウトとモジュールシステムを連動させるには、まずそのレイアウトのルートとなるディレクトリにモジュールに関する宣言を行う必要がある。これは、 cue コマンドを利用して行うことができ、レイアウトのルートとなるディレクトリに移動し、以下のコマンドを実行することで宣言できる:

cue mod init [モジュール名]

モジュール名は、そのモジュールに所属するパッケージのルートパスとなる識別子で、ドメインとオプションでパスを指定する。例えば、 mizunashi.work/pkg といった感じだ。手元で試すだけならドメインは所有している必要はなく実在している必要もない。ひとまず他のモジュールと被らないようなドメイン名であれば問題ないだろう。さて、モジュールの宣言を行うと、 cue.mod というディレクトリが作られ、そこにモジュールに関するファイル群が配置されることになる。それぞれ

module.cue ファイルはモジュールに関する情報が宣言されるファイルで、モジュール名が記述されることになる。
pkg ディレクトリは、外部モジュールが置かれるディレクトリで、ここに他のモジュールをダウンロードしてそのモジュール名に合わせて配置すると、そのモジュールも読み込めるようになる。
usr ディレクトリは使ったことがないのでよく分からないが、使用する CUE 言語のユーザ定義拡張などを置く場所のようだ。

この cue.mod が置かれたディレクトリについて、 a/b/sample.cue といったファイルを以下の内容で作る:

package sample

sample_string: "abc"

この時、モジュール名が mizunashi.work/pkg であれば、

import "mizunashi.work/pkg/a/b:sample"

sample_obj: imported: sample

は

sample_obj: {
    imported: {
        sample_string: "abc"
    }
}

に評価される。基本的にパス名にコロン区切りでパッケージ名を繋げることで、そのパッケージのパスになる。なお、パッケージ自体を複数ファイルに分割することもでき、 a/sample/obj1.cue を

package sample

sample_string2: "abc2"

a/sample/obj2.cue を

package sample

sample_string3: "abc3"

とすると、

import "mizunashi.work/pkg/a/sample"

sample_obj: imported: sample

は

sample_obj: {
    imported: {
        sample_string2: "abc2"
        sample_string3: "abc3"
    }
}

に評価される。この機能により、基本的に CUE 言語にファイル分割も任せれば、特に Ansible などの変数の利用側でファイル分割の機能を利用しなくてもよくなり、より柔軟で安全なデータ記述管理ができる。

Ansible での利用

では、この CUE を使って僕が Ansible の変数をどうやって管理しているかも紹介していこう。実例は、https://github.com/mizunashi-mana/mizunashi-work-playbook にある。

Ansible での CUE による変数管理の場合、僕は基本的に以下のような構成にするようにしている:

インベントリディレクトリを CUE モジュールのルートとする。
ロール一つ一つをパッケージとするそのロールのスキーマを roles/*/schema.cue に書く。
- 例えば、 roles/node_exporter という Node Exporter のインストールロールがある時、 roles/node_exporter/schema.cue に node_exporter パッケージとして、そのロールで使用する変数を記述する。
- 記述例は、https://github.com/mizunashi-mana/mizunashi-work-playbook/blob/389cfd78428dc8ede6fa941d7e2014fb47d3a136/roles/node_exporter/schema.cue とかを参照してもらうのが良いだろう。
インベントリグループ毎の変数のスキーマを、 schemas/*.cue にグループの名前に合わせたパッケージを書く。
- 必ずしもこれはグループを発行する必要はないし、グループに対応させる必要もない。が、グループに対応させておくと分かりやすい。
- 記述例は、https://github.com/mizunashi-mana/mizunashi-work-playbook/blob/389cfd78428dc8ede6fa941d7e2014fb47d3a136/roles/node_exporter/schema.cue とかを参照してもらうのが良いだろう。
- 基本的には、そのグループでプロビジョンが必要なロールのスキーマを読み込むだけで良い。上の記述例がどういう意味論を持つかは後ほど詳しく見る。
その他共通化したいスキーマや設定などは適宜ディレクトリを作ってパッケージを作る。
グループ変数、ホスト変数生成用の CUE ファイルを、生成先のディレクトリに生成先の名前に合わせて作る。
- 上で作ったスキーマを適宜読み込み、グループに対しての変数を設定していく
- 記述例は、https://github.com/mizunashi-mana/mizunashi-work-playbook/blob/389cfd78428dc8ede6fa941d7e2014fb47d3a136/group_vars/internal_vagrant.cue とかを参照してもらうのが良いだろう。
- 上の記述例では、スキーマにない変数が間違って設定されないような工夫を施している。この記述例がどう言う意味論を持つかは後ほど詳しく見る。

そして、 cue export --out yaml group_vars/sample.cue --outfile group_vars/sample.yml といった具合にグループ変数、ホスト変数を生成する。基本生成するのは末端のグループだけで、後のグループの変数は CUE 側でマージしておけば、適切に共通化部分をコントロールでき、また最終的に適用される変数が分かりやすい。

ただ、このままだと対応できないものが一つだけあって、それが Ansible Vault だ。Ansible Vault は、暗号化済みファイルの注入か YAML カスタムタグでの注入しかサポートしてないっぽくて、CUE 言語では直接の対応はできない。そこで、僕は純粋に CUE 言語で対応するのはやめて、

sample_vault: "__ansible_vault": """
$ANSIBLE_VAULT;1.1;AES256
...
"""

みたいな入力が与えられた時、

sample_vault: !vault |
    $ANSIBLE_VAULT;1.1;AES256
    ...

に変換する簡単な Python スクリプトを書いている。そこまで大したことはしてなくて、 cue export で一旦上の CUE を YAML に変換した後、 "__ansible_vault": ... みたいなオブジェクトを探して !vault ... に変換し、YAML として再度出力してるというだけだ。ここら辺も CUE だけで完結できればかっこいいんだろうが、まあとりあえずこれで困ってない。他にいいやり方知ってたら教えて欲しい。

CUE の構造体とその開閉

さて、基本上記のような構成で、Ansible の変数をスキーマベースでファイル分割を怯えずに管理できる。ただ、幾つか CUE の構造体についてさらに知っておくと色々やりやすくなるので、最後にその点を触れておく。

まず、 CUE の構造体には開いているか閉じているかという属性がある。開いている構造体は、自身が含んでいないフィールドを持つ構造体でも、自身が含んでいるフィールドのみ互換性があれば順序がつく。つまり、 { a: int } という開いた構造体があった場合、 { a: 1, b: string } といった a フィールドは互換性があり、さらに b というフィールドが追加されているような構造体との間に順序がつく。このため、マージの際フィールドを新たに追加することが許可される。しかし、閉じた構造体はこういうことは許されない。つまり、 close({ a: int }) と { a: 1, b: string } の間には順序がつかず、同じ階層にも所属できない。ここで、 close({ a: int }) は { a: int } の閉じたバージョンだ。実際に

sample_ill: close({ a: int })
sample_ill: { a: 1, b: string }

は評価されず、 sample_ill.b: field not allowed というエラーが出る。閉じた構造体は、自身が持つフィールドと互換性のある範囲しかマージができない。例えば上記の例を逆に

sample_obj: close({ a: 1, b: string })
sample_obj: { a: int }

とすると、これは評価され、

sample_obj: {
    a: 1
    b: string
}

という結果になる。この閉じた構造体を使うことで、スキーマで定義されたフィールド以外の宣言がないことを検証できる。これは、更新忘れなどを防ぐのに役にたつ。

ここで、何点か注意して置く必要がある。一つ目は、宣言された構造体が開いたものになるか、閉じたものになるかの条件だ。基本的に {} で囲まれて宣言された構造体は開いた構造体になり、 close でさらに囲むと閉じた構造体になる。ただし、宣言の仕方によっては close を書かなくてもデフォルトで閉じた構造体になることがある。それが、秘匿フィールド (hidden field) での宣言の場合だ。秘匿フィールドは、 # から始まるフィールドで、このフィールドは最終結果からは除外される。例えば、

#sample_hidden: 1
sample_str: "str"

は、

1	sample_str: "str"

に評価される。秘匿フィールドではなく、最終結果に含めるフィールドとして宣言するには、

"#sample_int": 1
sample_str: "str"

というように、クオートで囲む必要がある。秘匿フィールドは、スキーマの宣言や、最終結果に含めたくないが CUE 上での共通化のための宣言を行うために便利だ。さて、この秘匿フィールドは、基本宣言がそれだけで完結していることが多いため、デフォルトで再帰的に構造体が閉じるようになっている。実際に試してみると、例えば

#sample_hidden: a: 1

sample_obj: #sample_hidden
sample_obj: b: 2

は、評価されず、 sample_obj.b: field not allowed というエラーが出る。注意したいのは、秘匿フィールドの宣言自体では、開いた構造体が使えるということだ。例えば、

#sample_hidden: a: 1
#sample_hidden: b: 2

sample_obj: #sample_hidden

は、問題なく

sample_obj: {
    a: 1
    b: 2
}

と評価される。あくまで秘匿フィールドを使用する際には閉じた構造体として扱われるということだ。このことに注意しながら、秘匿フィールドを交えてデータ記述を行うと、より柔軟なデータ記述ができるだろう。

もう一つの注意点は、構造体のマージには実は幾つか構文があり、それぞれ異なる意味論を持っているということだ。今まで基本的に使ってきた

sample_obj: { a: 1, b: 2 }
sample_obj: { b: int, c: 3 }

という記述は、以下と等価になる:

1	sample_obj: { a: 1, b: 2 } & { b: int, c: 3 }

これは、今までのマージが、マージ対象の最小上界であるということが分かりやすい。もちろん、

sample_obj: close({ a: 1, b: int })
sample_obj: { b: 2 }

も

1	sample_obj: close({ a: 1, b: int }) & { b: 2 }

と記述できる。それに対して、構造体のマージは埋め込み (embedding) と呼ばれる他の意味論を持つ構文も用意されている:

sample_obj: {
    close({ a: 1, b: int })
    b: 2
    { c: 3 }
}

この記述を評価すると、

sample_obj: {
    a: 1
    b: 2
    c: 3
}

になる。これは、

sample_obj: close({ a: 1, b: int }) & {
    b: 2
    c: 3
}

が評価されずエラーになるのと対照的だ。埋め込みは、マージの対象に対して単に最小上界を取るのではなく、構造体のフィールドを全て展開してからマージを行う。このため、閉じた構造体も開いた構造体と同じようにマージされる。ただし、マージ対象の中に一つでも閉じた構造体がある場合、マージされた構造体も閉じた構造体になる。これらを同じ構文だと思うと色々ハマるので注意が必要だが、これらの構文をうまく使い分けできれば、柔軟なデータ管理ができるだろう。

まとめ

というわけで、CUE 言語の紹介と、それを Ansible の変数管理に活用する構成例を紹介した。最初の頃は構造体やモジュールの仕様につまづき、色々苦労もしたが、今は結構色々助かってて安心して変数を増やしたり削除したりできるようになったし、出力される変数のファイル自体は1ファイルなので、変数の差分なども見やすくなって色々重宝してる。まだ色々手探りなところもあるものの、現状そうつまづくことはないかなあという感じで、後の懸念点は安定性がどんくらいなのかなあということぐらいか。ま、興味があれば使ってみて欲しい。

では、今回はこれで。

nftables のログを JSON で吐く

2023-05-21T21:12:17+09:00

Linux でのファイアウォールが nftables になってからかなり経つ。iptables フロントエンドよりも分かりやすい設定ファイルと設定の永続化方法も用意され、カーネル側で単純なファイアウォールを組むだけなら nftables 単体で十分になった。

さて、nftables にはパケットフィルタリングの機能に加えて、パケットのロギングをする機能が組み込まれている。これは iptables 時代からある機能で、パケットフィルタの動作監視や、パケット流入の状況監視などに使える。標準では、このログはカーネルログに独自の形式で吐かれるが、フォーマッタや出力先は調整できる機能が入っている。今回は、この機能を ulogd を通して使い、JSON 形式で別ファイルにパケットログを出す方法を紹介する。

nftables とログ出力

nftables の基本的な使い方は、昔書いたので、そっちを参照してもらうのがいいだろう。僕が使ってる ruleset は https://github.com/mizunashi-mana/mizunashi-work-playbook/blob/04d0f8fc5701ef400d543bfa91bc45c4f056be4e/roles/nftables/files/etc/nftables.conf にある。良かったら、参考にどうぞ。今回は、ログ出力に関わる部分のみにとどめた nftables の使い方だけを見ていくことにする。

nftables には、ログ出力用の log statement があり、matcher / control flow と合わせて使うことができる。例えば、TCP 宛先ポート 80 のパケットを、1分に1エントリーのレートでログ出力するには、次のような文を入れる:

tcp dport 80 limit rate 1/minute log prefix "[NFTABLES HTTP PKT]: " continue;

input filter に仕込むと該当のパケットが来た場合、カーネルログに次のようなメッセージが出る:

May 21 08:01:58 internal kernel: [55242.749774] [NFTABLES HTTP PKT]: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:86:dd SRC=fde4:8dba:82e1:1006:0000:0000:0000:1001 DST=fde4:8dba:82e1:1006:0000:0000:0000:1001 LEN=401 TC=0 HOPLIMIT=64 FLOWLBL=815899 PROTO=TCP SPT=59840 DPT=80 WINDOW=512 RES=0x00 ACK PSH URGP=0

基本的にカーネルログへ出る形式は、 フィールド名[=値] という感じ。prefix でどのパケットのログかを見分けることになる。flood 対策のログとかは全部流してしまうと、DoS 対策のフィルターのログでディスクが詰まって DoS が成立してしまうということになりかねないので、基本 rate limiter とセットがいいだろう。今回は紹介しないが、counter 機能を使えば、数は正確に計測ができる。ログ出力と付き合わせれば、ある程度監視が効くようになるだろう。

ulogd で出力先を変更する

さて、監視には分析環境の整備とデータ整理が必要になる。特にデータ処理において、独自の形式のログだと色々取り扱いにくい。パケット監視にしても、やっぱりプロトコルの種類、送信元アドレス、宛先ポートなど、監視したい項目は色々あるだろう。そこら辺に関して、クエリが書けるようにはしときたい。そのような需要に対応するため、nftables のログは出力先の変更やフォーマットの変更に対応している。その中でも手軽な方法は、 ulogd を使う方法だ。

まずは、 ulogd をインストールする。Debian では標準のパッケージとして提供されていて、 apt で入る:

apt install ulogd2

後、JSON 形式での出力をサポートするため、JSON モジュールもインストールしておく:

apt install ulogd2-json

ulogd の設定ファイルは /etc/ulogd.conf にある。色々プラグインが用意されており、syslog や Graphite への出力などもサポートしているようだ。プラグインの種類は入力、フィルター、出力の3種類がある。今回は、

入力
- NFLOG: nftables での基本的なパケットログ入力元。ま、基本入力はこれで良い。
フィルター
- BASE: 基本的なパケット情報をログに含める。
- IFINDEX: ネットワークインターフェースをインデックスではなく名前でログる。
- HWHDR: MACアドレスを文字列形式でログる。
- IP2STR: IPアドレスを文字列形式でログる。
出力
- JSON: JSON 形式でファイルに出力する。

を使っていく。他のプラグインについては、https://git.netfilter.org/ulogd2/tree/doc/ulogd.sgml を参照すると良いだろう。まず、使うプラグインを有効化しておく。 /etc/ulogd.conf の上部にある、plugin の定義で該当する箇所をコメントアウトしておく:

plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_inppkt_NFLOG.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_inppkt_ULOG.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_inppkt_UNIXSOCK.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_inpflow_NFCT.so"
plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_filter_IFINDEX.so"
plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_filter_IP2STR.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_filter_IP2BIN.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_filter_IP2HBIN.so"
plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_filter_PRINTPKT.so"
plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_filter_HWHDR.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_filter_PRINTFLOW.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_filter_MARK.so"
plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_output_LOGEMU.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_output_SYSLOG.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_output_XML.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_output_SQLITE3.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_output_GPRINT.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_output_NACCT.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_output_PCAP.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_output_PGSQL.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_output_MYSQL.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_output_DBI.so"
plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_raw2packet_BASE.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_inpflow_NFACCT.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_output_GRAPHITE.so"
plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_output_JSON.so"

次に、入力先と出力先の設定をする:

[log17]
group=17

[json17]
sync=1
file="/var/log/ulog/nftables.log"

log17 は入力元の設定、 json17 は出力先の設定になる。入力側の group は nftables 側で設定するグループに合わせる。nftables 側では log statement に設定する:

tcp dport 80 limit rate 1/minute log prefix "[NFTABLES HTTP PKT]" group 17 continue;

group はそれぞれの statement 毎に指定可能で、ulogd 側でも複数のグループをそれぞれ扱うことができる。JSON 出力の設定には、出力先のファイルパスの指定 (file) と同期出力するかの設定 (sync)、他にもいくつか設定ができる。同期出力するかは、ログ出力を同期的に行う設定で、その分パケット処理のパフォーマンスは劣化するが、ログの反映が早くなる。

これらのプラグイン設定をもとに、以下のようにログ出力のスタックを組むことができる:

stack=log17:NFLOG,base1:BASE,ifi1:IFINDEX,ip2str1:IP2STR,mac2str1:HWHDR,json17:JSON

これにより、 /var/log/ulog/nftables.log に以下のようなログが載るようになる:

{"timestamp": "2023-05-21T10:54:05.058650", "dvc": "Netfilter", "raw.pktlen": 80, "raw.pktcount": 1, "oob.prefix": "[NFTABLES HTTP PKT]", "oob.time.sec": 1684666445, "oob.time.usec": 58650, "oob.mark": 0, "oob.ifindex_in": 4, "oob.hook": 1, "raw.mac_len": 14, "oob.family": 10, "oob.protocol": 34525, "raw.label": 0, "raw.type": 1, "raw.mac.addrlen": 6, "ip.protocol": 6, "ip6.payloadlen": 40, "ip6.priority": 0, "ip6.flowlabel": 960112, "ip6.hoplimit": 64, "ip6.nexthdr": 6, "src_port": 52938, "dest_port": 80, "tcp.seq": 3860706922, "tcp.ackseq": 0, "tcp.window": 64800, "tcp.offset": 0, "tcp.reserved": 0, "tcp.urg": 0, "tcp.ack": 0, "tcp.psh": 0, "tcp.rst": 0, "tcp.syn": 1, "tcp.fin": 0, "tcp.res1": 0, "tcp.res2": 0, "tcp.csum": 50192, "oob.in": "eth2", "oob.out": "", "src_ip": "fde4:8dba:82e1:1006::1001", "dest_ip": "fde4:8dba:82e1:1006::1002", "mac.saddr.str": "08:00:27:5b:f8:27", "mac.daddr.str": "08:00:27:2d:64:2b", "mac.str": "08:00:27:2d:64:2b:08:00:27:5b:f8:27:86:dd"}

後は適当にログコレクタで JSON パースして、分析環境に上げておけば、パケットの監視を行うことができる。

まとめ

というわけで、今回は nftables のログを JSON で別ファイルに出力する方法だった。ulogd インストールして、単純な設定するだけでできるので、割と簡単。

僕のサーバではとりあえずフィルタのログと、後出力パケットを limit かけてログって fluent-bit でパースして ElasticSearch に上げてる。で、プロトコル種別、宛先ポート番号とか別での時間帯によるパケット数推移とかを見てる。出力パケットからマルウェア検知とかできることもあるし、まあログを解析しやすいようにしておくと何かと便利。ま、今時 nftables 直接触ってる人も少ないと思うが、何か参考になれば。では、今回はこれで。

ACME 対応 Private CA を手軽に立てる

2023-05-19T19:55:20+09:00

今日のネットワーク通信では、様々な中継ポイントを介すことが多い。これにより、様々な繋がりを作ることができるようになっている。しかしその反面、中継ポイントには様々な運用者が挟まることになり、盗聴や改竄といった不正を行いやすい状況になっている。そのため、通信の秘匿化、接続相手の認証が重要になる。そのような状況で、覇権を握っているのが TLS という仕組みになる。

TLS 通信では、大まかには、接続先から提供される証明書が妥当なものかを検証し、その情報を元に暗号通信のための情報を秘密裏に共有し、秘匿化された暗号通信路を確保する。証明書の検証が接続相手の認証に相当し、その後の暗号通信路の確保が通信の秘匿化に対応することになる。今回は、このうち証明書の検証の部分のみを扱っていく。認証は事前の何らかの情報共有が必要になる。単純にはそれぞれの接続先に対して認証情報を事前に確保しておくと認証は行えるが、今日の接続先が無数にある状況では、認証情報の管理方式に問題が出てくる。そこで、TLS 通信では、一部の認証局と呼ばれる機関の認証情報のみを事前に共有しておき、接続先は証明書を事前に認証局に認証してもらった上で交付し、認証局の認証部分を検証するようにすることで共有する認証情報を抑えつつ、柔軟で拡張性のある暗号通信の仕組みを提供する。

さて、TLS 通信の規格は全て公開されており、もちろん認証局も自分で開設することが可能である。認証局からの証明書の発行は元来は手動操作だったが、昨今は発行操作が規格化され、より認証局の運用は簡単なものになっている。今回はこの ACME というプロトコルで規格化された証明書発行フローの紹介と、そのフローに対応した認証局の開設、運用を caddy という Web サーバで行う方法を紹介する。

TLS 証明書と CA

TLS 通信における接続相手の認証は、サーバから送られたサーバ認証証明書データとその証明書データを使って作られた署名データによって行われる。これはデジタル署名の応用によるもので、TLS 1.3 では署名アルゴリズムとして RSA / ECDSA / EdDSA などの幾つかのアルゴリズムが使えるが、これらのアルゴリズムには共通して

公開鍵、秘密鍵のペアを発行し、
秘密鍵から生成した署名データが公開鍵で検証可能、すなわち署名データが必ず元データから対となる秘密鍵で生成したものであることを判定でき、
公開鍵からは秘密鍵が現実的に類推不可能である

という特徴がある。この特徴を利用することで、公開鍵を証明書データに入れておき、証明書データの公開鍵と対となる秘密鍵でクライアントからのリクエストを署名して署名データとして送ることで、通信相手を認証することができると言うわけだ。ただ、これには前提として、送られてきた証明書データが送り主のものであることをクライアントが保証できる必要がある。

単純にはこれには現存する全ての証明書をクライアントが把握していれば良いわけだが、現状 TLS が普及し、無数のサーバが存在する中で、全ての証明書を把握することはリソース的に難しいし、また管理するリソースが増えることで安全性の欠落を招きかねない。そこで重要となるのが PKI、日本語で公開鍵基盤と呼ばれる仕組みである。PKI とはまさに、公開鍵がその持ち主のものであることを保証する仕組みのことを指す総称である。TLS において最も広く用いられている PKI 規格として X.509 PKI [1] がある。X.509 では、PKI の機能を証明書の連鎖によって実現する。つまり、ある通信先の識別子が書かれた証明書を別の秘密鍵で署名しておき、そちらの対となる公開鍵をクライアントが知れるようにしておくことで、署名された証明書そのものは通信の際に取得しつつ、証明書に署名している公開鍵さえ事前に取得しておけばその公開鍵を使って取得した証明書が通信先が発行したものであることを保証できる。しかも複数の証明書の署名を1つの秘密鍵で行えば検証用に管理する公開鍵の数自体が減らせるということになる。このような証明書自体の署名検証に使う公開鍵をさらに別の証明書に埋め込んでおき、その証明書もまた別の証明書の公開鍵で署名するといったことを繰り返すことにより、無数にある末端の証明書をその証明書の連鎖で繋がれた数個の公開鍵だけ管理していれば検証することが可能になるというわけだ。X.509 はその証明書の連鎖の方式と、その連鎖を実現させるための証明書データなどの形式を規格化したものになる。

X.509 のアーキテクチャには、以下のエンティティが登場する:

末端エンティティ: PKI により保証された証明書を使用するシステム。
認証局 (Certification Authority、略して CA): 証明書に署名する第三者機関。
登録局 (Registration Authority、略して RA): 証明書申請者の本人性を審査・確認する機関。CA が行う場合もあるが、他の機関に委任されることもある。
CRL 発行者 (CRL Issuer): 証明書失効リスト (Certificate Revocation List、略して CRL) を生成して署名する機関。CA が行う場合もあるが、他の機関に委任されることもある。
リポジトリ (Repository): 証明書と CRL を管理、配布するシステム。

X.509 ではこれらのエンティティにより、以下のやりとりが行われることによって、PKI の管理を行う:

登録: CA に認証先を登録するプロセス。これは、RA を介して行われることもある。認証先は、末端エンティティもしくは別の認証局である。
証明書発行: 登録された認証先に対して CA が証明書を発行するプロセス。証明書が発行されるとリポジトリに登録される。
証明書更新: 古くなった証明書の代わりに CA から新しく証明書を発行するプロセス。公開鍵・秘密鍵のペアは定期的に更新されなければならないため、このプロセスは定期的に発生する。
証明書失効要求: 証明書を何らかの理由により有効期限前に失効させるべきであることを CA に通知するプロセス。証明書は有効期限を持ち、通常はその期限の満了まで有効だが、秘密鍵の漏洩など何らかの理由によりその有効期限前に証明書を失効させる必要が生まれる場合がある。その場合に CA に通知し、CA は CRL にその証明書を載せることを CRL 発行者に依頼し、リポジトリの更新とともに CRL を通じて証明書が失効されたことが証明書検証者に通知される。

X.509 はそれぞれのプロセスは規格化せず、それぞれの CA に任せるが、発行する証明書及び CRL の形式と、それらの検証方法を規格化している。まずは証明書の構造から見ていく。X.509 証明書は、

署名対象証明書 (To Be Signed Certificate、略して TBS Certificate): 証明書本体の情報。証明書の持ち主及び証明書を発行した CA の情報、認証先の公開鍵、有効期限などの情報が含まれている。載せられる情報については後述する。
署名アルゴリズム識別子 (Signature Algorithm): 署名に使うアルゴリズムの識別子。
デジタル署名 (Signature Value): 署名対象証明書に対して署名アルゴリズム識別子に示される署名アルゴリズムで生成された CA による署名。これにより、署名対象証明書が改竄されることを防ぎつつ、CA から発行されたものであることが保証できる。

の3つにより構成される。署名対象証明書には、以下の情報が載っている:

バージョン: X.509 のバージョン。X.509 は v1 から今までバージョン更新が2回あり、最新の v3 が現在最も多く使用されているバージョンである。この記事では、v3 しか扱わないので、基本ここは 3 が埋まってると思って良い。
シリアル番号: 証明書発行者毎に各証明書に振られる一意な正整数による番号。つまり、各証明書は発行者とシリアル番号により一意に定まる。
署名アルゴリズム識別子: これは証明書発行の際与えられた識別子で、証明書本体の署名に使われたアルゴリズムの識別子と一致している必要がある。
発行者 (Issuer): 証明書発行元 (認証元) を識別する名前。空でない key-value による列で定義される。標準的には、国 (country)、組織 (organization)、組織単位 (organizational unit)、識別名の修飾子 (distinguished name qualifier)、州または地方の名前 (state or province name)、共通名 (common name) を key とした属性が埋められるようにすることが規定されており、これらの属性が使われていることが多い。
有効性 (Validity): 証明書の有効期間。証明書が有効化される日時 (not before)、証明書の有効期間が終了する日時 (not after) が設定できる。
主体者 (Subject): 証明書の公開鍵により保証されるエンティティを識別する名前。発行者名と同じく、空でない key-value による列で定義される。ただ、後述するが昨今は個人情報保護の観点もあって、共通名のみ埋める CA も結構出てきている。一般には、TLS 用の末端エンティティの場合共通名にドメイン名が用いられるのが一般的で、これを前提に HTTPS の意味論が規定されていた時代もあったが、今は代わりに後述する subjectAltName という拡張フィールドで明確にドメイン名を指定するのが一般的で、共通名の検証は HTTPS では禁じられている [2]。CA 証明書の場合は、発行する証明書の発行者と同じにする必要がある。
主体者公開鍵情報 (Subject Public Key Info): 主体者の検証に使う公開鍵と検証用の署名アルゴリズムの識別子。主体者が TLS 用の末端エンティティであれば TLS で使う公開鍵が、CA であれば発行された証明書の署名検証用に使う公開鍵が書かれることになる。
拡張 (Extensions): key-value により載せられる任意の拡張で、CA用の独自の情報を埋め込んだりできる。X.509 内で標準的に規定されており、証明書検証に影響を与える拡張もある。

他に一意識別子が載せられるが、これは現在は非推奨で特に要件は設けられておらず、載せても載せなくても良い。他に標準拡張として

鍵識別子: 鍵を識別する識別子。発行者、主体者それぞれに対して付加できる。
鍵使用目的 (Key Usage): 証明書に含まれる公開鍵の使用目的。複数指定可能。デジタル署名 (digitalSignature)、否認防止 (nonRepudiation)、鍵暗号化 (keyEncipherment)、データ暗号化 (dataEncipherment)、鍵交換 (keyAgreement)、証明書署名 (keyCertSign)、CRL署名 (cRLSign)の中から選ぶ。鍵交換についてはさらにデータ暗号化 (encipherOnly)、データ復号 (decipherOnly)の制御が指定できる。
証明書ポリシー (Certificate Policies): 証明書及びその証明書による証明書パスに連なる証明書の利用目的を表すデータ。今回は詳しく触れない。
ポリシーマッピング (Policy Mappings): CA 証明書において、ポリシー間のマッピングを規定するデータ。今回は詳しく触れない。
主体者別名 (Subject Alternative Name): 主体者の別名。複数指定可能。複数の末端エンティティについて、一つの証明書を使いたい時に用いられる。TLS 用証明書では慣例的に、主体者名に証明書識別のための共通名を設定し、主体者別名でドメイン名 (DNS 名) を指定するのが一般的。
基本制約 (Basic Constraints): 主体者が CA であるか、及びこの証明書が含まれる証明書パス中の中間証明書の最大の数 (最大長) を規定。拡張と言いながらこの拡張は必ず含める必要がある。つまり、X.509 では、CA 証明書かどうかを必ず規定する必要があるため、証明書署名用の証明書を、末端エンティティ用に使うことはできない。証明書パスの最大長は、CA 証明書である場合のみ指定できる。
ポリシー制約 (Policy Constraints): CA 証明書の場合に、受け入れ可能なポリシーを規定する。今回は詳しく触れない。
拡張鍵使用目的 (Extended Key Usage): 鍵使用目的に加えて追加で指定できる公開鍵の使用目的。サーバ認証 (serverAuth)、クライアント認証 (clientAuth)、コード署名 (codeSigning)、メール保護 (emailProtection)、電子タイムスタンプ (timeStamping)、OCSP署名 (OCSPSigning)が指定できる。また特別に、任意の目的に利用可能 (anyExtendedKeyUsage) であることが指定できる。
CRL 配布点 (CRL Distribution Points): CRL の取得方法を規定する。複数指定可能。いくつか項目が指定できるが、基本的には CRL がダウンロードできる URI だけが指定されていることが多い。
任意ポリシー禁止 (Inhibit anyPolicy): 証明書ポリシーで anyPolicy の使用を禁じることを規定する。今回は詳しく触れない。
機関情報アクセス (Authority Information Access): 証明書の発行者に関するサービスへのアクセス方法。CA 証明書の配布 URL や、OCSP レスポンダの URL などが書いてある場合が多い。

他にもいくつか標準拡張はあるが、主なものはこんな感じ。これらの情報を元に、X.509 では証明書パスが与えられた時に以下を検証する:

証明書パスの出だしはトラストアンカーに載っている、つまり既に知っている証明書である。
- 一般にこの出だしの証明書をルート証明書といい、その証明書の発行元 CA をルート CA という。ブラウザや OS には信頼するルート CA の証明書のデータベースがインストールされており、これが X.509 におけるトラストアンカーとなっている。
- ルート CA は発行者が自分自身になっている自己署名になっている場合が多い。このような他の認証局の認証によらずトラストアンカーによる認証を受ける必要がある CA を、自己認証 CA と呼んだりもする。
証明書パスに載っている証明書は、出だしを除いて、その証明書の発行者名と一つ手前の証明書の主体者名が一致しており、一つ手前の証明書の主体者公開鍵で署名が検証できる。
証明書パスに載っている証明書は、検証時刻においてCRL に載っておらず全て有効期間内である。
証明書パスに載っている証明書は、拡張で規定される制約を満たす。

これにより、TLS においてルート CA までの証明書パスをサーバから取得すれば、ルート CA 証明書を持っているだけで、X.509 PKI と主体者名による判定により公開鍵が主体者のものであることが保証できるというわけだ。

HTTPS サイトの X.509 証明書を見るビュワーは、大体どのブラウザにも搭載されてるので、結構手軽にみることができる。OpenSSL コマンドで見ることも可能だ。例えば、我らが github.com の証明書は以下のように見ることができる:

$ openssl s_client -connect github.com:443 -showcerts
CONNECTED(00000005)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert TLS Hybrid ECC SHA384 2020 CA1
verify return:1
depth=0 C = US, ST = California, L = San Francisco, O = "GitHub, Inc.", CN = github.com
verify return:1
write W BLOCK
---
Certificate chain
0 s:/C=US/ST=California/L=San Francisco/O=GitHub, Inc./CN=github.com
i:/C=US/O=DigiCert Inc/CN=DigiCert TLS Hybrid ECC SHA384 2020 CA1
-----BEGIN CERTIFICATE-----
MIIFajCCBPGgAwIBAgIQDNCovsYyz+ZF7KCpsIT7HDAKBggqhkjOPQQDAzBWMQsw
CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMTAwLgYDVQQDEydEaWdp
Q2VydCBUTFMgSHlicmlkIEVDQyBTSEEzODQgMjAyMCBDQTEwHhcNMjMwMjE0MDAw
MDAwWhcNMjQwMzE0MjM1OTU5WjBmMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2Fs
aWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZyYW5jaXNjbzEVMBMGA1UEChMMR2l0SHVi
LCBJbmMuMRMwEQYDVQQDEwpnaXRodWIuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0D
AQcDQgAEo6QDRgPfRlFWy8k5qyLN52xZlnqToPu5QByQMog2xgl2nFD1Vfd2Xmgg
nO4i7YMMFTAQQUReMqyQodWq8uVDs6OCA48wggOLMB8GA1UdIwQYMBaAFAq8CCkX
jKU5bXoOzjPHLrPt+8N6MB0GA1UdDgQWBBTHByd4hfKdM8lMXlZ9XNaOcmfr3jAl
BgNVHREEHjAcggpnaXRodWIuY29tgg53d3cuZ2l0aHViLmNvbTAOBgNVHQ8BAf8E
BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMIGbBgNVHR8EgZMw
gZAwRqBEoEKGQGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFRMU0h5
YnJpZEVDQ1NIQTM4NDIwMjBDQTEtMS5jcmwwRqBEoEKGQGh0dHA6Ly9jcmw0LmRp
Z2ljZXJ0LmNvbS9EaWdpQ2VydFRMU0h5YnJpZEVDQ1NIQTM4NDIwMjBDQTEtMS5j
cmwwPgYDVR0gBDcwNTAzBgZngQwBAgIwKTAnBggrBgEFBQcCARYbaHR0cDovL3d3
dy5kaWdpY2VydC5jb20vQ1BTMIGFBggrBgEFBQcBAQR5MHcwJAYIKwYBBQUHMAGG
GGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBPBggrBgEFBQcwAoZDaHR0cDovL2Nh
Y2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0VExTSHlicmlkRUNDU0hBMzg0MjAy
MENBMS0xLmNydDAJBgNVHRMEAjAAMIIBgAYKKwYBBAHWeQIEAgSCAXAEggFsAWoA
dwDuzdBk1dsazsVct520zROiModGfLzs3sNRSFlGcR+1mwAAAYZQ3Rv6AAAEAwBI
MEYCIQDkFq7T4iy6gp+pefJLxpRS7U3gh8xQymmxtI8FdzqU6wIhALWfw/nLD63Q
YPIwG3EFchINvWUfB6mcU0t2lRIEpr8uAHYASLDja9qmRzQP5WoC+p0w6xxSActW
3SyB2bu/qznYhHMAAAGGUN0cKwAABAMARzBFAiAePGAyfiBR9dbhr31N9ZfESC5G
V2uGBTcyTyUENrH3twIhAPwJfsB8A4MmNr2nW+sdE1n2YiCObW+3DTHr2/UR7lvU
AHcAO1N3dT4tuYBOizBbBv5AO2fYT8P0x70ADS1yb+H61BcAAAGGUN0cOgAABAMA
SDBGAiEAzOBr9OZ0+6OSZyFTiywN64PysN0FLeLRyL5jmEsYrDYCIQDu0jtgWiMI
KU6CM0dKcqUWLkaFE23c2iWAhYAHqrFRRzAKBggqhkjOPQQDAwNnADBkAjAE3A3U
3jSZCpwfqOHBdlxi9ASgKTU+wg0qw3FqtfQ31OwLYFdxh0MlNk/HwkjRSWgCMFbQ
vMkXEPvNvv4t30K6xtpG26qmZ+6OiISBIIXMljWnsiYR1gyZnTzIg3AQSw4Vmw==
-----END CERTIFICATE-----
1 s:/C=US/O=DigiCert Inc/CN=DigiCert TLS Hybrid ECC SHA384 2020 CA1
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/ST=California/L=San Francisco/O=GitHub, Inc./CN=github.com
issuer=/C=US/O=DigiCert Inc/CN=DigiCert TLS Hybrid ECC SHA384 2020 CA1
---
No client certificate CA names sent
Server Temp Key: ECDH, X25519, 253 bits
---
SSL handshake has read 2801 bytes and written 351 bytes
---
New, TLSv1/SSLv3, Cipher is AEAD-CHACHA20-POLY1305-SHA256
...
---
read R BLOCK
read R BLOCK
^D

この場合の証明書パスは

depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert TLS Hybrid ECC SHA384 2020 CA1
verify return:1
depth=0 C = US, ST = California, L = San Francisco, O = "GitHub, Inc.", CN = github.com
verify return:1

になっており、それぞれの depth に続く key-value が主体者名を表す。ルート CA が DigiCert のもので、そこから DigiCert TLS CA 用の証明書が発行され、さらに DigiCert TLS CA から github.com の末端エンティティ証明書が発行されている。ルート CA と末端エンティティの間の証明書を持つ CA を中間 CA と呼んだりする。今回は中間 CA 一つの証明書が 3 つ連なる証明書パスとなっている。 -----BEGIN CERTIFICATE-----、 -----END CERTIFICATE----- で囲まれたデータが証明書データになる。証明書データは、ASN.1 という表現により規定されてるのだが、その符号化方式は幾つかある。一般的にはバイナリ表現として DER、表示用の表現として DER を Base64 エンコードする符号化形式 PEM が一般に用いられている。TLS では DER でやりとりが行われ、OpenSSL コマンドはそれを PEM 形式で表示しているというわけだ。この符号化されたデータの中身を見たい場合は、証明書データを以下の要領で OpenSSL に食わしてやれば良い:

$ cat github.com.pem
-----BEGIN CERTIFICATE-----
MIIFajCCBPGgAwIBAgIQDNCovsYyz+ZF7KCpsIT7HDAKBggqhkjOPQQDAzBWMQsw
...
-----END CERTIFICATE-----
$ openssl x509 -in github.com.pem -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            0c:d0:a8:be:c6:32:cf:e6:45:ec:a0:a9:b0:84:fb:1c
    Signature Algorithm: ecdsa-with-SHA384
        Issuer: C=US, O=DigiCert Inc, CN=DigiCert TLS Hybrid ECC SHA384 2020 CA1
        Validity
            Not Before: Feb 14 00:00:00 2023 GMT
            Not After : Mar 14 23:59:59 2024 GMT
        Subject: C=US, ST=California, L=San Francisco, O=GitHub, Inc., CN=github.com
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:a3:a4:03:46:03:df:46:51:56:cb:c9:39:ab:22:
                    cd:e7:6c:59:96:7a:93:a0:fb:b9:40:1c:90:32:88:
                    36:c6:09:76:9c:50:f5:55:f7:76:5e:68:20:9c:ee:
                    22:ed:83:0c:15:30:10:41:44:5e:32:ac:90:a1:d5:
                    aa:f2:e5:43:b3
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Authority Key Identifier:
                keyid:0A:BC:08:29:17:8C:A5:39:6D:7A:0E:CE:33:C7:2E:B3:ED:FB:C3:7A

            X509v3 Subject Key Identifier:
                C7:07:27:78:85:F2:9D:33:C9:4C:5E:56:7D:5C:D6:8E:72:67:EB:DE
            X509v3 Subject Alternative Name:
                DNS:github.com, DNS:www.github.com
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 CRL Distribution Points:

                Full Name:
                URI:http://crl3.digicert.com/DigiCertTLSHybridECCSHA3842020CA1-1.crl

                Full Name:
                URI:http://crl4.digicert.com/DigiCertTLSHybridECCSHA3842020CA1-1.crl

            X509v3 Certificate Policies:
                Policy: 2.23.140.1.2.2
                CPS: http://www.digicert.com/CPS

            Authority Information Access:
                OCSP - URI:http://ocsp.digicert.com
                CA Issuers - URI:http://cacerts.digicert.com/DigiCertTLSHybridECCSHA3842020CA1-1.crt

            X509v3 Basic Constraints:
                CA:FALSE
            1.3.6.1.4.1.11129.2.4.2:
......-....c.K..6.!...;`Z#.)N.3GJr...F..m..%......QG..P..+.....G0E. .<`2~ Q....}M...H.FWk..72O%.6....!...~.|..&6..[...Y.b .mo..
    Signature Algorithm: ecdsa-with-SHA384
        30:64:02:30:04:dc:0d:d4:de:34:99:0a:9c:1f:a8:e1:c1:76:
        5c:62:f4:04:a0:29:35:3e:c2:0d:2a:c3:71:6a:b5:f4:37:d4:
        ec:0b:60:57:71:87:43:25:36:4f:c7:c2:48:d1:49:68:02:30:
        56:d0:bc:c9:17:10:fb:cd:be:fe:2d:df:42:ba:c6:da:46:db:
        aa:a6:67:ee:8e:88:84:81:20:85:cc:96:35:a7:b2:26:11:d6:
        0c:99:9d:3c:c8:83:70:10:4b:0e:15:9b

ACME による証明書発行

さて、X.509 PKI により、認証局の運営とそこから発行された証明書の管理がちゃんとできれば、技術的に TLS 通信の前提となる PKI の機能を実現できることは分かった。ただ問題は、認証局の運営をどうするかである。ここら辺は長年そこまで厳密な規格はなされておらず、各 CA がブラウザなどの要望を踏みながら各自が手続きを整備している。一般的なフローは、

証明書に載せる公開鍵、主体者名などの情報が書かれた証明書署名要求 (Certificate Signing Request、略して CSR) を作成
CA に CSR と本人確認情報などを渡す
CA (RA に委任している場合は RA) はドメインの所有者であることや本人確認情報などの審査を行う
審査が通ったら CSR を元に証明書を発行

という感じだ。審査内容は、CA によってまちまちだが、主要な CA・ブラウザにより構成された CA/Browser Forum である程度の基準値が設けられており [3]、以下の区分がある:

ドメイン認証 (Domain Validated): エンティティのドメインを、証明書署名要求者が所有していることが確認された証明書。そのドメインにメールを送る、トークンを TXT レコードで設定するなど確認方法はいくつかある。
実在組織認証 (Organization Validated): 主体者名に指定された組織が実在し、そのエンティティを所有していることが確認された証明書。
実在個人認証 (Individual Validated): 主体者名に指定された個人が実在し、そのエンティティを所有していることが確認された証明書。
拡張認証 (Extended Validated): CA/Browser Forum の最初の仕事で、標準化された法的な実在性確認などを含む認証プロセスを通して主体者が確認された証明書。

ここら辺は色々歴史的な紆余曲折があり、ドメイン認証は PKI としての機能には沿ったもので運用コストも安い反面ドメインを持っていれば誰でも取れるためフィッシングの温床になり、それを問題視して拡張認証が生まれたが、世の中の人はサイトの所有者情報をそこまでちゃんと見ていないことが分かって実はフィッシング対策にそれほどならなかったなど、まあ色々ある。最近の潮流としては、主体者情報に組織、個人の情報を含める場合はちゃんと実在認証をやる、PKI 技術にただ乗っかりたい場合は主体者情報はその証明書を使用するエンティティを識別できる情報を共通名に入れるだけにしておいて、ドメイン認証は最低限やるが、実在確認までは必要ないといった感じに落ち着いてきたように思う。さて、その潮流において、ドメイン認証だけであれば別に大層なことをやる必要はなく、手続きをサーバ間のやり取りのみで自動化できる。そのような中で生まれたのが Let's Encrypt というサービスである。Let's Encrypt はドメイン認証証明書の発行手続きを完全自動化することで、CA 業務コストをサーバ管理のみにし、TLS を無償で使用できるようにすることを目指したサービスである。そして、このサービス提供の中で生み出され規格化された証明書自動管理プロトコルが Automatic Certificate Management Environment、略して ACME になる。

ACME は HTTPS 上でサーバ-クライアントが JSON POST で話す割と今時のプロトコルで、

アカウント作成: サービス規約に同意し、CA のサービスを受け取る、クライアントのユーザ単位リソースを作成する。
証明書の注文: 証明書が必要なことを CA に伝え、発行手続きを開始する。
識別子の承認: CA から証明書発行に必要な認証手続きを受ける。
証明書の発行: 注文して認証された証明書を取得する。
証明書の失効: 証明書を有効期間前に失効させたい旨を CA に伝える。

の機能をサポートしている。初めて証明書を発行するまでの流れは以下のようになる:

アカウント作成
- このステップでは、証明書を管理するためのサービスユーザ単位を発行する。
- クライアントは、認証兼リクエスト署名検証用の公開鍵、サービス規約への同意の意思と、連絡先などの情報をサーバに渡すと、サーバからアカウントIDが発行される。
- クライアントは発行されたアカウント ID と秘密鍵を保存しておき、この後の手順では ID と秘密鍵から生成された署名をリクエストに含めるようにする。
証明書の注文
- このステップでは、要求される証明書の識別子の認証と証明書発行の手続きに入る。
- クライアントは発行したい証明書の主体者識別子をサーバに送り、サーバは認証手続きを開始し、クライアントに認証状態を取得できる URL と証明書発行手続きに進む URL を返す。
- 識別子の認証は単体で事前に行うこともできる。
- 識別子自体は、現在はドメイン名のみ対応している。これについては詳しくは後述する。
識別子の承認
- このステップでは、識別子が指し示すエンティティがクライアントから制御できること、つまりアカウントに所有されていることを確認する。
- クライアントは、認証状態を確認する URL から課題を取得し、課題への対応の準備ができたらサーバに通知する。サーバは課題への対応を確認し、識別子の承認を行う。クライアントは承認が行われるまで認証状態をポーリングしながら待つ。
- 課題の方式は現在 HTTP 検証、DNS 検証の2つがある。これについては後述する。
証明書の発行
- このステップでは、承認済みの識別子に対して証明書を発行する。
- クライアントは、証明書発行手続き用の URL から CSR をサーバに送り、サーバはその識別子が承認済みであること、CSR の内容が許容可能であることを確認し、証明書ダウンロード用 URL を返す。

証明書の更新時はアカウント作成を除くステップを繰り返す。これにより、クライアント-サーバ間の HTTPS でのやり取りのみで CA から証明書を受け取ることができる。

さて、後回しにした識別子の認証だが、ACME では現状認証方式としてドメイン認証のみ対応している。ただ、プロトコル自体は組織認証、拡張認証などにも対応できるよう設計されており、将来的にはそれらのサポートもされるかもしれない。ドメイン認証は、HTTP による検証と DNS による検証の2通りに対応している。HTTP 検証では、課題として受け取ったトークンとアカウントに紐づく鍵のフィンガープリントを http://<domain>/.well-known/acme-challenge/<token> にデプロイできることにより、そのドメインがアカウントに所有されているとみなす。DNS 検証では、 _acme-challenge サブドメイン、つまり _acme-challenge.<domain> の TXT レコードに、トークンとアカウントに紐づく鍵のフィンガープリントをデプロイできることにより、そのドメインがアカウントに所有されているとみなす。この部分のデプロイをクライアントが自動化できれば、検証も自動化することができる。

Caddy で CA を立てる

さて、ここまでで X.509 PKI における CA の役割、ACME による CA と末端エンティティとのやり取りの自動化について見てきた。では、実際に世の中でどう運用されているかだが、まず ACME クライアントの有名どころが Certbot で、ACME サーバとのやり取りと CSR の生成はもちろん、HTTP 検証に必要な項目を Web サーバにデプロイするところまでこなしてくれたり、有効期限によって証明書の再発行を制御する機構なども入っており、結構便利。Let's Encrypt 利用時はお馴染みという感じだろう。Certbot は接続先の ACME サーバとして Let's Encrypt をデフォルトで使うが、接続先をカスタマイズすることもできる。なので手元で ACME サーバを立てて、証明書を ACME 経由で作ることもできる。ACME 対応の CA は Let's Encrypt が自身が使っている Boulder という CA の実装を公開している。他にも smallstep CA というミニマルな実装がある。CA としての機能は欠けてるものも多いが最低限のものは揃ってる。今回紹介する Caddy はバックエンドで smallstep CA を使っている。

さて、今回紹介する Private CA は、Certbot をクライアントに使って、ACME サーバは Caddy という Web サーバで立てる方法だ。 Caddy を使う場合、OCSP レスポンダは諦める必要があるが、まあかなり小規模な常時 TLS 環境を手元で作りたいとかなら、割と手軽でそこまで困らないかなという感じ。 Caddy は割と面白い機能を持った Web サーバで、ACME クライアントの機能を備えて自動で証明書を取得したり更新してくれたり、Private CA を立ててそこから証明書を自動で発行して使ったりしてくれる。さらに、Private CA に対して ACME サーバを立てる機能も持っている。今回はこの機能を使っていく。

caddy のインストールは、https://caddyserver.com/docs/install に書いてある手順でできる。Debian なら、

$ sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
$ curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
$ curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
$ sudo apt update
$ sudo apt install caddy

の手順でリポジトリ追加してパッケージインストール可能。結構お手軽。Docker image もである: https://hub.docker.com/_/caddy

設定ファイルは /etc/caddy/Caddyfile にある。ドキュメントは https://caddyserver.com/docs/caddyfile。入れておくといい設定は、以下:

{
    auto_https disable_redirects
    skip_install_trust
}

1つ目は勝手に HTTP サーバが立つのを無効化する設定。Caddy はデフォルトで全てのサイトを HTTPS でサービングし、HTTP には HTTPS へのリダイレクトサーバを立てる。ドメインを指定する場合 Let's Encrypt から証明書を発行、IP アドレスを指定する場合自己署名証明書を発行する。ただ、勝手に 80 ポート占有されるのは微妙なので、リダイレクトの方は無効化しておく。2つ目は、Private CA のルート証明書を Java のトラストアンカーや ca-certificates に加えてくるおせっかい機能を止める。

Private CA の設定は、pki オプションで指定できる:

{
    pki {
        ca local {
            root_cn "My Local CA - 2023 ECC Root"

            intermediate_lifetime 30d

            root {
                cert /etc/pki/caddy/ca/local/root.crt
                key /etc/pki/caddy/ca/local/root.key
            }
        }
    }
}

root_cn オプションはルート証明書の共通名を指定する。 intermediate_lifetime は中間証明書の有効期間を 30 日に伸ばす。デフォルトは 7 日。ま、基本デフォルトの期間から変えなくていいと思う。root.cert / root.key はルート証明書とその秘密鍵のファイルを指定している。指定しない場合は自動生成してくれる。証明書の生成は、以下の要領でできる:

$ cat > cacert.cnf
[ req ]
distinguished_name  = req_distinguished_name
req_extensions      = req_ext
default_md          = sha512

[ req_distinguished_name ]
commonName                      = Common Name
commonName_default              = My Local CA - 2023 ECC Root

[ req_ext ]
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid:always, issuer:always
basicConstraints        = critical, CA:TRUE, pathlen:1
keyUsage                = critical, cRLSign, keyCertSign
$ openssl req -config cacert.cnf \
    -x509 \
    -newkey EC \
    -pkeyopt ec_paramgen_curve:secp384r1 \
    -pkeyopt ec_param_enc:named_curve \
    -days 3600 \
    -out /etc/pki/caddy/ca/local/root.crt \
    -passout 'pass:'
    -keyout /etc/pki/caddy/ca/local/root.key

これによりルート証明書を永続化しつつ、他のサーバに配布してトラストアンカーに入れておけば、Private CA から発行された証明書で HTTPS サーバを立てて通信できる。Caddy で ACME サーバを立てるには、以下の設定を Caddyfile に追加する:

acme.mylocal.domain:6100 {
    tls internal

    acme_server {
        ca local
        lifetime 10d
    }
}

これにより、6100 ポートからの acme.mylocal.domain ホストへのリクエストは ACME サーバで受けるようにできる。 tls internal は Private CA から発行された証明書を使う設定になる。この ACME サーバは Private CA から10日有効の証明書を発行する。デフォルトは 12 時間。流石に 12 時間は短いと思うが、基本 2 日以内にはしとく方がいいだろう。

この ACME サーバから nginx 向けに Certbot を使って証明書を発行してみる。まず、Certbot と Nginx をインストールする。Debian なら、

apt install -y nginx certbot

で入る。まず、Nginx の方で、Certbot の Web ルートをサービングする HTTP サーバを立てる:

server {
    listen 80;
    listen [::]:80;

    server_name _;

    location /.well-known/acme-challenge/ {
        allow all;
        root /var/www/certbot/;
        default_type "text/plain";
        try_files $uri =404;
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

次に certbot で証明書を発行する:

env REQUESTS_CA_BUNDLE=/etc/pki/caddy/ca/local/root.crt \
    certbot certonly
    --server https://acme.mylocal.domain:6100/acme/local/directory
    --webroot --webroot-path /var/www/certbot
    --domain www.mylocal.domain
    --email contact@myemail.domain
    --agree-tos
    --no-eff-email

REQUESTS_CA_BUNDLE は Python の環境変数で、トラストアンカーとなるルート証明書のバンドルファイルのパスを指定できる。今回は Private CA のルート証明書を指定している。 --server には、ACME サーバのディレクトリパスを指定する。デフォルトは、Let's Encrypt の https://acme-v02.api.letsencrypt.org/directory が使われているが、今回は Caddy の ACME サーバの URL を使っている。Caddy の場合、ルートパスは、 /acme/<CA name>/directory になる。webroot はトークンファイルをデプロイして HTTP サーバにそれをサーブしてもらい、HTTP 検証で課題をこなすモードで、 /var/www/cerbot にトークンファイルが置かれるのでそれを Nginx が ACME サーバに返すことで識別子の承認を得る。 agree-tos はサービス利用規約に同意するフラグで、 --no-eff-mail は指定したメールアドレスで電子フロンティア財団からのニュースを購読しないフラグ。これで、ドメイン設定などをちゃんとしていれば、 /etc/letsencrypt/live/www.mylocal.domain に証明書と秘密鍵などが発行される。

後は、nginx 側で HTTPS サーバに証明書を設定すればよい:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name www.mylocal.domain;

    ssl_certificate         /etc/letsencrypt/live/www.mylocal.domain/fullchain.pem;
    ssl_certificate_key     /etc/letsencrypt/live/www.mylocal.domain/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/www.mylocal.domain/chain.pem;

    add_header Strict-Transport-Security  "max-age=63072000; includeSubDomains" always;
    add_header X-Frame-Options            "SAMEORIGIN"                          always;
    add_header X-Content-Type-Options     "nosniff"                             always;
    add_header X-XSS-Protection           "1; mode=block"                       always;

    location / {
        return 200 "OK";
    }
}

証明書は定期的に更新する必要がある。特に ACME では、自動で管理できる分発行される証明書の有効期間が短くしてあることが多い。Private CA なら尚更、管理をルーズにする分有効期間は短くしておく方がいいだろう。さて、有効期間を短くする場合、手動での更新とかやってられないので、証明書更新の自動化が必要になってくるだろう。Debian の Certbot パッケージはデフォルトで weekly で全部の証明書更新をかける timer を入れてくれる。ただ、今回は weekly じゃ追いつかないのとルート証明書の指定が必要なので、自分で timer を書くのが良いだろう。まず、systemd oneshot service を以下の感じで書く:

[Unit]
Description=certbot renew service for www.mylocal.domain

[Service]
Type=oneshot
Environment=REQUESTS_CA_BUNDLE=/etc/pki/caddy/ca/local/root.crt
ExecStart=certbot renew \
    --cert-name www.mylocal.domain \
    --post-hook 'systemctl reload nginx'

これを /etc/systemd/system/certbot_renew_www.mylocal.domain.service におく。後はこの service を呼び出す systemd timer を以下の感じで書く:

[Unit]
Description=certbot renew timer for www.mylocal.domain
ConditionPathExists=/etc/letsencrypt/live/www.mylocal.domain/fullchain.pem

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

これを /etc/systemd/system/certbot_renew_www.mylocal.domain.timer におく。後は、 systemctl start certbot_renew_www.mylocal.domain.timer で timer を開始しておけば、daily で更新が走るようになる。後はルート証明書をブラウザにインストールするなりしておけば良い。

これで、プライベートネットワーク内、プライベートアドレスについても手軽に証明書発行して TLS 対応できる。CRL 配布対応がないのが残念だが、小規模なオレオレ環境なら特に困らないだろう。

まとめ

今回は X.509 PKI の仕組みとその管理を自動化する ACME プロトコルについて紹介した。また、Caddy という Web サーバで、Private CA の ACME サーバを立て、証明書を自動発行し、プライベートネットワーク内で TLS 環境を構築する方法を紹介した。これによりプライベートネットワーク内であっても TLS 網が結構手軽に構築できるし、Let's Encrypt の検証環境を手元で構築したりもできる。

TLS プロトコル自体の説明は巷に結構あるのだが、X.509 PKI の情報となるとかなり限られるし、毎回調べることになってたので書いた。X.509 の拡張とかなんとなく指定してるものも多かったので、割と情報整理になってよかった。後、ACME もなんとなくの部分が多かったので、知識補強になったかなという感じ。ACME もうちょっと流行ってほしい。2020 年過ぎても証明書の手動更新してるのは流石になあって感じがある。まあ、TLS 必須と謳われてる割には CA/B は迷走してる感じもあるが。

では、今回はこれで。

[1]	https://datatracker.ietf.org/doc/html/rfc5280

[2]	https://datatracker.ietf.org/doc/html/rfc6125#section-6.4.4

[3]	https://github.com/cabforum/servercert

Mastodon へのシェアボタンを追加した

2023-03-08T21:54:34+09:00

Mastodon への記事共有を行うボタンを追加したので、その仕組みについてちょっと解説しとこうかなと思う。是非、利用してみてくれ。一番最後にあるぞ。

先行研究

Mastodon に移ってきてから、記事投稿機能は追加したかったのだが、そもそも分散的な Mastodon の世界において、共有先とはみたいな感じになってあまりとっかかりが見いだせなかった。そんな中で、マストドンのシェアボタンを自作した(追記あり)(今日から使えます) - Lambdaカクテルと言う記事を見つけた。この記事は、色々先行研究がまとまっていて、その上で改良版が提供されており、めちゃくちゃお世話になった。圧倒的感謝という感じ。ただ、モノは動かなかったので、自分で作ろうと相なった。

まず、僕が共有ボタンに求める要件は以下のようなことだった:

日本語対応している: Mastodon の場合基本共有ボタンのためにワンステップ必要になってくる。つまり、分散的だからこそ、どこに共有すればいいか分からないので、共有先を選択する中継点が必要になる。このブログの読者は基本日本語読者なので (というか、記事は日本語で書かれているので)、この中継点は日本語に対応しておいてほしい。
読者が信用しているサービスの他に、共有のために不透明なサービスを通したくない: 読者にとって、記事共有なんてそれほど大した動機でやるモノではないので、記事共有のためだけになんか共有先以外のアカウント作らなくちゃいけないとか、なんかよく分からないサーバに情報送らないといけないとか、そういうのが必要になるサービスは避けたかった。一番良いのは、コードがオープンになっていて、ブラウザ内で操作が完結するようなもの。
何か問題があった時の対応がスムーズ: Mastodon は結構進化が早いのが特徴だと思っていて、これは良い反面色々壊れやすいという面もあると思う。そうなると自然、共有ボタン側も随時進化が必要になってくる。そういう問題に対しての対処が継続的に行われていく体制があるようなサービスがいいなという感じ。

一応上の記事に載ってるものは一通り試してみたんだけど、この点であまり満足がいくものがなかった。で、記事のシェアボタンのコードを読んだ感じ割と簡単に作れそうなので、どうせなら僕個人の需要に合わせた Web アプリ作ってみるかとなった。実際、基本的なコードは3時間ぐらいで動くものができたので、まあその程度っぽい。

共有ボタンの仕組み

共有ボタンの使い方に関しては、https://mizunashi-mana.github.io/mastodon-front-gateway/add-share-button/ を見てくれって感じ。ボタンの動作としては、

https://mizunashi-mana.github.io/mastodon-front-gateway/share?text={{text}}&url={{url}} というリンクに飛ぶ
共有先の情報を入力する画面が開く
共有先の情報入力して共有ボタン押すと、 https://your.mastodon/share?text={{text}}&url={{url}} に飛ぶ

という感じ。 https://mizunashi-mana.github.io/mastodon-front-gateway/share?text={{text}}&url={{url}} は完全にクライアントサイドだけで動くアプリとなっていて、共有ボタンを押すと、

ユーザIDが URL だったら、そのオリジンを共有先に設定
ユーザIDが URL じゃなかったら、ドメイン部分をパースして、そのドメインの WebFinger にアクセスしてユーザIDの情報を取得し、プロフィール URL のオリジンを共有先に設定
「ブラウザにユーザIDを保存」にチェックついてたら、ブラウザのローカルストレージにユーザID保存。次回、ローカルストレージからユーザID補完
共有先のオリジンの /share をクエリパラメータ渡して開く

みたいな挙動になる。これを JavaScript でやってる感じ。自動遷移機能というのもつけていて、これは単にローカルストレージにそういうオプション追加で保存して、次回開いた時ローカルストレージにそういうオプション載ってれば、自動で共有処理が走るだけ。自動遷移は、https://mizunashi-mana.github.io/mastodon-front-gateway/reset/ でリセットすれば解除できる。30日の有効期限もつけてるので、期間空いて解除の仕方分からんくなっても、多分大丈夫。

技術スタックとしては、

View フレームワークは、 React。これも慣れ。もうこれでいいじゃんってなって抜け出せない。
国際化対応フレームは、 i18next。これも慣れ。まあちょっと不便な点はあるが、基本これでいいなって感じ。
CSS フレームワークは、 Tailwind。なんか慣れた。まあ、正直こんぐらいなら大人しく style 直接書けばいいじゃんと思わなくはない。
フォントフレームワークは、 FontAwesome。レパートリー豊富だしね。ただ、最近 SVG の書き方覚えたので、簡単なのは自分で書けばいいじゃんってなってる。
バンドルツールは、 webpack 。これも慣れ。まあ、辛い点はあるが、そこまで大きく困ってることもない。というか、他も辛くて、満足いくものがない。

という感じ。改めて書いてみると慣れがほとんどだな。その内時代に取り残されそう。

コードは、https://github.com/mizunashi-mana/mastodon-front-gateway に公開してて、GitHub Pages へのデプロイ方法まで揃ってるんで、自分で立てたかったらフォークして適当に設定変えてどっかにデプロイして貰えばいいし、https://mizunashi-mana.github.io/mastodon-front-gateway/add-share-button/ をそのまま使ってもらってもいいって感じ。CDN サービス契約して、CI さえなんとかすれば普通にそれだけで立つんで、ま、ご随意にという。

共有ボタン自体は、 a タグでリンクすれば終わり。https://mizunashi-mana.github.io/mastodon-front-gateway/add-share-button/ に一応幾つかサンプル載せてる。サンプルのロゴは公式から引っ張ってきて AGPL なので使いにくいかも。ま、その辺は好きに変えてくれ。というか、AGPL じゃないいい感じの再頒布条件の Mastodon ロゴ募集中です。コピーライトさえ載せてて、免責特記さえあれば、自由に再頒布可能とかだと嬉しい。

まとめ

というわけで、Mastodon への共有ボタン用の Web アプリ作ってみたので、仕組み紹介という感じだった。そして、共有ボタン追加してみた。是非、使ってみてくれ。以上。

双方向型検査: 検査と構築の融合

2023-02-21T22:45:32+09:00

単純型付きラムダ計算へ多相型を導入した拡張として System-F という体系がある。これは、通常の型付きラムダ項に、型の量化と特殊化を行う構文拡張を加えたもので、有限の項で様々な型に対応する共通のプログラムを表現できるようになる。このような表現力の拡張は、理論上も応用上も重要であり、多くの研究が行われた。型推論も題材の一つになる。System-F はパラメータ多相、いわゆるジェネリック型をプログラミング言語に取り入れる際重要な基盤になることが期待され、この拡張へ型推論が提供できれば応用範囲はかなり広がるだろう。しかし、この問題については、Wells により型推論が決定不能であることが示され [1]、一つの決着がついている。

さて、このような背景から、System-F の型推論の研究は、完全な型推論は諦め、実用的な範囲の少し力を落とした型推論を考えるのが一般的だ。その中でも、推論方法のアプローチとして、大きく2つの流派がある。一つが、System-F そのものの機能を落としたある程度完全な型推論が行える体系を考えるというものだ。このアプローチにより、大きく成功を収めたのが HM 型システムと呼ばれる体系だ。HM 型システムでは、System-F の強力な型の抽象化の機能を実用的な範囲、特に制限をかなり加えた量化と特殊化が、抽象と適用が連なった構文要素の糖衣についてだけ行えるようにするといった体系に弱めることで、いわゆる完全な型推論とまではいかないまでも、型付け可能性のある項についてある程度代表的な型を推論できる方法を提供する。もう一つのアプローチは、System-F そのものの機能は落とさず、型推論ができる範囲を明示し、その範囲についてある程度実用的な型推論を行おうというものである。今回紹介する双方向型検査というのは、このアプローチにより推論を伴った型検査を提供する技術体系で、こちらも一定の成果を上げている。特に、HM 型システムは、結局のところ機能を制限した System-F とは異なる体系に焦点を当ててのアプローチだったが、こちらのアプローチは元の体系の機能自体は落とさないため、方法論自体は System-F 以外にも流用しやすい。実際、双方向型検査というのは、System-F の推論だけにとどまらず、依存型や積型・和型の入った体系など、かなり強力な機能が入った型システムについて、推論方法の基盤を提供してくれる [4]。

双方向型検査では、型検査モードと型構築モード (型推論モード) という2種類のモードを用意し、この2つを随時切り替えながら、型検査と推論を連動させた型システムにより、型検査を行うことができる。今回は、この双方向型検査を (可述的) System-F の型推論で提供する方法を紹介する。題材は

Jana Dunfield and Neelakantan R. Krishnaswami. 2013. Complete and easy bidirectional typechecking for higher-rank polymorphism. In Proceedings of the 18th ACM SIGPLAN international conference on Functional programming, ACM, Boston Massachusetts USA, 429–442. DOI: https://doi.org/10.1145/2500365.2500582

と

Simon Peyton Jones, Dimitrios Vytiniotis, Stephanie Weirich, and Mark Shields. 2007. Practical type inference for arbitrary-rank types. J. Funct. Prog. 17, 1 (January 2007), 1–82. DOI: https://doi.org/10.1017/S0956796806006034

一つ目は、双方向型検査の権威 Dunfield 先生による、可述的 System-F への双方向型検査の提供について。もう一つは、お馴染み SPJ による可述的 System-F の型推論方法についての比較検討といった感じ。System-F の型推論については、SPJ の方の題材は読んでみると色々参考になるだろう。今回はそのうち、双方向型検査の部分だけ、扱っていく。

可述的 System-F

System-F は元々、型の量化と特殊化の構文を入れた型付きラムダ計算だが、今回扱う言語では型推論を見据えて変数の型注釈を省略したり、明示的な特殊化ではなく型注釈から特殊化が自動的に行われるような体系を考える。具体的には、構文として以下のものを考える:

$\tau$ は単相型、 $\sigma$ が通常の型、 $e$ が項の構文となる。また、型システムの環境として、以下のものを使用する:

この時、以下の型システムを持つ言語が今回扱う対象になる:

前半3つが型の妥当性判定、後半が型付け判定になる。最後の2つが、型の量化と特殊化に当たる。通常、パラメータ多相を含む言語は、型変数の動く範囲について単相型のみを割り当てられるか、割り当てる型に制約が特にないか、つまり多相型ですら型変数によって割り当てられるかにより、言語全体の能力や性質が大きく変わってくることが知られている。前者を可述的 (predicative) であるといい、後者を非可述的 (impredicative) であるという。型推論においてもこの違いは大きく、一般に非可述的な言語の方が型推論が難しい。System-F は可述的な体系、非可述的な体系、それぞれ存在するが、今回は双方向型検査の紹介が目的なので、比較的難易度が低い可述的な System-F を対象として扱っていく。可述性は型システムにより決まり、今回の型付け判定では最後の型の特殊化規則で、置換が単相型に制限されている部分が可述性を決定づけている。これを、単相型でなく型全般にすると非可述的な体系になる。

Wells の結果 [1] から、このシステムにおいて型付け可能性、つまり以下の問題は決定不能であることが知られている:

項 $e$ について、 $\vdash e: \sigma$ となる $\sigma$ は存在するか？

もちろん完全な型推論方法があれば、 $\sigma$ の存在性は示せるため、逆に言えば完全な型推論も決定不能ということになる。

双方向型システム

これに対して、双方向型検査では、双方向の型システムを提供し、上記の型システムへの完全な型推論を諦める代わりに、双方向の型システムに対してはある程度完全な型推論アルゴリズムを提供する。双方向の型システムは以下のように定義される:

双方向型システムは2つの部分型関係 $\leq$ 、 $\preceq$ に依存するが、これについては後で見るとして、まずは双方向型システムの概要を見ていく。双方向型システムの判定は、

$\Gamma \vdash e \Rightarrow \sigma$ は、 $\Gamma$ の下で $e$ から型 $\sigma$ が構築される
$\Gamma \vdash e \Leftarrow \sigma$ は、 $\Gamma$ の下で $e$ は型 $\sigma$ で型付けできる

と読む。なお、紛らわしいので、元々の双方向でない型システムによる型付け判定を単方向型付け判定と呼ぶことにし、双方向型システムの判定をそれぞれ単に構築判定、型付け判定と呼ぶことにする。まず、単方向型付け判定と双方向型システムの対応関係を見てみる [2]:

このように、双方の部分型関係が反射的であり、 $\leq$ が具体化を判定できるなら、ラムダ抽象、型の量化と特殊化に適宜型注釈をつけることで、元の型システムを尊重するような型構築ができる。この型注釈を適宜つけなければいけないというのが今回のポイントで、前述のように今回の対象言語は型注釈なしの項に対して決定可能な推論を提供できないため、今回の双方向型システムでは適宜型注釈を要求することで決定可能な範囲の推論にとどめるようになっている。これが完全な型推論を目指すアプローチと異なる部分になる。とは言っても、決定可能な範囲で推論を増強することは可能だ。例えば AbsSyn、AnnAbsSyn の規則は入れなくても単方向型付けとの対応は取れるが、これがない場合抽象に対して一々注釈を入れなくてはいけないようになってしまう。この後紹介する部分型関係の規則についても、決定可能な範囲で推論できる範囲を増やす為いくつか工夫が施されている。

さて、では部分型関係の方も見ていく。部分型関係はそれぞれ型の量化、具体化を自動でいい感じにやってくれるようなものになる。また、上記の話から反射性を満たし、 $\leq$ については具体化をサポートする必要がある。また、単方向型付け規則に対する健全性への制約から、型注釈を足す程度で変換できる範囲での関係にしておく必要がある。この条件を満たすような $\leq$ 構成としては、例えば以下のようなものがある:

左が部分型関係の判定、右がその保証となる変換式になる。この定義であれば、変数、関数型はそのまま、多相型は Spec、Skol を組み合わせることで反射性を保証でき、特殊化もサポートしているため、条件を満たしている。さらに、この程度の判定であれば決定可能にできる。これについては後述する。 $\preceq$ の方は、関数型への変換に特化した部分型関係となっており、適用の際暗黙的変換として使用される。こちらも、幾つかデザインの幅があると思うが、例えば以下のようなものがある:

こちらは、基本的には型注釈をいい感じにつけて最終的に関数型に行きつくような範囲で、決定可能な判定が作れれば良い。例えば、以下のような判定を入れることもできる:

この拡張により、量化された型の構築ができる。まあ、今のところあまり有用な場面は思いついてないが、とりあえず関数型に行き着くような暗黙的変換の定義は色々できるという話。そこら辺は言語デザインに合わせて調整が必要になってくる部分だろう。ただ、暗黙的変換は一度採用してしまうとプログラマ側で変換を無効化すると言ったことができない。そこら辺は注意して設計するのが良いだろう。

さて、双方向型システムで型構築の導出をしてみた例が以下になる:

あまり型構築してるようには見えないかもしれないが、左から型を構築していき、構築した型を元に型付け判定をしていくのが基本的な流れだ。

推論アルゴリズム

さて、先ほどの導出例から分かる通り、双方向型システムはそれだけだと、アルゴリズミックに項に対して型を推論するのは難しい。ただし、この型システムに対して完全な、具体的に型を推論するアルゴリズムが構成可能だ。最後にこのアルゴリズムと、その構成の仕方を紹介しておく。

推論アルゴリズムの紹介に入る前に、まず型環境をアルゴリズム向けに拡張しておく:

$\hat{\alpha}$ はアルゴリズム中で生成される変数を表す。 $\hat{\alpha} = \tau$ は、 $\hat{\alpha}$ が $\tau$ と等価であるという制約を表す。 $\alpha \mapsto \hat{\alpha}$ は $\alpha$ が $\hat{\alpha}$ に置換されたことを表すマーカのような役割を持つ。詳細は、アルゴリズムを見ながら説明していく。もう一つ、アルゴリズムを説明する前に導入しておくものがある。それが型環境による置換だ:

この置換では、環境内にある等価制約を使って、アルゴリズム中で生成された変数を置き換えていく。これをアルゴリズム中で適用していくことで、単一化の代わりにしているという感じだ。では、実際のアルゴリズムを見てみる:

相変わらず部分型関係の推論は後回しにすることにして、まずは判定の読み方だが

$\Gamma \vdash e \Rightarrow \sigma \mid \Delta$ は、環境 $\Gamma$ が与えられた時、 $e$ から $\Gamma$ を尊重するような環境 $\Delta$ と型 $\sigma$ が構築される
$\Gamma \vdash e \Leftarrow \sigma \mid \Delta$ は、環境 $\Gamma$ が与えられた時、 $e$ は $\Gamma$ を尊重するような環境 $\Delta$ の下で型 $\sigma$ に型付けできる

という感じ。まあ、大雑把には、 $\Gamma$ に新しく生成した変数やら制約やらを入れた $\Delta$ が出力され、 $\Rightarrow$ ではさらに型も出力される、 $\Leftarrow$ は型 $\sigma$ が入力となっており、型検査が通るかがチェックされるという感じだ。この入出力を押さえておくと、双方向型システムから割と機械的に上記のアルゴリズム的型判定は生成できる。例えば、Abs 規則は、 $\Gamma$ 、 $\lambda x\ldotp e$ 、 $\sigma_1 \to \sigma_2$ が入力として与えられるので、そこから $e$ に対してまた判定をかけて、出力の環境 $\Delta$ を得るという感じ。なお、このアルゴリズム的型判定では環境の順序が大事で、基本的に変数が生成されて環境に突っ込まれた場合その変数に関する制約はその位置に突っ込まれるようになっているため、基本最終結果に使用する変数以外の環境情報はいらない。なので、環境に生成された変数以外の何かを最後に突っ込んでおくと、それ以降に突っ込まれたものは最終結果には影響しないことが保証される。これについては、この後の部分型関係の推論と導出例で詳しくみる。もう一つ、AbsSyn の例を見ておくと、この場合は $\Gamma$ 、 $\lambda x\ldotp e$ だけが入力となっている。この場合、型も頑張って作らないといけない。ただ、これは正直よく分からん。というわけで、ブラックボックスのまま推論を進めるため、変数 $\hat{\alpha_1}$ 、 $\hat{\alpha_2}$ を当てがい、推論を進めてみて、その中で明らかになった制約を出力環境に保持したまま、生成した変数を使って出力の型を作るということをする。後は、出力に制約が含まれていたらそいつで置換、含まれていなかったら自由変数として放置すれば、いい感じの型になる。

さて、2つほどそもそも何が入出力かわからない部分があると思う。定義をまだ出していない部分型関係の推論を使っている、Sub規則、App規則だ。まず、Subの方だが、こいつは単一化兼一般化兼具体化みたいな役割担ってるやつで、環境 $\Gamma$ 、型2つを入力として、その間に $\leq$ の関係が成り立つような、 $\Gamma$ を尊重する環境 $\Delta$ を出力する。App規則の方は、 $\Gamma \vdash \sigma_1 \preceq \sigma_2 \to \sigma_3 \mid \Delta$ のうち、 $\Gamma$ 、 $\sigma_1$ が入力で、 $\sigma_2$ 、 $\sigma_3$ 、 $\Delta$ が出力になる。こいつも、 $\Gamma$ を尊重するような $\Delta$ と、 $\Delta$ の下で $\preceq$ の関係が成り立つような $\sigma_2$ 、 $\sigma_3$ を計算するのが役割だ。

$\preceq$ の方が簡単なので、まずそちらから見てみる:

Refl は良い。Spec は元の規則通りだが、どういう具体化するか分からんので、そこを変数作ってブラックボックス化して凌ぐ感じ。で、元にない Unify というのが追加されているが、これが生成された変数にぶち当たった時用のやつで、この場合関数型になることだけ分かるので、関数型との等価制約だけ入れて、後の方はブラックボックスにして後続の推論におまかせという感じだ。ここで、制約を入れる位置が重要で、前述の通り元々の変数があった位置に入れることで、変数のスコープを調整している。

次に $\leq$ を見る。こちらはやや複雑:

前半が部分型の検査、後半がそれに伴う単一化という感じだ。前半はまあいいだろう。後半も実際はそれほど難しいことはしてなくて、単相型ならそのまま単一化、それ以外の場合は生成された変数か、関数型か、量化された型のいずれかなので、それぞれに規則があるという感じ。変数の場合は、環境の出現位置で順序をつけて、出現が早い方に単一化し、関数型の場合は両辺それぞれを単一化する。量化されてる型の場合だけ特殊で、この場合はどちらに量化された型が現れるかで Spec、Skol どちらの規則に合わせるかが変わるので、それぞれ調整している感じ。

こんな感じでやれば双方向型システムに対してある程度完全な推論がアルゴリズミックにできる。ある程度というのは、多少抽象度が高い推論をしてしまうことがあるかもしれないということで、残った変数に適宜型を割り当てられると完全になるみたいな感じ。さて、では実際に導出例を見てみる:

基本、推論に使う規則選びつつ、左から順にそのまま規則を適用していけば自然に導出が完成している。導出が完成しなければ推論失敗という感じ。あとは、規則を決定的にしてやれば、アルゴリズムになる。また、元の双方向型システムでの導出例と対応が取れてることも分かるだろう。このようにちゃんと規則が対応して適用できるようになっているため、完全な推論ができるという感じだ。完全性の証明は、題材には載ってないが Dunfield 先生が別途公開していて、https://research.cs.queensu.ca/home/jana/papers/bidir/ の Proofs から見れる。興味があれば見てみると良いだろう。

まとめ

というわけで、System-F の推論を考慮した双方向の型システムと、それに対する完全な推論アルゴリズムを紹介した。完全な推論はあれば便利だが、完全な推論ができない体系について言語の機能を落とさずにある程度実用的な推論を提供できるのは実用的には嬉しそうだ。ただ、双方向型システムは理論的にも面白いと思っていて、基本的に型推論の文脈では任意の項について主要型 (principal type) を見つける話から始まるわけだが、双方向型システムは主要型が決まる項と決めるのが難しい項を意味論として形式化できる能力があるところが面白いと思う。今回の System-F では、量化された型の導入は $\Leftarrow$ の判定しか持たない。逆に適用は $\Rightarrow$ しか持たない。これはそれぞれ、量化された型の導入について型付け判定はできるが主要型の探索は難しい、適用は部分項の型が決まれば主要型が自然に決まるみたいな性質に対応する。ここら辺は、一般的な (単方向の) 型付け判定より、言語の型のモデルをよく捉えられていると言えそうで、結構面白いなと思った。なお、じゃあ何かしら言語があった時、双方向の型システムをどうやって構成していけばいいかについては、

Jana Dunfield and Neel Krishnaswami. 2022. Bidirectional Typing. ACM Comput. Surv. 54, 5 (June 2022), 1–38. DOI: https://doi.org/10.1145/3450952

で、Dunfield 先生が step-by-step で解説してくれてる。これは割と参考になると思うので読んでみると良いんじゃないだろうか。

ところで、実はこの記事を書いたのは The appeal of bidirectional type-checking という記事がきっかけだった。この記事は「HM 推論はもう古い、これからは双方向型検査の時代！」という感じの文面 [3] で、まあそうなのかと乗せられた感じだ。ただ、導入部分で説明したように、そもそも HM 推論と双方向型検査ではかなりアプローチも達成できることも異なる。それに、HM 推論は具体的な体系に対する推論だが、双方向検査はより一般的な双方向の型システムに対しての検査を指す総称なので、比較対象としても成り立つかと言われると微妙だ。そして、双方向型システムをちゃんと一から構成するのはかなり難易度が高いと個人的には思う。なので、HM 推論周りの応用技術が使える範囲で済むなら、別に双方向型システムの方を採用する意義は薄そうだと思う。ただ、型システムをどんどん拡張していき、結構強い型の機能を入れていくなら、双方向型システムでモデル化してそこからアルゴリズムを作っていくのは結構合ってそうだ。別に難易度は易しくはないと思うが、無理に HM 推論を拡張するより扱いやすそうな印象がある (実用経験なしの言葉)。ま、一度触れてみて、HM 推論はもう古いとか言ってる人尻目に、自分の言語に合いそうだったら使っていくのがいいんじゃないだろうか。

ま、そんな感じで。今回はこれで。

[1]	(1, 2) J.B. Wells. 1999. Typability and type checking in System F are equivalent and undecidable. Annals of Pure and Applied Logic 98, 1–3 (June 1999), 111–156. DOI: https://doi.org/10.1016/S0168-0072(98)00047-5

[2]	これは Dunfield 先生の方の題材では完全性として提示されている関係性。題材には、証明は載っていないが、https://research.cs.queensu.ca/home/jana/papers/bidir/Dunfield13_proofs.pdf に証明が載っており、そこから復元したものになる。

[3]	まあ、そこまでは言ってないかもだが、ニュアンス的にはそんな感じの印象が強い。

[4]	元々 Scala や Agda を事例に出してたが、どちらも双方向型システムによるアルゴリズムは型検査に使ってなさそうだったので、訂正した。申し訳ない。

Mastodon 体験記

2023-02-19T00:58:46+09:00

Twitter から Mastodon に移住して一ヶ月ほど経ち、あんまり Twitter に戻る気がなくなってきた。せっかくなので、備忘録と案内を兼ねて、Mastodon への移住経緯とその後のことや、いろいろ感想などをまとめておこうと思う。とりあえず、一言で言うと Twitter には多分戻らんと思うのでよろしくという感じ。

Mastodon への移住

正直きっかけは今でもよく分からない。2023/01/30 に毎度ながら Twitter を開いて TL を見てたんだが、ふと寂しさを覚えた。割と、流速は速かったと思うので人がいなかったわけでも無さそう。そもそも「フォロー中」のタブが増えてから、割と Twitter で寂しさを覚えることは多かった。凍結騒動で色んな人が凍結され Mastodon に行ったみたいなことも聞いていたので、なんかあまり「フォロー中」のタブの人口がいないことが原因なんじゃないかみたいなのを思ったりした。自分が知らない間にみんな Mastodon に移行しており、僕だけ Twitter に取り残されてるんじゃないかという焦りが生まれ、とりあえず Mastodon を覗いてみることにしたという感じだ。これが最初のきっかけ。なお、実際に Mastodon に移行してみて分かったことだが、それほど移行した人は多くなく、Twitter の方がまだまだ人口は多い。つまり、寂しさの原因は人口ではないということだ。これについては後で考察する。とりあえず、きっかけはそんな雑な感じだ。

さて、そもそも僕は Mastodon にあまり興味がなかった。3年前くらいに話題になった時、アカウントを作って見たことはあった。が、使い方がよく分からなくて、それを調べるモチベもあまり生まれず、そのまま放置していたという感じだ。なんかサーバが各自で立てられる、Twitter 似の単文 SNS ぐらいの認識で、Mastodon に参入したわけだ。3年前くらいに作ったアカウントをそのまま動かす気にはなれず、少し前から気になっていた Vivaldi Social (https://social.vivaldi.net/) というところにアカウントを作ってみることにした。さて、ここで予備知識、というか僕は Vivaldi Social に入ってから身につけた知識だが、Mastodon というのはサーバソフトウェアの名前だ。GitHub 上に AGPL 3 or later でソースが公開されており、多数のコントリビュータによって開発されている。このサーバソフトウェアをインストールし、運用されているサーバが Mastodon インスタンスと呼ばれるもので、世界に無数にあるし、それぞれ入っているソフトウェアのバージョンも、管理人も、運用環境も異なる。中には、プログラムに独自の手が加えられたものも存在する。このようなインスタンスそれぞれに、ユーザがおり、それぞれ相互にやり取りをしている。公式の可愛らしいイメージを拝借してくると、以下のような状況というわけだ:

Vivaldi Social はそうしたインスタンスの中の一つで、ブラウザでお馴染み Vivaldi が管理する Mastodon インスタンスだ。Vivaldi アカウントがあれば利用できる。Vivaldi ブラウザでは、サイドメニューに標準で自己主張激しめの Vivaldi Social へのリンクが置かれている。Vivaldi は利用することがたまにあり、信頼感は少しあって、まああとは成り行きで Vivaldi Social を利用することにした。それまでアカウントは作る必要性を感じてなかったので作ってなかったが、この機会に作った。なお、Mastodon インスタンスは他にもたくさんある。例えば、僕の知ってるものでは以下のようなものがある:

Mastodon開発チーム運用鯖 (https://mastodon.social/): Mastodon開発チームが運用するインスタンス。誰でも歓迎。時々新規登録を閉鎖している。
Mastodon日本鯖 (https://mstdn.jp/): 元々、ぬるかるさんという方が個人で運用していたインスタンスで、誰でも歓迎というスタンスのインスタンス。ユーザ数が多く、また色々管理人が変遷していて、サーバ運用の難しさを感じる。
Pawoo (https://pawoo.net/): Pixiv が作ったインスタンス。創作活動推しで、ユーザ数が多く、やはり色々管理人が変遷している。
Fedibird (https://fedibird.com/): のえるさんという方が運用するインスタンス。Mastodon に独自の機能を色々加えたサーバを運用しているのが特徴。
Medium鯖 (https://me.dm/): ブログサービスでお馴染みの Medium が最近立ち上げたインスタンス。
セキュリティ情報共有鯖 (https://infosec.exchange/): 情報セキュリティ界隈の人たちが集まるインスタンス。Signal といい、情報セキュリティ界隈の人にはやっぱ透明性が担保されたツールへの需要があり、Mastodon はそこにマッチしたという感じか。

他にも多数の鯖があるし、個人で鯖を立てて SNS に参加している人も多い。僕はそんな壮大なネットワークの一角に参加したというわけだ。ネットは広大だわ。で、Vivaldi Social に入ってみた。以下は Vivaldi Social の画面:

今は面影はないが、当初はサイドメニューにあるホームのページが開いており、何も表示するものがない旨が表示されていたと思う。僕は最初、とりあえずサイドメニューにある項目を次々と開いていった。そうすると、2つだけ何かしらが表示される項目があった。それが「ローカル」ってやつと「連合」ってやつ。調べたところによると、Mastodon には Twitter と違って4つのタイムラインがあるらしい:

ホーム (HTL): 自分専用のタイムライン。自分のトゥート (Twitter でいうツイート) やフォローしてる人のトゥート、フォローしてる人がブースト (Twitter でいうリツイート) したトゥートが流れてくる。Twitter の「フォロー中」のタイムラインと同じ。
ローカル (LTL): インスタンスのタイムライン。そのインスタンスに参加している人のトゥートが流れてくる。
連合 (FTL): インスタンスに繋がっているユーザのタイムライン。ローカルに加えて、インスタンス内のユーザからフォローで辿った先のユーザのトゥートも流れてくる。自分が所属するインスタンス以外のインスタンスを、自分から見てリモートインスタンスというが、連合は自分が所属するインスタンス内の誰かがフォローしていれば、リモートインスタンスのトゥートも流れてくるというわけだ。これは、インスタンスから見たネットワーク全体のタイムラインということになるだろう。
ハッシュタグ: これは、上記サイドメニューに直接は項目としてないが、「エクスプローラ」という項目から辿った先のハッシュタグから覗けるタイムライン。Twitter のハッシュタグなどと同じく、ハッシュタグをつけた連合内のトゥートが流れてくる。活用方法は後述する。

というわけで、ホームは伽藍堂でハッシュタグは仕組みをあまり知らず、結果ローカルと連合でなんか流れてるなーと眺めてる存在になった。で、数分間そうしてなんとなく探検は終わった感があったので、トゥートをしてみることにした。記念すべき第一トゥートはこちら:

https://social.vivaldi.net/@mizunashi/109778117918755023

ところでこのトゥートを見てみると星マークに 5 という数字が並んでいるのが分かると思う。これは Twitter のいいねと同じ、お気に入り登録を 5 人のユーザがしてくれたということを表している。フォロワーが誰もいないのにお気に入りが 5 個付くのは、LTL / FTL がある Mastodon ならではだろう。ただ、僕は最初そもそも LTL / FTL などという仕組みすら知らなかったので、多少慌てた。どうやら、僕の雑な何気ないトゥートは不特定多数の人に見られたようだ。何も気づかないでこのままやべートゥート連発していたら、大惨事だ。さて、Mastodon は流石に全トゥートが LTL に流れるわけではない。トゥートの公開範囲は制御できるし、それも Twitter よりかなり細かく制御できる。Mastodon にはまずトゥート自体に以下の 4 つの公開範囲を設定できる [1]:

公開: ログインしてない人でもパーマリンクを知っていれば見れる。僕の第一トゥートはこれになっていた。通常地球儀マークが表示される。フォロワーの HTL に配信される他、LTL / FTL にも配信される。誰でも自由にブーストできる。
未収載: 基本公開と同じだが、LTL / FTL には配信されない。錠が外れた南京錠マークが表示される。
フォロワー限定: 名前の通り基本フォロワーだけしか見れない。基本というのは、メンションした人にも特別に見れる仕様らしいので。フォロワーの HTL とメンションした人の通知欄にのみ配信される。自分以外はブーストできない。Mastodon でも Twitter の鍵垢と同じくフォローを承認制にすることができ、そうすると自分が承認した人しか見れないようになる。だが、承認制にしない場合はフォローは自由にできるので、フォロワー限定は基本見ようと思えば見れる。なお、名称が途中で変わったらしく、非公開という単語が昔は使われていたっぽい。こっちを使っている界隈もまだ結構あるようだ。
ダイレクト: Twitter の DM とほぼ同じだが、Mastodon では通常のトゥートと区別がないようだ。メンションした人にだけ見れる。メンションした人の通知欄にのみ配信され、ブーストはできない。Twitter と同じく UI 的にはタイムラインが分かれているようだ。使ったことがないので使い勝手は分からない。

これはトゥートごとに設定でき、トゥートする時に変更できる。もちろんデフォルトの公開範囲設定もあり、ユーザ設定で指定できる。Vivaldi Social では、以下の設定ができた:

これは僕の設定だが、個々人にあった設定をまずは行うのが良いだろう。僕は第一トゥートの後慌ててこの設定項目を見つけ、色々設定できることを知った (行き当たりばったりライフ)。無事公開設定を理解し、意識的に公開を選んでのトゥートが以下:

https://social.vivaldi.net/@mizunashi/109778240439598295

これで無事挨拶を終え、その後はネットの海で未収載設定で潜伏しつつ、好き勝手なことを人様の迷惑を考えず垂れ流している。

さて、初日にもう一つやったことがフォローを増やして HTL を拡充させることだ。一番最初のフォローは、おすすめユーザという欄で唯一知っていた「数学ガール」作者の「結城浩」さん。とりあえずフォローポチっておいた。その後は、Twitter でアカウント開設告知しつつ Masaki Hara さんとかのフォロー欄から辿ってって見たことあるアイコンをフォローしていき、またそのフォロー欄辿るみたいなことしてた。もっといい方法あるのかもしれないが、今もその戦略とって人探してる。初日はそんな感じで終わった。

2日目はクライアント探し。Mastodon がサーバソフトウェアであることは言ったが、こいつには標準の Web UI も付属でついている。ただ、外部クライアント用の API も用意してあり、自由にクライアントソフトウェアを作成してそこでタイムラインを覗いたり、フォロー、トゥートなどが行える。まず、PC 用のクライアントとして TheDesk (https://thedesk.top/) というクライアントソフトウェアを見つけ、インストールしてみた。これは今でも愛用しており、非常にお世話になっている。今の僕の TheDesk の画面はこんな感じ:

このように Tweetdeck のような、あるいはそれより複雑なタイムライン表示ができる。ローカルは、人がいて常に色々会話されていて、SNS に人がいることを実感できるので表示している。フォローが少ない時は重宝していたが、最近はなくてもいいかなという気持ちになりつつはある。他はリストという機能を使っていて、これについては後で少し触れる。

デスクトップ版はこれでいいかなとなって、モバイル版もいくつか探した。iOS は色々探したり教えてもらったりして Ivory にいきつき、とりあえずこれを使ってみている。Ivory は Tweetbot の開発元が作成した iOS 版クライアントソフトウェアで、インストール・閲覧だけなら無料ででき、投稿などは有料のサブスクリプションが必要になる。とりあえず、僕はサブスクリプションには入らないで閲覧機能だけ使っている。使い勝手やデザイン的には、Twitter の公式アプリとあまり変わらない。Android の方は Subway Tooter というアプリを使っている。このアプリは結構癖があるが、個人的にはアクセスしている API がローディング時に表示されることが魅力的で使っている。これはソフトウェア技術者ならではの感性な気がするが、ログが出ているとなんとなくやっていることが分かって安心感がある。基本的な機能も揃っているため、機能面で困ることはあまりない。ただ、やっぱりモバイル向けだとデザイン面で辛いことが多いというのはある。画面が小さいし、タップでの操作が基本になるが、結構要素が多くて誤タップなどを誘発しがち。そこの操作感は微妙に感じることはある。とりあえず、基本は TheDesk を常用してるので、モバイル版はあまり使い込んでなく、不満を持つ機会が少ないというのはある。その内感想が変わっていくのかもしれない。

その後はフォロー増やしたり、色々調べたり、時折トゥートしたりしてしばし過ごす。そんな中で探していたのが、ニュース系のbotアカウント。僕は Twitter は最近 SNS というより社会情勢を知る道具として使っていたところがあった。そこら辺の機能の代替が欲しかったわけだ。その結果見つけたのが以下のアカウント達:

特務機関NERV (https://unnerv.jp/about/more): Twitter でフォローしてる人も割といるんじゃないかと思うが、災害情報、鉄道情報、NHK ニュース速報などを配信しているボットアカウント。Mastodon では https://unnerv.jp/@UN_NERV を起点に、情報ごとにブーストするアカウント群があり、そちらをフォローすれば気になる情報だけ購読できるようだ。元ネタは新世紀エヴァンゲリオン。
毎日新聞ニュースbot (https://u-tokyo.social/@mainichi_bot): 毎日新聞のニュース速報 RSS を配信しているボットアカウント。
震度速報 (https://mastodon.social/@quaketelop): 気象庁の速報情報をもとに、地震の震度速報を配信しているボットアカウント。
News Selection (https://mastodon.social/@newsselection): Twitter で話題になったニュースを配信してるボットアカウント。出自はいまいち分からん。

他にゲーム情報や為替情報を配信しているボットアカウントなども探したけど、見つからんかった (というか探し方がよく分からんかった) のでとりあえずこれだけフォローしてる。自分で作ってみるのもありだなあとは思っている。で、そういうボットアカウントをフォローしまくると、HTL がかなりごちゃごちゃしてくる。そこでリスト機能を使い始めるようになった。リストは Twitter のリストと基本同じだが、非公開リストしか作れないっぽい。後、リストにはユーザを追加してからのトゥートしか保持されない。僕はとりあえずメインのリスト作って、基本そっちの TL を見てる。TheDesk で HTL も置いといて、そこに流れてくるのでメインに入れたいなと思ったやつはメインに入れてる。モバイルとかではメインリストのしか基本見ないかな。

さて、そんなこんなで色々環境を整備しつつ TL を見ていた Mastodon 生活一週間目ぐらい、ようやく実はこの SNS に繋がっているのは Mastodon インスタンスだけではないことが分かってきた。どうやら僕が参加した世界は、W3C で標準化された ActivityPub というプロトコルでやりとりするサーバが、群雄割拠しているネットワークだった。そして、そこにいるサーバは Mastodon インスタンスだけではなく、他にも様々なサーバがいて、それぞれに特色を持っていた。僕が参加しているネットワークは Mastodon ネットワークではなく、ActivityPub による Fediverse という名前のネットワークだったっぽい:

Fediverse には Mastodon 以外にも様々なサーバソフトウェアが繋がっている。主に僕が知っているものが以下:

Misskey: 最近有名なので知っている方も多いと思うが、しゅいろさん (https://misskey.io/@syuilo) という日本の方が作成、メインで開発しているやっぱり Twitter 風のソフトウェア。日本人開発者がメインということもあり、サーバの運用者、登録者も日本人が多い印象がある。個人的には、他の ActivityPub サーバに比べ先をいっている印象があるが、僕は使ったことないので詳しいことは分からない。
Pleroma: Elixir で開発されている Twitter 風のソフトウェア。Mastodon などと比べて軽量という噂。やっぱりよく知らない。
GNU Social: 結構歴史が古めの Twitter 風のソフトウェア。お馴染み Free Software Foundation 管理。ただ、あまり開発が活発ではなく、バグも多いようだ。
Pixelfed: Instagram 風の写真特化型 SNS ソフトウェア。そもそも僕はインスタやったことがないので、使い勝手がまるで想像できない。
Frendica: Facebook 風の SNS ソフトウェア。こっちも僕は Facebook やったことがないので、使い勝手がまるで想像できない。
Wildebeest: 最近 Cloudflare が出してきた Mastodon 互換のソフトウェア。ActivityPub は基本相互のやり取り、フォローなどの基本的な機能しか策定されていないため、ここまで上げたソフトウェア達はそれぞれ独自に ActivityPub を拡張している。Mastodon ももちろん独自拡張を加えており、それに対応しているというのが Wildebeest の特徴になる。まだ出たばかりで機能が薄いという噂。

もちろん Fediverse に繋がっている人の中には、自身で一からサーバ書いて繋げてる人などもいるし、それぞれのソフトウェアをフォークして、独自の機能を追加している人などもいる。うまく繋がっていないサーバもいれば、協調路線を組んでいるサーバもいるし、それぞれが独立ながら相互に協調して発展していっているというのが現状のようだ。これは僕にとってはかなり衝撃的で、しかも魅力的だった。そもそもこの頃には、僕は Mastodon には様々な Twitter の未来をいく機能があることを知り、あまり Twitter に戻る気がなくなっていた。ところが、さらに Mastodon の機能の未来をいくソフトウェアや、全く毛色の異なるソフトウェアがネットワーク内には色々いたのだ。しかも、それにも不満があれば、自分でサーバを書き、それを繋げられる。これは Twitter やインスタ、Facebook、Tiktok などには成し得ない世界だろう。さらには、Tumblr が ActivityPub 対応を匂わせており、商用サービスが標準化されたプロトコルを喋ってくる日がくる可能性もある。

さて、ここまで Mastodon と Fediverse の世界に感銘を受け、毎日が感動の連続みたいな感じだったが、もちろん Fediverse は理想の世界ではなく現実のものであり、素晴らしい構想と発展性の影には、様々な問題も存在している。詳しくは後述する。さて、始めて2週間ぐらい、Fediverse のメタ的な話題を追うために、鯖缶や開発者などをフォローして TL を追うようになって分かってきたのは、Fediverse ノードの管理者は癖が強い人が多いということだ。実は正直なところ、Mastodon を始める前、僕が Mastodon に抱いていた印象は、機能は Twitter 劣化だが、分散的で、自由で、寛容というものだった。これは基本的に Twitter アンチテーゼとして生まれたという喧伝の影響が強いのだろう。ところが、Vivaldi Social で生活しているうちに、これはほぼ詐欺であることが分かってきた。

実際には、Fediverse も Twitter と同様ポリコレに侵されており、当然法の下での秩序を保つ義務があり、モデレーションが行われている。さらには、Fediverse ノードは個人の運用者が多く、Twitter のようにコストもあまりかけられないし、感情で動く人も多い。結果、治安は個々個人の裁量と妥協に委ねられることになる。これは、時に Twitter よりも強い縛りをもたらすことも多い。もちろん、それに不満があれば、個人のインスタンスを立てたり、他のノードに移ると言ったことは可能で、実際これを盾に個々の価値観で強権的な規則を敷くノードも多い。ただ、個人のインスタンスを立てたり、他のノードに移ることには、もちろんそれなりのコストとリスクが伴う。Fediverse の自由とは、あくまでそれなりの対価を支払う覚悟がある人にもたらされるものであり、寛容とは寛容でいられる範囲であれば寛容というわけだ。実際、このような実態は幾つか問題を起こしている。有名なものが Pawoo 国交断絶事件 [2] だが、Fediverse 界ではその手の事件が日夜起きている。まあ、Twitter などと違って、管理人が星の数いるわけだ。その分トラブルの種も多いのは当然と言えるだろう。また、これらのトラブルに嫌気がさしたり、コストに見合わないとして、多くの管理者が撤退している。

さらに、Fediverse はかなり薄氷の上に立っているという印象もある。皮肉なことに分散的に各個人がノードを建てることにより、「規模の経済」の法則が効かなくなり、全体的に Fediverse 運用コストは上がっている印象がある。運用コストが上がるということは、同じコストで運用できる機能が限られるということで、機能の中には冗長性とか安定性といったものも含まれる。つまり、分散的な Fediverse は、中央集権的な Twitter よりも脆弱で不安定であるということだ。もちろん、これらの問題を解決すべく、いろいろな取り組みはあるが、あまり解決に至っている印象はない。実際、この数週間の中で Pawoo がかなり不安定になり、一時接続できない状態になり、多数のユーザが他のノードに流入する事件があった。結果、他のノードもリソース増強を迫られる事態となった。結果的にこれは商用サービスにとっては好機となったと言えるだろう。

ここまでの一連の流れを見た僕の、Fediverse に参入して2週間目のトゥートがこちら:

https://social.vivaldi.net/@mizunashi/109851262694371031

で、Fediverse に嫌気が刺したかって？別にそんなことはない。今や Twitter も安定的ではないし、Fediverse の各サービスが Twitter 風のサービスを独自に発展させ、かなり魅力的な世界を構築していることは揺るがないわけで、Fediverse の政治的な問題とは一線を画しつつこの魅力的なネットワークに参入する価値はあるだろうと思っている。

さて、こうして時間はどんどんこの記事を執筆している時間帯へと近づいてくるわけだ。さて、最近はある程度 Mastodon の使い勝手が分かってきて、純粋に Fediverse の世界を楽しみつつある。ただ、新しい発見が全くなくなったわけじゃない。最近ようやく分かってきたのが、公開トゥートとハッシュタグの活用法についてだ。

僕は基本これまで未収載トゥートしかしてきてない。最初の右も左も分からない状態での公開トゥートはともかく、僕の中ではあまり公開トゥートでフォロワー以外に情報発信をするモチベはなかった。また、Vivaldi Social は割と LTL での会話が発展していて、常に一部日本人同士で公開トゥートでのやり取りが行われている。これは見てて楽しいが、僕にとっては参入するモチベはあまりなかった。公開トゥートを行うと、自然 LTL にトゥートが流れるため、LTL の会話を遮ってしまうことになる。そうまでして何か公開トゥートがしたいという動機がなかったのだ。ただ、最近この動機をハッシュタグに見つけつつある。

ハッシュタグタイムラインは、テーマを絞ったタイムライン作成を援助する機能だ。ただ、こいつは公開トゥートしか基本載らない。そのため、そこまで活発に活用されている印象はない。それは前述の LTL を意図せず遮ってしまうという側面によるところもあると思っている。多分これはそれほど間違った観察ではなくて、Fedibird では実は LTL を廃止し、公開タイムラインは基本ハッシュタグタイムラインで構築する運用にしているようだ。これは面白いし、向かうべき方向性に思える。つまり、ローカルでの会話をしたかったらインスタンス名つけたハッシュタグをつければいいし、そういう補助をするような UI を持ってもいいだろう。今の LTL の仕組みは、ローカルでの会話から抜け出して別の会話、それも連合全体でテーマに絞った会話をしたくなるみたいな状況には対応できない。しかし、全てハッシュタグ運用にすれば、またそれ用のハッシュタグを持ってくればいいわけだ。実際、Twitter の実況タグなどはそういう使い方がされてるだろう。公開で緩い連帯に基づくグループ会話にハッシュタグは活用でき、好きなタイミングで閉じたり再開でき、また参加をしたりやめたりをできる。さらには、同時に複数のタイムラインで会話が実現できるというのは個人的には割と欲しい機能だ。このような世界は、Fedibird で既に実現されてるらしいし、Misskey でもそれ用の機能があると聞いている。現状僕に対してこれを阻んでいるものは Vivaldi Social の LTL だけなので、ちょっとそういう世界に行ってみたくて近々引っ越しを画策している。個人で運用する Mastodon インスタンス、またはその他のサーバにするか、Fedibird などに行くかは決めてないが、多分近々どっちかに移るかもという感じ。

ここまでが、今の所の僕の Mastodon 体験記ということになる。

Mastodon、あるいは Fediverse の魅力

Mastodon には商用サービスにも負けない機能、他のサービス以上に魅力のある機能、他のサービスにはない問題点があることがこれまでの体験記を通してなんとなく分かってもらえただろうか？ここではさらに Mastodon の魅力を整理して、言語化してみたいと思う。

一つ断っておくと、これは個人的な価値観による考察で普遍的には通じない、つまり今この記事を読んでいるあなたに通用する考察ではないかもしれない。また、Twitter より Mastodon の方が優れているという話でもない。単に僕が Mastodon について魅力に感じている点をピックアップして紹介しているだけで、Mastodon にはもちろん改善した方がいいと感じる点もある。これは後述する。また、将来に渡って通用する話でもないかもしれない。僕はまだ Fediverse に所属して一ヶ月経っていないため、かなり浅い考察になっている部分はあるだろう。それは踏まえて読んでもらえると良いだろう。

実は僕はここ数年ほど Twitter はあまり呟かなくなっていた。これは僕自身あまり呟くことがない、あるいはその時間がないのだろうと思っていた。ところが、Mastodon を始めてみてこの考えは変わった。どうやら、Twitter は僕にとって呟くことに魅力がなくなってしまったサービスだったようだ。正直この理由はあまりうまく言語化できない。というのは、この原因が自分でもあまりよく分かってないからだ。ただ、いくつか思い当たることはある。まず、Mastodon は明らかに Twitter より安心して呟くことに関して的確な支援が多い:

投稿の公開範囲指定機能: これは先の体験記で話したとおりで、Twitter にも似たような機能はできたが、微妙に使いにくい。
投稿の自動削除機能・インデックス拒否機能: これは僕は使ってないが、これがあると安心して投稿できるという人はちらほら見る。まあ、自分がなんも考えずに呟いた投稿が、永遠にインターネットに残り続ける可能性があるというのは結構恐怖という気持ちはわかる。
投稿警告機能: 投稿に関してデフォルトでは警告文のみを出して、投稿全体はボタンを押さないと見れないようにする機能。これによりネタバレ投稿や、他人から見て不快に感じる可能性のある投稿にワンクッションいれることができるようになる。これも、安心して投稿できる範囲を増やすという意味で魅力的な機能だ。
投稿文字数制限の大幅な引き上げ: Twitter は最近投稿文字数上限を 280 文字に引き上げたらしいが、Mastodon は 500 文字が普通だ。これにより詳細な説明が必要な投稿を気にせずできる。さらに、各クライアントには長文トゥートの折りたたみ機能なども提供されていて、長文投稿による迷惑もあまり考えなくて良い。

基本的にユーザの価値観というのは個々で違うわけだが、そのそれぞれの価値観の反映が、Twitter のような集権的サービスよりも、Fediverse では個々のソフトウェアへの反映となって形に出る幅が広いと感じる。これらの機能は Mastodon が当時から持っていたわけではなく、発展的に採用していったもので、また他のソフトウェアからの影響も多大に受けていると思われる。つまり個々の発展性による多様な価値観の受け入れと、それに対する機能開発の迅速さというのが、個人的な Fediverse の大きな魅力だ。

ただ、これらの支援もさることながら、Twitter の「おすすめ」タブ機能がないというのもどうやら Mastodon で僕がよく呟くようになった要因のようだ。これは Twitter にいた頃には全く意識したことがなかったのだが、Twitter のおすすめは閲覧材料としては優れているのだが、コミュニケーションネットワーク支援としてはかなり悪いアイデアであるようだ。というのは、おすすめにはフォロワーよりも今話題の人や広告、過去のツイートなど、かなり今の自分とかけ離れたものが流れてくることが多く、基本コミュニケーションが成り立たないものが多い。そうなると、自分のツイートへの反応なども迷子になりがちで、また自分の相手への反応も相手がおすすめタブを見ていると伝わらないといったことが起きやすく、反応がいいねとリツイートだけでしか推しはかれなくなる。Twitter を SNS としてみた時、この機能はコミュニケーションを阻害するように働くので、結果的に大きく SNS の魅力を削ぐことになる。逆に言えば、おすすめ機能がない Mastodon はほとんどの人が HTL を見に行くわけで、少なくともそのような阻害要因が一つ除かれていることになる。そうなると、Twitter より SNS としては魅力のあるプラットフォームになるのだ。これはどっちかというと Twitter が下手を打っているという話な気がするが、まあ Twitter と比較した Mastodon の魅力と言っていいだろう。実際僕は Twitter から Mastodon に移ってからかなり投稿数が増え、これが定着の一つの要因となっている。

もう一つ、これも Twitter にいた頃は考えもしなかったのだが、Twitter が人間工学的に下手を打ってそうな部分がある。それはタイムラインの密度だ。体験記の初動で、Twitter のタイムラインに寂しさを覚えたというのが、僕が Mastodon への移行をする直接の動機となったという話をした。実はこれは、少し研究してみて、どうやらタイムラインで一度に見れる投稿が少なく、特に自分に関係がある投稿が少ないことが関係していることが分かってきた。Twitter の公式 Web は結構でかい OGP 表示や、画像・動画表示を愚直に行うし、広告の表示もタイムラインに行う。これはもう一つの公式 Web UI の Tweetdeck では少し緩和されてるもののやはり同じ傾向にあり、あまりカスタマイズもできない。そうなると自然、画像・動画投稿や、リンク投稿が増えると一度に表示される投稿は少なくなる。どうやらこれが寂しさを感じる原因となっているらしい。特に、あまり意味のないヘッダ画像を OGP に据えるサイトが多い中、そういうサイトのリンク投稿が結構多い時にそれをそのまま表示してしまうと、かなりタイムラインを空虚にさせる原因となるようだ。これは Mastodon でも解決されてるというわけではないのだが、TheDesk を使うことで僕は割と解決した。TheDesk の長文投稿折りたたみ機能と、画像のクロップ機能を使うことで、Mastodon 側のタイムラインはかなり密度を保てており、これは結構僕的には定着率向上に貢献している。また、TheDesk が URL の概要表示をそこまで積極的にしないというのも大きい。これは、エンゲージメント減少には繋がっているかもしれないので、ビジネスとの兼ね合いで見たときには微妙かもしれない。また、これは個人的な価値観によるところも大きいのかもしれない。だが、少なくとも僕にとってはかなり致命的だったわけだ。

また、Fediverse 全体の魅力として、やはり運用者が個々におり、ソフトウェアも多数あり、選択肢の幅が広いというのも一つの魅力だ。特に Mastodon には引っ越し機能があり、多少のリスクはあるが、ノードを移動して別のとこにいく支援を受け入れられるという点も良い。これはいざという時の保険にもなるし、発展性の一つの支えにもなっていると思う。引っ越し機能を使っているユーザは結構多いし、気軽に使える。こうして、それぞれのノードの文化を取り入れつつ、自身の今の状況にあった場所をその時々で見つけられるというのは Fediverse ならではの魅力だと思う。

Mastodon、あるいは Fediverse の課題

もちろん Fediverse には課題も多い。それについても言語化しておこう。

もう一回念のため断っておくと、これは個人的な価値観による考察で普遍的には通じない、つまり今この記事を読んでいるあなたに通用する考察ではないかもしれない。また、 Mastodon が向くべき方向性を間違っているという話でもない。単に僕が今の Mastodon について感じる不満を書いているだけ。また、将来に渡って通用する話でもないかもしれない。僕はまだ Fediverse に所属して一ヶ月経っていないため、かなり浅い考察になっている部分はあるだろう。それは踏まえて読んでもらえると良いだろう。

まずこれは多分異論が出ないと思うのだが、今の Fediverse は検索性がかなり弱い。これは Twitter での経験があるというのも大きいだろうが、辿り着きたいと思ったタイムラインやトゥート、ユーザにたどり着けることがあまり多くない。そしてこれはかなり需要があるだろう。では、なぜ実現できないのか？技術的な問題というのも確かにあるだろうが、個人的にはやはり資本力の差が大きいと感じる。多分検索機能は大体やればできる。要は Fediverse のトゥートに限った検索エンジンを作ってしまえばいいだけで、課題も多いだろうが、解決できないというほどでもないと思っている。にも関わらず、そのような機能が現れないのは、一つには検索エンジンは技術的にはそう難しくないのだが、運用コストがバカにならないという問題があるからだと思っている。体験記でも述べたのだが、Fediverse は金で殴れない分それがもろに効いてくる部分で結構脆弱である。これを技術だけで解決できればかっこいいのだろうが、なかなか難しいところだろう。

検索が弱いというのもそうだが、Fediverse は全体的に繋がりを作った後の支援機能は多いのだが、繋がりを作る部分についての機能が薄いと感じる。おすすめのユーザやトレンドはそこまで機能していないと思うし、検索性も薄く、さらにはユーザがそれぞれのリモートサーバに散らばっていることを考えると、Twitter より的確にユーザやクラスタを探すのはかなり難易度が高いと思う。少なくとも僕は結構苦労している。これは、繋がりを増やしたいという動機を持っている現ユーザが少ないのもありそうだが、新規参入者では結構問題になるだろうなとは思っている。こういう新規参入支援が薄い部分は、やっぱビジネスでやってる商用サービスと違うところだなとは思う。

さて、もう一つ、おそらく結構な人数の間で Fediverse が選ばれない、あるいは離脱者が多い理由に人口があると思う。これは、まあ解決すべきかと解決できるのかという問題もあると思うが、ただここで言っているのは単純な人口の話というより、網羅率というか、今の Fediverse には参入できない人が多く、また今の Fediverse の正確な人口に比して、それを感じられる機会が少ないという感じの話だ。

まず、現在の Fediverse はかなり参入障壁が高いと思っている。幾つか理由はあるがやはり分散性がかなり効いていると思う。分散的であるということは、それだけ扱う対象が増えるという話で、これは検索性の阻害にも繋がっているわけだが、そもそも対象が一つしかないものより対象が複数のものの方が学習コストは高くなるという問題もある。そうなると自然、学習コストが低いものよりもサービス開始につながらないユーザは増えるわけだし、サービス開始ができてもその後の体験の向上に繋がるまで時間がかかるだろう。また、知らなければいけないこともかなり増える。例えば、この記事はかなり技術的知識を前提に書かれているわけだが、世間のほとんどの人にとってちんぷんかんぷんな説明も多いだろう。Fediverse において、そういう技術的知識込みでの説明を入れないと物事が正確に説明できない場面が多いと感じる。もちろん、それは時間をかけて説明を噛み砕けば解決できるのだろうが、そこまでのコストを払って啓蒙を行う人は少ないだろう。また、啓蒙を行ったとしてそこに辿り着く導線を作れるかというのも問題になる。Mastodon の UI もところどころ結構リテラシーの高さを要求してくる部分があり、割と足切りラインはありそうと感じる。まあ、その分治安が保たれるという見方はできるかもしれないが。

また、検索性がないこともあって、どの人がネットワーク内にいるか把握しづらく、実際より人口がいない印象を受けやすいという面もあると思う。繋がりを作るのにも割かしコストがかかるので、そのまま馴染めず、離脱する人が多いのだろう。この辺の導入支援が少ないのは、ビジネスでやってないサービスの共通点で弱いところではあると思っていて、まあそれはそもそもそこに動機がないからだが、だからこそ成長が遅いという側面はありそうだ。基本 SNS の魅力として人口はかなり大きいと思う。個人的には、そこに動機がないことが今回分かったのだが、大多数の人にとっては友達が使ってるから繋がりを持つために自分も使ってみるというのが動機としては大きいだろう。僕としても、もし人口が多く Mastodon 並に魅力的な機能があれば、多分そっちに流れるだろう。逆に言えば人口は Fediverse の生命線になり得るということで、課題の一つに挙げておいてもいいんじゃないかと思う。

さて、最後が Mastodon のキャッチである「売り物ではないソーシャルネットワークサービス」というものに対してだ。正直僕が最近まで Mastodon を敬遠していたのはこのキャッチによるところが大きいと思う。これはおそらく僕の価値観によるところが大きいのだろうが、ビジネスで運用されていないサービスほど胡散臭いものはないというのが僕は思っていて、その価値観で言うと Mastodon はそもそも思想からして色々反しているわけだ。まず、どこの国の法でも大体そうなのだが、非営利で運用しているサービスというのはある程度免責される部分が出てくる。逆に営利企業には様々な制約が法律レベルでかかり、まともな企業であればそれを守らざるを得ないし、もし守ってないことが明るみに出た場合は法に基づいた民事係争手続きによるしかるべき処置や補填を求めることなどもできる。つまり何が言いたいかというと、一般的に非営利より営利の方がある程度セキュリティレベルや財務の健全性などが保証されている場合が多く、また利用者の権益も法律によって保護される場合が多いということだ。これは一般のイメージとは真逆かもしれないが、非営利というのは口で割と出まかせを言って何とかできる範囲が大きく、実際それは度々問題になっている。ビジネスでやってるところはそれなりにセキュリティや財務健全性にも力を入れている。それは入れざるを得ないからなわけだが、非営利ではそこがおざなりになりがちだ。ま、もちろんビジネスでやってるから安全とか、ビジネスでやってないからやばいという話ではないが、一般論として個人的にはビジネスでやってもらった方が信頼が持てる。そこは課題なのか？と思う人も多いだろう。ただ、Fediverse 全体として商用サービス化への忌避があると思っていて、それは逆に安定的で信頼のあるプラットフォームを築くための障害になるだろうなという感じだ。実際、今の Fediverse の管理者には、「自分は苦労して何のメリットもない管理者を買って出ているのに、なぜ更なる苦労を強いられなければいけないんだ」とか「メリットを自分で作ってもいいだろう」という声を持つ人もたまにいることを観測している。これは真っ当な感想であり、僕は1ユーザにしか甘んじていないためあまり強く言える立場ではないのだが、こういう動機からえてして色々な線を越える行動に出る個人や団体は多いというのが現実だ。これは善意と努力で行われている場合、ふとした弾みにより暴発しやすく、法的責任もない場合が多いのでそのまま有耶無耶になりがちだ。このようなことが起こりやすい土壌は、サービスとしてあまり健全ではなく、世間一般にあまり受け入れられてほしくはないと僕は思っている。世間一般に受け入れられるには、ちゃんと信頼性のあるサービス運用と健全な財務に力をいれて、正当な手続きを用意する手間を惜しまないプラットフォームであるべきで、そういうプラットフォームであるには専任で時間を使う人たちが必要で、専任で時間を使うには金と保証が必要だ。これは善意と献身によるサービス運営では、あまり実現できないだろう。もし、Fediverse が世間一般に受け入れられることを目指しているなら、個人的にはこの課題は解決してほしいと思う。

まとめ

というわけで、Mastodon を始めてからの振り返りと、魅力と課題についての紹介だった。ま、とりあえず Mastodon は楽しい。Misskey も楽しそう。

Twitter は多分アカウントはそのまま当分なんかあるまで残すけど、呟くことはないかなという感じ。Fediverse 崩壊しても Twitter 以外に流れそう。大したこと呟いてないが、興味あったらフォローしてくれ (https://social.vivaldi.net/@mizunashi)、よろしく。では、今回これで。

[1]	https://docs.joinmastodon.org/ja/user/posting/#privacy

[2]	https://togetter.com/li/1101173

SecureRandom.getInstanceStrong を気軽に使ってはいけない

2023-02-05T13:16:35+09:00

何番煎じか分からないが、個人的に詰まったので備忘録。JDK には、暗号用の乱数生成器 SecureRandom クラスが用意されている。そして、このクラスには、 getInstanceStrong というメソッドが用意されている。この名前はいかにも強そうで、基本的にはこのメソッドを使っていれば安全そうに見える。ところが、このメソッドは何も考えずに使うと思わぬ落とし穴にハマることになる。今回はその話をする。

突然フリーズするサーバ

アリスはボブに頼まれ、単純なデータベースへの読み書きを担当する API サーバを作ることになった。読み書きするデータは機密性の高いもので、万が一にも漏洩するのは良くないし、生データに触れるのも制限された人のみにすべきで、それはアリスに対しても開示できないものなので、データベースに保存するデータは全てサーバ側で書き込み側から鍵を受け取って暗号化してから保存することになった。アリスは普段使い慣れている Java でサーバを書くことにした。開発は順調で、手元でアリスは万全のテストを行い、自信を持ってボブに完成したサーバプログラムを渡した。

ところがその数日後、ボブからクレームが来ることになる。君からもらったプログラムはまるで使いものにならない、サーバはある程度リクエストを受け付けるとフリーズしてしまうというのだ。それも、秒間数千リクエストとかではない。ほんの数リクエスト程でというのだ。それぐらいの状況ならアリスはテスト済みだ。どうせサーバの起動環境の問題だろうと思いつつ、ボブに請われて原因調査のためインスタンスに潜る。すると確かに、アリスが作ったサーバはほんの数リクエストでレスポンスを返さなくなってしまうようだった。ただ、データベースへの接続が止まっている雰囲気でもない。不思議に思いながら、アリスはひとまずスレッドダンプを取ってみることにした。 jps でサーバのプロセス ID を調べ、 jstack でスレッドダンプを表示してみたところ、何やら不思議なダンプ情報が出力された:

$ jstack 9
...
"Thread-0" #13 prio=5 os_prio=0 cpu=23.44ms elapsed=12.94s tid=0x0000ffff88172de0 nid=0x1c runnable  [0x0000ffff5cdec000]
java.lang.Thread.State: RUNNABLE
        at java.io.FileInputStream.readBytes(java.base@17.0.6/Native Method)
        at java.io.FileInputStream.read(java.base@17.0.6/FileInputStream.java:276)
        at java.io.FilterInputStream.read(java.base@17.0.6/FilterInputStream.java:132)
        at sun.security.provider.NativePRNG$RandomIO.readFully(java.base@17.0.6/NativePRNG.java:425)
        at sun.security.provider.NativePRNG$RandomIO.getMixRandom(java.base@17.0.6/NativePRNG.java:405)
        - locked <0x000000008cf91998> (a java.lang.Object)
        at sun.security.provider.NativePRNG$RandomIO.implNextBytes(java.base@17.0.6/NativePRNG.java:537)
        at sun.security.provider.NativePRNG$Blocking.engineNextBytes(java.base@17.0.6/NativePRNG.java:269)
        at java.security.SecureRandom.nextBytes(java.base@17.0.6/SecureRandom.java:758)
        at DataCryptor.encrypt(DataCryptor.java:66)
        at ApiService.registerData(ApiService.java:15)
        at Server.run(Server.java:10)
        at java.lang.Thread.run(java.base@17.0.6/Thread.java:833)
...

どうやら、 SecureRandom.nextBytes の呼び出しが止まっているようだ。該当部分のコードは以下のようになる:

...

public class DataCryptor {
    ...

    private final ThreadLocal<Cipher> cipherThreadLocal = new ThreadLocal<>() {
        protected Cipher initialValue() {
            try {
                return Cipher.getInstance(CIPHER_ALGORITHM);
            } catch (NoSuchAlgorithmException | NoSuchPaddingException e) {
                throw new RuntimeException("unreachable: expect AES/GCM/NoPadding support", e);
            }
        }
    };

    private final ThreadLocal<byte[]> gcmNonceBytesThreadLocal = new ThreadLocal<>() {
        protected byte[] initialValue() {
            return new byte[12];
        }
    };

    private final SecretKeySpec keySpec;
    private final SecureRandom random;

    DataCryptor(byte[] key) {
        assert key.length * 8 == KEY_BIT_LENGTH;

        this.keySpec = new SecretKeySpec(key, KEY_ALGORITHM);
        try {
            this.random = SecureRandom.getInstanceStrong();
        } catch (NoSuchAlgorithmException e) {
            throw new RuntimeException("unreachable: expect SecureRandom strong algorithm support", e);
        }
    }

    public byte[] encrypt(byte[] plain) {
        final Cipher cipher = cipherThreadLocal.get();
        final byte[] nonce = gcmNonceBytesThreadLocal.get();
        this.random.nextBytes(nonce);

        ...
    }

    ...
}

これの encrypt メソッド3行目が該当部分のようだった。なんの変哲もない SecureRandom.nextBytes の呼び出しに見える。一体全体なぜこんなところでフリーズするんだろう。もう一度ダンプをよく見てみよう:

at sun.security.provider.NativePRNG$RandomIO.implNextBytes(java.base@17.0.6/NativePRNG.java:537)
at sun.security.provider.NativePRNG$Blocking.engineNextBytes(java.base@17.0.6/NativePRNG.java:269)
at java.security.SecureRandom.nextBytes(java.base@17.0.6/SecureRandom.java:758)

どうやら、 SecureRandom.nextBytes の呼び出しは実際には NativePRNG.Blocking.engineNextBytes と呼び出しになるようだ。名前に Blocking という文字が入っているのが気になるところだ。さて、そもそもこの記事はタイトル落ちなのだが、実際の問題の箇所は以下の部分だ:

DataCryptor(byte[] key) {
    assert key.length * 8 == KEY_BIT_LENGTH;

    this.keySpec = new SecretKeySpec(key, KEY_ALGORITHM);
    try {
        this.random = SecureRandom.getInstanceStrong();
    } catch (NoSuchAlgorithmException e) {
        throw new RuntimeException("unreachable: expect SecureRandom strong algorithm support", e);
    }
}

つまり、 SecureRandom のインスタンスを作成してる部分、つまり this.random = SecureRandom.getInstanceStrong() の部分だ。ただ、この原因の説明には少し時間が必要だ。では、なぜこのような現象が起こるのか見ていこう。

SecureRandom.getInstanceStrong

アリスがつまづいたポイントを理解するには、まず SecureRandom.getInstanceStrong メソッドがどういう動作をするかを理解しなければいけないだろう。Oracle の JavaSE 19 向けのドキュメントには、以下のような記述がある:

securerandom.strongAlgorithmsSecurityプロパティで指定されたアルゴリズムまたはプロバイダを使用して選択されたSecureRandomオブジェクトを返します。

RSA公開/非公開キーのような付加価値の高い永続的な秘密情報を作成する場合など、状況によっては強力な乱数値が必要になります。アプリケーションが適切で強力なSecureRandom実装を選択できるようにするため、Javaディストリビューションでは、securerandom.strongAlgorithmsセキュリティ・プロパティに既知の強力なSecureRandom実装のリストが含まれています。

つまり、 SecureRandom.getInstanceStrong メソッドが返すインスタンスはSecurityプロパティの securerandom.strongAlgorithms の値によって変わり、そのプロパティも Java ディストリビューションによって変わるというわけだ。Securityプロパティというのは、Security.getProperty で取得できる値のこと。java.security.Security のドキュメントによると

セキュリティ・プロパティのデフォルト値は、実装固有のロケーション(通常はJavaインストール・ディレクトリのプロパティ・ファイルconf/security/java.security)から読み取られます。

とのことで、OpenJDK の定義では、以下のようになっている:

Windows 以外: NativePRNGBlocking:SUN,DRBG:SUN
Windows: Windows-PRNG:SunMSCAPI,DRBG:SUN

この形式についての説明はちょっと見つけられなかったが、OpenJDK の実装を読む限り、 Algorithm1:Provider1,Algorithm2:Provider2,... という形式のようだ。優先順位は左からのようだ。つまり、Windows 以外の環境では NativePRNGBlocking というアルゴリズムが SUN プロバイダにあればそれが使われる。Windows では Windows-PRNG というアルゴリズムが SunMSCAPI プロバイダにあればそれが使われる。そして、それらが無ければ DRBG というアルゴリズムが SUN プロバイダにあればそれが使われるということになる。

アリスの手元は macOS/AArch64、サーバが実際に動いた環境は Linux/x64 の環境だった。そしてどちらの環境も SUN プロバイダで NativePRNGBlocking アルゴリズムが提供されていた。つまり、どちらにしても SecureRandom.getInstanceStrong() は SecureRandom.getInstance("NativePRNGBlocking", "SUN") と同じということで、アルゴリズムの違いによって動作に違いが生まれていたわけではない。問題なのはこの NativePRNGBlocking アルゴリズム自体の動作というわけだ。

SecureRandom のアルゴリズム

さて、NativePRNGBlocking の詳細に入る前に、SecureRandomの実装アルゴリズムの概要について少し見ておこう。アルゴリズムの一覧は、 Javaセキュリティ標準アルゴリズム名及び Java SE セキュリティ開発者ガイドで説明されている。それぞれまとめると

アルゴリズム	プロバイダ	概要
NativePRNG	SUN	基盤となるネイティブOSから乱数を取得する。乱数生成のブロック性については何も表明されない。基本実装は、`nextBytes` では `/dev/urandom` 、 `generateSeed` では `/dev/random` が使用される。
NativePRNGBlocking	SUN	基盤となるネイティブOSから乱数を取得し、必要に応じてブロック化する。基本実装は、`nextBytes` 、 `generateSeed` で `/dev/random` が使用される。
NativePRNGNonBlocking	SUN	基盤となるネイティブOSから乱数を取得するが、アプリケーションの速度低下を避けるためブロックしない。基本実装は、`nextBytes` 、 `generateSeed` で `/dev/urandom` が使用される。
PKCS11	SunPKCS11	基礎となるインストール済および構成済のPKCS #11ライブラリから乱数を取得する。
DRBG	SUN	NIST SP 800-90Ar1 で定義されている DRBG メカニズムを使用するアルゴリズムを使用する。
SHA1PRNG	SUN	各操作につき値が1増加する64ビット・カウンタを使って鎖状につながった真にランダムなシード値から、SHA-1ハッシュを計算する疑似乱数生成アルゴリズムを使用する。初期シードは、現在、システム属性とjava.securityエントロピー収集デバイスの組合せによって決定される。
Windows-PRNG	SunMSCAPI	基盤となるWindows OSから乱数を取得する。

ここまでで何が問題か分かった人は多いと思うが、 NativePRNGBlocking の必要に応じてブロックするというところ、特に /dev/random が通常使われるというところが問題になる。簡単に言えば /dev/random つまり NativePRNGBlocking の取得元は真の乱数のみを生成するようになっており、十分な乱数性が保証されていない状態では乱数性が保証されるまでブロックを行うのだ。Linux での乱数生成についてはこの後触れるが、基本的に OS は普段からハードウェア割り込みなどタイミングが予測不能のイベントを観測するなどして環境ノイズから乱数源を確保している。そして、 /dev/random が参照されるとその乱数源に溜め込まれたノイズから乱数を生成する。ただ、ノイズは使ったら再利用できないので、乱数生成ごとに使えるノイズは減っていくわけで、無限にノイズを貯めるのも難しいため枯渇する状況は発生してしまう。そのような場合に /dev/random はノイズがまた必要な分貯まるまで乱数生成をブロックするというわけだ。環境ノイズは基本的に稼働している外部デバイスがある程度多くないとあまり貯まらない。特に、サーバ用途で普段外部要因があまり関わらないような放置された環境だと、ノイズ元があまりなく、十分な乱数源が確保されるまで時間がかかることが多い。例え、乱数生成がブロックされなかったとしても、本当に真の乱数が必要な他のプログラムに影響を与えるということにもなりかねない。ここから、サーバなどで /dev/random、つまり NativePRNGBlocking アルゴリズムを使う場合は注意が必要だ。

さて、今回のアリスのサーバは意図して /dev/random を使ったわけではないが、 SecureRandom.getInstanceStrong() の中身が実際には NativePRNGBlocking だったため、結果的にノイズを消費しつつノイズがなくなったら貯まるまでブロックするという動作を起こすコードになっていたというわけだ。手元では、普段からキーボード入力やマウス入力、音声デバイスの使用など様々なノイズ源があるため、あまり /dev/random のブロックという事態までには至りにくかったが、ノイズが枯渇しがちな実際の環境ではデータ暗号化毎にノイズを消耗してしまうため、ノイズの枯渇という事態に陥りサーバがフリーズするという事態になったわけだ。アリスは結局、 SecureRandom.getInstanceStrong() を使う代わりにブロックしないことが保証されている SecureRandom.getInstance("NativePRNGNonBlocking") を使うことにした。その後サーバのフリーズという事態は起きず、ボブの事業も成長していきましたとさ。めでたしめでたし。

ところで、アリスはブロックしないことを理由に NativePRNGNonBlocking を使うことにしたわけだが、この選択は正しいのだろうか？そもそもなぜ SecureRandom.getInstanceStrong はデフォルトでブロックするような実装になるのだろうか？先ほど少し触れたが、基本的に NativePRNGBlocking がブロックを起こすのは結果的な話で、目的としては真の乱数のみを使えるようにすることにある。では、 NativePRNGNonBlocking、つまり /dev/urandom とはどういう実装になっているのかという話なのだが、こちらは暗号的な強度をある程度落とす代わりにブロックしないようなアルゴリズムになっているのだ。具体的には、初期シードはノイズ源から生成しそこから疑似乱数を生成するような生成器を用意しておき、ノイズ元が不足している場合はそちらの生成器から乱数を生成するようになっているのだ。そんなことをして安全なんだろうか？そこら辺の詳細は後で説明するが、使用上の注意点は確かに幾つかある。ただ、基本的に /dev/urandom も速度より安全性を重視した実装になっており、注意点が守られるなら長期に何度も再利用されるような乱数列を生成するのでない限りは目的に沿うぐらいの強度は得られるだろう。

実際、 SecureRandom のコンストラクタでインスタンスを作った場合、標準的には NativePRNG が実装として使われることになるが、この際 nextBytes で使われるのも /dev/urandom になる。基本的には、 SecureRandom.getInstanceStrong を使う場面というのは JavaSE のドキュメントで述べられている通り、付加価値が高く永続性も高いような乱数列の生成、つまり暗号化用の秘密鍵のようなものだ。それ以外についても、性能が許すなら真の乱数源からの生成を行なってもいいだろうが、あまりにノイズを消費しすぎると、他のプログラムにも影響が出かねないし、ノイズの質も落ちやすくなってしまう。そこのトレードオフを考えつつ、使用するべきだろう。なお、 SecureRandom の標準的な実装の優先順位、つまりコンストラクタでインスタンスを作った場合に選ばれるアルゴリズムの優先順位はセキュリティ開発者ガイドで述べられており、以下のようになっている:

Linux

NativePRNG
DRBG
SHA1PRNG
NativePRNGBlocking
NativePRNGNonBlocking

macOS

NativePRNG
DRBG
SHA1PRNG
NativePRNGBlocking
NativePRNGNonBlocking

Windows

DRBG
SHA1PRNG
Windows-PRNG

なお、Linux、macOS には注記があり、

java.securityのエントロピー収集デバイスをfile:/dev/urandomまたはfile:/dev/randomに設定すると、SHA1PRNGよりNativePRNGが優先されます。それ以外の場合は、SHA1PRNGが優先されます。

ということのようだ。OpenJDK では基本このプロパティが設定されているようなので、優先順位は基本書いた通りになると思っていいだろう。先ほどのアルゴリズムの解説を合わせると、どのプラットフォームでも優先度が高いものは、シード生成は真の乱数を元に生成、乱数生成はシードを元にした疑似乱数の生成ということになり、 /dev/urandom 相当のものになることが分かる。アリスの場合シード生成には SecureRandom インスタンスを使っていないため、標準基準と同レベルと言えるもので、特に問題ないだろう。

なお余談だが、アリスのスレッドダンプは https://github.com/mizunashi-mana/securerandom-getinstancestrong-freeze-cfp のリポジトリのコードで再現した。基本的には、 /dev/random をパイプファイルで上書きしておき、 /dev/random のブロックを擬似的に再現している。興味があったら覗いてみてくれ。

OS の乱数生成

さて、 SecureRandom のインスタンス選びには多少注意が必要なことは分かってきたと思う。最後に、 SecureRandom 標準のアルゴリズムが内部で使用している、 /dev/random、 /dev/urandom についてもう少し中身を詳しく見ておこうと思う。なお、以降の話は Linux カーネルでの話。それ以外は知らん。

Linux の /dev/random、 /dev/urandom の実装は最近結構大きく変わった [1]。ただまだ変更後のカーネルを使ってるところは少ないだろうと思うので、一応変わる前後について両方見ておこう。混乱を避けるため、変更前のアーキテクチャを Linux-Legacy-RNG、変更後のアーキテクチャを ChaCha20-DRNG と呼ぶことにする。まずは Linux-Legacy-RNG の方から見ていく。さて、今まで /dev/random は OS が集めた環境ノイズを消費しつつ乱数を生成するというぼかした説明をしてきた。正確には、乱数の生成源はいくつか種類があり、その概要は以下のようになっている:

なお、この図は以下のレポートから拝借した:

Patrick Lacharme, Andrea Röck, Vincent Strubel, and Marion Videau. 2012. The Linux Pseudorandom Number Generator Revisited. Retrieved from https://eprint.iacr.org/2012/251.pdf

まず、乱数の生成源の乱雑さを表す状態量をエントロピーと呼ぶが、OS はこのエントロピーをエントロピー元、つまりハードウェア割り込みなどの環境ノイズから上手く抽出し、入力プール (input pool) に溜め込んでおく。このエントロピーが高いほど、入力プールは質の良い状態、つまり極めて乱雑になっているということだ。入力プールは実際には、固定サイズのビット列プールで、エントロピー源から得たビット情報を都度混ぜ合わせた乱数列を保持している。ただ、 /dev/random、 /dev/urandom は直接この入力プールからエントロピーを抽出して使うのではなく、一度ビット情報を必要に応じてそれぞれのプールに持ってくる。 /dev/random はブロッキングプールを参照する。ブロッキングプールは自身のエントロピーを監視しつつエントロピーが不足してくると都度入力プールからエントロピーを抽出し、自身の今の情報と混ぜ合わせながらエントロピーを補充、つまり乱雑なビット列を保つ。そして、 /dev/random の参照元にその乱雑なビットを返しつつ参照された分自身へのフィードバックをしつつ、エントロピーの評価を下げていく。 /dev/urandom が参照する非ブロッキングプールも基本的には同じようなことを行うが、エントロピーが入力プールから補充できない場合は補充を諦め、現在のプールの状態のまま乱数列を生成する。まあ、ここら辺の具体的なアルゴリズムは興味があれば実装を読んでみるといいと思うが、実益を兼ねてということであれば、この後紹介する ChaCha20-DRNG の方を参照することをお勧めする。Linux-Legacy-RNG のコードベースはかなり混沌としており、この状況の改善も ChaCha20-DRNG プロジェクトの一つの目的であり、そっちの方が読みやすい。また、今後は ChaCha20-DRNG の方が主流になっていくだろうからだ。

さて、ChaCha20-DRNG では Linux-Legacy-RNG と異なり、ブロッキングプールが実は廃止された。以下がその概要図になる:

なお、この図は以下のレポートから拝借した:

Documentation and Analysis of the Linux Random Number Generator. Retrieved from https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/LinuxRNG/LinuxRNG_EN_V4_3.pdf

さて、もちろんこの背景にはいくつか説明が必要だろう。まず、最近の Linux は /dev/random を参照しても真の乱数を生成しない。もちろん真の乱数とは何かという議論はあるだろうが、ここで言いたいことはつまり、エントロピー源から得られた乱雑さだけをその都度使うことは無くなったということだ。言い換えれば、 /dev/random はこれまでの /dev/urandom と同じく、エントロピー源からシードを生成したり、フィードバックを受けたりすることはあるが、基本的にはブロックせず疑似乱数によって生成されるようになったということだ。これを聞くと Linux-Legacy-RNG の話はなんだったのかと多くの人は思うだろう。この背景は割と複雑で、政治的な事情も色々孕んでいるのだが、ひとまずそこは置いておいて、ひとまず ChaCha20-DRNG の概要を見ていこう。

ChaCha20-DRNG でも、Linux-Legacy-RNG と同じようにエントロピーを貯める入力プールがある。ただ、Linux-Regecy-RNG の時のようなブロッキングプール、非ブロッキングプールといったプールは存在せず、 /dev/random、 /dev/urandom は共通の一つの状態を参照する。状態は固定長のビット列領域で、ChaCha20 の乱数ストリーム生成に使用される。状態ははじめエントロピープールから生成されたシードで初期化され、その後は入力プールが更新されたかによらず入力プールの内容と状態のデータを使って状態を更新し続けながら、乱数生成をしていく。もちろん、入力プールに環境ノイズが入ればそれは都度反映されるし、環境ノイズが入らなくても暗号学的に安全な乱数生成が行われることになる。これにより、 /dev/random と /dev/urandom の違いは、一番最初のシード初期化が完了するまで待つか、それを待たずに警告のみでエントロピーの反映が甘いかもしれない乱数を警告込みでブロックしないで生成するかの違いになった。シード初期化自体も基本的には1秒ほどの短時間で終わるため、ほとんどの場合 /dev/random と /dev/urandom の違いを意識して使用する必要は無くなったわけだ。

さてこのような変更が受け入れ可能なら、なぜ Linux-Legacy-RNG では2つのデバイスの使い分けが必要だったのだろうか？まずこのような変更が可能になったのには、一つには乱数生成器が大きく改善されたというのがある。Linux-Legacy-RNG の時代は SHA1 実装だったのだが、ChaCha20-DRNG では BLAKE2 による実装になっており、攻撃耐性が色々向上している [2]。この強化により、エントロピーをそこまで過剰に反映させなくても、初期化時に十分に反映されていればある程度安全性の高い乱数が生成されるようになったというのがある。もう一つは、そもそもブロッキングプールに対する暗号学的耐性への疑念があるということだ。これは結構昔から言われていたことなのだが、真の乱数を使えば攻撃耐性が備えられるというのは誤りであり、品質の向上に繋がるかも怪しい面が多いというのがある。環境ノイズはそもそも環境によって左右されるわけだが、逆に言えば環境が突然激変しない限り規則性を生む場合も多い。また、時間帯などで品質が大きく変わってくる。実際、環境ノイズだけを乱数の情報源として使用してしまうと、逆に攻撃耐性が下がるというのは割と知られており、むしろ環境ノイズを使うなら疑似乱数や状態をちょいちょい混合してやらないといけないというのが昨今のベストプラクティスで、 /dev/random と /dev/urandom の差が実際に安全性に大きい差があるかについては懐疑的な声も多かった。どちらもエントロピーの反映自体は行われているわけで、違いは単純にその量だけであり、SHA1 LFSR 実装ならばともかく、そこから脱却した今となってはその違いは大きいものではないということだ。また、 /dev/random がブロックすることに至っては DoS 攻撃の要因にもなり兼ねないため、セキュリティ的に負の面もあった。このようなリスクに対して真面目に対処してまで、 /dev/random にエントロピーを確実に反映させる必要があるのかという不満は Linux 開発者の間で割と上がってはおり、ChaCha20-DRNG ではその声が反映されたという形になる。将来的には、 /dev/random と /dev/urandom の中身を全く同じにする、 /dev/urandom を廃止するという動きもある。もし、アリスが案件を引き受けたのが5年後だったら、もしかしたら今回の問題とは無縁でいられたかもしれない。

というわけで、最近の Linux ではあまり必要性がなくなってきているが、一応入力プールの状態の監視方法についてもまとめておこうと思う。入力プールの状態を監視する為、proc ファイルがいくつか用意されている。それぞれ以下のようになる:

/proc/sys/kernel/random/poolsize: 入力プールのビットサイズを表す。
/proc/sys/kernel/random/entropy_avail: 入力プールのエントロピービットサイズを表す。これが /proc/sys/kernel/random/poolsize と同じならエントロピーは十分にあるということで、 0 だとエントロピーが枯渇していることを表す。ChaCha20-DRNG では初期化後は基本 /proc/sys/kernel/random/poolsize と同じになる。

他にもいくつかあるが、基本はこの2つを見ておけばいいだろう。node exporter にはこいつらの collector がデフォルトで有効になっていて、それぞれ node_entropy_pool_size_bits、 node_entropy_available_bits で見れる。この辺を監視していれば、アリスやボブももう少し早く原因に気づけたかもしれない。

まとめ

というわけで今回は Java の SecureRandom.getInstanceStrong() を使う際の注意点について紹介した。 SecureRandom.getInstanceStrong() は Linux 環境では基本的には /dev/random を参照する実装になり、 /dev/random はエントロピーが不足するとブロックする挙動になるため注意が必要だ。また、付加価値が高く永続性が高い機密情報でもない限りデフォルトの new SecureRandom() のインスタンスを使うので十分であり、そちらはブロックを行わないため問題が起きにくい。 SecureRandom.getInstanceStrong() を単に名前が強そうだからという理由で使うのではなく、自身のサービスの特性に合うアルゴリズムをちゃんと選ぶのが重要だろうということだった。最も最近の Linux では事情が異なり、 /dev/random と /dev/urandom の違いがなくなりつつあるため、今後はその違いについて考慮する必要はなくなってくるだろう。

/dev/random を使ってはいけないみたいな話時々聞くが実際にどういう話なのか実は知らなかったので、今回のはためになった。最も、この知識がこれから役立つことはあまりなくなっていきそうだが。では、今回はこれで。

[1]	詳しい経緯は https://lwn.net/Articles/884875/ を参照するのが良いだろう。

[2]	https://www.zx2c4.com/projects/linux-rng-5.17-5.18/inside-linux-kernel-rng-presentation-sept-13-2022.pdf

HM(X): 多相と制約と推論と

2023-01-24T21:49:16+09:00

パラメータ多相を持つプログラミング言語は多いが，その多くは型パラメータの記述機能だけを持つわけではない．例えば，Java ではパラメータ多相に加え，パラメータの変性を指定でき，その指定とサブタイプ関係によって受け入れるパラメータの範囲や挙動を変えたりできる．また，Haskell では型パラメータに対して，その型に付随した特定の機能を持つ保証を要求するような型制約を記述できる．他にも型パラメータに対して追加で条件を科すような機能を持つ言語は多い．もちろん，そのような言語が型推論の機能を持つ時，パラメータの制約に対しても考慮をしなければその言語のユーザ体験は著しく損なわれる．そのため，単純な多相型の推論機能だけでなく，制約も考慮した推論体系を搭載するのが普通だ．

そのような体系について，HM 推論をベースに，汎用的な推論フレームワークを提供してくれるのが HM(X) 型推論である．HM(X) 推論は制約の体系 X に対して HM 推論を拡張した推論体系を提供してくれる．今回はそのフレームワークを紹介したいと思う．なお，題材は以下:

Martin Odersky, Martin Sulzmann, and Martin Wehr. Type inference with constrained types. Theory and Practice of Object Systems, 5:35–55, 1 1999.

ただし，上の題材はかなり制約体系を抽象化しており，実装屋としては結構扱いにくいので，今回は

Dimitrios Vytiniotis, Simon Peyton Jones, Tom Schrijvers, and Martin Sulzmann. Outsidein(x): Modular type inference with local assumptions. Journal of Functional Programming, 21:333–412, 9 2011.

の文献から着想を得て制約体系の方はかなり具象化した話をしていく．元の話がどういうものか知りたい場合は元文献を参照してもらうのが良いだろう．また，HM 推論の話を理解していることが前提となる．HM 推論については，前回解説記事を書いたのでそちらをまず参照してもらうのがいいだろう．

制約

今回扱う言語は基本的には Let 多相を搭載した型付ラムダ計算の拡張になる:

本来，HM(X) は制約に関して具体的な構文要素を用意せず，一定の性質を持ち推論解決アルゴリズムが存在するような抽象的な制約システムに対しての推論体系を提供する．ただ，今回はもう少し掘り下げて，具体例と制約解決アルゴリズムについても言及するため，あえて制約についても具体的な構文を用意している．各構文要素は以下のようになる:

型コンストラクタ $T$: 型の等価判定の基本単位．原始的に関数型のコンストラクタ $\to$ を含んでいる．それぞれの言語によって導入される型コンストラクタは変わる．
制約コンストラクタ $D$: 制約の等価判定の基本単位．それぞれの言語によって導入される制約コンストラクタは変わる．
型 $\tau$: 型を表す項．変数と型コンストラクタから生成される． ${\to}\; \tau_1\; \tau_2$ は $\tau_1 \to \tau_2$ と表記することもある．
制約 $Q$: 制約を表す項．制約がないことを表す空制約 $\epsilon$ ，制約の結合，型制約，等価制約から生成される．
型スキーム $\sigma$: 多相型を表す項．型パラメータ，パラメータを含んだ制約，パラメータを含んだ型から生成される．
式 $e$: 式を表す項．変数，λ抽象，適用，let 式から生成される．

制約はそのまま言語機能として組み込んでもいいが，elaboration の対象として，他の言語機能を模倣するのにも応用できる．例えば，加算，乗算ができる型とそうでない型がある言語で，多相的な加算演算子，乗算演算子を提供したい場合を考える．具体的には次のようなコンストラクタを提供する言語を考える:

この場合に，

\mathbf{let}\;\mathit{double} = \lambda x\ldotp \mathit{plus}\; x\; x\; \mathbf{in}\; \mathit{double}\; 1.0

のようなプログラムにおいて， $\mathit{plus}$ は $\forall \alpha\ldotp \mathbf{Num}\; \alpha \Rightarrow \alpha \to \alpha \to \alpha$ ，即ち $\mathbf{Num}$ 制約を満たす型パラメータ $\alpha$ の引数を2つ受け取りその加算結果を計算して返すような多相関数として提供され，また $1.0$ は $\mathbf{float}$ 型の値として提供されたとき，それを元に $\mathit{double}$ は $\forall \alpha\ldotp \mathbf{Num}\; \alpha \Rightarrow \alpha \to \alpha$ として推論され，let 式の主部では $\mathit{double}$ の型パラメータ $\alpha$ が $\mathbf{float}$ 型にインスタンス化され，上記プログラム全体としては $\mathbf{float}$ 型の式と推論される，もし $\mathit{double}$ に $\mathbf{bool}$ 型の値を渡すと型推論が失敗する，というようにパラメータに関して何かしら条件を科すような機能を持った言語について，コンストラクタと提供する原始関数につける制約を工夫することで HM(X) の枠組みの推論体系を流用できるというわけだ．原著でも，サブタイプ関係を伴った推論や多相レコードを使った項への推論への応用例を挙げている．ま，動機としてはそんな感じ．

型推論

では，具体的に型システムと推論体系を見ていく．まず，型システムを見ていくが，その前に環境を用意しておく:

今回の制約付き Let 多相では，型付けを型環境 $\Gamma$ の他に制約環境 $C$ を元に判定する．型環境は言わずもがなだと思うが，制約環境とは今充足していることが保証される制約が入っている環境だ．今回は，制約と同じものしか入れないことにするが，例えば制約環境のみ特別な制約を導入することも可能だ．このような環境に対して，制約含意と型システムが定義される．

制約付き Let 多相の型システムは制約含意 $C \Vdash Q$ に依存する．制約含意とは制約環境から導かれる制約の判定のことで，以下のようになる:

基本的な含意の規則は最初の2つで，後は型の等価判定制約に関する要求規則という感じだ．型の等価判定に対して特別な要求規則が入っているのは，おまけという意味合いも強いだろう．単純な構文的等価性の範疇を超えた型の等価性を扱う言語も多いし，等価性がパラメータの制約により影響を受ける言語も多い．その為，型の等価性，要はキャスティングについての拡張も考慮できるように型の等価判定を加えているという面が強くそこまで本質的な機能ではないと思われる．ま，これに関しては型判定の規則も見てみる方がいいと思うので，型判定の規則も示しておく:

前回は Let 多相のイントロも兼ねてアルゴリズムに素直に対応する型システムを紹介したが，今回は一般化とインスタンス化を規則として分けて書いている．ただ比較がしにくいと思うので，HM(X) での加筆点を赤で示している．この赤の部分がなければ，普通の Let 多相の型規則ということになる．変数以外の式は一般化をしない限り多相型でない単相型の型でしか型付できず，部分項についても単相化されていることを要求している．let 式のみ束縛部分で使用する式に限り型スキームで型付されていることが許される．最後の2つの規則が一般化とインスタンス化に対応し，一般化では新たなパラメータと制約を導入することができ，インスタンス化ではパラメータ全てに単相な型を割り当てることと制約が満たされていることが要求される [1]．また，型の等価判定が成り立つ範囲ではキャストができるというのが，最後から3つ目の規則になる．

インスタンス化では制約含意を仮定においているが，これと制約含意の最後の規則により，型の等価判定の範囲であればインスタンス化する型を実際の型制約で使った型と同じにしなくても良くなる．ただ，導出としては制約含意での制約のキャストをするのでも，一度インスタンス化してからキャストの規則を使って型を変えるのでも問題ない．このキャストの規則と制約含意の規則の釣り合いが取れるようにというのと，無茶なキャストができないように制約含意の方にも型の等価制約に関する幾つかの要求規則が仕込まれているという感じだ．

さて，見ての通り HM(X) の型システムはそれほど大した拡張ではない．キャストの規則を追加して，制約込みで一般化できるようにし，インスタンス化の際制約のチェックが入るようになっただけだ．実際，推論の方もそこまで複雑な拡張を入れないで実現できる:

$\mathit{gen}$ は一般化関数で， $\mathit{gen}(\Gamma, Q, \tau)$ は $\vec{\alpha} = (\mathit{ftv}(Q) \cup \mathit{ftv}(\tau)) \backslash \mathit{ftv}(\Gamma)$ をパラメータとし， $\forall \vec{\alpha}\ldotp Q \Rightarrow \tau$ を返す [2]．

さて，この時，制約解決関数 $\mathit{solv}$ ，式 $e$ ，環境 $\Gamma$ ，制約環境 $C$ について， $\mathcal{W}(\Gamma, e) = (Q, \tau)$ で， $\mathit{solv}(C, Q) = S$ の時 $S\tau$ ，それ以外の時 $\bot$ を返せば，型推論アルゴリズムとなる．この時，制約解決をいい感じに設計すると， $C; \Gamma \vdash e: S\tau$ となるような推論が行えるアルゴリズムになる．今回は制約解決は具体的に後で構築し，あまり抽象的に「いい感じの設計」というのがどういう性質を指すかは立ち入らない．興味があれば元論文を読んでみるのがいいだろう．ま，基本的には制約解決の条件は $C \Vdash Q$ を満たし， $Q$ に含まれる型の等価性に関する制約が全て置換 $S$ に反映されていることという感じだ．こんな感じの設計を満たせば，大体制約込みの型推論になる．

一般化が制約込みで行われるようになること，単一化が型の等価性制約の追加，そして最後に制約解決が入ることのみが異なるが，基本アルゴリズム W と構成は同じだ．このように，HM(X) では与えられる制約システムにおいて，制約解決の方法が与えられた時，それを元に HM 推論を構成はほとんど変えずに拡張できる．

例えば，

\mathbf{let}\;\mathit{double} = \lambda x\ldotp \mathit{plus}\; x\; x\; \mathbf{in}\; \mathit{double}\; 1.0

について， $C = \mathbf{Num}\; \mathbf{float}$ ， $\Gamma = 1.0: \mathbf{float} + \mathit{plus}: \forall \alpha\ldotp \mathbf{Num}\; \alpha \Rightarrow \alpha \to \alpha \to \alpha$ の下での型推論を考えてみる．この時，まずは以下のように， $\mathcal{W}$ による制約と型の生成が行われる:

HM 型推論のアルゴリズム W に比べ，各所での単一化が起きずただ型の等価制約だけがどんどん増えていく．その等価制約に加え，必要な型制約も加えられ，最終的に変数を含む型と制約が生成される．これに対して，さらに $\mathrm{solv}(C, \mathbf{Num}\; \beta_6 \land (\beta_6 \to \beta_6 \to \beta_6 \simeq \beta_5 \to \beta_7) \land (\beta_7 \simeq \beta_5 \to \beta_8) \land (\beta_5 \to \beta_8 \simeq \mathbf{float} \to \beta_9)) = \theta$ により， $\theta(\beta_5) = \theta(\beta_6) = \theta(\beta_8) = \theta(\beta_9) = \mathbf{float}$ ， $\theta(\beta_7) = \mathbf{float} \to \mathbf{float}$ となるような置換 $\theta$ が生成されることになり，最終的に $\theta\beta_9 = \mathbf{float}$ が推論される型になる．このように，HM(X) では制約の生成が主な担当であり，その制約が妥当か検証し，制約から置換を生成することができれば，妥当な型が出力される．ただ，そのような制約解決をうまく定義するのはそれぞれの制約体系に任されることとなる．

制約解決

さて，HM(X) は制約を考慮した推論を，制約解決の方法が与えられた時に提供してくれる．最後にこの制約解決の方法についても言及しておこう．HM(X) 自体は基本これらの方法はパラメータとして与えられることが前提になっており，それを元に推論を提供してくれる体系なのだが，具体的に制約システムの方についても言及しておいた方がイメージがつきやすいだろう．

制約解決の役割は大きく2つある．1つは，型の等価制約からそれに合う置換を作成することだ．これは HM 推論での単一化に当たる．HM(X) では等価性が単純な構文的等価性の枠組みを超えることがあるかもしれない為，そのような体系にも耐えられるよう制約から置換を作成する．もう1つは制約の妥当性検証だ．つまり，推論された制約が満たされるべきものかを検証するということだ．この2つの役割を実現する為，制約解決はかなり段階を踏むことになる．

まず，制約を扱いやすいように原始制約の集合に変換する方法を用意しておく:

原始制約とは， $D \vec{\tau}$ ， $\tau_1 \simeq \tau_2$ のことで，もうそれ以上分解できないような制約のこと．今回は，この関数 $\mathrm{flat}$ により変換された集合に対して，書き換えシステムにより制約解決を行なっていく．書き換えシステムは，制約環境を取り，原始制約の集合をより単純な原始制約に変換するか，妥当でない原始制約が含まれていることを表す $\bot$ に書き換えを行う．具体的には以下のようなシステムにより制約解決を行える:

この制約解決システムは最終的に，

元の制約に現れる自由変数 $\alpha$ に対して，高々一つだけ代表的な型 $\tau$ を伴った等価制約 $\alpha \simeq \tau$
制約環境から解決できなかった制約 $D \vec{\tau} \not\in C$

だけを含む原始制約の集合に変換するか，制約が妥当でないことを表す $\bot$ に変換を行う． $\prec$ は等価制約を正規化するための関係で，何でもいいが変数に対しての全順序が提供された時，それを型全体に対して拡張する．与えられた原始制約の集合に含まれる全ての等価制約は，最初の3つの等価制約解決の規則と，4つ目の規則により，最終的にこの関係を遵守することになる．もう一つ， $\lll$ は正規化された等価制約であることを表す関係になっており， $\prec$ に加えて，妥当でない再帰的な等価制約でないことを表す．やはり，与えられた原始制約の集合に含まれる全ての等価制約は，最終的にこの関係を遵守するように変換される．残りの6から8番目の規則は最終的な置換を構成するための変数に紐づく型の単一化規則，最後の規則は制約環境からの制約の解決の規則になる．制約解決は，この書き換えシステムの正規系 [3] を元に，置換を構成することで定義される:

基本的に置換は書き換えにより生成された等価制約を元に構成される．ただ，等価制約には言及されない変数が存在することもある．そして，この変数が残っている状態だと制約解決がうまく行われないが，変数をうまく具体化すれば制約を満たすような状況が考えられる．例えば， $\mathbf{Num}\; \beta$ のような制約が書き換えの結果残ったとして，制約環境に $\mathbf{Num}\; \mathbf{float}$ のような制約が含まれていることを考える．この時， $\beta$ が置換に含まれなかったとしても， $\theta(\beta) = \mathbf{float}$ というような置換を加えれば制約を満たせる．このような制約を考慮したデフォルティングの余地を残すため，上記の定義では置換を具体的に構成していない．ただ，デフォルティングは諦めるという選択肢もあり，その場合は書き換えシステムのみで置換を構成できることになる．さて，この置換の構成を元に，最終的に以下のようにして制約を考慮した推論が行える:

この時，推論を行なった型について， $C; \Gamma \vdash e: \theta\tau$ が成り立つ．例えば，

\mathbf{let}\;\mathit{double} = \lambda x\ldotp \mathit{plus}\; x\; x\; \mathbf{in}\; \mathit{double}\; 1.0

について， $C = \mathbf{Num}\; \mathbf{float}$ ， $\Gamma = 1.0: \mathbf{float} + \mathit{plus}: \forall \alpha\ldotp \mathbf{Num}\; \alpha \Rightarrow \alpha \to \alpha \to \alpha$ の下での型推論を考えてみる．上記で，第一段階の制約と型の生成の結果は，

\mathcal{W}(\Gamma, \mathbf{let}\;\mathit{double} = \lambda x\ldotp \mathit{plus}\; x\; x\; \mathbf{in}\; \mathit{double}\; 1.0) = (\mathbf{Num}\; \beta_6 \land (\beta_6 \to \beta_6 \to \beta_6 \simeq \beta_5 \to \beta_7) \land (\beta_7 \simeq \beta_5 \to \beta_8) \land (\beta_5 \to \beta_8 \simeq \mathbf{float} \to \beta_9), \beta_9)

であることが分かっている．後はこの生成された制約を書き換えシステムにより書き換えていく．なお，変数の順序は $n \leq m$ の時 $\beta_n \leq \beta_m$ と考える．この時，書き換えの過程は以下のようになる:

分かりやすいように各ステップで書き換え対象となっている原始制約を，赤で記している．書き換えの過程で型コンストラクタを含む等価制約がどんどん分解され， $\lll$ の関係を満たすよう整理されていき，最終的に単一化により型が具体化されていく様子が分かるだろう．この結果から， $\theta = [\beta_5 \leftarrow \mathbf{float}, \beta_6 \leftarrow \mathbf{float}, \beta_7 \leftarrow \mathbf{float} \to \mathbf{float}, \beta_8 \leftarrow \mathbf{float}, \beta_9 \leftarrow \mathbf{float}]$ のような置換が条件を満足することが分かり，最終的に $\theta\beta_9 = \mathbf{float}$ が推論結果として得られることになる．

制約解決と完全性

さて，HM(X) は基本的に制約の生成だけを担当し，その制約を解決する仕組みは別途制約体系として与える必要があった．上記では，その仕組みの具体例を紹介した．ところが，上記で与えた制約解決は実はかなり不完全である．つまり，本来制約解決を行えるようなものに関して，幾つか取りこぼしが生じるということだ．例えば，

\mathbf{Int} \simeq \mathbf{Int64}; f: \mathbf{Int} \to \mathbf{Int} + 1: \mathbf{Int64} \vdash f\; 1: \mathbf{Int}

のような型付について考えてみる．この型付が正しいことは， $C = \mathbf{Int} \simeq \mathbf{Int64}$ ， $\Gamma = f: \mathbf{Int} \to \mathbf{Int} + 1: \mathbf{Int64}$ と置いた時，以下のように確かめられる:

しかしこの式について，上記の型推論アルゴリズムを適用してみると， $\mathcal{W}(\Gamma, f\; 1) = (\mathbf{Int} \to \mathbf{Int} \simeq \mathbf{Int64} \to \beta, \beta)$ となり， $C \vdash \{\mathbf{Int} \to \mathbf{Int} \simeq \mathbf{Int64} \to \beta\} \to \{\mathbf{Int} \simeq \mathbf{Int64}, \mathbf{Int} \simeq \beta\} \to \bot$ となるため，型推論に失敗することになる．これは制約解決が，等価制約の解決について制約環境を参照しないことによる．

HM(X) は制約解決がうまく設計できれば，ある程度緩めた形ではあるが完全な推論を提供する．ところが，上記でも述べたとおり，HM(X) の主な役目は制約の生成であり，制約解決は何らかの形で別途与えられなければならず，完全さはその与えられた制約解決に大きく依存する．そして，この制約解決の設計こそが難関だったりする．制約解決をある程度計算時間を抑えつつ，完全性を保証するものにしたかったら，ある程度機能を絞るか，細かい制約の使用条件を課す必要が出てくる．これは各種言語苦労している部分で結構アドホックな対応になりがち．つまり，HM(X) は HM 推論の簡易な拡張としての立場を取りつつ，制約体系をパラメータとして様々な体系に適用できることを売りにしているわけだが，実際には制約体系をパラメータとして与えるように設計すること自体はそれほど簡易とは限らないわけだ．さらに，実は HM 推論を土台にしつつそのまま各体系に合わせて推論規則を拡張する方が素直にいく場合も多いというのが実情ではある．ま，ここら辺は，実用寄りの応用理論ではよく起こりがちのジレンマというやつだろう．

なお，今回あげた制約解決は

Dimitrios Vytiniotis, Simon Peyton Jones, Tom Schrijvers, and Martin Sulzmann. Outsidein(x): Modular type inference with local assumptions. Journal of Functional Programming, 21:333–412, 9 2011.

の一部を取り出したものとなっていて，この文献は Haskell の型推論の基礎理論となっているんだが，元文献の制約解決では type エイリアス，type family などを扱うため，もう少し強力な書き換えシステムと制約環境への追加条件などを紹介している．このような，HM(X) を基礎としつつ制約解決を頑張って設計し拡充していく方向性は良し悪しはあるものの，参考になる部分も多いだろう．ま，まさに参考実装としての側面では HM(X) は結構有用だ．ただ，上記の文献でも完全さはかなり諦めている．この辺は，実装としては完全さにこだわるよりも実用に耐えることが一般的には重視されるという面もあるが，HM(X) 自体の完全性を満たすように制約解決を設計する難しさがあるという面は否めないだろう．その辺は，HM(X) を基礎として型推論を実装する戦略を取る際は頭に入れておくのが良いと思う．

まとめ

というわけで，制約を考慮した HM 推論の拡張フレームワーク HM(X) の紹介だった．HM(X) は HM 推論を少しの工夫を入れることで制約という新たな要素に対応できるようにしている．ただ，HM(X) の本質は，HM 推論を制約生成も合わせて行うよう拡張している部分で，推論として完成するにはさらに生成された制約を解決し，置換をうまく生成するような仕組みが別途必要になる．そして，HM(X) 自体は割と簡易的な拡張に見えて，実際は制約解決の仕組みを作ることこそが難関という面がある．その為，HM(X) が提供している範囲のアルゴリズムだけでは，そのまま応用は難しいという側面もある．今回は，一応制約解決の方も具体的に構築例を示してみた．ま，何かの参考になればという感じ．

なお，Pottier 先生の ATTaPL の 10 章「The Essence of ML Type Inference」でも，HM(X) を具体的な制約システムの構成を踏まえて説明している．こちらは，HM 推論の説明から，HM(X) への拡張と具体的な制約システムの構成，ML の型推論実装に対する応用まで，ちゃんと各種形式化をしながら見ており，制約システムもかなり強力なものを構成している．こんな雑記事と違ってかなり参考になると思う (その分分量も多いが) ので，HM(X) に興味があればぜひ参照してみるのがいいんじゃないだろうか．

今回はこんな感じで．

[1]	なお，今回は分かりやすさと実装しやすさを優先し省略しているが，原文の規則では一般化で satisfiable という性質の導入を行い，制約含意でその性質が検証されるようにしている．この検証がない場合，絶対に満たされないような制約に対して一般化を行なってしまう可能性がある．個人的には別にそれでありだと思うし，制約の satisfiablity を考慮すると結構話がややこしくなるので今回はそこは検証しないようにしている．興味があれば題材の方を当たってもらうのが良いだろう．

[2]	HM(X) における本来の一般化は実はもう少し自由が与えられていて，型スキームに含める制約と環境に残す選択を分離できる．ただ，今回はアルゴリズムを単純にする為，そのような自由は許しておらず，全部の制約を型スキームに含めるようにしている．この辺は興味があれば題材の方をあたってもらうのが良いだろう．

[3]

正規系を考えるとなると，気になるのは停止性と合流性が成り立つかだが，今回のシステムは停止性は成り立つが残念ながら合流性は成り立たない．ある程度書き換え結果は一貫したものになること，妥当でない制約を含む場合は必ず

\bot

に辿り着くことは保証できるが，完全に合流はせず書き換えによって最終的に得られる制約は変わる．そこら辺は実装依存ということになるだろう．合流性を保証する単純な方法は，書き換えシステムを決定的にすることだ．今回横着して，集合を使った書き換えを行なっているが，例えば原始制約の列に対して一番先頭から適用できる書き換え規則を適用していくというような規則を追加で入れれば，ある程度そこら辺の問題は解決できるだろう．今回は HM(X) の紹介という側面が強いのでそこまではやらず，とりあえず妥当な場合のみある程度一貫した結果が得られることだけで満足しておく．

Let多相と型推論

2022-08-27T19:05:29+09:00

プログラミング言語において，パラメータ多相は今や標準的な機能と言って良い．Java のジェネリクスや C++ のテンプレートをはじめ，Kotlin，Swift，TypeScript などの昨今の言語には当然搭載されており，Python の型アノテーションにもジェネリクスは搭載されている．パラメータ多相を搭載する言語では，パラメータを持たせたような型を付けた値を作成することができ，例えばリストの操作を，リストの要素の型についてはパラメータとして総称性を保ったまま，リストの構造だけに着目した関数として提供することができる．この機能は，プログラミングにおいて基本的なデータ構造を標準ライブラリが提供するために活用されることが多い．特にリストやマップなどのコンテナと呼ばれるデータ構造は，大体はそこまでカスタマイズ性を必要とせず，ある程度標準的な実装で需要を満足できる．そのため，パラメータ多相を使ってこれらのデータ構造とそれに対する操作を提供することで，快適なプログラミング体験を提供する言語が増えている．

さて，もう一つ，昨今標準的に搭載されるようになってきた型システム関連の機能として，型推論と呼ばれる機能がある．これは，文字通り型を自動で推論してくれる機能だ．基本的に型システムを持つ言語は，型によって値をある程度制約し，実行前にミスに気づけることを動機にしているものが多い．しかし，関数内の細かい変数などは自明に型が分かる場合も多く，一々型を書いていると冗長になりがちで，変更にも弱い．そこで最近はローカル変数について型推論機能を導入し，型を書いても書かなくても推論できる場合は推論して静的チェックを行なってくれる言語が増えている．

最近の主流な言語は，ほとんどこれら2つの機能を併せ持っている．ところが，実はある程度強力なパラメータ多相を実現できる機能では，型推論にある程度制約がかかってくることが知られている．今日は，それらの背景とパラメータ多相と型推論を同居させる際の指標となる著名なアイデア Let 多相とその型推論について紹介する．題材は以下．

Oukseh Lee and Kwangkeun Yi. Proofs about a folklore let-polymorphic type in-ference algorithm. ACM Transanctions on Programming Languages and Systems, 20(4):707–723, July 1998.

なお，そもそもの提唱元はこの界隈では聖典となっている Milner 先生の以下の

Robin Milner. A theory of type polymorphism in programming. Journal of Computer and System Sciences, 17:348–375, 1978.

だが，これより題材のやつの方が整理されているのでそっちをお勧めする．原典もちょっと難易度は高いが読んでみる価値はあると思うので，興味があればぜひ読んでみるのがいいんじゃないだろうか [1]．

単純型付ラムダ計算と型推論

Let多相の話に入る前に，まずは単純なものから話を始めていく．つまり，単純型付ラムダ計算の型推論を考えていく．単純型付ラムダ計算は，変数と定数，抽象，適用だけがある，単相な型の値しか作成できないような言語で，以下のような構文要素により構築される．

今回は定数として， unit 型の値 () のみを考えることにする．型システムは以下のように与えられる．

型安全性とかは今回はあまり興味はないので，評価モデルとかは省略する．さて，この体系に関しての型推論というのはいくつか考えられるが，今回考えたい問題は，式の構文要素から型指定を抜いたものに対して型チェックを満足させるような型を計算できるかというものだ．つまり，以下の型なしラムダ計算の式に対して型がつけられる場合はその型を，付けられない場合付けられない旨を出力するアルゴリズムが作れるかということになる．

ちゃんと問題として形式化するなら，

のような型システムについて，

型なしラムダ計算の項 $e$ に対して， $\vdash e: \tau$ を満たす $\tau$ が存在すればその $\tau$ を，存在しなければ $\bot$ を出力する

アルゴリズムを構築できるかというのが今回扱う問題になる．これを解くためのアルゴリズムは色々知られているが，今回は以下のようなアルゴリズムを考える:

この時， $\mathcal{W}_{\text{simply}}(\emptyset, e) = (S, \tau)$ の時 $\mathbf{default}(\tau)$ ，それ以外の時 $\bot$ を返すと問題の解になる．アルゴリズム中での $\mathcal{U}$ は単一化と呼ばれるアルゴリズムで，以下を返す:

$S\tau_1 = S\tau_2$ を満たす置換 $S$ がある時， $\mathcal{U}(\tau_1, \tau_2) = S$

アルゴリズム $\mathcal{W}_{\text{simply}}$ は基本抽象の変数の型を変数としておいておき，単一化により型チェックが通る範囲まで型を具体化する．例えば， $(\lambda f\ldotp \lambda x\ldotp \lambda y\ldotp f\; y)\; (\lambda x\ldotp x)\;\text{\texttt{()}}$ に対して，この推論アルゴリズムは次のように動く:

イメージとしては，以下のような感じ:

抽象の各変数に型変数を割り当てていき，各式を見て単一化により型を具体化していく．このようにして，単純型付ラムダ計算の型推論は行える．

Let多相

さて，先ほど見た単純型付きラムダ計算は単相的な型，つまりパラメータなどを持たない型としか扱えない．なので，例えば次のようなプログラムは型付けできない:

\lambda \mathit{id}\ldotp (\mathit{id}\;(\lambda x\ldotp x))\;(\mathit{id}\;\text{\texttt{()}})

先ほど紹介した型推論アルゴリズムでこのプログラムの型を推論しようとすると，

のように途中で $(\beta_2 \to \beta_2) \to \beta_3$ と $\mathbf{unit} \to \beta_4$ のような型を単一化しようとして失敗する．これは，変数 $\mathit{id}$ を関数に適用する箇所と， $\mathbf{unit}$ 型の値に適用する箇所の二つがあるためだ． $\mathit{id}$ を関数をとる関数型として扱うと後者が立たず，逆に $\mathbf{unit}$ 型の値をとる関数型として扱うと前者が立たない．これが単一化の失敗に現れており，この式に正当な型をつけることはできない．これを回避するには，

\lambda \mathit{id}_1\ldotp \lambda \mathit{id}_2\ldotp (\mathit{id}_1\;(\lambda x\ldotp x))\;(\mathit{id}_2\;\text{\texttt{()}})

のようにそれぞれ必要な型ごとに変数を用意する必要がある． $\mathit{id}$ の実装としては $\lambda x\ldotp x$ が関数を受け取る場合も $\mathbf{unit}$ を受け取る場合も適合する．しかし，単純型付ラムダ計算の世界ではこの実装も型によってそれぞれ書く必要がある．しかし，これはモジュール性の観点からも再利用性の観点からも微妙だ．

そこで，多くのプログラミング言語は多相型を持つ値を作れるようにすることである程度この問題を解決している．具体的には，

\mathbf{let}\;\mathit{id}: \forall \alpha\ldotp \alpha \to \alpha = \lambda x\ldotp x\; \mathbf{in}\; (\mathit{id}\;(\lambda x\ldotp x))\;(\mathit{id}\;\text{\texttt{()}})

のように書くと， $\mathit{id}$ は関数を受け取る部分では $\alpha$ を適合する関数型に， $\text{\texttt{()}}$ を受け取る部分では $\alpha = \mathbf{unit}$ にと，それぞれの使用箇所で適合する型をパラメータに入れて，それで型付できればよしとするようなシステムを搭載している．これにより，多相型を持つ値を作ってそれを公開するようにすれば，使用箇所でわざわざ実装を書き直すことなく型を変えて使用することができ，実装と使用箇所を分離して管理することができるようになる．

さて，表現力の観点からも多相型を入れた体系は理論的に幾つか提唱されており，特に単純型付ラムダ計算にパラメータ多相を入れた拡張として System F という体系がある．System F は多相型の値を単装型の値と同じように扱うことができ，かなり強力な拡張になる．ただ，System F は完全な型推論が不可能であることが知られている [2]．現実的には，プログラミング言語の機能として，System F ほどの強力な拡張はいらずある程度型推論ができる体系が欲しくなる場合が多い．そこで，多相型の値の作成方法と扱い方を単装型に比べて制限した上で，完全な型推論が行える体系として Let 多相というものが提唱されている．Let 多相は先ほどの単純型付ラムダ計算の構文に，let 構文と呼ばれるものを足す．構文の全体は以下のようになる:

let 構文は，多相型を持つ値を作成できる構文で，この構文で束縛された変数のみ多相型を持って良いということになる．Let 多相では型は単相型と多相型の二種類を持ち，それぞれ以下のような構文を持つ:

単相型 $\tau$ は基本単純型付ラムダ計算の時と変わらないが，変数 $\alpha$ が許容される点が異なる．ただし，変数を含んでいても式 $e_1$ では変数に関数型を， $e_2$ では変数に $\mathbf{unit}$ 型をというような使い分けはできず，変数には何か一つの型を固定して単相的に紐づけることしかできない．逆に，多相型 $\sigma$ は内部にパラメータを持ち，そのパラメータに応じて単相型を変えることができる．Let 多相の型付規則は以下のようになる:

$\sigma \succ \tau$ はインスタンス化と呼ばれ，多相型 $\sigma$ のパラメータに何かしら単相型を紐づけたものが $\tau$ であると読む． $\mathrm{Gen}(\Gamma, \tau)$ は一般化と呼ばれ，単相型 $\tau$ に含まれる変数をパラメータ化して多相型を返す操作になる．Let 多相は，環境に多相型を持つ変数を含む．しかし，その変数が式中で使われる場合はインスタンス化して使わなければいけないというのが変数の規則になる．抽象と適用は単純型付ラムダ計算の際と同じで，抽象の際環境に入る変数は，パラメータのない多相型として追加される．let 構文では，変数に束縛する式の型を一般化して，型が具体化されていない部分はパラメータとして扱って良いということを示している．Let 多相の型推論とは，この型システムに対して，

Let 多相の項 $e$ に対して， $\vdash e: \tau$ を満たす $\tau$ が存在すればその $\tau$ を，存在しなければ $\bot$ を出力する

アルゴリズムを構築できるかという問題になる．

Let 多相の型推論

この型推論アルゴリズムは，単純型付ラムダ計算の時に紹介したアルゴリズムを let 構文に対して拡張することで得られる:

この時式 $e$ について， $\mathcal{W}(\emptyset, e) = (S, \tau)$ の時 $\mathbf{default}(\tau)$ ，それ以外の時 $\bot$ を返せば，型推論アルゴリズムとなる．単純型付ラムダ計算の時と異なるのは，インスタンス化と一般化の部分，すなわち変数の規則と let 構文の規則で，その他は基本単純型付きラムダ計算の時と同じである．考え方も基本同じで，ただ多相型から変数が参照される際にインスタンス化されること，let 構文では一般化が起きることが起きるようになることが付加されるという感じだ．

導出例は以下のようになる:

イメージとしてはこんな感じ:

変数 $\mathit{id}$ に行き着いたところどころで，インスタンス化によって新たに変数が置かれるのがポイントだ．これにより，同じ変数 $\mathit{id}$ でも出現位置が異なると異なる型を持てるようになる．

なお，Milner 先生の元文献では Algorithm J という Algorithm W の再代入可能な変数を使った効率良い版の実装も紹介されているので，興味がある人は見てみると実装の参考になるかもしれない．

さて，一応題材として扱ったやつにも触れておくと，今回の題材では Algorithm W とは別に Algorithm M という別の let 多相の推論アルゴリズムを考案している．Algorithm W は適宜型が分からない部分で変数を導入し推論を進め，部分式についての型の情報が揃った段階で単一化することで型の具体化と競合がないかのチェックを行なっていた．しかし，この方式は，型エラーが単一化まで先延ばしにされ，分かりにくいという問題がある．Algorithm M はその問題を解消するため，最後に一気に単一化を行うのではなく，ある程度できる単一化を早期に徐々に進めていこうといった感じの型推論アルゴリズムになる．具体的には以下のようになる:

この時，式 $e$ について， $\mathcal{M}(\emptyset, e, \beta) = S$ の時 $\mathbf{default}(S\beta)$ ，それ以外の時 $\bot$ を返せば，型推論アルゴリズムとなる．基本的には，与えられた式の型を変数としておき，それを部分式について推論を進める途中節々で単一化をかけて，徐々に具体化していくという感じだ．導出例は以下のようになる:

正直どっちがいいかは場合による気がするが，まあこういうアルゴリズムもあるよという感じだ．こんな感じで Let 多相であれば完全なアルゴリズムを与えられる．正当性とかに興味があれば，題材と Milner 先生の方のを見てみると良いだろう．

単一化の実装

さて，ここまで Let 多相の推論について扱ってきたが，推論アルゴリズムは基本単一化というアルゴリズムを基に構築されており，重要なパーツになっている．最後にこの単一化の部分について少し触れておこう．単一化は何も型の文脈だけで重要なアルゴリズムではなく，論理プログラミング，パターンマッチなどでも根幹をなす概念で，要は変数を含む項が2つあった時，その変数の部分いい感じに弄れば同じにできるかというのを解くアルゴリズムだ．ただ，体系によって結構決定不能になったり，効率があまり良くできないといった問題があるので注意が必要な問題でもある．

さて，今回扱う範囲の単一化は，俗に first-order unification と呼ばれる問題の範疇になる．要は単純な木で表現できる，変数とコンストラクタで構成される項の単一化は大体どういう構文を持っていても似たようなアルゴリズムが用意できるということだ．ついでに，higher-order，つまりラムダ項などを入れ正規化後の項が一致するかみたいな問題は決定不能になることが知られている．つまりは，型システムに型関数みたいなもの入れた状態で，Algorithm W のような型推論入れようとすると基本決定不能になる．なので，今回は first-order unification の範囲なので，アルゴリズムはいくつか知られたものがあるが，現実的には型システム強化しすぎると一筋縄でいかなくなるので注意が必要という感じ．

first-order unification のアルゴリズムはいくつか知られているが，中でも Martelli-Montanari Algorithm [3] が有名なものかな [4]．基本的には以下のようなアルゴリズム:

単純に項の根から一致しているか見ていって，変数部分は代入で両者一致するよう置き換えていきましょうというやつ． $\tau_1 \to \tau_2$ を2引数のコンストラクタ $(\to)(\tau_1, \tau_2)$ ， $\text{\texttt{()}}$ を0引数のコンストラクタだと思ってこのアルゴリズムを使うと，単一化ができる．

まとめ

というわけで，Let 多相とその推論アルゴリズムの紹介だった．あんまりネット上でこういうのまとめてる文献見つからなかったので，自分の参照用という側面が強いが，まあなんかお役に立てばという感じ．

型付ラムダ計算ベースの多相型を導入している言語は，それぞれが色々創意工夫をしてはいるものの，基本はこれらのアルゴリズムをベースにしていることが多い．なので，ここら辺理解しておくとエラーメッセージの気持ちを読み取りやすくなったりする [5]．興味があれば学んでみて損はないだろう．

今回はこんな感じで．

[1]	正当性とか諸々をすっ飛ばせば，Algorithm W，Algorithm J とかの部分は普通に理解できるだろうし．

[2]	J.B.Wells. Typability and typechecking in system f are equivalent and undecidable. Annals of Pure and Applied Logic, 98:111–156, 6 1999.

[3]	Alberto Martelli and Ugo Montanari. An efficient unification algorithm. ACM Transactions on Programming Languages and Systems, 4:258–282, 4 1982.

[4]	ここら辺はあんまり知らん領域なので良く分からん．SAT へのエンコード方法とかあったりするんかな?

[5]	正直アルゴリズム理解しないと読み取れない型エラーもどうかと思うが...

文脈依存 PEG による Haskell パーサ

2022-02-23T23:53:35+09:00

前に PEG パーサジェネレータライブラリ ptera を作っているという話をしたが，今回はその第二弾．ptera で Haskell2010 の文法パーサを例に追加してみたんだが，その過程で色々あったのでその備忘録．

結論から言うと，ptera に前回から以下の拡張を加えた．

先読みを強化し，もうちょっとちゃんと機能するように
文脈依存でパースができるようにした

後は，Template Haskell で文法書けるようにしたりもしたが，まあそれはいいでしょ．

Haskell2010 と ptera

ptera でひとまず Template Haskell で文法が書けるフロントエンド部分作った後，Haskell 2010 ぐらいパースできないと使い物にならないなあと言う感じで Haskell の example project 書いてみたんだが，ここで色々つまづいてしまった．主に今回説明する ptera の拡張は，この example project 書くために入れたと言っても過言ではない．まあ，普通に Haskell 2010 パーサ実装以外でも役に立つ機能で，今後僕は普通に使っていく機能ではあると思うので足りない機能ではあったんだろうけど．

さて， Haskell 2010 の文法自体はまあ大きくはあるんだが，曖昧さ含む部分が結構あるのを除けば割と普通の文脈自由文法によって定義されていると思う [1]．ただ，Haskell 2010 のパーサを実装する上で凶悪なものとして知られているのが，レイアウトルールと呼ばれる規則だ．

レイアウトルールとはインデントによって文法の意味を変えるようなパース時のメタ規則だ [2]．レイアウトルールは Haskell 内の用語で，一般的にはオフサイドルールなどと呼ばれることもある．仕様自体は一見そこまで複雑なものではなく，基本的にはトークナイズの後にそれぞれのトークンの位置を見て「 {」，「 ;」，「 }」を自動で挿入するようなものになっている．これを前段にかます前提で文脈自由文法は定義されていて，例えば

f :: Int
f = x where
    x = 1

みたいなプログラムは，

{f :: Int
;f = x where
    {x = 1
}}

のように明示的にレイアウトが判別できるようなプログラムに変換された後，パースが走るという感じだ．さて，この話を聞く限りはそこまで複雑な話であるように見えないだろう．実際，ここまでの話で終わるならレイアウト・ルールがここまでパーサ実装者にとって凶悪認定されることはないだろう．パーサ実装者の頭を悩ますのは，レイアウトルールの規則の中の1つ， Haskell 2010 Language Report 10.3 Layout に存在する以下の規則だ:

L (t : ts) (m : ms) = } : (L (t : ts) ms) if m ≠ 0 and parse-error(t) (Note 5)

Note 5. The side condition parse-error(t) is to be interpreted as follows: if the tokens generated so far by L together with the next token t represent an invalid prefix of the Haskell grammar, and the tokens generated so far by L followed by the token "}" represent a valid prefix of the Haskell grammar, then parse-error(t) is true.

Note 5. 右隅の条件 parse-error(t) は次のように解釈されます: L がこれまで生成したトークンと次のトークン t が，Haskell 文法の無効な接頭辞を成し，L がこれまで生成したトークンと "}" が Haskell 文法の有効な接頭辞を成す場合，parse-error(t) は真である．

L は文法に入る前の前処理で，トークンの位置を見ていい感じに「 {」，「 ;」，「 }」を挿入する前処理関数の実装になっている．この規則以外はトークンとその位置から決まるのだが，この規則だけはなんと文法のパースができるかに依存することになる．この関数を愚直に実装するなら，トークン列の全ての位置でパースしてみて失敗しないかを見ることになるだろう．さらに厄介なのが，パースが失敗した後に「 }」が挿入されトークン列が 変わる ということだ．そのため，今まで試してきたパースとトークンが挿入された後では結果が異なる可能性が十分あり，予測も難しいということになる．

我らが GHC も例に漏れずレイアウトルールの実装ではかなり苦労しており，時々パーサに関するイシューが上がっている [3]．また，Haskell のパーサは GHC 以外でも Haskell コミュニティ内でさえいくつも実装が行われている．HSE (haskell-src-exts) と言うライブラリもその1つで Hoogle， stylish-haskell などで使われている．HSE ももちろんレイアウトルールには対応しているわけだが，その実装にもかなり根深い問題として，空の where をパースできないと言うことが知られている [4]．

このような苦労をしてまでこのレイアウトルールを入れることに意味はあるのだろうか？このルールさえなければ，おそらく GHC や他の実装もトークナイザとパーサを完全に切り離して実装できるはずだ．このルールが役に立つ例として，例えば以下のケースがある:

main = do
    pure x
    where
        x = 0

この場合，詳細は省くが

{main = do
    {pure x
    ;}where
        {x = 0}}

のような形でトークンが挿入されることになる．このうち， where の手前の } がパースエラーによって挿入されるものになる．このようなプログラムはしばしば書かれるので，割とパースエラーによるレイアウトに依存したプログラムはあるはずだ．後は，Haskell Language Report でも例として紹介されている以下のケースだ:

let x = e; y = x in e'

この場合は，

let {x = e; y = x }in e'

のようにトークンが挿入されることになる．流石にこういうプログラムを書く人は少ないかもしれないが， let x = 1 in x + 1 みたいなワンライナーを書く人は割といるんじゃないだろうか．このようなプログラムはパースエラーによるレイアウト終了のルールに頼っていることになる．割と便利ではあるのだ．正しく実装するのが非常に困難なだけで．

さて，具体的にこのレイアウトルールに則ったパースをどう行うかだが，GHC ではどうやっているかというと，GHC が使っている LALR パーサジェネレータに，error トークンというそのトークンの位置でパースが失敗した場合に復帰するようなうってつけの機能が実装されており，それを使用している．GHC の場合は，そもそもトークナイザとパーサが分かれてはいるものの深く連動しており，互いにコンテキストを共有しあっているという (恐ろしい) 実装になっていて [5]，かなり改修が困難なものになっている．そのため，昔はコーナケースのパースイシューを提示されても修正が不可能みたいなこともあり (今も眠っているイシューがあるかもしれない)，バージョンアップ毎のリファクタリングでかろうじて拾っていくみたいな状況になっている．

例に漏れず ptera でもレイアウトルールに対応するため大幅な機能アップデートを余儀なくされた．特に，パース途中で入力のトークン列が変わるというのは，PEG と大変相性が悪い．最終的にその部分については，それなりに満足いく対応はできたが，代わりに幾つかのものを捨てることにもなった．その対応方法について紹介すると言うのが，今回の内容だ．対応方針は「パースアクションで文脈を変更できるようにし，その際のメモ化は捨てる」だ．この結果，純粋な (アクションで文脈をいじらない) PEG が入力なら相変わらず線形時間でパース可能だが，全体としては ptera は線形時間パースを捨てるという道を選んだ．

文脈依存 PEG とレイアウトルール

さて，ptera で Haskell のパーサを実装するとなった段階でまず着手したことは，そもそもトークン列をパースの状態によって変えるのをやめられないかということだった．入力トークン列がパース途中に変わる場合かなり実装が手間だし，そもそも PEG とかなり相性が悪い．ただ，まあこんぐらいパースできないと後々困るので，方法をいくつか模索した．その結果，PEG ではちょっと難しそうだったので，文法を拡張する方向でいくことにした．ただ拡張の方向として，文法に何か規則を加えたわけでなく，文脈依存のアクションを許すようにした．具体的には，文脈を規則毎に更新したり，文脈によってパースを失敗させたりできる．

コンセプトとしては，

body ::= open body? close

open ::= "(" | "{" | "["
close ::= ")" | "}" | "]"

みたいな文法があった時に，

body ::= open body? close

open ::= "("    { l ↦ push("(",l) }
       | "{"    { l ↦ push("{",l) }
       | "["    { l ↦ push("[",l) }

close ::= ")"   { l ↦ pop(l) | !empty(l) & front(l) = "(" }
        | "}"   { l ↦ pop(l) | !empty(l) & front(l) = "{" }
        | "]"   { l ↦ pop(l) | !empty(l) & front(l) = "[" }

みたいな形で文脈の変更アクションと文脈検査を追加できるみたいな感じ．読み方としては，{} で囲まれた部分が文脈操作を現していて，x ↦ y で文脈 x を y に更新する． | で条件をつけることもでき，その場合条件が成立しなければその部分の選択を失敗させ，次の選択にいく．最初に例示した文脈なしの場合は開く数と閉じる数が一緒かどうかを検査しないので，例えば ([{])} みたいな対応がめちゃくちゃなものを accept してしまう．しかし文脈付きのやつはその対応を文脈上で検査することで，ちゃんと括弧の種類が対応しているものでないと accept しない．もちろんこの例は，次のように書けば文脈上での検査は不要になる:

body ::= "(" body? ")"
       | "[" body? "]"
       | "{" body? "}"

ただ，これぐらいの構文定義ならいいかもしれないが，構文定義が大きくなると文脈でなんとかした方が見通しが良くなることもある．もちろんこの機能は，文法クラスの拡張にも使える．基本 PEG はスタック1つ分のマシンで検査できる範囲としたら，文脈にもスタックを持たせることでスタック2つ分の検査ができる．なので文脈の持たせ方によっては，基本チューリング完全な構文検査ができる．

この機能をどうレイアウトルールに適用するかだが，基本的な発想としては，レイアウトルールの前処理関数を文脈操作でエミュレートすると言う感じになる．さて，その前にまず Haskell のレイアウトルールの詳細について説明しておこう．Haskell Language Report に記載されているレイアウトルール [2] の処理は，2段階に分けられる．

1段階目はトークンの位置情報を適度に挿入する処理になる．
2段階目がその位置情報を見ながらレイアウトトークン「 {」，「 ;」，「 }」を挿入していく．

具体的には次のとおりだ．1段階目は，トークンの列に対して要所要所に以下のレイアウト位置情報を埋め込む:

{n}: 新規レイアウト開始． n はレイアウトのインデント位置を表す．
<n>: レイアウト中の改行． n は改行時のインデント位置を表す．

処理の内容は以下のようになる:

$P$ はトークンの列 $\mathit{ts}$ を受け取り，適宜レイアウト位置情報を挿入する．例えば，

module Main where

x = case "str" == "str" of
    True  -> Nothing
    False -> y where
        y = do z <- Just ()
               pure z

f z = z where

のようなプログラムの場合，

module Main where

{1} x = case "str" == "str" of
    {5} True  -> Nothing
    <5> False -> y where
        {9} y = do {16} z <- Just ()
                   <16> pure z

<1> f z = z where{0}

のようになる．新規レイアウト開始情報は，

プログラムが module で始まってない場合一番最初
let， where， do， of の4つのトークンの後

で { が続いていない場合に挿入される．Haskeller の中にはあまり意識していない人も多いかもしれないが，プログラム全体もレイアウトを持っているので，例えば

  x = 0
y = 1

のようなプログラムは

  {x = 0
}y = 1

のようにレイアウトがちゃんと付かないためパースが失敗する．このような場合に最初に { が挿入されるのは， P が挿入した新規レイアウト開始の情報に依るものだ．module が最初にない場合となっているのは， module ... where の後でもレイアウトを字下げなしで開始できるようにするためのハックだ．詳しくは後述するが，Haskell のレイアウトは今のレイアウトより 1 以上字下げをしないと開始できない．なので，もし「module が最初にない場合」の条件がなければ，

module Main where

x = 0

みたいなプログラムは valid にならず，代わりに必ず

module Main where

 x = 0

のように一文字以上下げてモジュールの本体を書かなければいけなくなる．そこらへんの事情があって，最初だけ特殊な条件が入れてある．

2段目のレイアウト処理では，1段目に挿入されたレイアウト情報とスタックを元に，レイアウトトークンを挿入していく:

この処理により，最終的に上記で挙げたプログラム

module Main where

{1} x = case "str" == "str" of
    {5} True  -> Nothing
    <5> False -> y where
        {9} y = do {16} z <- Just ()
                   <16> pure z

<1> f z = z where {0}

は，

module Main where

{x = case "str" == "str" of
    {True  -> Nothing
    ;False -> y where
        {y = do {z <- Just ()
                ;pure z

}}};f z = z where{}}

のように明示的なレイアウトトークンが挿入された状態に変換される．この処理は大まかには

レイアウト開始時スタックにレイアウト開始位置をプッシュする．明示的な中括弧の場合は 0 をプッシュする
暗黙的な中括弧で開始されたレイアウトについては，スタックとレイアウト位置情報によって適宜レイアウトを閉じ，スタックから対応するレイアウト開始位置をポップする．明示的な中括弧閉じの場合は，スタックの先頭が 0 かチェックしてポップする

と言う感じのことをする．細かく見ていくと，

L_1(t:\mathit{ts}, \mathit{ms}) = \texttt{";"}:L_1(\mathit{ts}, \mathit{ms})\hspace{1em} (t = \langle n\rangle, \mathit{ms} = n:\mathit{ms}')

の規則は，現在レイアウトの位置と一致した改行を見つけると ; を挿入していく．まあこれはいいだろう．

L_1(t:\mathit{ts}, \mathit{ms}) = \texttt{"\}"}:L_1(t:\mathit{ts}, \mathit{ms}')\hspace{1em} (t = \langle n\rangle, \mathit{ms} = m:\mathit{ms}', n < m)

の規則は，現在レイアウトの位置よりインデントが下がった場合は，そこでレイアウトを閉じる．

L_1(t:\mathit{ts}, \mathit{ms}) = L_1(\mathit{ts}, \mathit{ms})\hspace{1em} (t = \langle n\rangle, \text{otherwise})

の規則は，現レイアウトの位置よりインデントが上の場合やレイアウトがまだ開始されていない場合，改行位置情報を無視する．これらにより，改行の情報は現在のレイアウトの状態により適切なレイアウトトークンへと置き換えられる．次に

L_1(t:\mathit{ts}, \mathit{ms}) = \texttt{"\{"}:L_1(\mathit{ts}, n:\mathit{ms})\hspace{1em} (t = \{ n\}, (\mathit{ms} = m:\mathit{ms}' \land n > m) \lor (\mathit{ms} = \epsilon \land n > 0))

の規則は，レイアウト開始位置を見て，現在のレイアウトより字下げが行われている場合は中括弧トークンに変換し，スタックにも新しい位置情報を入れておく．その次の規則

L_1(t:\mathit{ts}, \mathit{ms}) = \texttt{"\{"}:\texttt{"\}"}:L_1(\langle n\rangle:\mathit{ts}, \mathit{ms})\hspace{1em} (t = \{ n\}, \text{otherwise})

では字下げが行われていない場合は即レイアウトを閉じる．また，この場合改行情報だけは残しておく．これらの規則により，

{1} x = 0 where
    {5} x1 = 1

<1> y = 0 where

{1} z = 0 where{0}

みたいな場合，

最初の {1} を見る場合，スタックが空なため新たなレイアウトを開始し，スタックに 1 をプッシュする
次の {5} では，現在のレイアウト位置 1 より字下げしているため，また新たなレイアウトを開始し，スタックに 5 をプッシュする
5 のレイアウトは次の <1> で閉じられる
次の {1} では，現在のレイアウト位置 1 と同じレイアウト位置なため，レイアウトを即閉じ改行情報を残す．この改行情報により， z の前に ; が挿入される
最後の {0} では，現在のレイアウト位置 1 よりレイアウト位置が左にあるため，レイアウトを即閉じ改行情報を残す．この改行情報により，残っているレイアウトも全て閉じられる

という風な処理になり，

{x = 0 where
    {x1 = 1

};y = 0 where

{};z = 0 where{}}

というプログラムが出来上がることになる．残りも見ていくと，

L_1(t:\mathit{ts}, \mathit{ms}) = t:L_1(\mathit{ts}, \mathit{ms}')\hspace{1em} (t = \texttt{"\}"}, \mathit{ms} = 0:\mathit{ms}')

は明示的な中括弧閉じの場合，レイアウトが明示的な開始がされたか確認する．明示的な開始でなければ

L_1(t:\mathit{ts}, \mathit{ms}) = \mathrm{fail}\hspace{1em} (t = \texttt{"\}"}, \text{otherwise})

の規則によりパースを失敗させる．

L_1(t:\mathit{ts}, \mathit{ms}) = t:L_1(\mathit{ts}, 0:\mathit{ms})\hspace{1em} (t = \texttt{"\{"})

の規則では，中括弧により明示的なレイアウトを開始する．

L_1(t:\mathit{ts}, \mathit{ms}) = \texttt{"\}"}:L_1(t:\mathit{ts}, \mathit{ms}')\hspace{1em} (\text{otherwise}, \mathit{ms} = m:\mathit{ms}', m > 0, \mathrm{parseError}(t))

の規則は，冒頭で問題にした規則で，パースエラーが起きる位置で暗黙のレイアウトを自動で閉じるというものだ．他の場合は

L_1(t:\mathit{ts}, \mathit{ms}) = t:L_1(\mathit{ts}, \mathit{ms})\hspace{1em} (\text{otherwise})

の規則により単にトークンを受け流していく．最後に入力トークンがなくなった時は，

L_1(\epsilon, \mathit{ms}) = \left\{\begin{array}{ll} \epsilon &(\mathit{ms} = \epsilon) \\ \texttt{"\{"}:L_1(\epsilon, \mathit{ms}') &(\mathit{ms} = m:\mathit{ms}', m > 0) \\ \mathrm{fail} &(\mathit{ms} = 0:\mathit{ms}') \end{array}\right.

の規則により，閉じていないレイアウトを閉じていく．その中に明示的な開始によるレイアウトがあった時はパースエラーにする．これが標準仕様の全容になる．

これを文脈付き PEG にどう変換していくかだが，基本的には1段目のレイアウト処理は少し改良しつつそのまま残し，2段目のレイアウト処理を文法に統合するといった感じになる．まず，レイアウト処理を

のように変更する．主な変更点は，以下の2点:

新規レイアウト開始トークンの後に，改行トークンも続くようにしたこと
入力終了時の位置を 0 でなく 1 に変更

その変更の意味は置いといて，文法の方も載せておく:

$\mathit{decls}$ はレイアウトルールを処理する文法の代表として載せている．レイアウトルールを適用する場所では，このように $\mathit{expbo}$ ， $\mathit{expbc}$ ， $\mathit{impbo}$ ， $\mathit{impbc}$ で囲むようにする．

さて，肝心の文脈操作の方だが，文脈にはレイアウトスタックをそのまま使う． 0 が明示的なレイアウト位置，それより上の値は暗黙的なレイアウトの開始位置を表す． $\mathit{expbo}$ ， $\mathit{expbc}$ についてはいいだろう． $\mathit{impbo}$ に2つの規則は元々のレイアウト処理関数の

L_1(t:\mathit{ts}, \mathit{ms}) = \texttt{"\{"}:L_1(\mathit{ts}, n:\mathit{ms})\hspace{1em} (t = \{ n\}, (\mathit{ms} = m:\mathit{ms}' \land n > m) \lor (\mathit{ms} = \epsilon \land n > 0))

の規則に対応するものになる．最後の一つは，

L_1(t:\mathit{ts}, \mathit{ms}) = \texttt{"\{"}:\texttt{"\}"}:L_1(\langle n\rangle:\mathit{ts}, \mathit{ms})\hspace{1em} (t = \{ n\}, \text{otherwise})

の規則の一旦を担うものになる．今回の前処理では， {n} の後に <n> が挿入されるため， $n + 1$ をスタックにプッシュしておくと強制的にレイアウトの字下げ判定が入り，後段の処理で即 } が挿入されることになる．元の処理と比べて面倒になっているように見えるが，むしろ元の処理は実は {n} がレイアウト開始と改行情報の両方の役割を担っていてそれを今回分離したからだ．実際上で挙げた元のレイアウト処理では， {n} を処理した後後段の処理を <n> を挿入し直して行っている．このトークンの挿入の代わりに，レイアウトを閉じる処理を全て一箇所にまとめるということを今回は行なっている．これが前処理時，元の処理では挿入していなかった <n> をわざわざ {n} の後に挿入するようにした理由になる．

$\mathit{impbc}$ はすごく単純になっている．今回の ptera では Haskell パーサ実装は，PEG で文法を書いているので貪欲にパースが行われる．つまり， $\mathit{impbc}$ にたどり着くということは，それ以上パースできるものがないということに他ならない．つまりはそのままパースを進めるとパースエラーになると言うことだ．これは冒頭に述べたパースエラー時のレイアウト自動終了を体現したものと同時に，字下げ時のレイアウト自動終了も包含している．今回の文法では，レイアウトの改行情報を扱うのは $\mathit{semi}$ の規則と $\mathbf{skip}$ の規則だけだ．そしてこれらの規則では，現在のレイアウトの開始位置以降に改行位置がある場合のみパースが成功する．逆に言えばレイアウト開始位置より手前の場合，パースに失敗する．これにより，字下げ時 $\mathit{impbc}$ がリデュースされる感じになる．

$\mathit{semi}$ はまあいいだろう． $\mathbf{skip}$ は特殊な非終端記号．この規則は全ての終端記号の手前で評価される．例えば，

A ::= "b" A "c"

みたいな規則があった時，これは

A ::= skip "b" A skip "c"

みたいな感じになる．これにより各トークンが消費される際，レイアウトに関与しない改行情報はスキップすることで，レイアウト処理を完結させていく．この特殊な非終端記号については，ptera では特に特別な機能を入れず対応しており，終端記号を作る API をラップし必ず $\mathbf{skip}$ がその手前に来るようにしている．

完全なパーサの規則については，https://github.com/mizunashi-mana/ptera/blob/ptera-th-0.2.0.0/example/haskell2010/src/Parser/Rules.hs を参照して欲しい．この規則により，GHC よりかなり見通しの良いパーサが実装でき，また例を見てもらうと分かると思うが，PEG で文法を書くことでほぼ Haskell Language Report の規則をそのまま表現できるという感じ [6]．

文脈を考慮した SRB

さて，ここまでは文脈付き PEG で何を実現したいかの話をしてきたが，では具体的に文脈付き PEG パーサをどう生成するかの話もしておく．前回は，最終的に PEG を SRB という機械に変換し，パーサを生成する方法を紹介した．今回もその方法は基本的に変更はない．ただし，SRB を文脈を考慮して修正したのと，先読みの強化をおこなっている．まずは，SRB の修正部分について話しておこう．といっても，修正自体は文脈が変わったらメモリをまっさらにするだけだが．

まず，文脈操作アクションを文法規則に付与する．具体的には，規則それぞれに対しコンテキストを受け取って以下を返す関数を付与する:

$\mathrm{nothing}$: 更新なし
$\mathrm{update}(\mathit{ctx})$: コンテキストを $\mathit{ctx}$ に更新する
$\mathrm{fail}$: リデュースを失敗させる

コンテキストの集合を $C$ としてこれらの集合を $\mathcal{A}(C)$ と表現する時，アクションは $f: C \to \mathcal{A}(C)$ のような関数となる．この関数は，例えば

{ l ↦ l | front(l) = "a" }

のような文脈操作は，

l \mapsto \left\{\begin{array}{ll} \mathrm{nothing} &(l = \texttt{"a"}:l') \\ \mathrm{fail} &(\text{otherwise}) \end{array}\right.

のような関数で表現する．この関数を SRB の操作， $\mathrm{reduce}$ ， $\mathrm{pushnot}$ にパラメータとして付与する．そして，これを元に SRB の意味論を以下のように修正する:

異なる部分は，

文脈をそれぞれの状態に付与する
文脈が変わったタイミングでメモは抹消
過去の文脈は覚えておき，バックトラック時に必要に応じて文脈を戻す

という感じ．なお，過去の文脈を全て覚えておくのはいささか微妙だが，実際の実装ではバックトラックが発生する場合のみ必要な文脈だけを覚えておくようにしている．こんな感じで，少々手を加えれば SRB の方は対応できる．

先読みの強化

さて，今回の実装でもう一つ大きく変更したのが，先読みの強化だ．ptera の実装は先読みによりバックトラックをなるべく少なくすることで，実用的なパースを行おうというものだ．ただ，今までの実装は $\epsilon$ 規則をどこかに含んでいるとそこで先読みを諦めてしまう．例えば，

abc :: ab "c"
ab ::= "a" | "b" |

みたいな規則があった時，通常 $\mathrm{abc}$ の1文字先読み結果は a / b / c になるが，これまでの ptera は $\mathrm{abc}$ の先読みに $\mathrm{ab}$ の結果をそのまま使っていた．そして， $\epsilon$ の先読みは何が次に来ても良いと言うものだったので， $\mathrm{ab}$ の結果も全てを許容するというものになり， $\mathrm{abc}$ もそれを継承することになる．その結果先読みが機能せず，無駄なバックトラックが発生しやすくなってしまう．特に今回の Haskell パーサの実装では，終端記号の前に $\epsilon$ 規則を含む $\mathbf{skip}$ 記号が置かれるため，ほとんど先読みが機能しなくなってしまっていた．そこで，もう少し先読みを強化してみるかと言う感じになった．

今までの先読みは先に続く文字で許容するものを特定すると言うものだったが，先読み強化にあたって何もトークンを消費しないで先に行ける空遷移 (イプシロン遷移)とトークンを消費する場合の先読み情報を明確に区別するようにした．これにより，上の例で今まで $\mathrm{ab}$ の先読み情報は「次に何があっても良い」と言うものだったのが，「a / b を消費して進むかまたは空遷移」というものに変わる．これにより， $\mathrm{abc}$ の先読みの際 $\mathrm{ab}$ の先読み情報見つつ，空遷移の場合はさらに先を見てみて c を必ず消費するので，先読み結果は「a / b / c いずれかを消費し進む」と結論づけることができるみたいな感じ．

ただ，この修正で変更すべき範囲は結構広い．今までは規則のそれぞれの位置で非終端記号があるならその非終端記号の先読み情報をそのまま使う，終端記号であればそれをそのまま先読み情報とするみたいな感じで先読みを行なっていた．ところが，今回の変更を適用するためには非終端記号の場合先読み情報をそのまま使えるわけではなく，空遷移が入っている場合はさらに先を読む必要が出てくる．そこら辺を踏まえ大きくアルゴリズムを修正することになった．修正した先読みのアルゴリズムは以下のようになる:

このアルゴリズムは最終的に，PEG の各規則ごとにその先読み結果をつけた先読みテーブルを返す．先読みはそれぞれ，消費が発生する場合の消費する可能性のあるトークンの集合と，空遷移が発生するかの真偽値の組から成っている．今回の先読みアルゴリズムは二段構成になっており，まず非終端記号それぞれに対する先読みを行なった後，その結果を元に各規則の正確な先読みを行うようになっている．これはそうしないで正確な先読み一回で済まそうとすると，先読みが循環して正確に行えない場合があるからだ．先読み自体は，空遷移があるなら後ろの先読み結果も使う，空遷移がないなら先読みはそこで完結みたいな感じのことを書き下すとこうなると言う感じ．後は否定の場合を少しだけ正確にしている（といっても焼け石に水という感じだが）．とりあえず，これにより否定が入らないなら本当の1文字先読みが実現できるはず．

まとめ

Haskell パーサが割とちゃんと狙い通りに実現できたので満足している．また先読み強化により，Haskell パーサのバックトラックも劇的に改善した．もう少し考えるべき点はまあまだもう少しあるんだが，とりあえず今回はこれで満足．後はまた使いながら改善していこうかなと．

当初は PEG 使えば割と楽できるんじゃね？と雑に考えていたが，PEG は PEG なりに苦労する部分があると気づけたのは大きいと思う．また，PEG そのものではないが，PEG に文脈をつけてもそれなりに何とかなり，レイアウトルールを割と綺麗に扱えるっぽいと分かったのも良かった．とりあえず，これで ptera 弄るのは一段楽かなという感じ．今回はこれで．

[1]	モジュール修飾子周りの仕様は，実装者に優しいかと言われるとちょっと微妙な気もするが．

[2]	(1, 2) https://www.haskell.org/onlinereport/haskell2010/haskellch10.html#x17-17800010.3

[3]	Haskell 98 から Haskell 2010 でレイアウトルールの仕様が一部変わったりなどや，構文を拡張する GHC 拡張などの影響も大きいが．最近でまだ閉じれられていないレイアウトルール関連の問題としては，https://gitlab.haskell.org/ghc/ghc/-/issues/17359 があるようだ．

[4]	https://github.com/haskell-suite/haskell-src-exts/issues/282

[5]	HSE もそれに倣ってか，同じようにトークナイザとパーサが連動している．PureScript などの Haskell 系列のものも大体似たようなことをやっているあたり，かなり根深い問題であると言うことだろう．

[6]	最も左再帰や曖昧性がある箇所については修正が必要で，その部分は少しずれているが．

upLaTeX から LuaTeX に移行する

2021-12-26T13:26:47+09:00

今まで日本語文書作成で upLaTeX を使っていたのだが，体験が微妙だったので最近 LuaTeX に移行した．特に数式フォントとして，STIX2 を使っていたのだが，文字が崩れたりするのをなんとかしたくて，unicode-math を採用するために移行したというのが大きい．そこまで大変でもなかったのだが，詰まるポイントはいくつかあったのでその備忘録．

移行したのは https://github.com/mizunashi-mana/proglang-notes なので，最終形見たかったらこちらをどうぞ．

構成の変更

今までは，upLaTeX と dvipdfmx を使っていて， jsbook をクラスに使った構成にしていた．

ビルドは， latexmk 経由で uplatex と dvipdfmx から PDF 生成
フォントは，デフォルト Latin Modern で，日本語は IPAex の埋め込み，数式は STIX2 Type1

みたいな感じだ．まあ良くある構成．これを， ltjsbook クラスを使い

ビルドは， latexmk 経由で luatex から PDF 生成
フォントは，デフォルトと数式は STIX2 OpenType，日本語は原ノ味

という構成にした．また，今までは stix2-type1 パッケージを直接使って Unicode 文字経由の数式記号マクロを使っていたが，これを unicode-math 経由で使うようにした．

Latexmk の設定

まず latexmk の設定を変更する．今まで uplatex / dvipdfmx を使っていたのを， luatex を使うよう変更した．設定ファイルは以下:

#!/usr/bin/env perl

use v5.10;
use experimental qw(smartmatch);

# tex options
$lualatex     = 'lualatex -shell-escape -synctex=1 -interaction=nonstopmode';
$pdflualatex  = $lualatex;
$biber        = 'biber %O --bblencoding=utf8 -u -U --output_safechars %B';
$bibtex       = 'bibtex %O %B';
$makeindex    = 'mendex %O -o %D %S';
$max_repeat   = 5;
$pdf_mode     = 4;

$pvc_view_file_via_temporary = 0;

# default preview
given ($^O) {
    when (/MSWin32/) {
        $pdf_previewer = 'start';
    }
    when (/darwin/) {
        $pdf_previewer = 'open';
    }
    default {
        $pdf_previewer = 'evince';
    }
}

# local config
$local_latexmkrc_path = './.latexmkrc.local';
require $local_latexmkrc_path if -e $local_latexmkrc_path;

$pdf_mode = 4; がポイント． latexmk の $pdf_mode は，デフォルトの PDF 生成モードを指定できる．指定できるのは以下のモード [1]:

0 の場合， $latex コマンドを実行するだけ．PDF は生成しない
1 の場合， $pdflatex コマンドによって PDF を生成する
2 の場合， $latex コマンドを実行した後， $dvips コマンドで一旦 PS ファイルを生成し， ps2pdf コマンドで PS ファイルを PDF ファイルに変換する
3 の場合， $latex コマンドを実行した後， $dvipdf コマンドで PDF ファイルに変換する
4 の場合， $lualatex コマンドによって PDF を生成する
5 の場合， $xelatex コマンドを実行した後， $xdvipdfmx コマンドで PDF ファイルに変換する

今までは 3 を指定していたが，今回から 4 を指定している．LuaTeX は基本 pdflatex の後継で，DVI ファイルを経由せず直接 PDF を生成する．この設定により， latexmk main.tex を実行すると main.tex から lualatex コマンドで PDF を生成する．設定はよくあるやつだが， -shell-escape オプションだけは特別に minted パッケージのために付けている． minted 使わないなら付けないほうがいいと思う．

必要なパッケージ

LuaTeX で日本語を書くには，以下のパッケージをインストールする:

luatex
luatexja

これらは collection-luatex， collection-langjapanese に含まれている．後今回は

unicode-math
stix2-otf

を数式用に使う．後は適当に使うやつをインストールする．

プリアンブル

LuaTeX-ja では，jsclasses 互換のクラスがいくつか提供されており，和文文書を書く時は以下のものが使える [2]．

ltjsarticle: 論文・レポート用
ltjsbook: 書籍用
ltjsreport: レポート用

元々 jsbook を使っていたので，今回は ltjsbook を使う:

\documentclass[
    luatex,
    japanese,
    unicode,
    titlepage,
    pdfusetitle
]{ltjsbook}

luatex オプションはドライバ判定のため， japanese は元々 babel のためにつけていたものの流用， titlepage はお好みで，他は hyperref のためのオプションという感じになる．後は適当に使うパッケージを読み込んでおく:

\usepackage{luatexja}
\usepackage{hyperref}
\usepackage{babel}
\usepackage{bookmark}
\usepackage[no-math,haranoaji,deluxe]{luatexja-preset}
\usepackage{unicode-math}

luatexja-preset は font preset を指定するとフォントをいい感じに諸々設定してくれるやつらしい．今回は haranoaji フォントを使うよう指定している． deluxe オプションを指定することで，使えるウェイトを増やせる．後は，

\setmainfont{STIX Two Text}
\setmathfont{STIX Two Math}

% some math fonts not support bold
\DeclareFontShape{TU}{STIXTwoMath(1)}{b}{n}{<->ssub*STIXTwoMath(1)/m/n}{}
\DeclareFontShape{TU}{STIXTwoMath(2)}{b}{n}{<->ssub*STIXTwoMath(2)/m/n}{}
\DeclareFontShape{TU}{STIXTwoMath(3)}{b}{n}{<->ssub*STIXTwoMath(3)/m/n}{}

欧文のテキストフォント，数式フォントに STIX2 を指定する．よく分からないが，フォントシェイプの警告がいくつか出ていたので，フォールバックを明示的に指定している．ここら辺はちゃんと調べたほうが良さそうだが，とりあえずこれでいいかなという．以下が表示サンプル:

アルファベット
いろは
数式

その他

今まで XY-pic を使っていたが，LuaTeX では使えないらしいので，これからは tikz 直接使っていく感じにする．後，数式の記号は今まで amssymb， mathtools， stix2-type1 を併用していたが， unicode-math に一元化した．多少今まで使っていた記号マクロから名前が変わっていた部分はあるが，基本特に使える文字に変化はなかった． unicode-math に一元化したことによって，記号の名前か Unicode コードポイントが分かれば unicode-math マニュアルの記号一覧から検索できる．Detexify が対応していないので，名前が何も分からないと不便な場合もあるが，まあ大体は今までより利便性が上がっているはず．

他に， amsalpha を bibliographystyle に使っていたが，これが使えなかった．こっちも原因はあまり調べていないが，とりあえず，

\bibliographystyle{alpha}

に切り替えて対応している．

まとめ

LuaTeX に移行する際の諸々を書いた．\xymatrix が使えなくなったのはちょっと残念だが，他はそれほど困っていない．まだ使って日が浅いが，なんとかなるかなあという感じ．今回はそんだけで．では．

[1]	https://mirrors.rit.edu/CTAN/support/latexmk/latexmk.pdf

[2]	https://mirrors.ibiblio.org/CTAN/macros/luatex/generic/luatexja/doc/ltjsclasses.pdf

ptera 式 PEG パーサ生成法

2021-11-21T06:02:13+09:00

最近 PEG パーサジェネレータライブラリを作っているんだが，一旦区切りがついたので忘れないうちに備忘録をまとめておく．

さて，PEG は曖昧さが存在しない言語を定義する為の文法だ．基本的には文法自体は結構単純で書きやすい．構文解析も単純ではある．ただ，愚直に構文解析すると入力の長さに対して指数時間かかってしまうため，取り扱いが少し難しい．ただ，入力の長さ分のメモリを用意することで，解析時間を入力の長さに対して線形時間にする packrat parsing という手法が提案され，最近では PEG をプログラミング言語の文法の定義方法として採用する言語も増えているようだ．

PEG の魅力はなんといっても曖昧さを排除できる点と，文法程度を簡潔にできる点だろう．ただ，あまりいい感じのパーサ生成ライブラリがない場合も多い．Haskell にもあんまりいい感じのがなかった．なので今回は，PEG の勉強がてらパーサ生成ライブラリを作ってみたので，その仕組みについて紹介する．なお，かなり PEG 勉強したてで，既存手法検索してもあんまりいい文献当たらないなあと言う感じで独自の手法に手を染めた話なので，もし他にこれよりいい確立された方法あるよとかあったらぜひ教えてもらえるとって感じだ．

なお，ライブラリ自体は https://github.com/mizunashi-mana/ptera で開発中という感じ．

PEG (Parsing Expression Grammar)

PEG は，非終端記号 $N$ ，終端記号 $\Sigma$ ，パース規則 $R = N \to E$ ，初期式 $e_S \in E$ で構成される．式は，以下の要素からなる．

\begin{array}{rlr} e \in E \mathrel{::=} & \sigma &(\sigma \in \Sigma) \\ \mid & A &(A \in N) \\ \mid & \epsilon \\ \mid & e_1\; e_2 \\ \mid & e_1 / e_2 \\ \mid & e^* \\ \mid & e+ \\ \mid & e? \\ \mid & \& e \\ \mid & !e \end{array}

この式は次のような意味論を持つ:

受理条件は $\llbracket (N, \Sigma, R, e_S)\rrbracket = \llbracket e_S\rrbracket = \{x \in\Sigma^* \mid \langle e_S, x\rangle \to \mathbf{s}(x)\}$ になる．特徴的なのは，分岐 $e_1 / e_2$ だろう．文脈自由言語の分岐は優先度は特にないが，PEG では1つ目が2つ目より必ず優先される意味論を持つ．後は， $\& e$ ， $! e$ といった先読み述語を原始構文として持つのも特徴の1つだろうか．ただ，基本的に上の規則をそのまま実装すれば，愚直な構文解析はできる．

さて，愚直な構文解析する場合，基本的に分岐を上から成功するまで順に解析してみてはバックトラックを繰り返すことになる．それぞれの分岐でさらに分岐することもあるわけで，例えば

\begin{array}{rrl} S &\to &\mathrm{a} A \\ &\mid &\mathrm{a} S \\ &\mid &\mathrm{a} \\ A &\to &\mathrm{a} A \end{array}

に $\mathrm{a}$ が $n$ 個続く文字列を受理させるには，基本的には $n$ 回入力文字列を走査することになる．

まあ流石に入力文字列の長さに対して指数時間というのはちょっと微妙なので，線形時間にする Packrat Parsing という手法が提案されている．これもそれほど難しい手法ではない．さて，先ほどの PEG の例で問題だったのは分岐の中でどんどん分岐がネストしていくということだったが，文字列走査が増えることの本質は，同じ文字列走査を何度もやっていることによる．非終端記号 $A$ は一回走査すればどの地点から解析しようとしても失敗すると分かる．ところが愚直にやる場合，何度も同じ解析をすることになる．Packrat Parsing というのは，この同じ解析を何度もやるのを，一度目の解析結果をメモして二度目以降はそれを流用することで抑えようという手法だ．

Packrat Parsing では，入力文字列の全ての地点と非終端記号に対してメモ化領域を用意する．そして，非終端記号の解析に入る時，結果がメモされていればその結果を流用し，メモされてなければ解析してその結果をメモしておく．これにより，非終端記号の解析は最大でも入力文字列の長さと非終端記号の数の積だけとなる．この手法を用いれば，変数は入力文字列の長さ分だけで，他は文法を固定すると定数分で換算できるので，入力文字列の長さの定数倍分のメモリ領域は必要になるが，線形時間で解析が可能ということになる．

PEG vs LALR

とはいえ，まあメモリも線形分消費するわけで，そこら辺は好みが分かれるところだろう．特に，プログラミング言語の構文解析では LALR パーサが主流になっていて，そちらでは Packrat Parsing のようなバックトラックありの線形時間解析ではなく，バックトラックなしに本当に文字列を最初から一度だけ走査していくため，PEG パーサよりパフォーマンス面では優秀ということになるだろう．

エラー箇所の特定もある程度工夫しないと難しい．LALR パーサでは，失敗はそもそも一度しか起こらない為，失敗した地点での規則の候補からエラーの原因を特定しやすい．しかし，PEG の場合バックトラックしながらパースが進んでいく為複数地点で失敗が発生する．しかし，それらが全てエラーの本質とは限らない．例えば，多くのプログラムは複数の文から構成されているが，それぞれの文のパースは多くの場合独立している．そして，それを PEG で解析する場合，一つ一つの文の解析でバックトラックが発生するかもしれない．しかし，文自体のパースに成功したならバックトラック自体は本質的に起こるものであり，プログラムの構文エラーではないのだ．このように，PEG ではエラーの原因を特定しようとすると，失敗した地点の中で構文エラーと捉えるべき失敗を精査する仕組みが必要になる．

このように，実装面で見ると PEG はかなり扱いづらい文法でもある．しかし，PEG にはこのような事情を鑑みても LALR パーサに勝る大きな利点がある．それはパーサの動作が単純であると言う点だ．LALR パーサは，文法からどのようなパーサが生成されるかがかなり捉えづらい．そのため，エラーを起こす規則が分かったとしても，具体的に元の文法でどこの定義の仕方が悪いのかを調べるのは結構難しい．また，元の文法の問題の箇所が分かったとしても，それを自分の要望を満たすように改善する方法を見つけるのにまた手間がかかる．また，本質的に LALR パーサを使っている限りは改善できないといった場合もある．Haskell の do 構文を例に出してみよう．Haskell の do 構文は文脈自由言語で以下のように定義される構文だ:

\begin{array}{rl} \mathit{lexp} \mathrel{::=} & \text{\texttt{do \{}} \mathit{stmts} \text{\texttt{\}}} \\ \mathit{stmts} \mathrel{::=} & \mathit{stmt}_1 \cdots \mathit{stmt}_n \mathit{exp} \\ \mathit{stmt} \mathrel{::=} & \mathit{exp} \text{\texttt{;}} \\ \mid & \mathit{pat} \mathrel{\text{\texttt{<-}}} \mathit{exp} \text{\texttt{;}} \\ \mid & \text{\texttt{let}} \mathit{decls} \text{\texttt{;}} \\ \mid & \text{\texttt{;}} \end{array}

$\mathit{exp}$ ， $\mathit{pat}$ ， $\mathit{decls}$ は定義は省略するが，それぞれ式，パターン，定義文の列を表す非終端記号だ．さて，この文のパーサを生成することを考える．しかし，この文をそのままちゃんと扱える LALR パーサジェネレータはおそらくないだろう．問題となるのは $\mathit{stmt}$ の最初の2つの選択肢だ．これらをそのまま LALR パーサで扱うとなると，例えば x のようなプログラム片において， $\mathit{exp}$ として reduce するか， $\mathit{pat}$ として reduce するかを決定する機構が必要になる．しかし，この文法を定義したものの意図は，後にくるであろう <- がある場合は $\mathit{pat} \mathrel{\text{\texttt{<-}}} \mathit{exp} \text{\texttt{;}}$ の文として，それ以外の時はもう一方の文としてパースしてほしいと言うことだろう．このように先をかなり見ないと前の決定ができないような文法は基本的に LALR では扱えない．もちろん，PEG ではそのまま素直に扱えることになる．

ところで，我らが GHC は LALR パーサジェネレータの Happy を使っているわけだが，そこから分かる通りこの問題は LALR で解決は可能だ．といっても，かなり力技になるが．GHC はここら辺の解決をどうしているかと言うと， $\mathit{exp}$ と $\mathit{pat}$ を一つの非終端記号にまとめ，パース結果からどう解釈するか決めてパース結果に対してバリデーションをかますと言う方法をとっている．具体的には，上の規則を以下のような規則に変更する:

\begin{array}{rl} \mathit{lexp} \mathrel{::=} & \text{\texttt{do \{}} \mathit{stmts} \text{\texttt{\}}} \\ \mathit{stmts} \mathrel{::=} & \mathit{stmt}_1 \cdots \mathit{stmt}_n \mathit{exppat} \\ \mathit{stmt} \mathrel{::=} & \mathit{exppat} \text{\texttt{;}} \\ \mid & \mathit{exppat} \mathrel{\text{\texttt{<-}}} \mathit{exp} \text{\texttt{;}} \\ \mid & \text{\texttt{let}} \mathit{decls} \text{\texttt{;}} \\ \mid & \text{\texttt{;}} \end{array}

こうしておけば，どの選択肢でも $\mathit{exppat}$ として reduce すれば良くなる為，reduce の衝突が起きなくなる．後は，それぞれの選択肢でパース結果を構成する際，式として解釈したい場所は式で使える構文要素だけかどうか，パターンとして解釈したい場所はパターンで使える構文要素だけかどうかをチェックするというわけだ．しかし，このような工夫が随所に散らばるとかなり文法の保守が面倒なものになり，構文木にも色々細工が必要になってきて結構面倒だ．

個人的に PEG に感じている魅力は，このような涙ぐましい工夫をせずとも，自然に文法を定義してそこから自然なパーサを生成することができ，かなり文法の保守が楽になるという点だ．その上で実用的にはある程度遜色ないパフォーマンスも出るはずという感じだ．実際，Python が最近 PEG パーサに乗り換えたことで有名だが [1]，そこでもやはり PEG によるパーサの書きやすさと，それに比べた LL パーサの複雑さと保守管理の手間が主なモチベーションとなっているようだ．

先読み付き PEG

ここからが本題．Packrat Parsing はかなり単純と言う話はしたが，この手法多くのメモは不要だし，入力もバックトラックが発生するので全部パースしないと捨てられないしで，実際問題としてメモリ消費の部分は結構杜撰な面がある．Packrat Parsing 提唱論文では遅延評価を利用してその辺うまく GC できるようにする実装も紹介されているが，正直それも本質的にはあまり寄与していないと思う．というのは，例えば以下の文法が与えられることを考えてみよう:

\begin{array}{rl} \mathit{p} \mathrel{::=} &\text{\texttt{\{}} \mathit{stmts} \text{\texttt{\}}} \\ \mid &\mathit{stmts} \end{array}

$\mathit{stmts}$ の定義は省略するが，こいつは文の列を表す非終端記号だ．さてこの文法から生成された PEG パーサでは，もしプログラムが { で始まる場合，本質的に入力が全て捨てられない．なぜなら，どっかでバックトラックが発生して一番最初に戻ってくることがあるかもしれないからだ．ただ，もし $\mathit{stmts}$ は絶対に { で始まらないように設計されていたとしたら，実際は一番目の選択肢に入った時点で二番目の選択肢は対象外になる．このような場合にも入力を全て保持し続けなければいけないと言うのはかなり微妙だし，それを考慮して注意深く文法を設計するのは PEG を使う動機からして本末転倒だ．

と言うわけで，この節のタイトルに繋がるわけだが，今回作ったライブラリ「ptera」の特徴は，

PEG に先読みを付けてそもそもバックトラックを少なくしてやる
バックトラックが発生する可能性がある地点を予め特定できる実行モデルを考え，適度に入力とメモを GC できるようにする機構を付ける

と言う感じ．まずは一つ目の詳細を紹介していく．といっても正規化して一文字先読みつけるだけだが．

ptera では，与えられる PEG 文法を，クラスは変えないがある程度制限された形で受け取る．まず，式を次の形に制限する:

\begin{array}{rlr} \mathrm{norm}(e) \mathrel{::=} & \mathit{alt}_1 / \cdots / \mathit{alt}_n \\ \mathit{alt} \mathrel{::=} & u_1 \cdots u_n &(n \geq 0) \\ \mid & \& (u_1 \cdots u_n) &(n \geq 1) \\ \mid & ! (u_1 \cdots u_n) &(n \geq 1) \\ u \mathrel{::=} & \sigma &(\sigma \in \Sigma) \\ \mid & A &(A \in N) \end{array}

また初期式 $e_S$ は非終端記号でなくてはいけないということにする．元の PEG のクラスと変わっていないことは，気合いで元の PEG からの正規化アルゴリズム書いて，生成言語が同じことを示せばよいが，今回はそこは省略する．さて，ptera はまず，この正規化された PEG 文法の非終端記号に対して，1文字目として許容しうるものを全て計算する．アルゴリズム自体はそこまで難しくなくて，次のような感じ:

なお，このアルゴリズムが fail する時は，全く文字を消費せずに同じ非終端記号に二度行き着くみたいな時で，つまり無限ループする可能性がある選択肢を含んでいる時．必ずしもその文法が無限ループするとは限らないが，その選択肢を除去しても文法の意味論は変わらないので，ptera ではそのような選択肢を取り除かないとエラーになるようにしている．

後，! (not) の時は先読みを諦めている．基本 not はやってみないと分かんないので，どっちにしろ先読みあんまり効かないケース多いし，そこまで手厚くサポートはしなくてよいかなという感じ．

こんな感じで先読みテーブルを作っておいて，先読み考慮して実行モデルを作ることで，バックトラックが少なくなるし，バックトラックがもう発生しないということも早めに分かるようになる．これにより，バックトラックするかしないかが分かれば，先読みつけない場合より早めにもう必要なくなった入力を解放することができるようになる．

もちろん，今回は1文字先読みしかしてないので，不要なバックトラックが全て事前に取り除けるわけではない．例えば，

\begin{array}{rl} A \mathrel{::=} &B / C \\ B \mathrel{::=} & abd \\ C \mathrel{::=} & acd \end{array}

みたいな文法があった場合，入力が $ab$ で始まっていれば，2文字パースした時点でもうバックトラックが起こらないことが確定する．しかし，今回は1文字しか先読みしていないので，このような場合もバックトラックが起こるものとしてパースは進んでしまう．あんまり深く考えていないが，まず完全にバックトラックが不要になる地点の先読みができるか問題は多分決定不能になる気がする．で，後は効果が良く先読みつける作業が妥当な時間で終わるところを探るという話になる気がするが，一文字先読みは効果が割と期待できアルゴリズムも簡単ということでやっている．ま，つまりあんまり考えてない．そんな感じ．

先読み付き PEG の実行モデル

さて，PEG に先読みを付けたはいいが，先読み付き PEG 文法からそのままバックトラック地点を考慮したパーサを直接生成するのは結構めんどくさい．そこで，ptera はパーサを生成する前に SRB というマシンに変換を行う．基本的に LR パーサの生成法にちょっと毛を生やしたようなもので，出力付き状態遷移機械にスタックを伴った意味論を付与するようなマシンになる．

SRB の遷移は，入力文字によりラベル付けされ，出力として以下の操作が指定できる:

シフト ( $\mathrm{shift}$ ): 入力文字を1つ消費し，次の入力文字を見る
リデュース ( $\mathrm{reduce}(\mathit{alt})$ ): 指定された選択肢を元に，スタックから今までのパース結果を取り出しアクションを行う
バックポイントの設置 ( $\mathrm{pushback}(s)$ ): バックトラック先の状態を伴ったバックポイントを，スタックにプッシュする
否定リデュースポイントの設置 ( $\mathrm{pushnot}(\mathit{alt})$ ): リデュースする否定がついた選択肢を伴ったバックポイントを，スタックにプッシュする
エンター ( $\mathrm{enter}(s, A)$ ): リデュース後の状態をスタックにプッシュし，非終端記号に対してパースを開始する

状態の集合 $S$ に対してこれらの操作の集合を $\Omega(S)$ ，文字列の終端を表す入力文字を $\bot \not\in \Sigma$ とすると，SRB は状態の集合 $S$ ，入力文字の集合 $\Sigma_\bot = \Sigma_\bot$ ，遷移規則を表す部分関数 $R = S \times \Sigma_\bot \rightharpoonup \Omega(S) \times S$ ，初期状態 $s_0 \in S$ の組で表現される．意味論は以下のようになる:

受理関数は， $\llbracket (S, \Sigma_\bot, R, s_0)\rrbracket = \{(x, t) \mid x \in \Sigma^*, \mathrm{c}\langle \emptyset, \epsilon, s_0, x\bot\rangle \to^* \mathrm{c}\langle m, \mathrm{arg}(t), s, \bot\rangle\}$ って感じだ．メタ変数はそれぞれ， $m$ は packrat parsing 用のメモリ， $\rho$ は実行スタック， $\alpha$ は実行結果の列， $t$ は実行結果を表す木， $x$ は入力文字列という感じ．SRB のパースは，3種類の実行状態を持つ:

シフト実行 $\mathrm{c}\langle m, \rho, s, x\rangle$: 通常の実行状態で，SRB の遷移規則を元に状態を遷移させ，遷移時の出力から実行スタックを操作する
リデュース実行 $\mathrm{r}\langle m, \rho, \alpha, \mathit{alt}, x\rangle$: エンターの実行結果を決める操作．今までの実行結果を集めながら，エンターに行き着いたら実行結果を確定し，次のパース実行を始める
バック実行 $\mathrm{f}\langle m, \rho\rangle$: パース失敗から復帰地点まで戻る．復帰地点に行きあたったら，次のパース実行を始める

これが，この3つの実行状態の頭文字が SRB の名前の由来．否定リデュースポイントは，リデュース実行とバック実行を途中で逆転させるようなものになっている．この SRB を先読み付き PEG に対して，選択肢一つ一つをシフト実行，最後までパースできたらリデュース実行，失敗したらバック実行というように作成し，SRB の意味論に則ってパーサを生成するというのが ptera の残りの処理になる．さて，具体的にどう先読み付き PEG から SRB に変換するかだが，これも LR パーサの状態作成方法から着想を得ていて，アイテムと呼ばれる文法の選択肢とパース位置の組を定義し，基本的にはその集合を1つの状態として変換を行なっていく．具体的なアルゴリズムは，PEG 文法 $G = (N, \Sigma, R, A_0)$ ，先読み関数 $L: N \to 2^\Sigma$ ，終端文字 $\bot$ に対して，以下の感じになる:

ちょっと長いが，

非終端記号に対して，入力文字それぞれに対してエンター遷移先のマップを作る
状態それぞれに対して遷移を作成していく

が基本的な流れだ．遷移は，状態に入っている最初の選択肢によって決まる．選択肢のパース位置にあるのが終端記号ならシフト，非終端記号ならエンターを行う．もし，失敗した場合の選択肢があるならその操作を行う前にバックポイントをプッシュしておく．また，バックポイントのプッシュをできる限り少なく，また必要な位置に埋め込む為，他の選択肢でまとめられるものはまとめておく．

正当性は示していないが，成り立つはず:

健全性: 正規化された PEG $G = (N, \Sigma, R, A_0)$ ，先読み関数 $L = \mathit{LookAHead}(G)$ ，終端文字 $\bot \not\in \Sigma$ ，SRB $M = \mathit{ConstructSRB}(G, L, \bot)$ について， $\llbracket G\rrbracket = \mathrm{dom}(\llbracket M\rrbracket)$ が成り立つ．

ptera ではこれらの変換アルゴリズムを使って，PEG から SRB への変換と SRB の実行器を提供している．

ptera の現状と今後

とりあえず，正当性は示していないが ptera は一通り変換と実行器の実装は終えていて，小さい言語で試しにパースしてみて問題なさそうなことも確認した．ただ，現状 ptera を使うにはパースする段階でパーサ生成しないといけない．この後，TemplateHaskell 用の API を作っていく予定で，それが済んだらパーサ生成を TemplateHaskell でやってコンパイル時に事前にパーサが生成できるようになるはずだ．そこまでやったら，一旦 Hackage に上げるかって感じ．その後はあんまり更新の予定はない．

デバッグ情報を出したりする機能は用意していないので，若干使いづらいのとまだバグがありそうという感じがある．多分今後もそれほど真面目にメンテする気はないので，あんまりプロダクション向けではないかなという感じはある．

PEG 自体は色々探求すればまだ面白いことが探せそう．例えば，PEG が他の文法と比べて面白いところとしてエラーハンドリングができるところがある．失敗した時の処理が書けるので，例えば非終端記号ごとにバックトラック先でエラーメッセージをパース結果にすれば，エラーメッセージのカスタマイズとかできたりするのかなあという．後は，Haskell のレイアウトルールパース失敗時の終了処理を，文法として正式に形式化できたりとかの応用が効きそう．時間があったらその辺も考えてみようかなという．とりあえず，備忘録だけ残しておく(結局，備忘録のみになりそうだが)．

まとめ

というわけで，備忘録兼ねて ptera のパーサ生成法を紹介した．ptera では，PEG に先読みつけて，SRB という実行モデルに変換することで，バックトラックを抑えつつ，素の PEG 文法より解析をしやすくしている．

興味があれば触ってみてほしい．後，もっと良い確立手法があればぜひ教えてほしいなあという感じ．では，今回はこれにて．

[1]	https://www.python.org/dev/peps/pep-0617

Happy のコンフリクトレポートと向き合う

2021-01-31T23:37:38+09:00

Haskell には，Happy と言う名前のパーサジェネレータがある．基本的には，yacc と同じような使い勝手のジェネレータで，GHC で使用されているため Haskell のパーサジェネレータとしてはそこそこ実績がある．

Happy は意味アクション付き BNF から LALR(1) パーサを生成する．このパーサは基本的に，構文解析表を見ながら shift / reduce と呼ばれる操作を行っていく，shift-reduce パーサの一種になる．しかし，shift-reduce パーサの生成は，一般に BNF から一意に決まらないことがある．そのような BNF が与えられた場合，一般にジェネレータは警告をユーザに伝えつつ，標準的なパーサを出力するようになっていることが多く，Happy もそのようになっている．ただ，その標準的パーサが意図していない動きをする場合も多い．

今回は，Happy が出す警告の見方とその自分なりの解決方法を紹介する．以下の文献を主に参考にしている．

なお、Happy 1.20 を前提に話す。

shift-reduce パーサ

まずは shift-reduce パーサの簡単な動きを押さえておく．shift-reduce パーサと言っても，その解析方法や実装によって結構生成方法が違うが，今回は LALR(1) に焦点を当てる．今回はそこまで細かい話には立ち入らないので，大まかなイメージをつかんでもらえれば良い．

shift-reduce パーサは，その名の通り，

shift: 入力から1つ文字を持ってきて，葉を作ってスタックに入れる
reduce: スタックから幾つか木を持ってきて，それを組み合わせた木を作りスタックに入れる

の2つの操作を繰り返しながら，パースを行うボトムアップ構文解析法を指す．動きのイメージは https://en.wikipedia.org/wiki/Shift-reduce_parser に割とわかりやすい表があるので，ちょっと拝借する．

R1: assign ← ID '=' sums
R2: sums ← sums '+' prods
R3: sums ← prods
R4: prods ← prods '*' value
R5: prods ← value
R6: value ← INT
R7: value ← ID

という文法があるとする．大文字や '..' が終端記号，小文字で書かれたものが非終端記号だ．この文法から生成されるパーサは，だいたい以下のような動きをする:

パーススタック	先読み	残りの入力	操作
`ID`	`=`	`ID + ID * INT`	shift
`ID =`	`ID`	`+ ID * INT`	shift
`ID = ID`	`+`	`ID * INT`	reduce by (R7)
`ID = value`	`+`	`ID * INT`	reduce by (R5)
`ID = prods`	`+`	`ID * INT`	reduce by (R3)
`ID = sums`	`+`	`ID * INT`	shift
`ID = sums +`	`ID`	`* INT`	shift
`ID = sums + ID`	`*`	`INT`	reduce by (R7)
`ID = sums + value`	`*`	`INT`	reduce by (R5)
`ID = sums + prods`	`*`	`INT`	shift
`ID = sums + prods *`	`INT`		shift
`ID = sums + prods * INT`			reduce by (R7)
`ID = sums + prods * value`			reduce by (R5)
`ID = sums + prods`			reduce by (R2)
`ID = sums`			reduce by (R1)
`assign`			accept

パーサは状態スタックを持っており、次にどういう操作を行うかは、先読み一文字とパーススタックの先頭要素、現在の状態から決まる。

Happy でパーサを記述する

実際に Happy で shift-reduce パーサを生成し、どういう状態と操作が行われるかを見てみる。

-- Parser.y
{
module Parser where
}

%token
    ID  { TokId _ }
    INT { TokInt _ }
    '=' { TokSym "=" }
    '+' { TokSym "+" }
    '*' { TokSym "*" }

%tokentype { Token }

%name assign
%%

assign :: { (Token, Expr) }
    : ID '=' sums   { ($1, $3) }

sums :: { Expr }
    : sums '+' prods    { Sum $1 $3 }
    | prods             { $1 }

prods :: { Expr }
    : prods '*' value   { Prod $1 $3 }
    | value             { $1 }

value :: { Expr }
    : ID                { Val $1 }
    | INT               { Val $1 }

{
happyError :: [Token] -> a
happyError _ = error "happyError"

data Token
    = TokId String
    | TokInt Integer
    | TokSym String
    deriving (Eq, Show)

data Expr
    = Sum Expr Expr
    | Prod Expr Expr
    | Val Token
    deriving (Eq, Show)
}

このプログラムに対して、

happy -i Parser.y

を実行すると、パーサプログラム Parser.hs とパーサ生成時の情報 Parser.info が生成される。Parser.info には文法解析時の情報と、状態遷移に関するものが書かれる。状態遷移に関するものは States 節に書かれている。今回は、

-----------------------------------------------------------------------------
States
-----------------------------------------------------------------------------
State 0


        ID             shift, and enter state 2

        assign         goto state 3

State 1


        ID             shift, and enter state 2


State 2

        assign -> ID . '=' sums                             (rule 1)

        '='            shift, and enter state 4


State 3

        %start_parseAssign -> assign .                      (rule 0)

        %eof           accept


State 4

        assign -> ID '=' . sums                             (rule 1)

        ID             shift, and enter state 8
        INT            shift, and enter state 9

        sums           goto state 5
        prods          goto state 6
        value          goto state 7

State 5

        assign -> ID '=' sums .                             (rule 1)
        sums -> sums . '+' prods                            (rule 2)

        '+'            shift, and enter state 11
        %eof           reduce using rule 1


State 6

        sums -> prods .                                     (rule 3)
        prods -> prods . '*' value                          (rule 4)

        '+'            reduce using rule 3
        '*'            shift, and enter state 10
        %eof           reduce using rule 3

...

みたいな情報が出力される．それぞれの状態について，

State の値
reduce 途中の規則
先読み値での操作
パーススタックの状態による操作

が表示されている．reduce 途中の規則表示は，. の位置までは reduce 済みということを表している．この辺は LALR 法に馴染みのある人なら分かると思うが，状態の作り方に由来する情報で，解析するプログラムが大きくなるとあまり役に立つ情報ではなかったりするが，覚えておいて損はないだろう．

コンフリクトとその解決

さて，ここからが本題．shift-reduce パーサ生成では，パーサが上記の通りの動きをすることから，先読みしている文字から shift か reduce のどちらを行うか一意に決めなければならない．しかし，書かれた文法によっては，うまく一意に決められないことがある．大方問題になるのは以下のケースだ:

文法が曖昧性を含んでいる
先をパースして見なければ，操作が決定できない

一般的に，shift-reduce パーサ生成器はこのような問題を直接検出はしてくれない場合が多い．特に，Happy の場合は，直接検出の機能はない．ただ代わりに，これらの問題は間接的に shift/reduce 衝突，reduce/reduce 衝突という2つの警告によって報告される．

それぞれの警告は，名前の通り

shift/reduce 衝突: shift 操作と reduce 操作，どちらも可能．この場合，自動的に shift 操作が選択される．
reduce/reduce 衝突: 可能な reduce 操作が複数ある．この場合，自動的に一番早く現れる規則に関する reduce 操作が選択される．

という問題を表している．実際に，衝突が報告されるようなプログラムを書いてみる:

-- Parser.y
{
module Parser where
}

%token
    ID  { TokId _ }
    '+' { TokSym "+" }

%tokentype { Token }

%name expr
%%

expr :: { Expr }
    : expr '+' expr     { Sum $1 $3 }
    | ID                { Val $1 }

{
happyError :: [Token] -> a
happyError _ = error "happyError"

data Token
    = TokId String
    | TokSym String
    deriving (Eq, Show)

data Expr
    = Sum Expr Expr
    | Val Token
    deriving (Eq, Show)
}

これの Parser.info を見ると，最初に

state 6 contains 1 shift/reduce conflicts.

というように shift/reduce 衝突が報告される．State 6 の情報を見に行ってみると，

State 6

    expr -> expr . '+' expr                             (rule 1)
    expr -> expr '+' expr .                             (rule 1)

    '+'            shift, and enter state 5
                    (reduce using rule 1)

    %eof           reduce using rule 1

という表示がある．'+' の操作で (reduce using rule 1) と言う表記があるのが分かるだろう．衝突している操作で，選ばれなかったものは (...) と言う形で表記される．今回の場合は，

shift, and enter state 5
reduce using rule 1

が衝突し，shift/reduce 衝突なので shift が優先されている．このケースは文法自体に曖昧性がある．つまり，a + b + c のような式が，Sum (Sum a b) c とパースされて欲しいのか，Sum a (Sum b c) とパースされて欲しいのか分からないのだ．'+' が出てきた時に shift を優先させると，shift を貪欲的に行い最終的にまとめて reduce されるため Sum a (Sum b c) が結果になる．実際，今回のパース結果を見てみると，

>>> expr [TokId "a", TokSym "+", TokId "b", TokSym "+", TokId "c"]
Sum (Val (TokId "a")) (Sum (Val (TokId "b")) (Val (TokId "c")))

となっている．reduce が優先された場合，まず出来上がったところから reduce していくため，Sum (Sum a b) c が結果になる．もし，shift 優先で問題ないなら，それを Happy に %shift ディレクティブで以下のように教えることができる:

expr :: { Expr }
    : expr '+' expr %shift  { Sum $1 $3 }
    | ID                    { Val $1 }

または，文法から曖昧性を排除することで，解決できる．こちらの方が一般的な解決方法だろう．左結合でのパース結果，つまり reduce 優先した場合の結果が得たかったら次のように書けば良い:

expr :: { Expr }
    : expr '+' ID   { Sum $1 (Val $3) }
    | ID            { Val $1 }

shift/reduce 衝突は基本避けられるなら避けた方がいいが，そこまで無理をして避ける必要はないだろう．shift/reduce を無理に避けるため文法が複雑になるより，%shift ディレクティブを指定した方がプログラムが保守しやすい場合も多い．特に，演算子・ブロックの優先順位の問題においては，%shift ディレクティブや %left，%right を使用した方が意味アクションが書きやすい場合が多い．

しかしながら，reduce/reduce 衝突の方は，プログラマが意図しないパーサが生成されるケースが多いため，注意が必要だ．例えば問題になるのは，以下のような文法だ:

expr :: { Expr }
    : value '+' expr            { Sum $1 $3 }
    | value '+' value           { Sum $1 $3 }
    | value                     { $1 }

value :: { Expr }
    : ID                        { Val $1 }

この文法では，

state 10 contains 1 reduce/reduce conflicts.

という警告が生成される．State 10 は次のような情報表示がされる:

State 10

    expr -> value . '+' value                           (rule 1)
    expr -> value '+' value .                           (rule 1)
    expr -> value . '+' expr                            (rule 2)
    expr -> value .                                     (rule 3)

    '+'            shift, and enter state 6
    %eof           reduce using rule 3
            (reduce using rule 1)

この場合，a + b という式を，

expr -> value '+' expr の規則で reduce するか
expr -> value '+' value の規則で reduce するか

が分からない点で，文法が曖昧になっている．ただ，警告自体は，

expr -> value '+' value
expr -> value

の2つが衝突していると言っている事には注意が必要だ．実際には，後者のルールは reduce が起きた後 expr -> value '+' expr で reduce が走ることを前提にしているわけだが，警告をそのまま素直に受け取ると，問題の特定が難しい場合があるのには注意だ．さて，今回のケースでは2つの reduce が被らないように文法を修正するのが良いだろう．具体的には，

expr :: { Expr }
    : value '+' value '+' expr2     { Sum $1 $3 }
    | value '+' value               { Sum $1 $3 }
    | value                         { $1 }

expr2 :: { Expr }
    : value '+' expr2               { Sum $1 $3 }
    | value                         { $1 }

value :: { Expr }
    : ID                            { Val $1 }

というように修正するのが良いだろう．

基本的に，自身が管理できていない衝突は，その原因を特定して解決しておいた方がいい．特に，reduce/reduce 衝突は解決しておく必要があるだろう．Happy はデフォルトでは衝突を検知してもパーサをそのまま生成するが，このようなマナーを考慮して，%expect ディレクティブというものを用意してくれている．これを使って，

%expect 10

というように書くと，reduce/shift 衝突が 10 箇所，reduce/reduce 衝突がない場合のみパーサを生成するようになる．基本的に，reduce/shift 衝突は，その起こっている箇所に %shift ディレクティブを指定するのがいいだろう．なので，基本的に，

%expect 0

を指定し，%shift ディレクティブを適宜入れながら，reduce/reduce 衝突は回避していくのが良いだろう．

まとめ

今回は shift-reduce 生成器 Happy で起こる shift/reduce 衝突，reduce/reduce 衝突の回避方法を軽く紹介した．基本的に，衝突は回避していくのが良いが，shift/reduce 衝突については無理に回避せず %shift を使うという手がある．また，%expect 0 はつけておいた方が良いだろう．

文法が大きくなってくると，State の情報で提示された reduce の対象ルールと実際問題がある曖昧性のあるルールは割とかけ離れていたりするので注意が必要だ．基本的には，先読み対象のトークンが使われている場所を探索し，地道に曖昧性がある部分を探していくしかないと思う．また，実際には先読みを十分に行えば判別可能な曖昧性についても，衝突を起こしてしまう場合がある．その場合は，効率的なパースのためにも早期に判別可能な文法に修正していくのが良いだろう．この辺は，PEG とかと比べると少々使い勝手悪いっすね．というわけで，今日はこの辺で．

Unicode とサロゲートコードポイント

2020-11-14T19:48:12+09:00

Unicode は、文字コードの標準を目指して創設された規格であり、文字をどう処理するか、テキストデータとしてどう表すかを規定している。今や国際的に普及した規格で、特に Unicode が規定する符号化方式 UTF-8 は、いまやテキストデータのエンコーディングデファクト標準となっている。

Unicode は歴史的経緯からサロゲートコードポイントという仕様を包含している。今回は、この仕様の紹介と、UTF-8 を使う際の注意点を見ていく。なお，

Unicode 13.0.0: https://www.unicode.org/versions/Unicode13.0.0/

を元にしていく．

Unicode と固定長の夢

当初、Unicode は ASC-II の固定長 7bit 表現に倣い、固定長 16bit で世界中の文字を表現する規格として提案された。当時の提案 [1] では、

In the Unicode system, a simple unambiguous fixed-length character encoding is integrated into a coherent overall architecture of text processing.

Unicode システムでは，単純で明確な固定長の文字コードによって，全ての文書処理においての一貫性が提供されます．

が、Unicode の売り文句だった。つまり，文字一つ一つに 16bit の中からコードを割り当てることで，世界中の文字を表そうとしたのだ．このコンセプト自体は、現在の Unicode でも引き継がれているが、残念ながら今や Unicode は固定長ではなくなってしまった。Unicode の文字列において，長さとは何かというのは，また色々とややこしい話になるので，とりあえず置いておく．

さて，当初 16bit，つまり 65536 文字で世界中の文字を納めようという計画は，CJK (Chinese / Japanese / Korean) 圏の参戦で見事に頓挫することになる．文字の登録件数は，Unicode 1.0 [2] の時点で28706 件だったのが，Unicode 4.0 [3] では 96382 件まで膨れ上がることになる．Unicode 4.0 の数字から分かる通り，65536 文字を明に超える．Unicode は，2.0 から 16bit 固定長で全ての文字を収容することを諦め，以降 3.0 からは本格的に 21bit 体制に移行していくことになる．

さて，21bit 体制に移行する時に問題となったのが，それまで使っていたエンコーディング方法だ．Unicode はそれまで 16bit 前提の世界で，割り当てられた文字をそのまま 2byte 固定表現でエンコーディングする方法をとっていた．しかし，文字が 16bit に収まらなくなってしまった今，そのエンコーディングで全ての文字を表すことはできない．そこで Unicode は固定表現を諦め，それまでの互換性を保ったまま可変長の文字表現を導入することとなる．

こうして最初に掲げられた Unicode の標語は，仕様から姿を消すことになった．

UTF-16 とサロゲートペア

ところで，なぜ 21bit という中途半端なビット数を採用することにしたのだろうか？その話に入る前に，Unicode の簡単な概要を述べておく．

Unicode は扱える文字一つ一つにコードポイント (code point) と呼ばれる符号を割り当てている．符号は 0 から 0x10FFFF (1,114,111) の間から採用される．つまり，その空間に入る文字数しか Unicode は扱えない．ついでに，21bit 最高値は 0x1FFFFF なので，厳密に 21bit 空間がフルに使えるわけではない．この数は

\mathrm{0xFFFF} + \mathrm{0x400} ^ 2

という計算式によって得られる．この 0x400 という数はサロゲート領域と呼ばれるコードポイント空間のサイズ (の 2 分の 1) からくる．

実は，Unicode のコードポイント，つまり 0 から 0x10FFFF までの数は，全てが文字を割り当てられることを想定されているわけではない．文字を割り当てるコードポイントは，通常のコードポイントと区別して，Unicode ではスカラー値 (Unicode scalar value) と呼ばれている．正確な Unicode スカラー値の定義は，サロゲート領域に含まれないコードポイントのことだ．サロゲート領域とは，0xD800 から 0xDFFF のコードポイント空間を指し，この空間の値には文字は割り当てられない．よって，Unicode スカラー値とは，それ以外の 0 から 0x10FFFF の間の値のことということになる．この微妙な位置に領域が空いているのは，Unicode コードポイントとして何か特別な使用方法を意図してのものではなく，テキストデータへのエンコーディングを見据えてのものになる．

Unicode が初期，16bit 固定長の夢を描いており，それが途中で破綻したことは上で説明した．しかし，破綻したからといって，では今から 16bit による文字表現はやめますと言っても，全ての処理系がはいそうですかと応じられるわけではなかった．特に，文字表現はほぼ根幹となるようなデータ型であり，それが 16bit 固定になっていた場合，そのサイズを変えるのは容易なことではない．そこで，Unicode は 16bit 固定長の夢を諦めても，テキストデータの表現において処理するデータの単位 (これをコードユニットと言う) を 16bit から変えるわけにはいかない．さらに，それまで搭載していた文字については，今までのテキストデータと互換する必要がある．つまり，今まで 16bit で一つの文字を表していたものについては，コードポイントをそのまま 16bit で表した数値を一つのコードユニットとして扱い，かつ 16bit に収まらないコードポイントを持つ文字は，何とかして 16bit 単位のデータとして表現しなければいけない．もちろん，16bit を超えるコードポイントを持つ文字は，16bit 2つ分に分割して表現するという方法が取れるが，その場合デコーディングの方法が一意に定まらなくなってしまう．つまり，コードポイント 0x1f34e の文字を，

0x0001 0xf34e

とエンコードした場合，デコードする際 0x1，0xf34e それぞれのコードポイントに対応する文字 2 つにデコードするか，0x1f34e のコードポイントに対応する文字 1 つにデコードするかが決められなくなるのだ．

こうなってしまっては仕方ないため，Unicode は，それまで使用していなかった領域を特別にサロゲート領域として指定し，そこのコードポイントには文字は割り当てないことにした．そして，そこの範囲で何とか 16bit のコードユニットになるよう頑張る方法を考えることにした．この方法の利点は，

16bit を超えないコードポイントを持つ文字については，影響を受けない
それまでコードポイント1つを単純にコードユニット1つとして扱っていた実装は，コードユニット2つ分の文字は扱えないとすることでそれまでの処理を継続できる

というところにある．後は，デコードが一意に定まるようなエンコード / デコード方法を考えられれば良い．結果的に Unicode が採用したのは

コードポイントの内，0xD800 - 0xDBFF (0b110110??????????) を high surrogate，0xDC00 - 0xDFFF (0b110111??????????) を low surrogate という名の領域として確保し，そこは文字を割り当てないようにする
0x10000 - 0x10FFFF のコードポイントは，0x10000 を引き (つまり，0x00000 - 0xFFFFF の 20bit 値になる)，10bit の値を表すコードユニット 2 つとして扱う
コードユニットの値は，上位 10bit は 0xD800 を足して high surrogate のコードポイントになるように，下位 10bit は 0xDC00 を足して low surrogate に収まるようにする

という方法になる．この方法が俗に言う UTF-16 と呼ばれるエンコーディング方法である．コードユニット 2 つになる場合は，high / low surrogate は区別できるため，連結さえしていれば順不同で保存できるが，デフォルトではビッグエンディアン，つまり high の次に low という順で保存することが決められている [4]．

Unicode で格納できる文字が中途半端な上限を持っているのは，UTF-16 で表現できる値の上限で設定されているからである．

PEP 383: サロゲートエスケープ

というわけで，UTF-16 の互換性のため，Unicode のコードポイントには文字の割り当てが避けられてる領域があった．この領域はもちろん，Unicode scalar value ではないので，エンコードの対象ではない．

ところで，プログラミング言語には，文字列の内部表現のシェアが大きく分かれている．大きくは，

UTF-8 / UTF-16 / UTF-32 のいずれかを内部表現として使っている言語
Unicode コードポイントの列を内部表現として使っている言語

に分かれている．個人的に観測している範囲では，古い言語は UTF-16 の採用率が高く，最近は UTF-8 の採用率が高い気がする．古い言語で UTF-16 採用率が高いのは，やはり Unicode の歴史的事情が大きく影響を与えているんじゃないだろうか？まあ，その辺の話は置いておいて，今回注目したいのが「Unicode コードポイントの列を内部表現として使っている言語」だ．例としては，Python，Haskell [5] が相当する．

Unicode コードポイントの列というのは，つまりは 0 から 0x10FFFF の間の整数の列ということだ．ところが，コードポイントにはサロゲートコードポイントが含まれているため，文字表現として実質必要なのは 0 から 0xD7FF，0xE000 から 0x10FFFF の数値だけだ．なので，0xD800 から 0xDFFF の間は使われない領域ということになる．こういう領域を見ると有効活用したいと思うのがエンジニアの性らしく，Python / Haskell ではそれぞれが，実は微妙に Unicode コードポイントから拡張を施している．これらの言語では，コードポイントのうち，0xDC80 から 0xDCFF の数値は Unicode コードポイントして扱われない場合がある．

では，何に使われているかというと，ASCII 互換の文字コードでエンコードされたバイト列に対し，デコードに失敗した文字を表現するために使われる．正直こんな機能あまり出番はないと思うというか，使いたくなるユースケースはあまり思い浮かばないが，例えばこの機能によって文字列型でバイト列を扱うことができる．何を言ってるか分からないと思うので，とりあえず Python3 で例を見てみよう:

>>> b'ab\xe3\x81'.decode('ascii')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position 2: ordinal not in range(128)
>>> b'ab\xe3\x81'.decode('ascii', 'surrogateescape')
'ab\udce3\udc81'
>>> b'ab\xe3\x81'.decode('ascii', 'surrogateescape').encode('ascii', 'surrogateescape')
b'ab\xe3\x81'

b'ab\xe3\x81' というバイト列の \xe3，\x81 は，それぞれが 0x7F を超える値なため，ASCII では文字が割り当てられていない．そのため，もちろん ASCII エンコーディングでデコードしようとすると失敗する．ところが，surrogateescape というエンコーディングモードを使うと，このバイト列はデコードでき，サロゲートコードポイントを含む文字列が生成されることになる．Python の surrogateescape は次のようなことを行うモードだ:

デコード時

バイト列が正しくデコードできるならデコードする
正しくデコードできないバイト c に出会すと，
- c >= 0x80 ならば，コードポイント 0xDC00 + c にデコードする
- c < 0x80 ならば，デコードに失敗する

エンコード時

0xDC80 から 0xDCFF の範囲の文字 c は，c - 0xDC00 に相当するバイトを出力する
それ以外の文字はそのままエンコードする

c < 0x80 の時デコードに失敗するのが，ASCII 互換でない文字コードに対応できない理由だ [6]．この仕様は，PEP 383 で決まっている．なお，技術的には　c < 0x80 かどうかの分岐は取り除けるが，セキュリティリスクを軽減するためにこうなっているようだ [7]．とにかくこれにより，メモリ効率的にはだいぶ無駄ではあるが，文字列としてバイト列をそのまま扱えるようにできたりする．

Haskell も PEP 383 と大体同じ方式のエンコーディングモードを搭載している．こちらは Roundtrip モードという名前になっている．実際に試してみる:

>>> import System.IO
>>> import GHC.IO.Encoding.Latin1
>>> import GHC.IO.Encoding.Failure
>>> ascii = mkAscii RoundtripFailure
>>> openFile "sample.txt" ReadWriteMode >>= \h -> hSetEncoding h ascii >> hPutStr h "ab\uDC81" >> hClose h
>>> openFile "sample.txt" ReadWriteMode >>= \h -> hSetEncoding h ascii >> hGetLine h >>= \s -> print s >> hClose h
"ab\56449"

なお，この時実行したディレクトリに，以下の内容の sample.txt というファイルが生成される:

$ od -tcx1 sample.txt
0000000   a   b 201
     61  62  81
0000003

また，56449 の 16 進数表記は 0xDC81 になる．個人的には，誰が使うのか分からない邪悪なモードという感は強いが，Unicode のサロゲートコードポイントに文字を割り当てないという決定は，こういうところにも影響を及ぼしているということだ．

まとめ

というわけで，今回は Unicode のサロゲートコードポイントができた経緯と，内容の紹介，そして付随する PEP 383 という仕様を紹介した．この辺の理解，ちょっと曖昧だったので，まあいい勉強にはなった．文字コード界隈は，歴史的経緯と実装が合わさって魔窟っすね．

後，GHC の Char の内部管理が，実は素直な Unicode コードポイントではないということは知っていたんだが，その詳細は知らなかったので，理解は進んだ．この辺，資料ほぼ皆無なので，誰も使っていないんだろな．ってことで，今回は以上．

[1]	https://unicode.org/history/unicode88.pdf

[2]	https://www.unicode.org/versions/Unicode1.0.0/

[3]	https://www.unicode.org/versions/Unicode4.0.1/

[4]	正確には UTF-16 には2つのバリエーションがあり，コードユニットが2つになった時，ビッグエンディアンで並べるか (UTF-16BE)，リトルエンディアンで並べるか (UTF-16LE) が分かれている．通常の UTF-16 は BOM によりこの2つの方式のいずれかを指定することができ，指定されていない場合はビッグエンディアンになる．

[5]	Haskell の方は，厳密には Haskell の仕様ではなく，Haskell の処理系 GHC の実装仕様である

[6]	ところで，実はこの処理の流れだと UTF-16 とかも対応できる．UTF-16 で正しくデコードできないのは，high surrogate から続けて並んだりといったケースだが，そのような場合デコードできないバイト列は `0x80` 以上のバイトだからだ．実際，CPython 3.7.8 で確認したところ `surrogateescape` はエラーなしに動くようだ．

[7]

もしこの条件分岐がなかった場合，ASCII の範囲の任意の文字をサロゲートコードポイントとして内部に持ち，ASCII 互換の文字コードでエンコード時に，ちゃんとエンコードしてしまうことになる．そうすると，例えば入力でわざとデコードに失敗する文字コードを選択し，それを ASCII 互換の文字コードにエンコードさせることで，制御文字などをバリデーションを避けて埋め込める可能性がある．これを避ければある程度セキュリティリスクは抑えられるだろうという判断のようだ．また，世の中の多くの文字コード，特にロケール文字コードと呼ばれるものは ASCII 互換である．なので，基本的に ASCII の範囲でデコードが失敗することは少ない．なので，実用上も問題ないということらしい．以上のことは，PEP 383 の Discussion に書かれている．ASCII 以外の範囲で制御文字を持つ何かがあれば結構危うい気がするが，詳しくは調べてない．

ハイティング代数の性質

2020-10-04T23:11:38+09:00

古典論理の意味論がブール代数によって議論できるように，直観主義論理の意味論はハイティング代数によって考えることができる．ハイティング代数とは，冪で閉じている有界束であり，ブール代数もハイティング代数になる．

というわけで結構題材になるハイティング代数だが，巷でハイティング代数に関しての資料が少なかったりするので，自分のために諸々備忘録を残しておく．

ハイティング代数の定義

まずは基本的なところから。最初に poset を導入する。

定義. 半順序 (partial order, poset)

集合 $A$ とそれ上の二項関係 $(\sqsubseteq) \subseteq A \times A$ の組 $(A, \sqsubseteq)$ で以下を満たすものを、半順序と呼ぶ:

反射律 (reflexivity): 任意の $x \in A$ について、 $x \sqsubseteq x$
推移律 (transitivity): 任意の $x, y, z \in A$ について、 $x \sqsubseteq y$ かつ $y \sqsubseteq z$ ならば、 $x \sqsubseteq z$
反対称律 (anti-symmetric): 任意の $x, y \in A$ について、 $x \sqsubseteq y$ かつ $y \sqsubseteq x$ ならば、 $x = y$

束の定義方法は色々あるが、今回は poset ベースの束の定義を導入する。

定義. 束 (lattice)

半順序 $(A, \sqsubseteq)$ で以下を満たすものを、束と呼ぶ:

任意の $x, y \in A$ について、上限 $x \lor y \in A$ が存在する。この時、 $x \lor y$ を結び (join) と呼ぶ
任意の $x, y \in A$ について、下限 $x \land y \in A$ が存在する。この時、 $x \land y$ を交わり (meet) と呼ぶ

束は、幾つかの代数的性質が成り立つ。

定理. 束の性質

束 $(L, \sqsubseteq)$ について、以下が成り立つ:

交換律 (commutative): 任意の $x, y \in L$ について、 $x \land y = y \land x$ 、 $x \lor y = y \lor x$
結合律 (associative): 任意の $x, y, z \in L$ について、 $x \land (y \land z) = (x \land y) \land z$ 、 $x \lor (y \lor z) = (x \lor y) \lor z$
吸収律 (absorption): 任意の $x, y \in L$ について、 $x \land (x \lor y) = x \lor (x \land y) = x$
冪等律 (idempotent): 任意の $x \in L$ について、 $x \land x = x \lor x = x$

証明:

交換律，結合律，冪等律はいいと思うので，吸収律だけ示しておく．といっても，こいつもほぼ自明で， $x \leq x \lor y$ ， $x \land y \leq x$ より，下限，上限の定義から $x \land (x \lor y) = x$ ， $x \lor (x \land y) = x$ ．

束の中で、空集合に対する上限、下限が存在するもの、つまり最大元、最小元が存在するものを有界束と呼ぶ。

定義. 有界束 (bounded lattice)

束 $(L, \sqsubseteq)$ で以下を満たすものを，有界束と呼ぶ:

ある $\top \in L$ が存在し、任意の $x \in L$ について $x \leq \top$ を満たす
ある $\bot \in L$ が存在し、任意の $x \in L$ について $\bot \leq x$ を満たす

ハイティング代数は、有界束の中で冪対象を持つものである。

定義. ハイティング代数 (heyting algebra)

有界束 $(L, \sqsubseteq)$ で以下を満たすものを、ハイティング代数と呼ぶ:

任意の $x, y \in L$ について、 $\{z \in L \mid x \land z \leq y\}$ の上限 $x \to y \in L$ が存在する。この時、 $x \to y$ を冪 (exponential) または相対擬補元 (relative pseudo-complement) と呼ぶ

証明は省略するが，冪の例は $x \to x = \top$ ， $\top \to x = x$ ， $\bot \to x = \top$ などがある．

ハイティング代数の性質

分配律を満たす束を分配束という．

定義. 分配束 (distributive lattice)

束 $(L, \sqsubseteq)$ について、以下を満たすものを分配束と呼ぶ:

任意の $x, y, z \in L$ について、 $x \land (y \lor z) = (x \land y) \lor (x \land z)$
任意の $x, y, z \in L$ について、 $x \lor (y \land z) = (x \lor y) \land (x \lor z)$

なお，片方のみ成り立てば分配束になる．

定理. 分配束の条件

束 $(L, \sqsubseteq)$ について、以下は同値．

$(L, \sqsubseteq)$ は分配束
任意の $x, y, z \in L$ について、 $x \land (y \lor z) = (x \land y) \lor (x \land z)$
任意の $x, y, z \in L$ について、 $x \lor (y \land z) = (x \lor y) \land (x \lor z)$

証明:

1 ならば 2，1 ならば 3 は自明．2 ならば 1 は，

(x \lor y) \land (x \lor z) = ((x \lor y) \land x) \lor ((x \lor y) \land z) = x \lor (x \land z) \lor (y \land z) = x \lor (y \land z)

より，示せる．3 ならば 1 も対称的に証明できる．

ハイティング代数は、分配束になる．

定理. ハイティング代数の分配律

ハイティング代数は，分配束である．

証明:

$x \land y \leq x \land (y \lor z)$
$x \land z \leq x \land (y \lor z)$

より， $x \land (y \lor z)$ は $x \land y$ ， $x \land z$ の上界になる．よって， $(x \land y) \lor (x \land z) \leq x \land (y \lor z)$ ．また，

$x \land y \leq (x \land y) \lor (x \land z)$
$x \land z \leq (x \land y) \lor (x \land z)$

より，

$y \leq (x \to (x \land y) \lor (x \land z))$
$z \leq (x \to (x \land y) \lor (x \land z))$

よって， $x \to (x \land y) \lor (x \land z)$ は $y$ ， $z$ の上界より $y \lor z \leq (x \to (x \land y) \lor (x \land z))$ ．ここから，

x \land (y \lor z) \leq x \land (x \to (x \land y) \lor (x \land z)) \leq (x \land y) \lor (x \land z)

よって， $x \land (y \lor z) = (x \land y) \lor (x \land z)$ より，分配束になる．

ついでにだが、通常の有界束は分配律が成り立つとは限らない。反例は以下のもの:

この時、 $x \lor (y \land z) = x \neq \top = (x \lor y) \land (x \lor z)$ になる。さて，束の元には補元が存在する場合がある．

定義. 補 (complement)

有界束 $(L, \sqsubseteq)$ の元 $x \in L$ について，

$x \land y \leq \bot$
$\top \leq x \lor y$

を満たす $y \in L$ を $x$ の補と呼ぶ

$\top$ と $\bot$ は互いに補の関係になる．なお，有界束において一般に補は一意とは限らない．例えば，上の分配律が成り立たない束において， $x$ の補は $y$ ， $z$ 両方になる．もちろん存在するとも限らない．これは，線形な束を思い描いてみるといいだろう．ところで，分配束において補は存在するなら一意に定まる．

定理. 分配束における補の一意性

有界な分配束 $(L, \sqsubseteq)$ について，

任意の $x, y, z \in L$ について、 $x \land (y \lor z) = (x \land y) \lor (x \land z)$
任意の $x, y, z \in L$ について、 $x \lor (y \land z) = (x \lor y) \land (x \lor z)$

が成り立つ時，任意の $x \in L$ についてその補は高々1つである

証明:

$x \in L$ の補 $y_1 \in L$ ， $y_2 \in L$ が存在する時，

y_1 = y_1 \land (y_2 \lor x) = (y_1 \land y_2) \lor (y_1 \land x) = (y_1 \land y_2) \lor (y_2 \land x) = y_2 \land (y_1 \lor x) = y_2

より， $y_1 = y_2$ ．よって，存在すれば補は一意．

ハイティング代数において補は存在するとは限らないが，ハイティング代数は分配束より存在すれば一意である．さらに，ハイティング代数においては補が存在すればその形を特定できる．

定義. 擬似補 (pseudo-complement): ハイティング代数 $(H, \sqsubseteq)$ について、その要素 $x \in H$ に対し、 $x \to \bot$ を擬似補と言い、 $\neg x$ と表記する

ハイティング代数において，補が存在すればそれは $\neg x$ と一致する．

定理. 擬似補と補の一意性

ハイティング代数 $(H, \sqsubseteq)$ の元 $x \in H$ について，その補が存在する時，それは $\neg x$ のみである

証明:

$x \in H$ の補 $y \in H$ が存在する時， $x \land y \leq \bot$ より $y \leq \neg x$ である．この時，

$x \land \neg x \leq \bot$
$\top \leq x \lor y \leq x \lor \neg x$

より， $\neg x$ は補である．さらに，ハイティング代数は分配束なので，補は $\neg x$ のみである．

ハイティング代数ではド・モルガン則は片方のみ成り立つ．

定理. ド・モルガン則 (De Morgan's law)

ハイティング代数 $(H, \sqsubseteq)$ について、以下が成り立つ:

任意の $x, y \in H$ について、 $\neg x \land \neg y = \neg (x \lor y)$

証明:

(x \lor y) \land \neg x \land \neg y = (x \land \neg x \land \neg y) \lor (y \land \neg \land \neg y) = \bot \lor \bot \leq \bot

より， $\neg x \land \neg y \leq \neg (x \lor y)$ ．また，

x \land \neg (x \lor y) \leq (x \land \neg (x \lor y)) \lor (y \land \neg (x \lor y)) = (x \lor y) \land \neg (x \lor y) \leq \bot

より， $\neg (x \lor y) \leq \neg x$ ．対称性より $\neg (x \lor y) \leq \neg y$ ．よって， $\neg (x \lor y) \leq \neg x \land \neg y$ より， $\neg x \land \neg y = \neg (x \lor y)$ ．

ブール代数と二重否定変換

ハイティング代数のインスタンスにブール代数がある．

定義. ブール代数 (boolean algebra)

分配束 $(L, \sqsubseteq)$ で以下を満たすものを、ブール代数と呼ぶ:

任意の $x \in L$ について、その補が存在する

定理. ブール代数はハイティング代数

ブール代数 $(B, \sqsubseteq)$ は，ハイティング代数である

証明:

$x, y \in B$ について， $x$ の補を $a$ とする．この時， $x \to y = a \lor y$ を示す．

x \land (a \lor y) = (x \land a) \lor (x \land y) = x \land y \leq y

であり， $x \land z \leq y$ となる $z \in B$ について，

z = z \land (a \lor x) = (z \land a) \lor (x \land z) \leq a \lor y

より， $a \lor y$ は $x \to y$ の条件を満たす．よって，任意の元について冪が存在するため， $(B, \sqsubseteq)$ はハイティング代数．

ハイティング代数がブール代数になる条件として，以下が知られている．

定理. ブール代数の同値条件

ハイティング代数 $(H, \sqsubseteq)$ について，以下は同値

$H$ はブール代数
任意の $x \in H$ について， $x \lor \neg x = \top$
任意の $x \in H$ について， $\neg \neg x = x$

証明:

$x \in H$ について $x \land \neg x \leq \bot$ であること，ブール代数がハイティング代数であることから，1 と 2 の同値性はいいと思う．

2 から 3 は，

\neg \neg x = \neg \neg x \land (x \lor \neg x) = (\neg \neg x \land x) \lor (\neg \neg x \land \neg x) = \neg \neg x \land x

= (\neg \neg x \land x) \lor (x \land \neg x) = (\neg \neg x \lor \neg x) \land x = x

より示せる．3 から 2 は，ハイティング代数で適用できるド・モルガン則を使用して，

x \lor \neg x = \neg \neg (x \lor \neg x) = \neg (\neg x \land \neg \neg x) = \neg \bot = \top

より示せる．

ブール代数では，2つめのド・モルガン則も示せる．

定理. ド・モルガン則 (De Morgan's law)

ブール代数 $(B, \sqsubseteq)$ について、以下が成り立つ:

任意の $x, y \in H$ について、 $\neg x \lor \neg y = \neg (x \land y)$

証明:

ブール代数では二重否定の除去ができることから，ハイティング代数上で成り立つド・モルガン則を使用して，

\neg x \lor \neg y = \neg \neg (\neg x \lor \neg y) = \neg (\neg \neg x \land \neg \neg y) = \neg (x \land y)

のように示せる．

さて，ハイティング代数からブール代数への変換方法として，二重否定変換というものが知られている．これは，名前の通り全ての元に二重否定をかますような変換だ．それを示すため，まず準備として補題を用意する．

補題.

ハイティング代数 $(H, \sqsubseteq)$ について，以下が成り立つ:

任意の $x \in H$ について， $x \leq \neg \neg x$
任意の $x, y \in H$ について， $x \leq y$ ならば $\neg y \leq \neg x$

証明:

$\neg x \land x \leq \bot$ より， $x \leq \neg \neg x$ ．また， $x \leq y$ の時，

x \land \neg y \leq y \land \neg y \leq \bot

より， $\neg y \leq \neg x$ ．

補題.

ハイティング代数 $(H, \sqsubseteq)$ について，以下が成り立つ:

任意の $x \in H$ について， $\neg \neg \neg x = \neg x$
任意の $x, y \in H$ について， $\neg \neg (x \land y) = \neg \neg x \land \neg \neg y$

証明:

前の補題から， $\neg x \leq \neg \neg \neg x$ ．また， $\neg x \leq \neg \neg x$ から $\neg \neg \neg x \leq \neg x$ ．よって， $\neg \neg \neg x = \neg x$ ．

また， $x \land y \leq x$ ， $x \land y \leq y$ から， $\neg \neg (x \land y) \leq \neg \neg x$ ， $\neg \neg (x \land y) \leq \neg \neg y$ より， $\neg \neg (x \land y) \leq \neg \neg x \land \neg \neg y$ ．さて，後 $\neg \neg x \land \neg \neg y \leq \neg \neg (x \land y)$ を示せれば良い．これを示すには， $\neg (x \land y) \land \neg \neg x \land \neg \neg y \leq \bot$ を示せれば良い．

ところで， $\neg (x \land y) \land x \land y \leq \bot$ より，

\neg (x \land y) \land x \leq \neg y = \neg \neg \neg y

であるため， $\neg (x \land y) \land x \land \neg \neg y \leq \bot$ である．同様に $x$ についても同じ操作から， $\neg (x \land y) \land \neg \neg x \land \neg \neg y \leq \bot$ となる．よって， $\neg \neg (x \land y) = \neg \neg x \land \neg \neg y$ ．

これより，二重否定変換はハイティング代数上の準同型になり，二重否定の除去を付加できる．これにより，ハイティング代数からブール代数を生成できる．

定理. 二重否定変換 (double-negation translation)

ハイティング代数 $(H, \sqsubseteq)$ について， $H_{\neg\neg} = (\{\neg \neg x \mid x \in H\}, \sqsubseteq)$ はブール代数である

証明:

前の補題から，元の $H$ の $\land$ は $H_{\neg\neg}$ でも閉じている．また， $x \leq \neg\neg x$ より，冪も保存される．よって， $H_{\neg\neg}$ はハイティング代数．さらに， $\neg\neg(\neg\neg x) = \neg\neg x$ であり， $H_{\neg\neg}$ はブール代数になる．

圏論的視点

今までは通常の束論の議論でハイティング代数を取り扱ってきたが，圏論的な議論もしておく．まず，半順序での最大下界，最小上界は，poset での直積，直和になる．これは，定義を比べてみれば分かると思う．そして，最小元，最大元は始対象，終対象に相当する．よって，有界束とは，finitely complete かつ cocomplete な poset のことになる [1] ．

定義. 有界束

poset $C$ が有界束とは，以下を満たすこと

有限積を持つ (finitely complete)
有限余積を持つ (finitely cocomplete)

ハイティング代数は，有界束のなかで CCC (Cartesian Closed Category) になるものである．すなわち，冪も持つような poset になる．

定義. ハイティング代数

有界束 $C$ がハイティング代数とは，以下を満たすこと

CCC である

冪の定義も照らし合わせてみるとそのままだが，一応確認しておくと，

が冪対象の定義で，この時 $z^y \land y = z^y \times y \leq z$ かつ $x \times y = x \land y \leq z$ となる $x$ について $x \leq z^y$ となる．冪の随伴関係 $C(X \times Y, Z) \simeq C(X, Z^Y)$ がそのままで，つまりハイティング代数とは， $- \land Y$ が右随伴を持つような有界束のことになる．ついでに，CCC で finite coproduct を持つような圏を BCCC (BiCartesian Closed Category) と言うらしい．ハイティング代数は，この言葉を使うと poset で BCCC になるものと言える．

さて，左随伴の有用な性質として，余極限を保存すると言うものがある．つまり，ハイティング代数では $x \land -$ は余極限を保存する．ここから直ちに分配束であることが導ける．

定理.

ハイティング代数は，分配束である．

証明:

$x \land -$ は余極限を保存するため，

x \land \bigvee_y y = \bigvee_y x \land y

である．

ところで， $\neg$ はハイティング代数 $H$ 上の反変関手 $\neg: H \to H^{\mathrm{op}}$ になる．逆にも $\neg: H^{\mathop{op}} \to H$ を張れて，こいつらは随伴になる．一般に， $H$ の対象 $X$ について， $X^-: H \to H^{\mathrm{op}}$ は左随伴になる．

定理.

ハイティング代数 $H$ ， $X \in |H|$ について， $X^-: H \to H^{\mathrm{op}}$ は右随伴を持つ．

証明:

H^{\mathrm{op}}(X^Y, Z) \simeq H(Z, X^Y) \simeq H(Y \times Z, X) \simeq H(Y, X^Z)

より， $X^-: H^{\mathrm{op}} \to H$ が右随伴になり， $X^- \dashv X^-: H \to H^{\mathrm{op}}$ になる．

ところで， $\neg: H \to H^{\mathrm{op}}$ が左随伴を持つ場合がある． $\neg: H^{\mathrm{op}} \to H$ がその左随伴になる $H$ がブール代数である．

定義. ブール代数

ハイティング代数 $H$ がブール代数とは，以下を満たすこと:

$\neg \dashv \neg: H^{\mathrm{op}} \to H$

この定義がブール代数の条件に合うことを確認する前に少々寄り道する．さて，随伴同値 (adjoint equivalence) と言う条件がある．これは，随伴による単子 (unit)，余単子 (counit) が自然同型になることである．

定義. 随伴同値: 随伴 $F \dashv G$ について，その単子，余単子が自然同型である時， $F \dashv G$ を随伴同値という．

随伴同値の場合， $F \dashv G$ かつ $G \dashv F$ になる．

定理.

随伴 $F \dashv G$ が随伴同値ならば， $G \dashv F$ である

証明:

unit $\eta: 1 \Rightarrow G \circ F$ ，counit $\epsilon: F \circ G \Rightarrow 1$ が自然同型である時，それぞれの逆射 $\epsilon^{-1}: 1 \Rightarrow F \circ G$ ， $eta^{-1}: G \circ F \Rightarrow 1$ が存在する．この時，

$G \xrightarrow{G \epsilon^{-1}} GFG \xrightarrow{\eta^{-1}_G} G$
$F \xrightarrow{\epsilon^{-1}_F} FGF \xrightarrow{F \eta^{-1}} F$

はそれぞれ

$F \xrightarrow{F \eta} FGF \xrightarrow{\epsilon_F} F$
$G \xrightarrow{\eta_G} GFG \xrightarrow{G \epsilon} G$

の逆射になる．よって恒等射になるため，それぞれが unit / counit になる随伴 $G \dashv F$ が作れる．

ところで， $\neg \circ \neg$ は恒等関手，つまり二重否定の除去が成り立つとすると，この時 $\neg \dashv \neg: H \to H^{\mathrm{op}}$ の unit は自然同型になる．また，unit が自然同型になるならば二重否定の除去ができる．つまりブール代数とは，ハイティング代数で $\neg$ が随伴同値になるものである [2] ．

定理. ブール代数の条件

ハイティング代数 $H$ について，以下は同値

$H$ はブール代数
$\neg \circ \neg: H \to H$ は恒等関手
$\neg \dashv \neg: H \to H^{\mathrm{op}}$ は随伴同値

証明:

3 から 1 はよい．1 から 2 は，

$H(Y, \neg X) \simeq H^{\mathrm{op}}(\neg X, Y) \simeq H(X, \neg Y)$
$H(\neg X, Y) \simeq H^{\mathrm{op}}(X, \neg Y) \simeq H(\neg Y, X)$

より， $\neg X \xrightarrow{1} \neg X$ に対応する射

$X \leq \neg\neg X$
$\neg\neg X \leq X$

が存在する．よって， $\neg\neg X = X$ であることより，示せる．2 から 3 は，unit / counit が恒等関手から恒等関手への口頭変換になることから自明．

ところで，ブール代数に限らずハイティング代数では $\neg \dashv \neg$ だった．随伴からはモナドが作れるので， $\neg\neg$ はモナドになる．この時， $\neg\neg(\neg\neg x) \leq \neg\neg x$ がモナドの自然変換から作れるため， $\neg\neg$ により作られる subcategory がハイティング代数であれば， $\neg\neg(\neg\neg x) = \neg\neg x$ になる．つまり， $\neg\neg$ により作られる subcategory はブール代数になる． $\neg\neg$ により作られる subcategory がハイティング代数であることは，finite product / finite coproduct / implication を保存することを地道に証明する方法しか知らないので割愛する．誰か他の方法知ってたら教えて欲しい [4]．

まとめ

てことで，ハイティング代数は BCCC になる poset で，ブール代数は $0^-$ が随伴同値になるハイティング代数だよ，何か問題でも?

なお， $X^-$ が左随伴になるって話から， $(x \lor y) \Rightarrow z = (x \Rightarrow z) \land (y \Rightarrow z)$ が直ちに示せたり [3]，随伴 $\neg \dashv \neg$ の同値性 $H(Y, \neg X) \simeq H(X, \neg Y)$ に $X = \neg Z$ ， $Y = Z$ すれば $Z \leq \neg\neg Z$ が直ちに示せたりして便利．まあ，その証明が相手に通じるかは置いといて．てことで，今回は以上．

[1]	finitely complete になるには厳密には，finite product と equalizer の存在が必要になる．ただ，今回は poset なので，任意の対象間に射はたかだか一つしか存在しないため，equalizer は自明に存在する．finitely cocomplete も同様．

[2]	一般には， $F \dashv G$ ， $G \dashv F$ の時に $F \dashv G$ が随伴同値になるとは限らない．

[3]	$X^-$ は反変であることに注意．反変なので，product / coproduct が逆転する．

[4]	某勉強会でそのうち出てくる?

Prometheus Operator で k8s を監視する

2020-07-26T17:38:44+09:00

Prometheus は、メトリクスの監視を行うためのモニタリングツールだ。各種メトリクスを出す exporter とそれを集計する Prometheus サーバ、及びその集計結果を監視しアラートを出すアラートマネージャで主に構成されている。Prometheus それ自体は便利なんだが、Kubernetes クラスタを監視したい場合色々追加で設定が必要で、結構めんどくさい。そこで、Kubernetes 用に Prometheus をカスタマイズして提供してくれるパッケージがいくつか出ている。今回はそのうちの Prometheus Operator を触る機会があって、せっかくなので使い方を備忘録として残しておく。

Prometheus Operator のインストール

まずは、Kubernetes / helm が入った環境用意する。一応、Kubernetes のバックエンドは今回は Docker を想定する。Kubernetes 自体は Windows / macOS なら Docker Desktop で付属としてついてくるのでそれを使うといいだろう。WSL2 の環境なら、

Docker Desktop をインストール
設定から「Kubernetes」->「Enable Kubernetes」
「Resources」->「WSL Integration」-> 普段使ってる WSL コンテナを有効化

すれば、WSL コンテナ内で docker / kubectl などの CLI が使えるようになる。Helm は、大体各種パッケージマネージャでインストールできる。Linuxbrew とか使って、

brew install helm

とかすれば入る。後は、

helm repo add stable https://kubernetes-charts.storage.googleapis.com/

とかで標準のチャートリポジトリを追加しておく。後、Kubernetes Dashboard もデプロイしておくとよい。こっちも helm で入れられる:

helm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard/
kubectl create namespace kubernetes-dashboard
helm install kubernetes-dashboard kubernetes-dashboard/kubernetes-dashboard \
    --namespace kubernetes-dashboard \
    --set protocolHttp=true,service.externalPort=80

Prometheus Operator はかなり色々入るので名前空間を分けておいた方がいい。今回は prometheus という名前空間を作って、そこにインストールしていく。helm で簡単に入るので、それでインストールする:

kubectl create namespace prometheus
helm install prometheus stable/prometheus-operator --namespace prometheus

ポッドの様子を見てみる:

$ kubectl -n prometheus get pods
NAME                                                     READY   STATUS              RESTARTS   AGE
alertmanager-prometheus-prometheus-oper-alertmanager-0   2/2     Running   0          77s
prometheus-grafana-8c6966f8f-m45xx                       2/2     Running   0          99s
prometheus-kube-state-metrics-6df5d44568-p464c           1/1     Running   0          99s
prometheus-prometheus-node-exporter-2r7vq                1/1     Running   0          99s
prometheus-prometheus-oper-operator-749cd475f6-j7ftd     2/2     Running   0          99s
prometheus-prometheus-prometheus-oper-prometheus-0       3/3     Running   1          68s

サービスも見てみると、

$ kubectl -n prometheus get svc
NAME                                      TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
alertmanager-operated                     ClusterIP   None            <none>        9093/TCP,9094/TCP,9094/UDP   2m33s
prometheus-grafana                        ClusterIP   10.111.67.1     <none>        80/TCP                       2m55s
prometheus-kube-state-metrics             ClusterIP   10.97.237.255   <none>        8080/TCP                     2m55s
prometheus-operated                       ClusterIP   None            <none>        9090/TCP                     2m24s
prometheus-prometheus-node-exporter       ClusterIP   10.100.44.54    <none>        9100/TCP                     2m55s
prometheus-prometheus-oper-alertmanager   ClusterIP   10.98.127.253   <none>        9093/TCP                     2m55s
prometheus-prometheus-oper-operator       ClusterIP   10.97.208.129   <none>        8080/TCP,443/TCP             2m55s
prometheus-prometheus-oper-prometheus     ClusterIP   10.98.54.131    <none>        9090/TCP                     2m55s

みたいな感じになる。おおむねそれぞれのサービスは

prometheus-oper-prometheus: Prometheus 本体
prometheus-oper-alermanager: Alert Manager 本体
prometheus-node-exporter: ノードごとのメトリクス出力用 node exporter
kube-state-metrics: Kubernetes のオブジェクトごとのメトリクス出力用 exporter
grafana: Prometheus のメトリクス可視化用の Grafana 本体
prometheus-oper-operator: Prometheus Operator 本体

みたいになっている。Prometheus Operator の主な役割は、カスタムリソースによる Prometheus / AlertManager の設定管理及び監視対象との接続になる。具体的にどのように設定を管理していくは、後で見ていくとして、とりあえずデプロイされたものを触ってみる。まず、Prometheus 本体を見てみる。localhost で見たい場合は、プロキシ立てると良い:

kubectl proxy

で、

http://localhost:8001/api/v1/namespaces/prometheus/services/http:prometheus-prometheus-oper-prometheus:web/proxy/

にアクセスするといいだろう。Prometheus の画面が表示されて、色々ターゲットが追加されてるのが分かると思う。お試し環境だと etcd とかデプロイしてないと思うので、etcd が立ち上がってないとかアラートが出てると思うが、それらのアラートの調整の仕方は後で紹介する。Grafana の画面も見てみるといいだろう。Grafana の方は proxy から見るのはちょっときついので、ポートフォワードして見るといい:

kubectl port-forward service/prometheus-grafana 3000:80 --address 0.0.0.0 -n prometheus

Grafana の方はログインが必要で、ユーザ admin / パスワード prom-operator で入れる。このパラメータは、チャートのパラメータとして弄れるようになっている。Grafana も初期段階で色々テンプレートが追加されていて便利という感じ。

カスタムリソース

これだけ見ると、まあ単に初期設定モリモリの Prometheus 周辺ツールがパッとデプロイできるだけとなるんだけど、Prometheus Operator の神髄はここから。Prometheus Operator は、Prometheus の設定をカスタムリソースとしてデプロイできる。まずは、どういうリソースがデプロイされているかを見てみる。以下の URL から Dashboard にアクセスする:

http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:http/proxy/

そして、上のメニューから prometheus ネームスペースを選択し、左のメニューの「カスタムリソース定義」欄を選択する。すると、幾つかの項目が表示されると思う。それぞれ、

Prometheus: Prometheus ポッドのテンプレート。このテンプレートを基に operator が Prometheus ポッドをデプロイする。
Alertmanager: Alertmanager ポッドのテンプレート。このテンプレートを基に operator が Alertmanager ポッドをデプロイする。
PrometheusRule: Prometheus のルールを表すカスタムリソース
ThanosRuler: Thanos のルールを表すカスタムリソース (Thanos 触ったことないので、今回は割愛)

みたいなもの。後、PodMonitor / ServiceMonitor があるが、これは後述するので今は割愛する。Prometheus のルールを弄りたかったら PrometheusRule カスタムリソースをいじることになる。新規にルールを追加したかったら新しく PrometheusRule を作ってデプロイすればいいし、既存のものをいじりたかったら既存のカスタムリソースを弄ればいい。

試しに、etcd のアラートを消してみる。PrometheusRule カスタムリソースの欄に prometheus-prometheus-oper-etcd というカスタムリソースがある。定義を見てみると、etcdMembersDown などのアラートルールが記載されてるのが分かると思う。このカスタムリソースでは etcd ターゲットに関するルールが規定されている。これを削除してみる:

kubectl -n prometheus delete prometheusrules prometheus-prometheus-oper-etcd

で、しばらく待ってから [1] Prometheus のダッシュボードをのぞいてみると、アラートから etcd 関連のルールが消えてることが確認できると思う。次は新しくルールを追加してみる。以下のカスタムリソースを作成する:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
    name: mysample-alert.rules
    namespace: prometheus
    labels:
        app: prometheus-operator
        release: prometheus
spec:
    groups:
    -
        name: mysample-alert.rules
        rules:
        -
            alert: MyTargetDown
            expr: >-
                100 * (count(up == 0) BY (job, namespace, service) / count(up) BY
                (job, namespace, service)) > 10
            for: 10m
            labels:
                severity: warning
            annotations:
                message: >-
                    {{ $labels.job }}/{{ $labels.service }} targets in
                    {{ $labels.namespace }} namespace are down.

これを、例えば mysample-alert.rules.yaml として、

kubectl apply -f mysample-alert.rules.yaml

とやると、デプロイできる。後はしばらく待てば、Prometheus Dashboard のアラート一覧に、MyTargetDown というアラートが追加されてることが分かる。このようにして新しいルールを追加したり、既存のルールを編集・削除したりできる。

ところで、上でデプロイしたルールの labels で設定されてる app / release の値は、デフォルトでデプロイされている prometheus でセレクタとして設定されてる値で、これを設定しないとルールが認識されないようになっている。実際にその部分を見てみる。Prometheus カスタムリソースとして、1つだけデプロイされている prometheus-prometheus-oper-prometheus の設定をのぞいてみる。ここでは、

接続する Alertmanager
ServiceMonitor / PodMonitor のセレクタ
PrometheusRule のセレクタ

や、Prometheus ポッドの設定ができる。PrometheusRule のセレクタは、

ruleNamespaceSelector: {}
ruleSelector:
    matchLabels:
        app: prometheus-operator
        release: prometheus

の部分がそうで、デフォルトの Prometheus ポッドでは app が prometheus-operator で、release が prometheus のラベルを持っている PrometheusRule のみ認識され、Prometheus にルールとして取り込まれる。メトリクスによって監視サーバを分けたい場合などは、対応するルールにラベルを設定しておき、そのラベルに対するセレクタを設定した Prometheus カスタムリソースをデプロイすればいい。

Prometheus カスタムリソースから作られたポッドは、Prometheus のログがそのままログとして出ている。カスタムリソースで書いたルールが間違っていたら、ログにその旨が出力されるので、カスタムリソースがちゃんと設定されてるのにルールが反映されていない場合は確認してみるといい。カスタムリソースから作られた設定及びルールは、

/etc/prometheus/config_out/prometheus.env.yaml
/etc/prometheus/rules/<pod名>/<rule名>.yaml

に入っている。ログでは正常に動いてそうなのに、ルールが反映されない場合次に確認するのが、カスタムリソースに対応するルールファイルがあるかとそのファイルの中身がちゃんと入っているかだ。大体それを確認すればトラブルシューティングができるはず。

Alertmanager カスタムリソースはちょっとめんどいので今回は省略する。ドキュメントを参照のこと。基本的には、Alertmanager カスタムリソースを作成し、対応する alertmanager の設定を secret で作成する。で、Prometheus カスタムリソースにその Alertmanager カスタムリソースと secret を指定するとアラートが設定できる。

`PodMonitor` / `ServiceMonitor`

さて、ルールの変更とポッドの設定はできたが、Prometheus の監視対象、つまりターゲットの変更はどうすればいいのだろう？そのターゲットの管理を担うのが PodMonitor / ServiceMonitor になる。それぞれ名前の通り、pod / service ごとのターゲットの設定ができる。

初期で追加されているターゲットは、それぞれ ServiceMonitor で設定されている。例えば、grafana の設定は、prometheus-prometheus-oper-grafana という名前のカスタムリソースがそれに当たる。中身は、

spec:
    endpoints:
    -
        path: /metrics
        port: service
    namespaceSelector:
        matchNames:
        - prometheus
    selector:
        matchLabels:
            app.kubernetes.io/instance: prometheus
            app.kubernetes.io/name: grafana

のような内容になっている。namespaceSelector で prometheus 名前空間、selector でその名前空間のラベルでマッチするサービスを探すことになる。このセレクタに引っかかる service が、prometheus-grafana になる。その内容は、

spec:
    type: ClusterIP
    ports:
    -
        name: service
        protocol: TCP
        port: 80
        targetPort: 3000
    selector:
        app.kubernetes.io/instance: prometheus
        app.kubernetes.io/name: grafana

となっている。ServiceMonitor は、このサービスの service という名前のポート、つまり 3000 番の /metrics パスをターゲットとして設定する。このように ServiceMonitor をデプロイしたり、編集することで、サービスに対してのターゲットを設定できる。試しに、etcd / proxy のターゲットがお試し環境だと機能していないので消してみる。それぞれ prometheus-prometheus-oper-kube-etcd / prometheus-prometheus-oper-kube-proxy という ServiceMonitor が対応している。これら2つを削除し、しばらく待つと、ターゲットからその2つが消えてることが確認できる。もちろん、自分でデプロイした exporter を持つサービスに対して自由にターゲットを設定できる。試しにやってみる。Kotlin で Spring Actuator を使ったメトリクス出力機能付き Web アプリを service としてデプロイし、その service に対して ServiceMonitor でメトリクスをターゲットとして追加してみる。

デプロイするサンプルアプリは、https://github.com/mizunashi-mana/kotlin-spring-actuator-sample 。k8s のリソースも書いてあるので、それでまずデプロイをする:

git clone https://github.com/mizunashi-mana/kotlin-spring-actuator-sample
cd kotlin-spring-actuator-sample
./gradlew docker
kubectl apply -f k8s/deployment.yaml
kubectl apply -f k8s/service.yaml

これで、actuator のメトリクスが出されるようになる。そのメトリクスの内容は、

http://localhost:8001/api/v1/namespaces/default/services/http:spring-actuator-demo:web/proxy/actuator/prometheus

とかで見れる。これを ServiceMonitor で監視してみる。以下のようなリソースを書く:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor

metadata:
    name: spring-actuator-demo-monitor
    namespace: prometheus
    labels:
        release: prometheus

spec:
    namespaceSelector:
        any: true

    selector:
        matchLabels:
            app: spring-actuator-demo

    endpoints:
    -
        port: web
        path: /actuator/prometheus

で、例えば demo-service-monitor.yaml として、デプロイする:

kubectl apply -f demo-service-monitor.yaml

で、しばらく待ってから Prometheus のターゲットを確認すると、spring-actuator-demo のためのターゲットが確認できると思う。実際にメトリクスが取れてるかは、Grafana にポートフォワードして、

http://localhost:3000/explore?orgId=1&left=%5B%22now-1h%22,%22now%22,%22Prometheus%22,%7B%22expr%22:%22jvm_buffer_memory_used_bytes%22%7D,%7B%22mode%22:%22Metrics%22%7D,%7B%22ui%22:%5Btrue,true,true,%22none%22%5D%7D%5D

とかで確認してみるといいだろう。デフォルトでデプロイされてる Prometheus カスタムリソースは、release: prometheus ラベルで PodMonitor / ServiceMonitor を探すので、そのラベルは設定する必要がある。それから、ターゲットのジョブラベルは明示的に設定することもできるが、指定しない場合は name が設定される。Prometheus では同じジョブを持つメトリクスを複数登録できないので、monitor の name は注意して設定しておくといいだろう。

今回のは service ごとにセレクトしてターゲットに設定をするが、pod ごとにセレクトできるのが PodMonitor になる。こちらは使い方は ServiceMonitor と同じで、pod のセレクトか service のセレクトかだけが異なるので、今回は省略する。

まとめ

というわけで、Prometheus Operator の使い方を紹介した。Prometheus Operator は Kubernetes 上での監視体制を整えるためのパッケージで、カスタムリソースで監視対象を追加したりルールを追加したりできる。監視対象の追加は Kubernetes のエコシステムに合わせた形で定義できるため、結構便利。ただ、現状は beta 版なのでこの先大きく使い方が変わる可能性がある。そこは注意した方がいいだろう。今回はそういう感じで。

[1]	反映の完了は各 prometheus ポッドのログから確認できる。`Completed loading of configuration file` というログが出たら反映が行われている。

CBC mode に対しての Padding Oracle Attack

2020-07-19T22:33:47+09:00

共通鍵暗号の暗号方式としてよく用いられている暗号の種類として，ブロック暗号がある．ブロック暗号は，暗号方式の大別で，固定長のデータを単位として処理するような暗号の総称である．ところで，もちろん暗号化の対象となるデータは，固定長とは限らないし，かなり長さが大きくなる場合もある．そこで，ブロック暗号を扱うデータサイズより長いデータに対しても利用できるよう補佐する暗号利用モードと呼ばれるメカニズムも用意されている．

ところで，この暗号利用モードは，誤って利用すると，元となったブロック暗号が優秀であろうと致命的に安全性が損なわれる場合が多いことが知られている．今回はそのケースのうち，CBC と呼ばれる暗号利用モードについて知られている攻撃手法，padding oracle attack の概要を見ていく．

CBC (Cipher Block Chaining)

ブロック暗号として，

暗号化アルゴリズム $E_K: \Sigma^n \to \Sigma^n$
複合アルゴリズム $D_K: \Sigma^n \to \Sigma^n$

があったとする．ここで， $\Sigma^n$ は入出力として考えられる長さ $n$ の文字列の集合， $K$ は鍵である．これを任意の長さの文字列 $P \in \Sigma^*$ に適用することを考える．つまり，

暗号化アルゴリズム $E^+_K: \Sigma^* \to \Sigma^*$
複合アルゴリズム $D^+_K: \Sigma^* \to \Sigma^*$

を作りたい．さて，状況を簡単にするため，入出力の長さがブロック長 $n$ の倍数になっている状況を考える．この時，入出力は長さ $n$ の文字列 (ブロック) の列と考えられる．つまり，

暗号化アルゴリズム $E^+_K: (\Sigma^n)^* \to (\Sigma^n)^*$
複合アルゴリズム $D^+_K: (\Sigma^n)^* \to (\Sigma^n)^*$

が作れれば，その列を平坦にしたものを入出力の文字列として捉えることで，ブロック暗号を拡張できる．で，その拡張方法だが，単純に思いつくのは以下のようなものだ:

$E^+_K = \{P_i\}_{i \in [m]} \mapsto \{E_K(P_i)\}_{i \in [m]}$
$D^+_K = \{C_i\}_{i \in [m]} \mapsto \{D_K(C_i)\}_{i \in [m]}$

つまり，単純に各ブロックにそのまま元のブロック暗号を適用する方法だ．この方法は ECB モードと呼ばれている．ただ，この方法は

同じブロックは同じブロックに暗号化されるため，暗号文を見て同じブロックの箇所が判定できる
ブロック単位で複製・削除・順序入れ替えなどの改竄ができる

と言った問題がある．そのため，もう少し改良を加えたい．ECB の問題点は，主にそれぞれのブロックが独立に扱われていることに由来する．そこで，それぞれのブロックに対して他のブロックの内容に依存するようなベクトルを注入することが考えられる．CBC モードは，この注入を XOR で行うようなモードになる．

CBC モードは，初期ベクトル $\mathit{Iv}$ が与えられた時，

E^+_K = \{P_i\}_{i \in [m]} \mapsto \{C_i\}_{i \in \{0\} \cup [m]}

C_i = \left\{\begin{array}{ll} \mathit{Iv} &(i = 0) \\ E_K(P_i \oplus C_{i - 1}) &(\text{otherwise}) \end{array}\right.

D^+_K = \{C_i\}_{i \in \{0\} \cup [m]} \mapsto \{D_K(C_i) \oplus C_{i - 1}\}_{i \in [m]}

というような拡張を施す．一応よくある図を，NIST の資料から拝借して掲載しておく [1]:

最初は初期ベクトルが注入され，その後は一つ前のブロックの暗号文がベクトルとして注入されるようになる．これにより，EBC と異なり各ブロックはそれ以前のブロックの内容に依存するようになる．さて，このモードの正当性は，以下のように確かめられる:

\begin{array}{ll} D^+_K(E^+_K(\{P_i\}_{i \in [m]})) &= \{D_K(E_K(P_i \oplus C_{i - 1}) \oplus C_{i - 1}\}_{i \in [m]} \\ &= \{P_i \oplus C_{i - 1} \oplus C_{i - 1}\}_{i \in [m]} \\ &= \{P_i \oplus (C_{i - 1} \oplus C_{i - 1})\}_{i \in [m]} \\ &= \{P_i \oplus 0\}_{i \in [m]} \\ &= \{P_i\}_{i \in [m]} \end{array}

このように，最終的に暗号化と復号で注入したベクトルが XOR によりうまく打ち消し合い，最終的に平文に戻る．これが CBC モードの概要になる．

ところで，CBC モードを利用するには，入力の長さがブロック長の倍数になっていないといけなかった．ブロック長は AES では 128bit，つまり 16byte になる．つまり，AES を CBC モードで利用するには，入力のバイト数が 16 の倍数である必要がある．これは不便なので，パディングを埋め込む運用が通常取られている．

よく用いられている方法が，PKCS#7 由来の方法 [2] で，足りないバイト数分そのバイト数に相当する整数を埋めると言う方法だ．今回の例で言えば，例えば

30 31 32 33 34 35 36 37 38 39 40 41

というような 12 byte のデータに対して，パディングを埋めたい場合，足りないバイト数は 4 バイトなので，

30 31 32 33 34 35 36 37 38 39 40 41 42 04 04 04 04

というように 4 byte 分 4 を埋める．ところで，パディングを埋め込む場合，元データとパディングを区別できる必要がある．ただ，バイト数が 16 の倍数になっている場合パディングを埋め込まないようにすると，パディングが埋め込まれた結果のデータなのか，それともパディングが何も埋め込まれていない場合のデータなのかが分からない．そこで，パディングを埋め込む必要がない場合，つまりバイト数が 16 の倍数になっている場合も新しくパディングのみで構成されたブロックを追加するようにする．例えば，

30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

というようなデータの場合は，

30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10

のように 16 (16進数表記で 10) を 16byte 分末尾に足す．これにより，全てのデータは必ずパディングが埋め込まれており，データの末尾を見れば何バイト分がパディングか分かるようになるため，パディングと元データを区別することができるようになる．

CBC モードを使用する場合は，上記のようなパディングを埋め込んでバイト数をブロック長の倍数にし，それから暗号化を行う．また，復号した後はパディングを取り除くことで多くの場合運用されている．

Padding Oracle Attack

このパディングによる運用をつくことで，CBC モードにより暗号化された文を解読する攻撃が，padding oracle attack である．

CBC では，平文 $\{P_i\}_{i \in [m]}$ ，その暗号文 $\{C_i\}_{i \in \{0\} \cup [m]}$ について，以下の関係が成り立つ:

D_K(C_i) \oplus C' = D_K(E_K(P_i \oplus C_{i - 1})) \oplus C' = P_i \oplus C_{i - 1} \oplus C'

ここで，

P' = D_K(C_i) \oplus C'

とおくと，平文 $P_i$ に対して，

P_i = P' \oplus C_{i - 1} \oplus C'

という関係が求まる．つまり，何かブロック $C'$ があった時，それに対応する $P'$ が求まれば， $i - 1$ 番目の暗号ブロックから $i$ 番目の平文を復元することが可能になる．もちろん，鍵 $K$ とアルゴリズム $D$ が分かっていれば， $P'$ はそのまま求まる．しかし，攻撃側は普通鍵を知らないため，この攻撃を成功させるには $P'$ を何らかの方法で求める必要がある．ところで，もし攻撃対象のアプリケーションが複合時パディング情報が合っているかを検証し，わざわざ検証結果を教えてくれる場合，実は $P'$ を求めることができる．padding oracle attack の名前の由来は，攻撃対象が padding oracle，つまり padding が合っているかをわざわざ教えてくれる機能を持つ場合に，攻撃できる手法ということだ．

さて，では具体的にどうするかだが，この攻撃では $P'$ を求める式が復号処理とよく似ていることに着目する．つまり，復号機に $C' C_i$ を送ってみると，復号機はそれをちゃんとした暗号文だと思い $D_K(C_i) \oplus C'$ を計算するはずだ．これは $P'$ と同じになる．ところで，先ほどの $P_i$ を復元する式では， $C'$ は $P'$ が関係を守っているならば何でも良かった．そこで，この攻撃では最終的に $P'$ が，

10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10

つまり，パディングのみになるような $C'$ を探す．この探索は最後の 1byte から順に探していく．

今回は，攻撃対象はわざわざパディングが合っているかを検証しその結果を教えてくれるという機能，padding oracle を持っていた．そこで， $C'$ を中身は適当に設定し，最後の 1byte だけ順に 0 から 255 まで変えながら，padding oracle に送りつける．この時，padding oracle がパディングが正当であるという結果を返してくるということは，

たまたまパディングが正当な $C'$ を設定できた
$P'$ の最後が $01$ になった

の2択になる．ここでは，後者になるよううまく $C'$ を調整できていると仮定する．さて，この $C'$ を使うと，実は最後の byte を自由にいじることができる．例えば， $C'$ の最後のバイト $C'_{16}$ に対して $C'_{16} \oplus 01 \oplus 02$ としたものを新たに $C''$ とおくと，

D_K(C_i)_{16} \oplus C''_{16} = D_K(C_i)_{16} \oplus C'_{16} \oplus 01 \oplus 02 = (01 \oplus 01) \oplus 02 = 02

となる．後は，これにより最後が 02 となる $P'$ ， $C'$ が得られるので，その $C'$ をベースにまた最後から 2byte 目を変遷させて padding oracle に送りつけ，パディングが正当になる，つまり $P'$ の最後が 02 02 になるような $C'$ を探す．これを順に最初のバイトまで繰り返すと，最終的に $P'$ が

10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10

となるような $C'$ が得られることになる．後は， $C'$ との関係を守る $P'$ が得られたので，それを使って平文を復元すればいい．

実際に攻撃してみる

さて，ところで padding oracle をわざわざ提供してくれるアプリケーションは存在するんだろうか？ここでは，「わざわざ」とわざとらしく言っているが，実際には意識せず padding oracle を提供してしまう場合がある．多くの場合，サーバの返すエラーの種類が複数ある場合だ．多くの言語が提供する暗号化インターフェースでは，padding の不整合はそれ専用のエラーが出される．例えば Ruby では，

bad decrypt (OpenSSL::Cipher::CipherError)

というようなエラーになる．Java では専用の例外 BadPaddingException が用意されていて，こいつが投げられる．これらをもし，復号された後の文に対するバリデーションとは異なる例外ハンドリングで処理し，結果を異なる形 (例えばエラーメッセージをそのまま返すなど) でユーザに表示してしまうと，padding oracle ができてしまうことになる．

では，実際に padding oracle のあるサービスに対して攻撃をしてみる．今回は簡易的に，Ruby の以下のメソッドに対して攻撃を行う:

require 'openssl'

$n = 16

def encrypt(data)
    enc = OpenSSL::Cipher.new("AES-256-CBC")
    enc.encrypt

    enc.key = 'secret key'.ljust(32)
    iv = 'CBC IV'.ljust($n)
    enc.iv = iv

    iv + enc.update(data) + enc.final
end

def decrypt(data)
    sleep(0.01)

    dec = OpenSSL::Cipher.new("AES-256-CBC")
    dec.decrypt

    dec.key = 'secret key'.ljust(32)
    dec.iv = data[0, $n]

    dec.update(data[$n, data.length]) + dec.final
end

def valid_padding?(data)
    begin
        decrypt(data)
        true
    rescue OpenSSL::Cipher::CipherError
        false
    end
end

攻撃側が使用できるのは，valid_padding? メソッドのみである．気分を出すため，decrypt は 0.01 秒のレイテンシが出るようにしているが，これはまあ本質的ではないので無視してもらって良い．では，実際に攻撃側を実装していく:

def attack(data)
    cs = data.scan(/[\s\S]{#{$n}}/)
    ps = []

    (cs.length - 1).downto(1) do |i|
        pre_c = cs[i - 1]
        c = cs[i]
        plain = '?' * $n
        c_dash = "\x00" * $n

        is_illegal = true

        puts "Start detecting #{i}th block..."
        1.upto($n) do |j|
            0.upto(255) do |k|
                c_dash[-j] = k.chr

                print '.' if k % 10 == 0
                if valid_padding?(c_dash + c)
                    plain[-j] = (j ^ c_dash.bytes[-j] ^ pre_c.bytes[-j]).chr
                    c_dash = c_dash.bytes.map { |x| x ^ j ^ (j + 1) }.pack('C*')

                    is_illegal = false

                    puts <<~EOS
                    detected #{$n - j}th byte!
                    P: #{plain.inspect}
                    C': #{c_dash.inspect}
                    EOS

                    break
                end
            end
        end

        if is_illegal
            raise "Something illegal happend!"
        end

        ps.unshift(plain)
    end

    ps.join
end

基本的には，確認用出力以外は上記で述べたアルゴリズムをそのまま実装するだけだ．ただ平文の復元は，1byte ごとの $C'$ の値が分かればそれぞれのバイトごとに復元可能なので，見やすいよう 1byte ごとに復元している．これで，

plain_data = "This is a sample text to crypt by AES-CBC."
cipher_data = encrypt(plain_data)

p cipher_data
p attack(cipher_data)

というようなプログラムを走らせれば，最終的に

"CBC IV          St\xD7\xF0V\xADf\x05\xDB\x04\xAE\xE7/-\xF8\xC8\x91\xCFFL\xD8\xD8\xDD\x0F\xD3\xBC\b\xCBa]ZO\xAA\x06@F;g\x14\x81s\xF4_\x0E\x85\x15_\x1A"
Start detecting 3th block...
........detected 15th byte!
P: "???????????????\u0006"
C': "\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03K"
..........detected 14th byte!
P: "??????????????\u0006\u0006"
...
....detected 1th byte!
P: "?his is a sample"
C': "\x11::Cy/C\x10Q\x10CQ]@\\U"
.detected 0th byte!
P: "This is a sample"
C': "\x06;;Bx.B\x11P\x11BP\\A]T"
"This is a sample text to crypt by AES-CBC.\u0006\u0006\u0006\u0006\u0006\u0006"

というような出力が得られ，攻撃が成功することが確かめられる．

Encryption Attack

ここまでは暗号文の解読に焦点を当ててきたが，同様の方法で改竄も可能だ．まず，パディングがちゃんと付けられた平文 $\{P_i\}_{i \in [m]}$ があるとして，これを暗号化して送りつけたいとする．攻撃側は鍵を知らないので，これを他の方法でちゃんとした暗号文にする必要がある．

さて，平文に余分に $P_{m + 1}$ を付け加えた $\{P_i\}_{i \in [m + 1]}$ を考える．そして，そのちゃんとした暗号文を $\{C_i\}_{i \in \{0\} \cup [m + 1]}$ とおいた時，前の

P' = D_K(C_i) \oplus C'

を満たす $P'$ ， $C'$ が見つかれば，

C_{i - 1} = P_i \oplus P' \oplus C'

という関係が成り立つことになる． $P'$ ， $C'$ は上記の padding oracle attack の手法をそのまま使えば求められ，これによりある平文のブロックからその前のブロックに対応する暗号文が見つけられることになる．最終的に $C_{m + 1}$ 以外の暗号ブロックを求めることができ， $C_{m + 1}$ は余分に付け加えたブロックに対応する暗号文なので，それを取り除けば元の平文に対する暗号文が得られる．

実際に実装してみると，

def encrypt_attack(data)
    pad_len = $n - data.length % $n
    pad_len = $n if pad_len == 0

    ps = (data + pad_len.chr * pad_len)
      .scan(/[\s\S]{#{$n}}/)

    ps.push("\x00" * $n)
    cs = ["\x00" * $n]

    (ps.length - 1).downto(0) do |i|
        plain = ps[i]
        c = cs[0]
        pre_c = "?" * $n
        c_dash = "\x00" * $n

        is_illegal = true

        puts "Start detecting #{i}th block..."
        1.upto($n) do |j|
            0.upto(255) do |k|
                c_dash[-j] = k.chr

                print '.' if k % 10 == 0
                if valid_padding?(c_dash + c)
                    pre_c[-j] = (plain.bytes[-j] ^ j ^ c_dash.bytes[-j]).chr
                    c_dash = c_dash.bytes.map { |x| x ^ j ^ (j + 1) }.pack('C*')

                    is_illegal = false

                    puts <<~EOS
                    detected #{$n - j}th byte!
                    C: #{pre_c.inspect}
                    C': #{c_dash.inspect}
                    EOS

                    break
                end
            end
        end

        if is_illegal
            raise "Something illegal happend!"
        end

        cs.unshift(pre_c)
    end

    cs[0, cs.length - 1].join
end

のようになる．実際に

plain_data = "This is a sample text to crypt by AES-CBC."

attacked_cipher_data = encrypt_attack(plain_data)
p attacked_cipher_data
p decrypt(attacked_cipher_data)

のように攻撃してみると，

Start detecting 3th block...
...................detected 15th byte!
C: "???????????????\xBD"
C': "\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\xBF"
....................detected 14th byte!
C: "??????????????\xC0\xBD"
C': "\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\xC3\xBE"
...
..........detected 1th byte!
C: "?8\x80jG\xC0\xD8\xBF\x18[X@\xB1\xE7T\x93"
C': "\x11@\xF9\tw\xB9\xBB\x8Fik;1\xCC\x87(\xE6"
..................detected 0th byte!
C: "\xF48\x80jG\xC0\xD8\xBF\x18[X@\xB1\xE7T\x93"
C': "\xB1A\xF8\bv\xB8\xBA\x8Ehj:0\xCD\x86)\xE7"
"\xF48\x80jG\xC0\xD8\xBF\x18[X@\xB1\xE7T\x93\xC2[\xE2~\xC8\xAEO\x9Cf\x11}\x8F\xA5X\xC3\xED\xAE\eRI\x06Uk\x9E\xCB\x02n\xF9l\xC2E\x1A\xC8\xE8\x83\xBBc\x97\x82\x90R\xD5N]4\xFA\xC0\xBD"
"This is a sample text to crypt by AES-CBC."

のような出力が得られ，攻撃が成功してることが確認できる．

まとめ

というわけで，padding oracle attack の概要を見た．padding oracle を利用することで，暗号文からの平文の復元，改竄を行えることが分かった．ユーザに対して情報を提供することはユーザビリティの面では非常に重要だが，セキュリティの面では少しの情報で致命的な欠陥を招くこともある．そういうのは気をつけていかなきゃなと思いました（こなみ）．

なお，以下の文献に非常にお世話になった:

[1]	https://csrc.nist.gov/publications/detail/sp/800-38a/final

[2]	http://tools.ietf.org/html/rfc5652#section-6.3