@Monstercat “科学上网”我会，前面有还说目前仅有 2 种科学上网方式，有点慌呢。
回家后没有 IPv6，medium.com 就无法访问了，我就想向大家报告下，谁知道她早就进去了。。
我会下沉该主题。

通 ipv6 之后才看到过 medium 上内容的，没想到 16 年她就离开我们了。https://www.solidot.org/story?sid=47817

去年（前几天），电信 ipv6 访问正常。也就是说无法访问是这几天的事情，还是 ipv4 下早就无法访问了？
怕的是她越来越智能，怕有一天会越不过去。
目前仅有 2 种科学上网方式，有点慌。

机器 A 加一个 bridge 应该就可以了，后者机器 A 开启 ip_forward 试试看。
sysctl -w net.ipv4.ip_forward=1
参考下：
https://wiki.gentoo.org/wiki/Network_bridge
https://wiki.gentoo.org/wiki/Ethernet_plus_WiFi_Bridge_Router_and_Firewall

@luminous 了解。
tcp 还能建立连接，而 tls 无法建立，这关的不彻底啊。bitlocker 还有连接指向它。。。

重新试了下 zh.wikipedia 又连不上了。
openssl s_client -connect zh.wikipedia.org:443
一种情况是：
connect: Connection refused
connect:errno=111
另一种是：
connect: Connection timed out
connect:errno=110
还有一种是能连接的情况：
CONNECTED(00000003)
depth=2 OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
verify return:1
depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign Organization Validation CA - SHA256 - G2
verify return:1
depth=0 C = US, ST = California, L = San Francisco, O = "Wikimedia Foundation, Inc.", CN = *.wikipedia.org
verify return:1
---
Certificate chain
0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikipedia.org
i:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2
1 s:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2
i:/OU=GlobalSign Root CA - R3/O=GlobalSign/CN=GlobalSign
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIIMTCCBxmgAwIBAgIMFkDF1F0uxNlMfXxqMA0GCSqGSIb3DQEBCwUAMGYxCzAJ
BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTwwOgYDVQQDEzNH
bG9iYWxTaWduIE9yZ2FuaXphdGlvbiBWYWxpZGF0aW9uIENBIC0gU0hBMjU2IC0g
RzIwHhcNMTgxMTA4MjEyMTA0WhcNMTkxMTIyMDc1OTU5WjB5MQswCQYDVQQGEwJV
UzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZyYW5jaXNjbzEj
MCEGA1UEChMaV2lraW1lZGlhIEZvdW5kYXRpb24sIEluYy4xGDAWBgNVBAMMDyou
d2lraXBlZGlhLm9yZzBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABGd1rS7GauMx
J15BmViShjVMjwQJNjjw+OUhnIaqE5QF/q6c/LIvVh4N3473a7J52JcfmlfCrXvD
thHzaZNEneKjggWVMIIFkTAOBgNVHQ8BAf8EBAMCA4gwgaAGCCsGAQUFBwEBBIGT
MIGQME0GCCsGAQUFBzAChkFodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2Nh
Y2VydC9nc29yZ2FuaXphdGlvbnZhbHNoYTJnMnIxLmNydDA/BggrBgEFBQcwAYYz
aHR0cDovL29jc3AyLmdsb2JhbHNpZ24uY29tL2dzb3JnYW5pemF0aW9udmFsc2hh
MmcyMFYGA1UdIARPME0wQQYJKwYBBAGgMgEUMDQwMgYIKwYBBQUHAgEWJmh0dHBz
Oi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMAgGBmeBDAECAjAJBgNV
HRMEAjAAMEkGA1UdHwRCMEAwPqA8oDqGOGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5j
b20vZ3MvZ3Nvcmdhbml6YXRpb252YWxzaGEyZzIuY3JsMIICxQYDVR0RBIICvDCC
AriCDyoud2lraXBlZGlhLm9yZ4INd2lraW1lZGlhLm9yZ4INbWVkaWF3aWtpLm9y
Z4INd2lraWJvb2tzLm9yZ4IMd2lraWRhdGEub3Jnggx3aWtpbmV3cy5vcmeCDXdp
a2lxdW90ZS5vcmeCDndpa2lzb3VyY2Uub3Jngg93aWtpdmVyc2l0eS5vcmeCDndp
a2l2b3lhZ2Uub3Jngg53aWt0aW9uYXJ5Lm9yZ4IXd2lraW1lZGlhZm91bmRhdGlv
bi5vcmeCBncud2lraYISd21mdXNlcmNvbnRlbnQub3JnghEqLm0ud2lraXBlZGlh
Lm9yZ4IPKi53aWtpbWVkaWEub3JnghEqLm0ud2lraW1lZGlhLm9yZ4IWKi5wbGFu
ZXQud2lraW1lZGlhLm9yZ4IPKi5tZWRpYXdpa2kub3JnghEqLm0ubWVkaWF3aWtp
Lm9yZ4IPKi53aWtpYm9va3Mub3JnghEqLm0ud2lraWJvb2tzLm9yZ4IOKi53aWtp
ZGF0YS5vcmeCECoubS53aWtpZGF0YS5vcmeCDioud2lraW5ld3Mub3JnghAqLm0u
d2lraW5ld3Mub3Jngg8qLndpa2lxdW90ZS5vcmeCESoubS53aWtpcXVvdGUub3Jn
ghAqLndpa2lzb3VyY2Uub3JnghIqLm0ud2lraXNvdXJjZS5vcmeCESoud2lraXZl
cnNpdHkub3JnghMqLm0ud2lraXZlcnNpdHkub3JnghAqLndpa2l2b3lhZ2Uub3Jn
ghIqLm0ud2lraXZveWFnZS5vcmeCECoud2lrdGlvbmFyeS5vcmeCEioubS53aWt0
aW9uYXJ5Lm9yZ4IZKi53aWtpbWVkaWFmb3VuZGF0aW9uLm9yZ4IUKi53bWZ1c2Vy
Y29udGVudC5vcmeCDXdpa2lwZWRpYS5vcmcwHQYDVR0lBBYwFAYIKwYBBQUHAwEG
CCsGAQUFBwMCMB0GA1UdDgQWBBSt4NNfC33t2i98DfZjjYpZGMJsijAfBgNVHSME
GDAWgBSW3mHxvRwWKVMcwMx9O4MAQOYafDCCAQQGCisGAQQB1nkCBAIEgfUEgfIA
8AB2AKS5CZC0GFgUh7sTosxncAo8NZgE+RvfuON3zQ7IDdwQAAABZvUzN/YAAAQD
AEcwRQIgBATdvSzbd5NwGdtkmJ5SEvEPn6A8hgAsk6GSP6hzWcgCIQDKfHQNtObs
/hHPfLgXsVkcnHIbjlNwmWeiukGtGHZFMgB2AG9Tdqwx8DEZ2JkApFEV/3cVHBHZ
AsEAKQaNsgiaN9kTAAABZvUzN8cAAAQDAEcwRQIgYalEnXtd/fPhjq9SXPoSPRha
MmeDs0IMN5o5Y6QTKfUCIQClR1uj+B56K4tGh/mws4qugG1qSD9zfvmx8roKik3H
HDANBgkqhkiG9w0BAQsFAAOCAQEAUEJyg/AZo+owG5J/LIk8EIDnyOcanmfgvdjM
g8KnpBvh8l3Wb4HmOudluJhIeIbCUMwzEzSGqYQQ78n4wtjLaLwaDgL4WzHOVec2
k+rbfmPT6MUCtdlz1PK5/WY9JQyQq6vy+tm3a6Wijy6M8U/TdrJubK5X03SFfRb0
pDuFdr2fnkctLRnyCb1w0XHwGXjEcGm1LY42YKwdvbj3WIqumeSEuG4MZtquW6NU
RKELSil03G/hRHRAHHGx3zXes/jJcpH2GPX9eY9B+R1oHmCE2QF5Y/Bh+uNA2+2I
uj/6UJAOw/Z/8+qZcnLWWnK2Dwzc34C/AUD+Wb71oUcr60+pPg==
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikipedia.org
issuer=/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3552 bytes and written 429 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-ECDSA-AES256-GCM-SHA384
Server public key is 256 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-ECDSA-AES256-GCM-SHA384
Session-ID: 3F27683661A0844F1287380DC54DF05820E9F61B988698B59F766B22C212725B
Session-ID-ctx:
Master-Key: 0ED696B836B03A113065AAC57BF96031E96EE323BF9B5D4D0950BE40FE4001B3BDEE01ED0FDD8DE435AD39F3798D34EB
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1549520668
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
^C

