差生文具多 @差生文具多
7

很多墙外匿名站出于安全的角度,使用CDN隐藏真实IP,不幸的是有很多方法可以绕过CDN。

IPv4的总数是有限的(42亿个),网络上有很多扫描器在一刻不停的扫描,一天就可以过一遍全网IP。如果网站没有做好防御,这些扫描器就会找到IP地址上面对应的网站。很多扫描器的数据甚至是公开可查的。

幸运的是,只要做足防御,就完全不用担心源站IP泄露。这里科普一下防止源站IP泄露的方法。

设置防火墙

cloudflare会提供回源IP的名单,见https://www.cloudflare.com/ips/。我们要做的就是把这些IP全部添加进防火墙白名单。

这样除了cloudflare,其它一切ip就都没法连接服务器的https端口了。

防火墙白名单的具体规则是:

  1. 默认拒绝所有的入站IP。防火墙的拒绝模式有reject和drop两种,reject会明确返回一个拒绝信息,drop则直接丢弃入站包。我们要选deny而不是reject;
  2. 允许cloudflare的IP地址,从443端口连接服务器;
  3. 允许任意IP连接22端口,这是为了能SSH连上服务器。SSH加固是另外一个话题,这里暂且不提。

本文这里没有用防火墙限制出站连接,如果对安全有需求,也可以禁用所有的出站连接。通常而言,对入站规则做设置就足以防止IP扫描了。

我通常用的防火墙是nftables,在debian/ubuntu系统上,可以这样设置防火墙:

(1). 安装nftables

sudo apt install nftables

(2). 编辑nftables文件

sudo vim /etc/nftables.conf

然后写入如下的配置文件

flush ruleset

table inet firewall {
    chain inbound {
        type filter hook input priority 0; policy drop;
        ct state vmap { established : accept, related : accept, invalid : drop }
        iifname lo accept

        ip saddr {
            173.245.48.0/20,
            103.21.244.0/22,
            103.22.200.0/22,
            103.31.4.0/22,
            141.101.64.0/18,
            108.162.192.0/18,
            190.93.240.0/20,
            188.114.96.0/20,
            197.234.240.0/22,
            198.41.128.0/17,
            162.158.0.0/15,
            104.16.0.0/13,
            104.24.0.0/14,
            172.64.0.0/13,
            131.0.72.0/22
        } tcp dport { 443 } accept

        tcp dport 22 accept
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }
}

上面这个配置文件会:

  • 默认drop所有入站包
  • 默认drop所有转发包
  • 默认接受所有出站包
  • 接受所有来自cloudflare ip地址,向443端口建立的TCP连接
  • 接受全网IP向22端口连接
  • 允许本地环回上的连接(数据库和Apache等服务器需要)

(3). 最后保存配置并刷新

sudo nft -f /etc/nftables.conf

输入sudo nft list ruleset,如果显示上面的配置文件,就说明保存成功。

对nftables不熟的朋友,也可以用Ubuntu自带的ufw建立防火墙,安全性是一样的。

# 启用ufw
ufw enable

# 允许所有出站,禁止所有入站
ufw default allow outgoing 
ufw default deny incoming

# 允许22端口
ufw allow 22

# 允许cloudflare ip地址连接443
ufw allow from 173.245.48.0/20 to any port 443 proto tcp
ufw allow from 103.21.244.0/22 to any port 443 proto tcp

# (以下略)

打开cloudflare的客户端验证

按照上面的方法,就可以100%防止IP扫描。不过,黑客可以向cloudflare works上传脚本,利用cloudflare的IP地址去扫描。这种攻击形式很少见,不过,为了防止这种形式的探测,我们还要打开验证CF客户端证书。

具体而言,需要打开nginx配置里的以下选项:

ssl_verify_client on;
ssl_client_certificate /xxxxx/cloudflare_certificate.pem;

最后,需要让nginx拒绝无效请求,打开以下选项

ssl_reject_handshake on;

但是需要注意,最后这个指令只在1.19.4以上的nginx版本可用,你可能需要自己编译nginx。

其它注意事项

除了ip扫描,如果网站在配置CF前已经有了DNS记录,那么从这些DNS记录也可以匹配到源站IP。如果是全新的服务器,在配置完成之前,一定不要连上公网。

3

详细内容参考hCaptcha官方文档:https://docs.hcaptcha.com/

本文可作为教程和文档的补充。

使用hCaptcha前需要注册账号,注册完成后,会得到两个令牌

  • 一个令牌叫site key,是32个字符的uuid。site key放在前端,也就是需要插入到显示验证码的网页上,因此是可以公开的。

  • 另一个令牌叫Secret Key,是40位的16进制数。Secret Key放在后端,不可公开。

部署hCaptcha分两步:

  1. 在网页上插入hCaptcha控件,这段代码负责显示hcaptcha控件。比如说你希望在个人博客的评论区上添加验证码,就把这个控件放到发布按钮附近。

  2. 在服务器代码上部署后端验证代码,这段代码会把用户的验证码递交给hcaptcha服务器。比如你希望别人发布评论的时候填写验证码,就把后端验证代码添加进发布评论的逻辑里。

在hcaptcha验证过程中,存在三方:用户(填写验证码的人)、网站服务器(你要部署hcaptcha的服务器)、和hcaptcha的官方服务器。hcaptcha的工作流程是:

  1. 用户填写验证码;

  2. 验证码上传到网站服务器上,上传的内容称为Response;

  3. 网站服务器把Response和自己的Secret Key一起打包,发送给hcaptcha的官方服务器

  4. hcaptcha的官方服务器把验证结果发送给网站服务器

  5. 网站服务器根据验证结果,决定是否放行。

  6. 在网页上插入hCaptcha控件

1.1 首先在网页上引入hcaptcha脚本:

<scri src="https://js.hcaptcha.com/1/api.js" async defer></scri>

1.2 然后在欲展示验证码的位置,插入以下html

