Go netlink 属性标志与属性类型怎样分离

使用 AttributeDecoder 时，基础类型用 ad.Type()，高位标志用 ad.TypeFlags()。直接处理 Attribute.Type 时，它仍包含两类信息，应先用位掩码分离，再按基础类型进入业务分支。

官方项目地址：https://github.com/mdlayher/netlink。本文以v1.11.2源码为依据，只讨论Netlink属性的类型字段，不把属性标志与外层Message.Header.Flags混在一起。

用Type与TypeFlags分别取值

// raw来自某条Attribute.Type；分离后才用于业务类型匹配。
flagMask := uint16(netlink.Nested | netlink.NetByteOrder)
baseType := raw &^ flagMask
typeFlags := raw & flagMask
_ = baseType
_ = typeFlags

这是一个放在已有函数中的片段，需要上下文已导入netlink并定义raw。实际使用解码器时，无需重复写它：Type已经屏蔽高位，TypeFlags保留标志。不要把TypeFlags理解为独立于Type字段的另一个线上字段。

先保护属性分派的正确性

假设程序只接受某个计数器属性，却直接把原始Type与编号7比较。加上0x4000后，值成为0x4007，这个比较就不成立。若默认分支又悄悄丢弃属性，调用方可能得到一个看似成功、实际缺少字段的结果。

这里保护的对象是解码结果的完整性，而不是声称库存在已知漏洞。需要关注的输入路径包括内核响应、离线消息记录和应用自行构造的属性。分离类型之后还要依据协议约束判断允许哪些标志、要求多长载荷；不能因为掩码处理正确，就接受任意内容。

对“未知类型”和“已知类型但标志不符合定义”应分别制定策略：前者可按兼容约定忽略或保留，后者应避免悄悄解释成另一种数据。涉及配置或权限判断的字段，错误默认值尤其需要谨慎处理。

用离线属性演示网络字节序

下面创建一个自定义类型7、带网络序标志的uint32属性，然后解码。它不对应任何真实内核命令，只用来说明“编号用于分派、标志用于解释约束”这件事。

# 在已有Go模块中固定本文讨论的版本
go get github.com/mdlayher/netlink@v1.11.2

package main

import (
    "encoding/binary"
    "fmt"
    "log"
    "github.com/mdlayher/netlink"
)

func demo() error {
    // 类型7是本文自定义示例编号，不是某个内核协议的真实属性。
    const counterType uint16 = 7
    payload := make([]byte, 4)
    binary.BigEndian.PutUint32(payload, 2049)
    wire, err := netlink.MarshalAttributes([]netlink.Attribute{{
        Type: counterType | netlink.NetByteOrder,
        Data: payload,
    }})
    if err != nil { return err }

    ad, err := netlink.NewAttributeDecoder(wire)
    if err != nil { return err }
    // 此示例schema只接受网络序uint32，解析前显式指定字节序。
    ad.ByteOrder = binary.BigEndian
    for ad.Next() {
        typ, flags := ad.Type(), ad.TypeFlags()
        if typ != counterType {
            return fmt.Errorf("示例不接受属性类型%d", typ)
        }
        if flags != netlink.NetByteOrder {
            return fmt.Errorf("属性%d标志不符合网络序计数器约定", typ)
        }
        value := ad.Uint32()
        // 长度不匹配会在Err中报告，出错前不交付读取值。
        if err := ad.Err(); err != nil { return err }
        fmt.Printf("type=%d flags=0x%04x value=%d\n", typ, flags, value)
    }
    return ad.Err()
}

func main() {
    // 仅序列化与解码本地字节，不打开socket，也不修改网络配置。
    if err := demo(); err != nil { log.Fatal(err) }
}

按代码中的构造，预期基础类型为7、标志为0x4000、值为2049。这是示例推导，本文没有执行代码。若将载荷改为两个字节，Uint32的长度要求不再成立，应走错误分支，而不是使用读取出来的零值。

NetByteOrder不会替你自动切换解码器的ByteOrder。上例在解析前显式使用BigEndian。如果同一属性列表中既有本机序整数又有网络序整数，可以按各属性的协议定义取Bytes后分别解码，并在读取前约束长度，避免把一种ByteOrder无条件用于整份混合列表。

把嵌套与长度约束留给协议定义

Linux UAPI注明Nested与NetByteOrder两种高位标志互斥。不能为了“标志齐全”同时置位。若协议规定某属性是嵌套结构，应据此解析其子属性，不能把Nested当作所有字节都可信的证明。

处理嵌套时，可用解码器Nested方法建立子解码器。应用仍应限制允许的层数、总字节数与属性数量；这属于资源边界设计，不能从两个标志位中自动得到。还有一些历史协议对标志的实际用法需要参照该族定义，因此不宜写一个“看见任何Nested位就无限递归”的通用转换器。

另外，属性的Type字段所在头部与其载荷的字节序不是一回事。NetByteOrder描述载荷，不要求把整份Netlink消息按大端重新解释。处理整数、字符串、嵌套列表时，都应使用对应类型的读取规则。

日志里同时保留类型和标志

排查时同时记录基础类型、标志的十六进制值、载荷长度及协议族上下文。只记录“unknown type=16391”，看不出它其实可能是类型7加0x4000；只记录类型7，又会丢掉为什么使用不同解码方式的信息。日志无需携带完整载荷或敏感属性内容。

AttributeDecoder.Flag()能判断Nested吗？

不能。Flag用于协议中表示“存在即为真”的空载荷属性；Nested应从TypeFlags读取。两个名字相近，含义不同。

UnmarshalAttributes返回的Type已经去掉标志了吗？

直接Attribute结构保留原始Type，需要自己分离。若使用AttributeDecoder.Type，则得到屏蔽高位后的基础类型。

把属性再编码时需要保留标志吗？

需要按目标协议重新构造基础类型与合法标志组合。盲目只写基础编号会丢失语义，盲目复制所有高位也不能代替协议检查。

依据：netlink属性编码与解码实现、Linux UAPI属性标志与掩码定义。文中防护建议针对应用的解析边界，不代表库存在特定安全公告。