Кратко

  • RFC 9669 стандартизирует кодирование BPF и именованные группы соответствия, но доступные context fields и функции остаются частью платформы и program type.
  • Поддержка инструкции не равна приёму программы; приём не равен загрузке, attachment, invocation или подтверждённому внешнему эффекту.

Компилятор выпустил один и тот же объект для двух точек исполнения. На первой verifier принял вызов функции и программа загрузилась. На второй те же bytes были понятны, но прототип отсутствовал в разрешённой поверхности этого program type.

В инвентаре обе цели назывались «BPF-capable». Для ISA это было правдой. Для конкретного API-контракта — недостаточной правдой.

Ошибка появилась не в opcode, а в пропущенном контексте.

Что именно согласует RFC 9669

Базовая BPF-инструкция занимает 64 бита. Wide encoding добавляет вторые 64 бита. Opcode, регистры, offset и immediate интерпретируются по классу инструкции. Благодаря этому compiler и runtime могут одинаково понимать операцию, не копируя друг у друга всю реализацию.

Спецификация не требует полного каталога. Каждая реализация обязана поддерживать base32, а остальные группы может выбирать. base64 включает base32, atomic64 включает atomic32, divmul64 включает divmul32. Заявленная группа означает поддержку всех её инструкций.

IANA хранит группы с их именами, описаниями, includes, excludes, статусом, контролёром и ссылкой. Реестр инструкций связывает комбинации полей с описанием и группами. Новые инструкции получают новую группу, а не меняют задним числом обещание старой.

Permanent фиксирует управление назначением. Он не утверждает, что конкретный kernel, runtime, program type или аппаратный offload уже его реализовал. Historical не стирает старую возможность: deprecated packet-access instructions могут жить в старой среде, но не становятся современной переносимой базой.

Capability discovery поэтому должно выдавать набор для конкретной цели, версии, архитектуры и момента. Название технологии не заменяет этот receipt.

ISA не определяет весь контекст вызова

Даже программа из известных инструкций может быть некорректной. Jump offset измеряется 64-битными единицами; переход во второе слово 128-битной wide instruction создаёт undefined behavior. Значение отдельной инструкции не доказывает правильность control flow.

С map и function calls появляется ещё один слой. RFC описывает абстрактные операции разрешения, но конкретные объекты и функции задаёт платформа. Тип программы определяет, какой context доступен и какие прототипы можно вызывать. Совпадение ISA не обязано означать совпадение helper surface.

RFC 9669 перечисляет задачи verifier: завершение, безопасная память, соблюдение platform API и отсутствие undefined behavior. Подробности проверки сознательно вынесены за рамки документа. Общая машинная речь и локальная политика допуска — разные полномочия.

Документация Linux показывает реализацию этой границы. Сначала verifier проверяет control-flow graph, затем символически проходит возможные пути и отслеживает регистры и stack. Program-type callbacks разрешают context fields и function prototypes. Регистр-поинтер может после недопустимой арифметики стать scalar; вызов с неверными аргументами будет отклонён.

Linux Design Q&A формулирует практический ответ: чтобы узнать, примет ли verifier программу, попробуйте её загрузить. Анализ и внутренние limits меняются. Совместимость Linux для ранее принятых программ не является обещанием другого runtime, другого program type или offload.

Принятая программа ещё не действует

После verifier loader создаёт объект и program ID. Это доказывает наличие объекта. Link должен привязать именно эту generation к нужному hook. Затем событие должно пройти через hook, чтобы возникла invocation.

Нулевой счётчик может означать неправильную точку, отсутствие тестового трафика или ошибку selector. Он не позволяет автоматически заключить ни «политика сломана», ни «нарушений нет». Требуется трасса canary event до выбранного execution point.

Рост счётчика тоже не закрывает внешний результат. Program-side map сообщает, что видел механизм. Он не исключает параллельный путь и не доказывает durable state приложения. Сетевой поток, транзакция или физическое состояние нуждаются в независимом наблюдении.

Подпись остаётся отдельной квитанцией. Текущая документация Linux указывает, что BPF signing не заменяет permissions или verifier. BPF_SIG_VERIFIED на раннем admission hook означает валидную подпись, а не fully loaded program. Поздняя проверка ещё может отказать. Это Linux-specific example, не обязанность RFC 9669, и его нельзя превращать в универсальное правило.

Корреляция должна пережить замену поколения

Операционная цепочка хранит source и build inputs, object hash, compiler feature set, target runtime и architecture, program type, groups, relocations, verifier verdict и log hash, program ID, link ID, hook, map generation, attach/detach time, invocation counter, внутреннее решение и независимый outcome.

Отрицательные квитанции имеют разные причины: unsupported group, unknown function for program type, relocation failure, verifier rejection, load failure, attach failure, zero invocation и outcome mismatch. Один общий статус BPF error скрывает владельца исправления.

При обновлении новый object не гарантирует удаления старого link. Общая map может смешать счётчики. Dashboard, соединяющий данные только по имени policy, способен показать metadata новой версии поверх execution старой.

Rollback должен перечислить все links, подтвердить их поколение и решить судьбу shared state. Удаление последнего object не доказывает возврат трафика на прежний путь.

RFC 9669 даёт минимальную общую спецификацию: смысл инструкций и управляемое расширение. Локальные runtimes сохраняют выбор optional groups, verifier rules и exposed interfaces. Доверие возникает только после running-code receipts, а не из названия стандарта.

Источники