<diw class="h-captcha" data-sitekey="your_site_key"></diw>

(这里把script写作scri,div写作diw,防止被WAF拦截)

这里可以随意插入html,但必须满足以下三个要求:

  1. 必须包含“h-captcha”的类名;
  2. 必须包含“data-sitekey”的属性,属性值是你的site key;
  3. html内部必须是空值(在这里,div块之间不能有内容)

做完以上两步后,hcaptcha脚本就会自动在你的网页中插入验证码控件了,无需其它操作。

  1. 在后端引入hCaptcha验证

2.1 在用户提交请求时,携带Response

这需要修改提交请求的表单,因后端程序不同而异。

2.2 向hcaptcha服务器发起请求。

现在,后端需要打包Response和secret key,向hcaptcha服务器发起请求。

不同的后端语言,发起请求的方式不同,官方给出的例子是curl:

curl https://hcaptcha.com/siteverify \
  -X POST \
  -d "response=CLIENT-RESPONSE&secret=YOUR-SECRET"

hcaptcha的官方服务器返回的是json,取里面的“success”字段,如果是true,即为通过,反之不通过。

Python的例子如下(使用request)

def verify(secret, response) -> bool:
    # 用request发起post请求,表单数据里有secret和response两个字段
    r = requests.post('https://hcaptcha.com/siteverify', data={
        'secret': secret, 
        'response': response
    })
    
    # 从json里读取success字段
    valid = json.loads(r.text).get('success')
    if valid:
        return True
    else:
        return False

Rust语言的例子如下(使用Reqwest)


/// response: 前端提交的验证码
/// secret: secret key,需要保密
pub async fn verify_captcha(response: &str, secret: &str) -> Result<bool, std::io::Error> {
    use serde_derive::Deserialize;
    
    #[derive(Deserialize)]
    struct Response {
        success: bool,
        challenge_ts: String,
        hostname: String,
        error_codes: Option<Vec<String>>,
    }

    const URL: &str = "https://hcaptcha.com/siteverify";
    let form = [("response", response), ("secret", secret)];
    let client = reqwest::ClientBuilder::new().build()?;

    match client.post(URL).form(&form).send().await {
        Ok(resp) if resp.status().as_u16() == 200 => match resp.json::<Response>().await {
            Ok(r) if r.success => Ok(true),
            _ => Ok(false),
        },
        _ => Ok(false),
    }
}

在后端逻辑中加上上述的“verify”函数,就可以使用hcaptcha验证码了。

3

Cloudflare免费版提供不计上限的DDOS防护,几乎可以拦下100%的网络层DDOS攻击。然而,如果服务器的配置很差,那么即使是流量很小、不足以触发Cloudflare防护的HTTP DDOS攻击也可以使服务器宕机。

这里介绍一种防御HTTP DDOS攻击(也叫CC攻击)的方法,用Nginx的限速功能,拦截绕过Cloudflare的漏网之鱼。

Nginx使用漏桶算法限速,漏桶算法把传入请求看作往桶里注水,桶会以一定的速度往外漏水(放过合法请求),漏桶自身也有一定的容量,可以承受突发的注水(接受突发请求),如果桶满水就会溢出(拒绝超出限制的请求)。

Nginx使用漏桶算法限速用limit_req_zonelimit_req这两个指令。一个和cloudflare配合使用的例子如下:

http {

    limit_req_zone $http_cf_connecting_ip zone=my_limiter:20m rate=2r/s;

    server {

        limit_req zone=my_limiter burst=30;

    }
}

limit_req_zone指令的用途是分配内存,对每个来访问的IP,记录其一段时间内的访问次数,因此这个指令必须放在http块里。上面指令的意思是,设置一个新的限速器,命名为my_limiter,占用内存20MB,此限速器可接受的最大访问频率为每秒2次。

因为服务器套了cloudflare,所以nginx看到的是CF的IP,而不是用户的IP。cloudflare会把用户的IP放在cf_connecting_ip请求头里,可以用Nginx变量$http_cf_connecting_ip表示从http请求头中获取用户IP,对每个用户的IP进行限速。

注意这里的IP以文本形式记录,因此会浪费一些空间,不过20MB的内存足以支持数万的IP连接。

limit_req可以放在http、server、或location块里,表示指定该区域的可接受的突发请求速率。

nginx会把拦截的请求写入error.log,可以在日志看到nginx的拦截记录,被拦截的请求不会交给后端处理,而是返回503错误。

这样的配置足以防御一些小型的DOS攻击或者高频爬虫。

1

原文: https://blog.lilydjwg.me/2022/8/18/annoying-webpage-behaviors.216433.html

作者: 依云

有些网页的行为通常不被视为 bug,甚至是故意为之,但很令人讨厌。这里记录一些我所讨厌的网页「特性」。它们被归为两类,要么导致某些场景下用不了,或者用着很不方便,要么很打扰人。

可访问性问题

忽视系统、浏览器设置,在浏览器使用浅色主题的情况下默认使用深色主题,或者在浅色主题下代码部分使用深色主题。反过来问题不大,因为我有DarkReader

主体文本不支持选择和复制。选择和复制之后,用户能做很多事情,比如查生字、翻译、搜索相关主题。

已访问链接与未访问链接显示没有差别。

消除可交互元素(链接、按钮)的 outline。这个 outline 以前是虚线框,现在火狐改成了蓝色框,用于标识当前键盘交互的对象。

搜索框不支持回车确认,必须换鼠标点击。

位于文本框后的按钮不支持使用 Tab 键切换过去,并且 Tab 键在此文本框中也没有任何显著的作用。必须换鼠标点击。

需要交互的元素不能被 vimium 插件识别为可点击。这大概是使用非交互元素来处理交互事件,甚至事件监听器都不在元素本身上。

使用 JavaScript 实现原本可以直接用链接实现的内容(链接目标是某个 JavaScript 函数调用)。这导致我无法使用中键来在新标签页中打开。