感觉是有三层防火墙，分别对应前面上面说的三种情况。
关于第三种情况的疑惑：该次链接支持重协商“ Secure Renegotiation IS supported ”，重协商即使是“安全(secure)”的也不安全，所以 tls1.3 没有重协商。不知道墙外只连有没有“重协商”？

@infun 确实。
刚才测试了下 openssl s_client -connect sysdev.microsoft.com:443
得到这个：
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 303 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1549520563
Timeout : 300 (sec)
Verify return code: 0 (ok)
---

我对 tls 不太熟悉，怀疑是根据 sni 被阻断了，于是试了下 zh.wikipedia.org ，发现能连接了，其 CN 改为通用格式*.wikipedia.org 了，怕是维基百科将要全部被强了。

@sdijeenx 要能关闭 me 的才好，估计超微不给关。

@dangyuluo 看来我们理解的 runtime 不是同一个概念。我理解的 runtime：比如 c++语言的 runtime 是 c++标准库和 c 库。 [lvm.org/docs/SegmentedStacks.html] 有一句说 The runtime functionality is already there in libgcc. 她说 splitstack 作为 runtime 一部分包含在 libgcc 中。libgcc 对于 gnu c 而言也是其 runtime。所以，我认为只有汇编才没有 runtime。感觉你指 runtime 仅仅是字面的“运行过程中”。

在 cpu 执行你所指的” runtime “之前实际上是有动态内存分配的吧。比如你所说的”启动过程锁定 900MB 内存”。
std::string 的 allocator 用到你预分配的 900M，自然也没有显式的动态内存分配了。

