按照 GitLab 上的教程试着把 gitlab-runner 部署到 k8s 集群上，发现异常地简单，所以简单做个笔记： 编辑 values.yaml gitlabUrl: GITLAB_URL runnerRegistrationToken: "REDACTED" rbac: create: true 此处的信息按照 “Set up a specific Runner manually” 下面的提示填写。然后用 Helm 进行安装： $ helm repo add gitlab https://charts.gitlab.io $ kubectl create namespace gitlab-runner $ helm install --namespace gitlab-runner gitlab-runner -f values.yaml gitlab/gitlab-runner 然后去 Kubernetes Dashboard 就可以看到部署的情况，回到 GitLab 也可以看到出现了“Runners activated for this project” ，表示配置成功。 参考配置：https://docs.gitlab.com/runner/install/kubernetes.html
用 Kubernetes 部署无状态服务
背景 最近需要部署一个用来跑编译的服务，服务从 MQ 取任务，编译完以后提交任务。最初的做法是包装成 docker，然后用 docker-compose 来 scale up。但既然有 k8s 这么好的工具，就试着学习了一下，踩了很多坑，总结了一些需要用到的命令。 搭建 Docker Registry 首先搭建一个本地的 Docker Repository，首先设置密码： $ mkdir auth $ htpasswd user pass > auth/passwd 然后运行 registry： $ docker run -d -p 5000:5000 \ --restart=always \ --name registry \ -v "$(pwd)/registry":/var/lib/registry \ -v "$(pwd)/auth":/auth \ -e "REGISTRY_AUTH=htpasswd" \ -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm" \ -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd \ registry:2 简单起见没有配 tls。然后吧本地的 image push 上去： $ docker tag $image localhost:5000/$image $ docker push localhost:5000/$image 这样就可以了。
用 jailkit 限制用户仅 scp
最近需要用 scp 部署到生产机器，但又不想出现安全问题，所以用了 jailkit 的方法。首先是创建单独的用户，然后生成 ssh key 来认证，不再赘述。此时是可以 scp 了，但用户依然可以获得 shell，不够安全。 然后找到了下面参考链接，大概摘录一下所需要的命令和配置： mkdir /path/to/jail chown root:root /path/to/jail chmod 701 /path/to/jail jk_init -j /path/to/jail scp sftp jk_lsh jk_jailuser -m -j /path/to/jail jailed_user vim /path/to/jail/etc/jailkit/jk_lsh.ini # Add following lines [jailed_user] paths = /usr/bin, /usr/lib exectuables = /usr/bin/scp 之后可以发现该用户的 shell 已经更改 jk_chrootsh，并且只能用 scp。 参考：https://blog.tinned-software.net/restrict-linux-user-to-scp-to-his-home-directory/
每周分享第 56 期
咕咕咕 SystemVerilog linter https://github.com/dalance/svlint 东北方言编程语言 https://github.com/zhanyong-wan/dongbei JS LaTeX 渲染到 HTML https://github.com/michael-brade/LaTeX.js 一种对语音助手的攻击 https://surfingattack.github.io/ 在线打铃网站 http://thulpwan.net/timer/ 网络学堂 PC 端 App https://github.com/jiegec/learn_tsinghua_app/releases Rust 2020 roadmap https://github.com/rust-lang/rfcs/pull/2857/files
在 Vivado 中对 chisel3 产生的 verilog 代码仿真
默认情况下，chisel3 生成的 verilog 代码在 Vivado 中仿真会出现很多信号大面积变成 X。解决方法在一个不起眼的 Wiki 页面：Randomization flags： `define RANDOMIZE_REG_INIT `define RANDOMIZE_MEM_INIT `define RANDOMIZE_GARBAGE_ASSIGN `define RANDOMIZE_INVALID_ASSIGN 在生成的 verilog 前面加上这四句，就可以正常仿真了。
通过 BSCAN JTAG 对 Rocket Chip 进行调试
前言 在上一个 post 里研究了原理，今天也是成功在 Artix 7 上实现了调试。效果如下： OpenOCD 输出： Info : JTAG tap: riscv.cpu tap/device found: 0x0362d093 (mfg: 0x049 (Xilinx), part: 0x362d, ver: 0x0) Info : datacount=1 progbufsize=16 Info : Disabling abstract command reads from CSRs. Info : Examined RISC-V core; found 1 harts Info : hart 0: XLEN=32, misa=0x40801105 Info : Listening on port 3333 for gdb connections GDB 输出： Remote debugging using localhost:3333 0x0001018c in getc () at bootloader.
研究 Rocket Chip 的 BSCAN 调试原理
前言 最近 @jsteward 在研究如何通过 JTAG 对 FPGA 里的 Rocket Chip 进行调试。之前 @sequencer 已经做了一些实践，我们在重复他的工作，同时也研究了一下这是怎么工作的。 原理 我们从 @sequencer 得到了一份可用的 Scala 代码 和 OpenOCD 配置，并且了解到： 可以通过 openocd 找到并调试 Rocket Chip openocd 是通过 JTAG 向 FPGA 的 TAP 的 IR 写入 USER4，然后往 DR 写入特定格式的数据，然后控制 Rocket Chip 的 JTAG。 这里涉及到一个“封装”的过程，在一个仅可以控制 DR 的 JTAG 中控制另一个 JTAG。首先可以找到 OpenOCD 端的操作代码： tunneled_ir[3].num_bits = 3; tunneled_ir[3].out_value = bscan_zero; tunneled_ir[3].in_value = NULL; tunneled_ir[2].num_bits = bscan_tunnel_ir_width; tunneled_ir[2].out_value = ir_dtmcontrol; tunneled_ir[1].in_value = NULL; tunneled_ir[1].
在 macOS 烧写 Artix7 FPGA
首先安装好 openocd： brew install openocd --HEAD 测试所用版本为 0.10.0+dev-01052-g09580964 (2020-02-08-15:09)。 然后编写如下的 openocd.cfg： adapter driver ftdi adapter speed 10000 ftdi_vid_pid 0x0403 0x6014 ftdi_layout_init 0x0008 0x004b source [find cpld/xilinx-xc7.cfg] init xc7_program xc7.tap pld load 0 /path/to/bitstream.bit shutdown 上面的 ftdi 开头的两行按照实际的 JTAG Adapter 修改。可以参考 openocd 自带的一些 cfg。 然后在 openocd.cfg 的目录运行 openocd 即可： $ openocd Open On-Chip Debugger 0.10.0+dev-01052-g09580964 (2020-02-08-15:09) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Info : auto-selecting first available session transport "jtag".
在 macOS 上带执行权限 mmap 一个已删除文件遇到的问题和解决方案
背景 实验环境：macOS Catalina 10.15.2 最近在 rcore-rs/zircon-rs 项目中遇到一个比较玄学的问题，首先需求是在 macOS 的用户进程里开辟一段地址空间，然后把这个地址空间多次映射（权限可能不同、同一块内存可能被映射到多个地址），通过 mmap 模拟虚拟地址的映射。采用的是如下的方案： 在临时目录创建一个文件，把文件大小设为 16M（暂不考虑扩容） 需要映射一个虚拟地址到物理地址的时候，就对这个文件的物理地址偏移进行 FIXED 映射，虚拟地址就是期望的虚拟地址。 这样的方案在 Linux 下运行地很好，但在 macOS 下总是以一定概率在第二部出现 EPERM。网上搜了很多，但也没搜到相关的信息，于是自己断断续续地研究了一下，现在有一个比较初步的结果。 TL；DR 先说结论：调用一个带 PROT_EXEC 并且映射文件的 mmap 时，macOS 会进行安全检测，如果此时发现文件在文件系统上消失了，它会认为这可能是一个恶意软件行为，进行拦截，返回 EPERM。 而代码实际上在第一步和第二步之间，把临时目录删了：由于进程持有 fd，所以文件并不会真的删掉，当软件退出的时候文件自然会删除，这是临时文件的常见做法（见 tmpfile(3)）。 研究过程 查看 Console 在网上一番搜索未果后，就尝试在 Console 里面寻找信息。照着程序名字搜索，可以找到一些信息： temporarySigning type=1 matchFlags=0x0 path=/path/to/executable 这是编译这个 executable 的时候出现的，好像也没啥问题。然后解除过滤，在这个信息前后按照 syspolicyd 寻找： initiating malware scan (... info_path: /path/to/temp/file proc_path: /path/to/executable) Unable (errno: 2) to read file at <private> for process path: <private> library path: <private> Disallowing load of <private> in 50001, <private> Library load (/path/to/temp/file) rejected: library load denied by system policy 这几条记录比较可疑，每次运行程序，如果跑挂了，就会出现这几条，如果没跑挂，就不会出现这一条。所以很大概率是被 macOS 拦截了。错误信息的用词是 library，所以大概率是被当成加载动态库了，但既然内容是空的，所以我想的是文件名触碰到了什么奇怪的规则，然后文件名又是随机的，随机导致 EPERM 是概率性出现的，这好像很有道理。于是我把 tmpfile 换成了固定的路径，忽然就好了。但固定的路径只能保证同时只有一个程序在跑，如果路径拼接上 pid，怎么删，谁来删又是一个问题。虽然可以放到 /tmp 下面然后随便搞，但 /tmp 的回收并不是那么积极，在临时目录下丢太多文件也会出现问题。
每周分享第 55 期
一个月后终于复更 退出 vim 教程 https://github.com/hakluke/how-to-exit-vim SHA-1 攻击新进展 https://sha-mbles.github.io/ gmane 近况 https://lars.ingebrigtsen.no/2020/01/06/whatever-happened-to-news-gmane-org/ 浏览器能做的事情 https://github.com/luruke/browser-2020 一个 ext2 和 FAT 为一体的 fs https://github.com/NieDzejkob/cursedfs iptables 规则调试工具 https://github.com/x-way/iptables-tracer Qt 2020 的变化 https://www.qt.io/blog/qt-offering-changes-2020 后缀自动机可视化 https://yeah.moe/p/a8e74947/