另外，安全方面还有 ptrace, seccomp 等传统方法。

非主流方法：如果评测机用的是 Ubuntu 等自带 AppArmor 的系统的话，倒是可以不用容器，通过 AppArmor 来实现安全加固。

内存和时间限制，一般来说是联用轮询和 rlimit 系统资源限制：
1 ）定时器限制时间+轮询采样内存消耗情况作为主要监控手段，用于反馈 TLE/MLE
2 ） rlimit 系统限制设得比题面描述高一些，用来保底
（不单用 rlimit 是因为超限程序会被直接杀死，从而无法区分 RE, TLE 和 MLE ；而且无法限制程序的非用户态时间）

@systemcall

Keil 礦 ision 纯粹是教材坑爹而已。

本来 ST 官方就有基于 Eclipse 的 STM32 开发环境 TrueStudio 和 SW4STM32 （前者是新出的，后者是早期就有的开源方案；不想用打包好的想用纯开源的也可以自己在 Eclipse 上装插件配环境）。现在 JB 家的 CLion （收费软件，学生可申请免费授权）也支持 STM32 开发。
就算是更廉价的 51 单片机也有 sdcc 之类的开源免费开发工具。

奈何国内有些辣鸡教材非要搞一些蛋疼老版本盗版软件。

再加一个花钱换机的解决方案：把你的 XDR 换成 NETGEAR 或者 LinkSys Velop 的 MESH 路由，它们都原生支持 AP 模式做 Mesh 。（国内品牌 Mesh 路由几乎都不原生支持 AP 模式 Mesh ）

你是用 TP-Link 路由器不插 WAN 口只插 LAN 口关闭 DHCP 强行当 AP 用吗？

TP 家的家用路由最大特点就是万年不出 AP 模式，只有它做主路由才保证 Mesh 功能是正常的。

你这样接确实可能会有环路问题，你的两个 XDR 做了 Mesh，又通过 LAN 口上联，本身 TP 家的路由就是不原生支持 AP 模式的，接 LAN 口关 DHCP 只能说是一种奇技淫巧，它有可能不认为这个 LAN 口是回程线路，强行通过无线 Mesh 回程，就成环了。

几种解决方法：
1. 两个 XDR 不做 Mesh，独立当成两个“AP”用
2. 断开一个 XDR 的网线，强制只用无线 Mesh
3. 其中一个 XDR 断开目前的 LAN 口上联，用 WAN 口上联另一个 XDR，强制 Mesh 回程线路只在两个 XDR 之间建立

如果你要 AP 模式的话不建议 TP-Link 。

TP-Link 路由万年不出 AP 模式，你要做 AP 只能用“关闭 WAN 口自适应+关闭 DHCP+接 LAN 口”这种变通方式，很不方便。

更正一下，“以后的浏览器都要原生支持的”不准确。谷歌的这个认证是同属于 FIDO2 协议的，但更类似于 Windows Hello 这种平台相关的虚拟密钥（和原来就有的蓝牙物理密钥反而关系不大）。这样看来别的浏览器应该没法支持。

这个是 FIDO2 WebAuthn 认证，是新的 Web 标准里东西。相应的物理密钥设备本身就包含 usb, nfc 和蓝牙三种形式，同时还支持非物理密钥比如 Windows Hello，以后的浏览器都要原生支持的。

根本不是什么 js 直接读蓝牙。

@sasalemma 这个和 iptables 没什么关系，ipv6 默认纯路由模式不经过 NAT，是不涉及 iptables 的（当然，如果有防火墙的话还是要用到 iptables ）。涉及到的是 DHCPv6 Server 的工作逻辑，对于 PD 请求是“创建新的 VLAN”，还是和 NA 请求一视同仁直接从 LAN 里挖。这两种在路由表上都是很容易实现的。就看 DHCPv6 软件的开发者的选择了。

@cwbsw 这个是我阅读 odhcpd 的源码和查询相关资料得出的结论。OpenWRT 在处理 PD 请求的时候似乎是从已经配置到 LAN 的前缀上挖出一块向下分发的，而不是从闲置地址里分发。

比如说一级路由使用 Mikrotik RouterOS 的话，这种情况就是可以下发前缀的

@sasalemma
改正上个回帖里的一处错误：“如果一级路由器是 OpenWRT，是可以实现这种下发操作的”
现在的 OpenWRT 确实不支持这种下发。但是其它路由器不一定不支持。

我之前也见过一种光猫，获取 /60 的前缀后可以给二级路由 PD /64 的前缀，但可能路由表的建立有 BUG，导致二级路由后的设备获取了地址也上不了网......

