在debug期间我们可以给栈空间赋值为一个特定值，比如0x5a，然后在每次中断中检查该值是否发生变化，来检测操作内存附近是否有内存被改写，同时该方法也可以用于统计栈最大使用情况。
-fstack-protector 会在函数返回地址之前插入一个保护字（称为“canary”）。如果在函数执行期间发生了缓冲区溢出，可能会覆盖这个保护字。在函数返回之前，编译器会检查这个保护字是否被修改，如果被修改，程序会立即终止，从而防止潜在的攻击。
stack-protector：保护函数中通过alloca()分配缓存以及存在大于8字节的缓存。缺点是保护能力有限。 stack-protector-all：保护所有函数的栈。缺点是增加很多额外栈空间，增加程序体积。 stack-protector-strong：在stack-protector基础上，增加本地数组、指向本地帧栈地址空间保护。 stack-protector-explicit：在stack-protector基础上，增加程序中显式属性"stack_protect"空间。
通过wfi或wfe指令进入low-power-state。在low-power-state下cpu core保持上电状态，但其大部分时钟停止或者进入时钟门限。这意味着core的绝大部分都处于static state，唯一消耗的功率是用于寻找中断唤醒条件的泄漏电流和少量逻辑时钟。进入low-power-state后将暂停当前的工作直到某个中断或event事件发生会退出low-power-state进入正常运行state。
其唤醒wfi或wfe的interrupt或者event请参考《The AArch64 System Level Programmers’ Model 》D1.6 Mechanisms for entering a low-power state
测试发现period_size=512或者256时均不发生丢包，于是做以下实验：
| sampling rate | channel | bit depth | period_size | package size | 是否丢包 |
|---|---|---|---|---|---|
| 48k | 2 | 16bit | 1024 | 4096Byte | 丢包 |
| 48k | 1 | 16bit | 1024 | 2048Byte | 丢包 |
| 48k | 2 | 16bit | 512 | 2048Byte | 不丢包 |
| 48k | 4 | 16bit | 512 | 4096Byte | 不丢包 |
通过实验发现，丢包与period_size相关与package size无关。
AES（Advanced Encryption Standard），在密码学中又称Rijndael加密法，是美国联邦政府采用的一种区块加密标准。这个标准用来替代原先的DES。其密钥长度则可以是128，192或256比特。
安全启动的根本目的是为了防止消费者从软硬件层面对产品的部分关键系统进行读写、调试等高权限的操作。以限制消费者的能力，来达到保护产品的商业机密、知识产权等厂家权益的目的。当然，厂家是不会这样宣传 Secure Boot 的。他们的文案通常都是通过这项技术保护用户的隐私，防止恶意软件修改系统软硬件等等。
可以说，Secure Boot 的安全模型建立在消费者是攻击者这一假设上。消费者在物理上拥有产品硬件，可以对产品进行物理连接、拆机、改装等等物理上的操作，比较专业的消费者甚至可以使用数字示波器监听 CPU 和 RAM 、eMMC 之间的数据传输来读取非常底层的数据传输。可以说跟传统的安全模型中的攻击者相比根本不在一个层面上。
消费者作为攻击者的目的，一般常见的有刷机安装自定义的操作系统（Mod）、绕过厂家封闭的支付平台（IAP）和应用商城安装自定义的应用程序、绕过版权保护系统（DRM）达到复制厂家保护的数字产品内容等等。这些操作往往都会直接影响厂家的利益，因此需要一种能抵抗消费者攻击的安全机制。
而且像 eMMC 这种芯片通常都是业界标准化的，攻击者甚至可以把芯片拆下来，然后用市面上现成的通用 eMMC 编程工具来读写上面的内容。
Secure Boot 安全机制的原理，就是将最为核心的安全机制整合到最关键的主 CPU 中。因此就算攻击者可以监听电路板上的线路，甚至拆装个别芯片单独调试，也无法破坏 Secure Boot 的安全机制。
保证TA的安全需要做到三点：
TEE 系统软件从整体上包含 REE 和 TEE
两部分，各自对应的基础组件如下图所示。 
信息安全的三个基本目标是机密性，完整性和可用性。
CPU发出的地址都是虚拟地址，需要经过页表转换才能得到物理地址，其中在pte页表中低12bit（针对4k大小的页表）为控制位，用来控制页表的访问属性，也就是说在页表建立的时候就确定了访问状态是安全状态还是非安全状态，其pte低12bit如下：
1 | npm install hexo-cli -g |
1 | # 使用 pandoc 渲染器 |
卸载 hexo 默认 markdown 渲染器，安装 pandoc markdown 渲染器。hexo 默认的 markdown 渲染器不支持 Mathjax，不支持插件扩展，不支持 emoji 表情。pandoc markdown 渲染器支持 Mathjax 语法，不仅可以渲染 markdown，还支持 textile，reStructedText 和许多其他格式，仍然不支持 emoji 表情。
此外还有其他 markdown 渲染器，hexo-renderer-markdown-it 支持 Mathjax 语法（支持不太好），支持 Markdown 以及 CommonMark 语法，渲染速度比 hexo-renderer-marked 快，支持插件配置，支持标题带安全的 id 信息，支持脚注（上标，下标，下划线）。 hexo-renderer-markdown-it-plus 支持 Katex 插件并默认启用，默认启用插件列表：markdown-it-emoji，markdown-it-sub，markdown-it-sup，markdown-it-deflist，markdown-it-abbr，markdown-it-footnote，markdown-it-ins，markdown-it-mark，@iktakahiro/markdown-it-katex，markdown-it-toc-and-anchor。
这里要吐槽一下各版本的 markdown 渲染器，对 latex 语法的支持真是一言难尽，pandoc 用了一段时间发现某些特性不支持打算换一个，然后 latex 公式各种崩，😔毁灭吧。
本人是安装的OMV，服务基本上全是docker，而且安装的服务很多中间踩了一些坑，这里记录一下，如果有后来人有幸看到可以避免少踩一些坑：
关于raid，emmm本人不喜欢用raid，使用的basic模式，主要是为了便于插入到我的服务器上使用，关于数据安全，比较重要的文档笔记我会挂在一个网盘的sync目录下，在nas和网盘中双备份而非备份到两块硬盘里。至于几十G的一部电影，小姐姐什么的丢就丢了吧，不心疼。再次声明一个基本原则，选个大一点的网盘备份自己的重要资料，你要坚信并深信他跑路的可能性远远低于你搞坏nas的概率。
docker image路径问题：本人自用的是绿联DX4600，刷的OMV系统，系统刷到内部32G EMMC中，这个空间是比较小的，默认docker image会下载到/var/lib/docker/目录这个目录显然是挂载在EMMC中的。32G的空间是绝不能满足我的要求的，本人Docker服务安装了几十个，因此需要将该路径切换到其他磁盘路径，建议是搞个ssd，装到ssd里。
一定要采用docker compose部署服务，因为迁移起来非常简单，我从ugos系统切换过来的时候将所有服务改成了docker compose。已经如果要换其他nas，迁移是非常简单的。
一定要规划好docker端口号和映射目录，否则会导致数据很混乱，一个基本原则是config、data、download这几个目录分开其中download可以采用软连接的方式。
Docker默认支持30个不同的自定义bridge网络，如果超过这个限制，就会提示下面的错误
1 | could not find an available, non-overlapping IPv4 address pool among the defaults to assign to the network |
最好提前配置好docker的网络：
1 | cat /etc/docker/daemon.json |
具体修改可以参考：https://www.phpsdk.cn/plug/news/show.html?id=10278
玩NAS那定然少不了反向代理，对于有公网ip的可以使用lucky，而对于我这种苦逼租房的人ipv6都没有只能通过购买一台云服务器安装反向代理来实现内网穿透了。我的一个网络部署情况如上图所示，在购买的云服务器上安装frps（frp服务端）和nginx proxy manguage。在路由器或者nas里安装frpc，安装到路由器的好处是网路的事情让网络来干，nas专注于自己的事情，而且方便映射自己的服务器到公网。当然安装到nas里也很好，我当前就是安装到nas里（炫耀一下，我有很多路由器O(∩_∩)O），这样依赖降到最低，这样可以随便切换路由器，而且很多人可能并没有在路由器里安装frpc的条件。
通过以上步骤就实现了内网穿透，你可以在任何有互联网的地方通过访问服务器的公网ip，来访问nas设备，云服务器里的frp会将相关访问转到你的终端或者nas里。但是这样的访问都是基于http协议的，相当于你在互联网上裸泳，而且比如你在nas里部署了图床然后将blog部署到github page，那么blog访问图床是只能使用https（当然如果你的github page自定义了域名并且关闭了强制https就不存在这个问题了）。但是what ever，开启https总归是更好的选择。购买一个域名解析到你的云服务上，然后配合nginx proxy manguage帮你自动申请并续约ssl证书实现https安全访问。
有了这个框架，具体每一步的实现大家就自己google搜一下就好了，网上的教程一大把，过程也很琐碎，这里就不罗列出来了。
笔记是非常重要的资源，因此这里不建议使用NAS搭建云笔记，即使要用最好也只是作为备份使用。你要坚信一个道理，云笔记提供商跑路的概率要比你把nas搞崩的概率低很多。玩NAS的人大部分都是比较爱折腾的吧，说不定哪天你要在系统内搞个什么服务，就把NAS搞崩了，到时候再去恢复数据是很麻烦的，而且还有可能恢复不了（我就曾经手贱rm
-rf softlink
软连接目录删除了里面的所有数据，谨慎操作啊），云笔记做好定时备份就好。如果你已经确定折腾完了，以后只使用不会再折腾了那么可以了解一下一下笔记：
我还是钟爱Notion
大部分人玩nas可能都是玩影音，但是本人自用了几个月发现并不好用，主要适合收藏特别钟爱的电影，以及一些被下架的好电影。Jellyfin、Emby、Plex都用过，Emby仅安装过，是Jellyfin的收费版本，Jellyfin和Plex使用过程中都有各种问题，有刮削出错的，有播放h265的问题等等，当前我采用的方案是配合Infuse播放器使用，Infuse作为播放器前端，jellyfin作为服务端，在infuse中添加Jellyfin服务后直接使用Infuse播放，目前体验完美，没有遇到什么问题，当然infuse是收费的，而且不便宜的，但是他确实解决了我的问题，我愿意为之买单。
上面说完了观影，还有一个最重要的问题就是如何找资源，目前比较好的方案就是nastool这种，检索、下载一整个自动化，由于某些原因，这类工具都是不做宣传的，而且nastool作者已经不维护了，转去开发新项目了，这里也不做过多解释了，自行研究。这些都只是工具，真正的片源还是要通过BT种子来获取的，bt协议是一种分布式存储协议，他不是存储在中心化的服务器上的，而是存储在每个人的个人电脑里，我们下载的时候就是从其他保有这个文件的电脑里下载，其中查找谁的电脑保有该文件的服务叫track服务。这里就要求我们下载文件后需要做种给他人使用，否则大家都只下载不做种慢慢就变成死种了。
目前bt在国内已经被玩坏了，像迅雷（吸血雷）这种官方作弊盛行之下，大家都只下载不做种导致下载体验很糟糕，如迅雷的卡在99%。想要好的下载体验需要玩pt，pt站都是封闭的，想要进去有一定门槛而且进去后也需要你有一定的分享率才能保住号，pt的模式就是强制你分享，如果你只下载不分享那么你的分享率会非常低，就会把你踢出站点，这个要求客户需要刻意的去提高分享率（即你想下载多少资源就需要上传多少资源），人人为我，我为人人的精神。
当然还有一个工具叫stash，给你的小姐姐安一个家，只能说到这了，自行摸索吧。
至于音乐我觉得目前还是洗洗睡吧，Navidrome太丑，缺少好用的客户端，plex漂亮但是没有很好的推荐算法，只适合听收藏的音乐，也能用。但还是离不开QQ音乐或者网易云之类的APP。
对于摄影爱好者需要管理组织图片的可以尝试下Librephoto，还可以。
下载工具可以使用qBittorrent、transmission、aira2等。
Talebook个人认为比较丑，calibre-web要更漂亮一点，适合展示给别人看，以及在需要的时候检索和下载，不适合直接阅读，还是乖乖下载下来配合logseq、marginnote，obsidian等阅读。
paperless-ngx好看，很适合管理文档，但是不知道为什么在我的系统里经常出现cpu和内存干满的问题，于是暂时先关闭了。
本人当前自用的方案是hexo博客框架，配合Next和Butterfly主题使用，Nas中部署了halo，没有使用，主要感觉主题定制比较麻烦，教程太少，不太满足我的需求，如果不需要自定义主题同时又需要博客后台管理页面的可以一试。至于wordpress之类的也没有在使用，本人是枚嵌入式工程师，不懂前端后端这些，只能选择网上教程多的框架和主题。通过hexo将博客部署到github page是最经济的方案。其中Next主题完美体现了简洁之美，非常适合写技术博客。但是本人同时也喜欢摄影，旅游想分享一些picture，碎碎念等，需要对博客做很多定制，而用Butterfly主题的人非常多，网上的魔改教程非常多，非常适合既没有前端开发技术又想定制的用户。
由于hexo属于静态博客，没有后台，评论系统可以借助第三方平台，如果不想用第三方就在Nas里部署个Waline活着Twike就行了。
至于Markdown的图片，可以使用图床，我用的是兰空图床Lsky-pro。好处是博客和本地笔记的markdown可以保持完全一致，不用去处理图片链接位置的问题。
Alist挂载各种网盘，nextcloud虽然有点卡但是一般也不登陆进去，使用他同步备份一个本地目录就好。Amazue的对象存储很好用，minio同样支持S3接口的对象存储。可以将memos的备忘录数据存储到minio的对象存储中，当然也可以存储其他内容，看个人需求。
gitlab和jenkins也是必装的，这个懂的都懂，不懂的也不需要了解了。需要注意的是gitlab非常吃内存，内存资源紧张的慎重安装。
资讯应该是我最常用的一个功能了，这当然离不开大名鼎鼎的RSS了，一个古老到快要失传的互联网技能，现在很多网站基本上都不提供RSS订阅服务了，各家都在打造自己的流媒体信息推送系统，wechat的公众号，各种xx头条等，wechat其实跟RSS订阅差不多，你可以选择自己感兴趣额的内容订阅，但是各种头条系新闻客户端就完全是算法推荐了，用过的人都知道有多恶心，特别容易形成信息茧房，而且推荐算法还带有观点倾向性，一个基本常识我们如果想要了解一个事件的基本面貌是一定要看到各方代表（尤其是代表各方不同利益的人）纰漏的信息的，只有在充分了解这些信息的前提下才能更有机会了解到一个社会事件的事实的。头条系基本就被完全pass了，微信公众号是一个很好的平台，当然由于其基于其强大的社交后台其内容及其容易情绪化（利于传播）。但总体来讲微信公众号是很好的一个信息流分发平台。除了微信公众号外还有一些就是newsletter，通过邮箱订阅的方式订阅一些感兴趣的内容，但是邮箱app确实没有一个好的阅读体验。再就是RSS了，RSS可以自由选择阅读客户端，总体来讲可以选择到比较好的订阅+良好的阅读体验的ap的，一下是本人自用的服务，读者可自行参考选择。
RSSHub是一个后台服务，本质是一个RSS源生成器，我们要订阅某个网站，一般需要该网站提供RSS服务（一些网站的xml文件），因为现在很多网站都不提供RSS服务了，那么就无法订阅该网站，于是一帮RSS爱好者就搞出来RSSHUB这个神器，万物皆可RSS。RSSHub它通过根据特定规则抓取互联网上的特定内容，并根据抓取的内容创建RSS源。这可以为本身不支持RSS订阅的网站建立RSS源。用户可以在RSS阅读器内订阅这些RSS源。有了RSShub后我们基本上就可以订阅大部份网站了。剩下的就是选择一个RSS阅读器。
TTRSS/freshRSS是一款免费的 RSS 源阅读器。他可以定期到订阅网站上抓取内容显示给用户，而且其还集成了标签、分类等功能可以将订阅的众多网站按照不同类别（新闻、博客、论坛），不同形式（文字、视频、音频）进行分类管理，这个其实已经可以满足大部份pc用户的需求了，但是其阅读体验还是不佳，而且该服务是基于web端的，这个不符合移动互联网下的阅读习惯，因此还有一些ap客户端基于某些协议可以将TTRSS/freshRSS的内容导入到ap内阅读，提供更好的阅读体验，主要是美观，颜值即正义。我这里使用的是Fluent这个app个人比较喜欢他的审美，简洁，没有广告、可以抓取全文阅读而不需要跳转到源网站。
额外再谈一下TTRSS和freshRSS的选择，我选择的是freshRSS，还是因为颜值，freshRSS看着要更舒服一点，TTRSS页面实在太古老了，而且TTRSS配置https很麻烦，当时也没有配置成功，freshRSS基本上不需要额外配置，配置好反向代理就ok了。开启https的原因有两个一个是安全，另一个是Fluent这些ap客户端一般都要求你提供的服务必须基于https才行。
另外RSShub开发人员还开发了一款RSS阅读器，Follow，这个app不需要你有NAS或者云服务器也可以订阅大部分常用网站，对于喜欢RSS的人可以尝试下，我也尝试用过，体验确实还不错，不过当前只有pc客户端，持续关注移动端的app开发进度吧。
Nas本质就是一台服务器，如果你做了内网穿透后映射到公网，他就是一台云服务器，而且拥有的空间和计算性能可以自己配置，其玩法也是非常多的，我当前主要用到的就是这些。
爱折腾的用户一定做好数据备份！！！
爱折腾的用户一定做好数据备份！！！
爱折腾的用户一定做好数据备份！！！
已迁移到notion page，请访问:NAS 有趣的 Docker 推荐