显著不同的内容没有独立的 URL。尤其见于一些单页应用(SPA)。要到达特定内容(比如加书签或者分享给别人),就只能记录先点哪里、再点哪里等。

预设用户的屏幕大小,导致浏览器窗口过小的时候部分关键内容(如登录按钮)看不到、无法操作。

交互元素没有无障碍标签。成堆的「未加标签 按钮」。

通过 User-Agent 判断浏览器,并拒绝为某些 User-Agent 服务(但实际上去除这个限制之后,功能是完全没有问题的)。

当没有带声音自动播放权限时,无声播放主体内容(而非等待用户操作使其获得权限)。说的就是 Bilibili。

为大屏幕用户(如桌面用户)展示为手机屏幕设计的页面。这些页面中字体特别巨大,并且不能被浏览器缩放影响。交互元素上鼠标指针不改变为手状,甚至只支持触摸操作而不支持鼠标点击。

悬浮于主内容之上的「在App中打开」。点名批评 imgur。它的按钮不光挡住图片,而且用户放大图片的时候它也被放大,挡住更多图片内容。

不能禁用的图片懒加载,或者视频内容被移出画面、切换到后台就停止加载。点名批评 Telegram、维基百科。我等你加载呢,你非要我盯着看你加载浪费时间?现在网好,你赶紧给我加载好,进电梯或者地铁或者山洞了,我再慢慢看你的内容啊。

视频内容被移出画面就停止播放。点名批评知乎。我让你播放你就给我播放。我不看视频,是因为视频画面没啥可看的,可是我听音频部分呀。

覆盖浏览器的 Ctrl-F 查找快捷键,并不提供方案来避免覆盖。我就搜索当前页面,不要你的站内搜索功能。

注册前请务必先阅读用户条款和规则,用户条款和规则页面需登录后才可访问。

简体中文内容指定繁体中文的字体,或者添加繁体中文的标签。或者反过来。

打扰用户

在内容页面,任何会动的非主体内容,包括但不限于广告、内容推荐。形式可以是动态 GIF、滚动动画、视频等。用于首页渲染效果的背景动画和视频不算,作为主体内容者也不算。

针对非音视频网站,自动或者非用户明确表达地(比如在用户点击不相关内容时)播放带音频的内容。

消耗 CPU 的背景特效。如 canvas-nest。会让 CPU 很吵,也会浪费能源、加剧气候变化。

1

网站设计的四项基本原则——网站评点之一



·方舟子·

(原载《中国青年报》电脑周刊)

在开始正式评点网站之前,我需要先表明自己的评点标准,提出自己的“网站观”。网站观可以分成两派:一派是先锋派,更注重的是网站的艺术性,重视表面的设计更甚于实质的内容,尽量采用最新的技术,而不管现在还在普遍使用的各种浏览器是否都能支持这些技术。他们要求访问者迁就他们的设计,有的在第一页就预先声明:本网站需要用某某浏览器某某版某某分辨率阅读。那些未达其要求的访问者若扬长而去,对设计者来说似乎是无关痛痒的事。另一派是保守派,更注重的是网站的实用性,尽量与各种版本的浏览器兼容,尽可能多地争取访问者。

我是属于保守派的,如果嫌“保守”不好听,也不妨称为迎合大众的“实用派”,而把先锋派改叫孤芳自赏的“艺术派”。根据实用派的哲学,我提出网站设计的四项基本原则如下:设计简明实用,资料富有特色,内容定期更新,浏览普遍适用。下面再详细地讲一讲这四项原则。

一、设计简明实用。一个装潢精美、漂亮的网站,在访问者第一次访问时,也许能留下良好的第一印象,但第二次访问时,这种印象就要打大折扣,第三、第四……次之后,对设计艺术的印象也就等于零。所以,如果希望访问者能频频回访的话,大可不必在网站的艺术设计上煞费苦心,因为吸引回访靠的是内容而不是设计艺术,何况装潢的精美往往是以牺牲下载速度和浏览器的兼容性为代价的。因此之故,在评价一个网站时,我首先看其设计是否简明实用,而不是是否精美漂亮,值得特别注意的有几点:

  1. 不用大量的装饰性图象。现在绝大部分人还是通过电话线拨号上网,为避免这些人等得不耐烦,也为了避免加重网络负担,每一页装饰性图象的总量不要超过40K为宜。能用2色的不用16色,能用16色的不用256色或全色,分辨率也不应超过72dpi。有的网站迎面而来就是一幅大达几十上百K的全色题图,简直就是想把访问者拒之门外。

  2. 慎用背景。如果喜欢用背景的话,也应该用浅色的、图案简单的、若有若无的背景,以不影响读者阅读为准。许多网站喜欢用花哨的背景,也有的喜欢用黑色背景,对许多人的眼睛来说,都是难以忍受的。只要想想,世上的书几乎全都是白底黑字,也就不难明白其中的道理。

  3. 绝对不用背景音乐。许多人是在上班时间或三更半夜上网浏览的,进入某个网站后突然间乐声大作,是很令人尴尬的一件事。何况网页背景音乐的音响效果都非常差,喜欢边听音乐边浏览的人大可以自己用家中的音响播放。如果是手上有一首绝响不与人共享于心不忍,那也应该让访问者有选择是否播放的自由。

  4. 少用或者不用Java。我这不是存心跟SUN过不去。我承认Java有许多其他用途,我也承认若在网页上执行某些复杂的功能时也许Java有其优势,问题是,绝大多数的网站使用Java,不过是用来执行发布公告、更换图标、简单检索之类的简单功能,用Javascript或perl可以执行得更快、更好,用Java反而容易出错乃至导致死机,即使执行顺利,也要整台机器都停下等着它下载、执行(至少在我的机器上是这样的),令人难以容忍。有的人误以为在网站上使用Java可以让人觉得“很专业”,其实完全不是那么回事。会自己编写Java程序也许算得上专业,但是这些在网上使用的Java小程序到处都有现成的可抓,没有人会因为你用了它们就觉得有什么了不起。