@sasalemma 你这里对一些概念的理解有些问题。

是这样的，首先各个 /64 的意义是不一样的，通过 SLAAC 获得的只是一个地址，里面的“前缀长度”字段（值为“/64”）只是相当于 ipv4 的子网掩码的含义，只是提示了同一网段（ WAN 侧）的地址范围，同前缀的其它地址是不属于你的。所以说当路由器仅获取 WAN 地址时（无论是通过 SLAAC 还是 DHCPv6 IA_NA，前者只支持 /64，后者支持任意的前缀长度，注意这两种方式获取到的都是“地址”而不是“前缀”），LAN 端设备是无法直接获得 IPv6 全球单播地址（就是 2 开头的公网地址）的。

然后还有另外一种操作是 DHCPv6 IA_PD，这种操作可以向上级网络请求一个 IPv6 的前缀，一般家宽运营商给出的前缀长度都是 /56 或者 /60 的，也有极少情况是 /64 的。通过这种方式获取到的是“前缀”而不是“地址”，也就是说同前缀的 2^(128-PREFIX_LEN)个地址都是属于你的。这就是 DHCPv6 IA_PD 和其它地址获取方式（ SLAAC 和 DHCPv6 IA_NA ）的本质不同之处。

家宽单层路由器（包括光猫自带路由，以及光猫桥接路由拨号两种情况）的一般工作方式：首先路由器（路由模式光猫）建立 PPPoE 链路，然后通过 SLAAC 获取 WAN 侧地址（一般情况下前缀长度为 /64 ），然后通过 DHCPv6 IA_PD 向 ISP 请求一个地址段，比如楼主拿到的是一个 /56 的地址段，这些地址都是临时属于你的（ ISP 端在获取地址的那一刻就已经建立好了正确的路由）。然后重要的来了：路由器（路由模式光猫）从这 /56 的地址端中只取了一个 /64 的地址段作为前缀配置到了 LAN 接口上（包括本地路由器的路由表，自身 LAN 口地址，和负责分配地址的 RA 服务，有时候可能还有本地的 DHCPv6 服务），这样 LAN 侧的设备就可以通过相应的协议获取临时属于自己的公网地址了。至于为什么只取一个 /64 而不是整个 /56，是为了兼容 SLAAC 。

而且可以注意到，路由器 LAN 侧和 WAN 侧不是同一个网段，这也是 IP 协议的最基本要求（想想 v4 时代是怎么配置地址的）

这种情况下，还有 255 个 /64 全球可路由的地址段（或者也可以理解成 15 个 /64 地址段和 15 个 /60 地址段）是处于闲置状态的，理论上来说，一级路由器也可以响应 LAN 侧接入的下级路由器的 DHCPv6 IA_PD 请求，给下级路由器分配前缀（下级路由 WAN 侧通过 SLAAC 拿一级路由 LAN 侧的**一个**地址，LAN 侧拿一级路由从 ISP 得到且闲置的**一段**前缀，在这个过程中会自动配置好本地的路由表等参数），然后下级路由 LAN 侧连接的设备就也可以获得公网地址了。此时如果把 /56 改成 /60，也只是少一些可用地址段而已（只有 15 个 /64 地址段闲置），影响不大。如果一级路由器是 OpenWRT，是可以实现这种下发操作的。

所以说实际存在的问题并不是所谓的“/60 下发只有 /64 不能再下发”（实际上不存在这种说法），而是光猫自带路由根本不会正确响应下级路由器的 IA_PD 请求。
（我也见到过一些光猫，能够响应 IA_PD 请求，但是可能固件里有 bug 不能正确配置本地的路由表，导致二级路由后的设备能获取 ipv6 地址但不能上网）

@systemcall Surface 系列装 Linux 都会有硬件不兼容的问题（比如自带键盘不能用等等），需要装魔改版内核，非常不方便。而且这个 SB2 还是有独显热插拔的，估计兼容性问题会更大，装 Ubuntu 估计体验不好。

IPv6 DDNS 一般都不用软件，直接用脚本，要绑域名的服务器（不是路由器）上定时运行即可。

dynv6 这个 ddns 可以只解析 ipv6

大多数 Linux 发行版一般都可以直接迁移（除了自己编译、裁剪内核的情况）
Windows 10 这样做则会蓝屏，需要强制关机数次唤起启动修复提示，然后进一次安全模式，以后才能正常开机。

@DaRenCC 因为 VLAN 可以起到单线复用的作用，把 IPTV，上网等原本需要单独布线的变成走一条网线