要真正做到应用程序直接控制内存，也许这个可以 [en.wikipedia.org/wiki/Exokernel] 做到。

@dangyuluo 是这 2 个吧 https://github.com/ros2 https://github.com/osrf/osrf_testing_tools_cpp
专有硬件加专有 os （ ros2 是 os 的话），msan 可能不支持你的平台或者 OS。
即使是专有硬件加专有 OS，“不允许 runtime 动态内存分配”这一点，以我的水平怎么想也觉得做不到。
我理解“不允许 runtime 动态内存分配”，意味着没有“堆”。楼主写的是 OS 或者 kernel ？没有其他进程？
不知道有没有专业人士出来科普一下。

楼主遇到的问题的 msan （ MemorySanitizer ）可以定位。

看到“不允许 runtime 动态内存分配”，我很好奇并相信一定有和我一样的人同样感兴趣：能分享下你们是怎么做到这一点的？
这是我能想到的一种思路，作为抛砖引玉：
假定 std::string 仅测试部分使用，故不受到“不允许 runtime 动态内存分配”限制。标题限定到使用 g++，如果指的是 gnu c++的话，采用 splitstack （ http://gcc.gnu.org/wiki/SplitStacks ）也许算是能做到（如果 splitstack 被认为不是 runtime 的话）。假设 google sanitizers （ https://github.com/google/sanitizers ）和 splitstack 相互兼容的话（目前已知 splitstack 被 gcc go （ https://github.com/golang/gofrontend ）用到，同公司的不同团队合作的可能性很高），那么测试部分也没多大问题。即使考虑到 llvm 也是支持的（ http://llvm.org/docs/SegmentedStacks.html)
，但是真的有人这么写吗？

@dingwen07 跳线清除 bios 密码后，就可以从 USB 启动其他 OS 了，从其他 OS 访问本地遵循国内法律的加密方案保护的文件是可能的。目前在考虑 google 泰坦 https://cloud.google.com/titan-security-key

关于支持网络安全法已经反恐法：建议内置一个能获得所有账号所有权的内部邮件地址。
为了更好的保护用户数据，实现账号删除功能是应该并且迫切的。至于保存规定时间的问题，我对数据库不熟悉，不过数据库应该有类似的功能实现，估计给个时间戳就可以了。（我在 GitHub 上看到过介绍中还有” time xxx “相关的数据库。）

@KasuganoSoras 正好说到找回账号功能。我之前有忘记 github 密码的情况，github 提示我的密码不安全，有被撞库的风险。我就改了密码，恰好用的 chrome 自己生成的密码，遗憾的是我喜欢折腾，该密码未同步 chromebook 就被我重置了。之后发邮件给 GitHub 支持，他告诉我我还有一把 ssh key，后来从退役的本本上找到了这个 key，通过这个 key 把账号找回来了。找好所有权认定的方法有很多，我认为 ssh key 的方法很好。
既然你喜欢折腾，建议支持 fido https://fidoalliance.org/ 。

关于 public email 的问题，记得之前的 github 会提供一个 no replay 的伪邮件地址，现在不可选了，只能是 null。我目前特意将其设置为空。即使这样，我使用 github 账号登录 travis 也是没有问题的。按照你的说法，我的账号估计无法登录你的系统。有必要的话，你可以测试下这种情况。

@zingl 分区加密部分是应该的，但是个人单方面认为应该要注意的是应该避免使用神州网信版以及简体中文版（都是特供版）的 bitlocker。目前猜测 windows 繁体中文版不是特供版，但是安装的时候还是不要选简体中文的好。

@Tyanboot 怎么锁？ Windows 启动后自己再把它改回来？（ stackoverflow 上有人就是这么干的。。。）
还是 efishell 有相关的命令或者是你的主板支持？

@Osk 未遇到过 efi/boot/bootx64.efi 被替换掉的情况，倒是 Ubuntu 会安装该文件，估计 windows 启动修复会替换它吧。
启动流程具体是：使用另一个 boot manager （我选择的是 systemd boot ）替换掉 efi/boot/microsoft/bootmgrfw.efi ，然后用该 boot manager chain boot bootmgrfw.efi 重命名后的 bootw.efi 。
我发现只要从 efi shell 直接执行 bootmgrfw.efi （不管其是否被重命名） windows 都会还原 boot entry，以及 bootmgrfw.efi 本身，chainload bootmgrfw.efi 却不会。
签名部分目前我确实是签名了 MS 的 2 个证书和 intel 的一个证书（应该是更新固件要用到的，正应该有 intel 的证书在，我才不能确定是否能用 me_cleaner 清除 bios 固件中的 me，至少 me_cleaner 的 issue list 里面没有看到相同 nuc 的使用结果报告）。我的考量是，如果我签名(旧的 MS 签名会被替换掉）了 bootmgrfw.efi 等，Windows 也许不会替换它（比如假如神州网信版的签名也许就不是 MS 的签名呢？），那么我就可以用自己添加的 boot entry 启动 systemd boot 再用 system boot chainload 未被重命名的 bootmgrfw.efi 。如果可行的化，个人认为这比假装 bootmgrfw.efi 要好一点。