二、资料富有特色。目前中文网站似乎有一种追求“大而全”的倾向,以为如果无所不包、面面俱到,就能吸引最广大读者。这个如意算盘本来也打得不错,但是在已有了许多大而全的网站之后,再加入你一个,又能有什么效果?何况许多网站的框架固然搭得很“大”,“全”却是未必的,毕竟不是人人都有那份精力。所以,在评价一个网站时,我更注重资料的“特而全”,先选一个还很少见的主题,然后再尽量地收集与之相关的资料。这样的网站,更有存在的价值,也更能拥有一批热心的读者。可惜在这方面,中文网站做得实在不够,举例来说,世界闻名的外国古典诗人都有一个或数个内容翔实甚至颇具专业性的网站,而我至今还没见到有屈原、陶渊明、李白、杜甫、苏轼的主题站点。

三、内容定期更新。做网站不是一锤子买卖,心血来潮做完了就可以从此弃之不顾。这个信息社会日新月异,有责任心的网站管理员应该随时删除过时的信息,增添新的内容。大型的网站应该一、两天更新一次,中型的网站应该一、两个月更新一次,小型的网站应该一、两季度更新一次,至少那些已过时的链接应该即时删除、更换。

四、浏览普遍适用。国内的网民也许都已经被IE征服,所以国内的网站基本上都是按IE的标准设计的。但是海外的网民大部分仍坚持使用Netscape。所以,网站的设计,应该同时兼顾这两种浏览器,而且不能只根据最新的版本设计,还要顾及前一个版本。那些只有某个浏览器或最新版本才具有的功能,就先不要使用。指定访问者使用某个版本的某种浏览器是很令人反感的,而更令人反感的是,有的网站竟然还要求访问者先下载特制的浏览软件才能阅读其网站。在这么做之前,不妨先想想:你的网站的魅力是否强到这种程度,读者乐意于为了阅读你的网站而特地去安装一个软件?

既然这四项基本原则还未被载入“网络宪法”强制执行,而且网站的连接速度也与访问者的所在位置有关,那么,在开始评价特定的网站之前,我觉得应该在本文的最后向读者交代一下我所在的位置和使用的操作系统及浏览器:我是在美国加州南部,用英文版视窗95和Netscape4.5上网的,外挂中文之星2.5阅读国标码,外挂南极星阅读大五码。

1999.3.13.

原文:Rust: A Critical Retrospective:https://www.bunniestudios.com/blog/?p=6375

翻译:机器之心/张汉东:mp.weixin.qq.com/s/eb_U2rirLjCqCLH8qs8k5Q

译者注:说明:国内机器之心公众号对这篇文章进行了编译,发布了标题为《编写完10万行代码,我发了篇长文吐槽Rust》的一篇文章,我看了以后发现机器之心的这篇文章对原文原意的传达并不正确与完整,并且省略了很多对 Rust 开发者有帮助的关键细节,比如,作者如何防范 Rust 供应链攻击等,以及 Rust 超出作者预期的优点有哪些。所以特此全文翻译,供大家参考。当然,也要感谢机器之心对这篇文章的传播,让我有机会看到此文。

由于在大流行期间我有几年无法旅行,所以我决定利用我新获得的时间并真正专注于 Rust。在编写了超过 10万行 Rust 代码之后,我想我开始对这门语言有了一种感觉,并且像每一个脾气暴躁的工程师一样,我已经形成了我自己的观点,因为这是互联网,所以我要分享。

我学习 Rust 的原因是充实 Xobs 编写的 Xous[2] OS 的一部分。Xous 是一个用纯 Rust 编写的微内核消息传递操作系统。它的近亲可能是 QNX[3]。Xous[4] 是为轻量级(物联网/嵌入式规模)安全优先平台(如 Precursor[5] )编写的,支持 MMU 以实现硬件强制的页面级内存保护。

在过去的一年里,我们设法为操作系统增加了很多功能:网络(TCP/UDP/DNS)、中间件图形抽象(用于模版和多语言文本)、存储(以加密的、看似可否认的数据库的形式,称为PDDB[6])、可信启动,以及具有自配置和密封(sealing)属性的密钥管理库。

我们决定编写自己的操作系统而不是使用 SeL4、Tock、QNX 或 Linux 等现有实现的原因之一是我们想真正了解我们设备中的每一行代码在做什么。特别是对于 Linux,它的源代码库是如此庞大和动态,即使它是开源的,你也不可能审计内核中的每一行。代码更改的速度比任何人都可以审计的要快,除非是自己开发的。Xous的范围也很窄,只支持我们的平台,以尽可能地保持内核中不必要的复杂性。

范围狭窄意味着我们还可以充分利用CPU运行在FPGA中[7]的优势。因此,Xous的目标是一个不寻常的RV32-IMAC配置:一个有MMU+AES扩展的配置。毕竟是2022年,而且晶体管很便宜:为什么我们所有的微控制器都不像桌面上的同类产品那样具有页级存储器保护功能?作为一个FPGA,也意味着我们有能力在硬件层面修复API错误,使内核更加精简和简化。这在通过抽象破坏(abstraction-busting)过程的工作中尤其重要,比如从RAM中挂起和恢复。但这都是另一篇文章的内容:这篇文章是关于Rust本身,以及它如何作为Xous的系统编程语言。

Rust 的「卖点」

在我们启动Xous的时候,我们看了大量的系统编程语言,Rust脱颖而出。尽管它的 "no-std "支持在当时还不成熟,但它是一种强类型、内存安全的语言,拥有良好的工具和一个蓬勃发展的生态系统。我个人是强类型语言的超级粉丝,内存安全不仅对系统编程有好处,它还能让优化器更好地生成代码,此外它还能让并发性不那么可怕。实际上,我希望Precursor有一个CPU,它对标记指针和内存能力有硬件支持,类似于在CHERI[8]上所做的,但在与做CHERI的团队讨论后,显然他们非常专注于使C语言变得更好,没有带宽来支持Rust(尽管这可能正在改变[9])。从总体上看,C语言对CHERI的需求远远大于Rust对CHERI的需求,所以这是一个公平的资源优先排序。然而,我是一个安全方面的粉丝,所以我仍然希望有一天,硬件强制的胖指针会进入Rust。

虽然如此,我并不打算回到C语言阵营,只是为了踢一踢硬件改造的"轮胎",以弥补C语言的一个糟糕的方面。Rust 光鲜的手册还宣传它能够通过其严格的 「借用检查器」在错误发生之前就加以预防。此外,它的发布理念应该是为了避免我所说的 「Python的问题」:“如果你不主动跟上语言的最新版本,你的代码就会停止工作”。另外,与Python不同的是,Rust并非天生就不卫生,因为宣传的安装包的方式也不是错误的安装包的方式。与Python相反,在Python中,关于包的官方文档会引导你把它们添加到系统环境中,但却会被Python的“长老们”骂:“但你当然应该使用venv/virtualenv/conda/pipenv/...,大家都知道”。如果这个细节没有被归入官方教程的16章中的第12章[10],我对Python的体验会好得多。当有人取消发布一个流行的包时,Rust 也应该比 Node 更好地避免“哎呀,我删除了互联网”问题,至少如果你为你的包使用完全指定的语义版本。

从长远来看,Xous背后的哲学是,最终它应该 "变得足够好",到那时我们就应该停止对它的操纵。我相信,工程师的使命就是最终把自己的工作搞好:系统应该变得足够稳定和牢固,以至于它 "只是能用",没有任何注意事项。在这一点上,任何额外的工程都只会增加错误或臃肿。Rust的 "稳定就是永恒 "的理念,以及承诺永远不破坏向后兼容的理念,从让Xous变得如此完美,以至于不再需要我这个工程师的角度来看,是非常一致的,从而使我能够将更多的时间和精力用于支持用户和他们的应用程序。

Rust 欠打磨的地方

网上已经有很多写给 Rust 的「情书」了,所以,我打算先列举我遇到的一些 Rust 的缺陷。

语法中的噪音(Line Noise)

这是一个肤浅的抱怨,但我发现 Rust 的语法很密集、很沉重,而且难以阅读,就像试图阅读附带噪音的UART输出一样:

Trying::to_read::<&'a heavy>(syntax, |like| { this. can_be( maddening ) }).map(|_| ())?;

用更通俗的话说。上面这句话的作用是在对象(实际上是结构体')Trying上调用一个名为to_read的方法,其类型注释为&heavy,生命周期为 'a,参数为 syntax,闭包的参数为like,在另一个名为 this 的结构体实例上调用can_be方法,参数为 maddening,任何非错误返回值都映射到Rust单元类型(),如果有错误,会被自动unwrap并返回给调用者。

深呼吸。当然,我有一些地方是错的,但你会明白这种语法有多密集。

在此基础上,你可以将宏和指令分层,而这些宏和指令不需要遵循Rust的其他语法规则。例如,如果你想条件编译代码,你可以使用一个指令,如:

#[cfg(all(not(baremetal), any(feature = “hazmat”, feature = “debug_print”)))]

这就是说,如果启用了 hazmat 或 debug_print 特性(feature),而且你不是在裸机上运行,就使用下面的代码块(我肯定也弄错了)。对我来说,这个语法最令人困惑的部分是使用单一的=来表示等价而不是赋值,因为,配置指令中的东西不是Rust代码。它就像一种独立的元语言,有一个你可以查询的键值对的字典。

我甚至不打算讨论Rust宏的不可读性--即使我自己写了一些Rust宏,我也不得不承认,我觉得它们 "只是勉强能用",而且可能在它们的某个地方有“龙”(Bug)。这不是你在一门自称可靠的语言中应该有的感觉。是的,这是我的错,因为我不够聪明,无法解析语言的语法,但同时,我的生活中还有其他事情要做,比如构建硬件。

无论如何,这是一个肤浅的抱怨。随着时间的流逝,我最终克服了学习曲线并变得更加自在,但这是一条艰难而陡峭的曲线。这部分是因为所有的 Rust 文档要么是用eli5 风格[11]编写的(形容文档写的非常简陋),要么你会看到一个正式的语法定义[12](从技术上讲,定义一个“feature”在那里,但没有用简单的英语概括)。

要说明的是,我非常同情写好文档有多难,所以这不是在挖苦那些努力写出这么多优秀语言文档的人。我真的很欣赏文档生态系统的总体质量和丰富性。

Rust只是在语法方面有一个陡峭的学习曲线(至少对我来说)。

Rust 虽然强大,但并不简单

Rust 很强大。我很欣赏它的标准库,它包含了 HashMaps、Vecs 和 Threads 等数据结构,既“美味”又令人上瘾。一旦我们在 Xous 中获得了 std 支持,就再回不去了。来自 C 和汇编的背景,Rust 的标准库感觉丰富且有用。我读过一些负面评价,说它缺乏一些功能,但就我的目的而言,它确实达到了最佳状态。

话虽如此,我对 Rust std 库的依赖并没有在构建可审计的代码库方面带来任何好处。我以前对Linux的批评之一是:“天哪,内核的源代码包括红黑树的实现,怎么会有人来审计它呢”。

现在,在写过操作系统之后,我对这些丰富的动态数据结构的重要性有了深刻的理解。然而,Xous 没有在其存储库中包含 HashMap 的实现这一事实并不意味着我们比 Linux 更简单:事实上,我们只是把一大堆代码“隐藏”了起来。仅仅是标准库的 "collection "部分就代表了大约1万多行源代码,而且复杂度非常高。

因此,虽然 Rust 的 std 库允许 Xous 代码库专注于成为内核而不是其自己的标准库,但从构建最小攻击面、“完全由一个人可审计”代码库的角度来看,我认为我们对 Rust 的 std 库的依赖意味着我们在这个目标上失败了,尤其对于我们需要继续跟踪 Rust 的最新版本(我将在下一节中解释为什么我们必须这样做)来说。

理想情况下,在某些时候,事情会 "稳定下来",我们可以把Rust 仓库分叉,然后说 "这是我们的攻击面,我们不打算改变它"。即便如此,Rust std 存储库的大小仍使 Xous 存储库相形见绌,这还不包括编译器本身的复杂性。

Rust 还未完善

接下来的这一点与Rust还不适合做完全可审计的内核的原因相吻合:语言还未完善。例如,在我们编写Xous的时候,引入了常量泛型(const generic)。在这之前,Rust没有处理大于32个元素的数组(Array)的能力。这种限制有点让人抓狂,即使在今天也有一些缺点,比如Default trait 无法初始化大于32个元素的数组。这种阻碍导致我们把许多东西限制在32个元素:例如,当我们在进程之间传递 SSID 扫描的结果时,该结构只为最多 32 个结果保留空间,因为去更大、更多通用结构是不值得的。这是直接驱动面向用户的功能的语言级别限制。

另外,在编写Xous的过程中,像内联汇编(inline assembly)和工作空间(workspaces)这样的东西终于成熟了,这意味着我们需要回到过去,重新审视我们所做的一些“危险”的事情,使那些关键的几行用汇编编写的初始启动代码能够集成到我们的构建系统中。

我经常问自己“我们什么时候才能离开 Rust 发布火车(火车式发布)”,我认为的答案是他们最终让alloc稳定下来。目前,no-std target 无法访问堆,除非它们跳上“Nightly”列车,在这种情况下,你又回到了 Python 式的噩梦,你的代码经常因语言版本而中断。

我们绝对给了用no-std和 Stable Rust编写操作系统一个公正的机会。Xous第一年的开发都是用no-std完成的,在内存空间和复杂性方面付出了代价。我们有可能只用预先分配好的静态数据结构来编写操作系统,但我们必须在所有情况下满足最坏情况下的元素数量,这导致了臃肿。此外,我们还不得不推出很多自己的核心数据结构。

大约一年前,当Xobs将Rust的std库移植到Xous时,这一切都改变了。这意味着我们能够在稳定的Rust中访问堆,但这是有代价的:现在Xous被捆绑在一个特定的Rust版本上,因为每个版本的Rust都有自己独特的std打包版本。这个版本的绑定是有原因的:std是可以将内存分配和线程创建等基本 Unsafe 的硬件结构变成 Safe 的Rust结构的地方。(我最近还了解到一个有趣的事实。Rust对于大多数 target 没有本地分配器--它只是简单地使用libc的malloc()和free()函数!) 换句话说,Rust能够有力地保证稳定版本的“火车”不破坏旧的功能,部分原因是所有的松散部分都被扫进了std。

我必须不断提醒自己,拥有 std 并不能消除关键代码中严重安全漏洞的风险——它只是将许多关键代码移到了标准库中。是的,它是由一群比我聪明的天才程序员维护的,但归根结底,我们都只是人类,我们都是软件供应链攻击的公平目标。

Rust有一个发条式的发布时间表:每六周就会推送一个新版本。由于我们的 "std "分叉与特定的Rust版本相联系,这意味着每六周,Xobs都要承担更新我们的分叉并为其建立新的 "std "版本的艰巨任务(我们不是Rust的一级平台,这意味着我们必须维护自己的 "std "库)。这意味着我们同样迫使所有Xous开发者在他们的工具链上运行rustup update,这样我们才能保持与语言的兼容性。

这可能是不可持续的。最终,我们需要锁定代码库,但我没有一个明确的退出策略。也许我们可以考虑回到 "nostd "的下一个时间点,就是我们可以获得稳定的 "alloc "功能,这让我们可以再次访问堆。这样我们就可以把Xous从Rust发布的列车上解开,但我们仍然需要回填一些功能,如 Vec、HashMap、Thread和 Arc/Mutex/Rc/RefCell/Box结构,使 Xous 能够有效地进行编码。

不幸的是,alloc' crate 非常难,而且已经开发了很多年了。虽然如此,我真的很欣赏Rust在开发这一功能背后的透明度,以及为稳定这一功能所做的努力和思考。

译者注:这一点,也许学习一下 Android 和 Fuchsia 如何引入 Stable Rust 工具链会对他有所启发。当然,因为 Xous 是纯 Rust 实现,而 Android 和 Fuchsia 是部分模块或组件用 Rust,后者可能没有 Xous 的麻烦。

Rust 对供应链安全的观点有局限

我认为这一立场被rustup.rs安装页面推荐的安装方法很好地概括了: “嗨,在你机器上运行这个来自随机服务器的 shell 脚本。”

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

公平地说,你可以下载脚本并在运行前检查它,这比 Windows .MSI安装程序的vscode要好得多。然而,这种做法充斥着整个构建生态系统:每当你从crates.io Pull 一个新的crate时,一个名为build.rs的桩代码就有可能被编译和执行。这一点,加上 "宽松 "的版本定位(你可以指定一个版本,例如,简单的 "2",这意味着你将抓取任何最新发布的版本,主要版本为2),使我对通过crates.io生态系统发起软件供应链攻击的可能性感到不安。

Crates.io还受到一种错别字的影响,很难确定哪些是 "好 "的,哪些是 "坏 "的;一些名字和你想要的一模一样的 crate,结果只是旧的或被放弃的早期尝试,给你提供了你想要的功能,而更受欢迎的、积极维护的 crate 不得不采取不太直观的名字,有时与其他 crate 只有一两个字符的差别(公平地说,这不是Rust的包管理系统特有的问题)。

还有一个事实是,依赖关系是链式的--当你从crates.io Pull 一个东西的时候,你也 Pull 了该crate的所有附属依赖关系,以及所有最终会在你的机器上运行的build.rs脚本。因此,仅仅审核Cargo.toml文件中明确指定的crate是不够的,你还必须审核所有依赖的crate,以防止潜在的供应链攻击(upply chain attacks)。

幸运的是,Rust允许你使用 Cargo.lock 文件将 crate 固定在一个特定的版本上,你可以完全指定一个依赖 crate ,直到次要版本。在Xous中,我们试图通过发布Cargo.lock文件和指定所有第一阶的依赖 crate 到次要版本的政策来缓解这一问题。我们还对某些 crate 做了本地备份(vendored)和 forked,否则会使我们的依赖树增长而没有什么好处。

这就是说,我们的大部分调试和测试框架都依赖于一些相当花哨和复杂的 crate,这些crate Pull 了大量的依赖关系,而令我懊恼的是,即使我试图为我们的目标硬件运行一个构建,用于在主机上运行模拟的依赖 crate 仍然被 Pull 了下来,build.rs脚本即使没有运行,至少也被构建了。

针对这种情况,我写了一个叫 crate-scraper[13]的小工具,它可以下载Cargo.toml文件中指定的每一个源码包,并将它们存储在本地,这样我们就可以有一个用于构建Xous版本的代码快照。它还可以进行快速的 "分析",即搜索名为build.rs的文件,并将它们整理成一个文件,这样我就可以更快速地通过grep来寻找明显的问题。当然,人工审查并不是检测嵌入build.rs文件中的巧妙伪装的恶意软件的实用方法,但它至少让我了解我们正在处理的攻击面的规模: 它是令人惊叹的[14],大约有5700行来自不同第三方的代码,它们操纵文件、目录和环境变量,并且在我每次进行构建时在我的机器上运行其他程序。

我不确定这个问题是否有好的解决方案,但是,如果你是超级偏执狂,而且你的目标是能够构建可信赖的固件,那么就要警惕Rust的广泛的软件供应链攻击面。

你无法重现(reproduce)别人的 Rust 构建

我对Rust的最后一个问题是,在不同的计算机之间,构建是不可重现的(如果我们禁用我在Xous中为$reasons而嵌入的时间戳,它们至少在同一台机器上的构建之间是可重现的)。

我认为这主要是因为Rust将源代码的完整路径作为二进制文件中的恐慌(panic)和调试(debug)字符串的一部分拉进来。这导致了一些不舒服的情况,我们在 Windows 上构建了工作,但在 Linux 下失败了,因为我们的路径名在两者上的长度非常不同,这会导致一些内存对象在目标内存中移动。公平地说,这些失败都是由于我们在 Xous 中存在的错误,这些错误已经得到修复。但是,知道我们最终会有用户向我们报告我们无法重现的错误,这感觉并不好,因为他们在构建系统上的路径与我们的不同。对于想要通过构建自己的版本并将哈希值与我们的哈希值进行比较来审核我们发布的用户来说,这也是一个问题。

在Rust的维护者那里有一些bug,以解决可重复构建的问题,但由于他们必须处理语言中的许多问题,我对这个问题能否很快得到解决并不感到乐观。假设导致不可重现性的唯一原因是二进制文件中包含了操作系统的路径,那么解决这个问题的一个办法就是重新配置我们的构建系统,使其在某种chroot环境或虚拟机中运行,以一种几乎任何人都能重现的方式修复路径。我说 "几乎任何人 "是因为这个修复方法将取决于操作系统,所以我们将能够在例如Linux下获得可重复的构建,但它不能帮助Windows用户,因为chroot环境不是一个东西。

Rust 超乎预期的地方

尽管这里列出了所有的抱怨,但我认为如果我必须重新做一遍,Rust 仍然是我用于 Xous 的有力竞争语言。我做过 C、Python 和 Java 的大型项目,所有这些项目最终都背负着“不断增加的技术债务”(可能有一个软件工程师的术语来描述这种情况,我只是不知道)。问题往往是从一些数据结构开始的,我在第一遍的时候不能完全弄好,因为我还不知道这个系统是如何组成的;所以为了弄清楚这个系统是如何组成的,我就用一个半生不熟的数据结构拼凑出一些代码。

于是就开始陷入混乱:一旦我对事情的运作有了一个概念,我就回去修改数据结构,但现在在其他地方出现了一些未曾预料到的、微妙的破坏。也许这是一个逐个击破的问题,或者一个符号的极性似乎被颠倒了。也许这是个轻微的竞态条件,很难说清楚。没关系,我可以通过把<=改成<,或者修改符号,或者增加一个锁来解决这个问题。我仍然在充实这个系统,对整个结构有一个概念。最终,这些小的 hack 代码(意指非正规写法,只图完成功能)往往会转移到每一个依赖的模块中,因为事情的全部原因是由于 "作弊 "而产生的;当我回去切除这些 hack 代码时,我最终得出结论,它不值得努力,所以下一个最好的选择是把整个事情烧掉重写...但不幸的是,我们已经落后于计划和预算,所以重写从未发生,而hack代码继续生存。

Rust是一种很难编写代码的语言,因为它使这些 "作弊 "变得很难:只要你有纪律,不使用 Unsafe 的结构来使作弊变得容易。然而,真正的困难并不意味着不可能--在构建Xous的过程中,肯定有一些作弊行为被掩盖了起来。

这就是 Rust 真正超出我预期的地方。该语言的结构和工具非常擅长追捕这些作弊并对重构代码库有帮助,从而能达到“治愈癌症而不杀死患者”的效果,可以这么说。这就是 Rust 非常严格的类型和借用检查器将生产力负债转换为生产力资产的点。

我把它比作在穿过建筑物的复杂电缆束中更换电缆。在 Rust 中,可以保证电缆槽中的每一根线,无论线束变得多么复杂和糟糕,都是可分离的,并且两端都有清晰的标签。因此,您始终可以“拉到一端”并通过更改结构中元素的类型或方法的返回类型来查看另一端在哪里。在较不严格类型的语言中,您不会获得此属性;电缆可以在电缆槽内的某处合并并相互影响,因此在进行更改后,您只能通过手动测试“嗡嗡作响”每条电缆。即使这样,您也永远无法确定当有人打开浴室灯时,您更换的东西是否会导致咖啡机关闭。

这里有一个能说明Rust的重构能力在Xous中的作用的示例。在我们的图形子系统(我称之为GAM(Graphical Abstraction Manager[15]))中,处理信任级别的方式有一个问题。系统中的每个Canvas都有一个u8'分配给它,这是一个信任等级。当我开始写GAM时,我只知道我想要一些关于Canvas的可信任度的概念,所以我添加了这个变量,但并不确定它到底会被如何使用。几个月后,系统增加了带布局的上下文概念,布局是定义特定类型互动的多画布结构。现在,你可以有多个信任等级与一个上下文相关联,但我已经忘记了我之前放在Canvas结构中的信任变量--并且在上下文结构中也添加了另一个信任等级数字。你可以看到这是怎么回事:只要我有简单的测试案例,一切都能正常工作,但当我们开始在应用程序上弹出窗口,然后在窗口之上的菜单等等,疯狂的行为开始显现,因为我已经混淆了信任值的存储位置。有时我在更新Context中的值,有时我在更新Canvas中的值。它有时会表现为一个逐个击破的错误,有时则表现为一个并发错误。

这一直是困扰我的一件难以描述的事,而GAM已经成长为一个有许多移动部件的5千行的畸形代码。最后,我决定必须对此做些什么,但我真的不希望这样做。我认为我搞砸了什么,这次调查将以重写整个模块而告终。

幸运的是,Rust给我留下了一根小小的绳子。Clippy,也就是Rust中的 "linter",在我认为应该使用信任度变量的地方发出了一个警告--我在Context中存储了它,但之后没有人提到它。这很奇怪--它应该在每次重绘上下文时都是必要的!因此,我开始删除变量。所以,我开始删除这个变量,看看有什么问题。这很快让我想起,当画布被创建时,我也在画布内存储了信任度,这就是为什么我有这个悬空的引用。一旦我有了这个线索,我就能够重构信任的计算,只参考那个基础真理的来源。这也让我发现了其他一直潜伏着的错误,因为事实上我从来没有行使过一些我认为是常规使用的代码路径。经过几个小时的探究,我对这一切是如何运作的有了清晰的认识,我用简单易懂的API重构了信任计算系统,而不必折腾整个代码库。

这只是我在维护Xous代码库时使用Rust的许多积极经验之一。这是我第一次抬头挺胸,以积极的态度走进一个大版本,因为这是第一次,我觉得也许我有机会能够以诚实的方式处理困难的bug。我花在脑子里找借口的时间越来越少,以证明为什么事情是这样做的,为什么我们不能接受那个 Pull Request,而花更多的时间思考所有的事情可以变得更好,因为我知道Clippy在支持我。

对看此篇文章的 Rust 开发者的告诫

无论如何,对于一个硬件人(指作者本人)来说,这是很多关于软件的吐槽。很快就会有软件开发者提醒我,首先,我做的是电路和铝壳,而不是写代码的,所以我没有资格抱怨软件。他们是对的。我实际上没有接受过“以正确的方式”编写代码的“正式”培训。当我在大学时,我学习了麦克斯韦方程,而不是算法。我永远不可能成为一名专业的程序员,因为我连最简单的编码面试都过不了。不要让我写链表:我已经知道我不知道如何正确地去做;你不需要向我证明这一点。这是因为每当我发现自己在写一个链表(或任何其他基础数据结构)时,我都会立即停下来,质疑所有让我走到那一步的人生选择:这不是库的用途吗?难道我真的需要重新发明轮子吗?如果在编码面试中表现出色与实际编码能力之间存在任何关联,那么您绝对应该对我的意见持保留态度。

尽管如此,在花了几年时间使用Rust并阅读了无数关于该语言的文章之后,我觉得也许发表一篇关于该语言的批判性观点的文章会让人耳目一新。

参考资料

[1] Rust: A Critical Retrospective:https://www.bunniestudios.com/blog/?p=6375: https://www.bunniestudios.com/blog/?p=6375

[2] Xous: https://betrusted.io/xous-book/

[3] QNX: https://en.wikipedia.org/wiki/QNX

[4] Xous: https://github.com/betrusted-io/betrusted-wiki/wiki

[5] Precursor: https://precursor.dev/

[6] 称为PDDB: https://www.bunniestudios.com/blog/?p=6307

[7] CPU运行在FPGA中: https://github.com/betrusted-io/betrusted-soc

[8] CHERI: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

[9] 正在改变: https://gankra.github.io/blah/fix-rust-pointers/

[10] 第12章: https://docs.python.org/3/tutorial/venv.html

[11] eli5 风格: https://doc.rust-lang.org/rust-by-example/attribute/cfg.html

[12] 正式的语法定义: https://doc.rust-lang.org/reference/conditional-compilation.html

[13] crate-scraper: https://github.com/betrusted-io/crate-scraper

[14] 令人惊叹的: https://github.com/betrusted-io/crate-scraper/blob/main/builds.rs

[15] Graphical Abstraction Manager: https://github.com/betrusted-io/xous-core/tree/main/services/gam

如题,听说洗地是底薪+每平米5角加成,多洗多赚,清场是每月定薪+退职补助,固定工资。

缺点是工资被拖欠不敢讨薪,会被其他同事洗地的洗地,被清场的清场。