撸完汇编接着撸编译器，我看好你～

谢谢各位大佬分析，看完获益匪浅，同时也有点瑟瑟发抖。。。

这样吧，再具体明确一下：

1，环境就是在 Debian 的 vps 上跑了，要么 LAMP 全家桶，要么 Python 的各种轮子组合。
2，框架要开箱即用的，不需要折腾太多。说白了吧，主要是不需要我太多维护，框架拿来就用，稍微配置一下最好是不要配置。最好是无脑配好了直接上来撸 CRUD 业务代码。
Django 自带 Admin 后台这种最好，PHP 的框架太多，选择困难，高档货 Laravel 这种本身比较重，还需要花点时间理解框架本身的，感觉不太合适。（哎，说到这里感觉不如找个 CMS 搞二次开发了。。。）
3，一般需要注意的比如跨站防注入肯定要做到位，https 肯定要上，其他的比如防 D 这种感觉还是交给卖鸡的老板吧，大不了花点钱找个好点的鸡场，有问题交 ticket。一般也不会盯着这种小业务量的站点猛 D 吧。。高安全要多花钱这是肯定的，一分钱一分货都懂，但是毕竟比不上大厂，我自己也不是搞 security 的，老板们预算也有限，尽可能吧。
4，维护这一块，我想最好是弄个脚本，反正定期无脑更新，有更新就上，不管是操作系统还是框架还是用到的第三方的轮子什么的，勤备份，升挂了大不了回滚。

感觉选来选去可能最后还是 Django 了。。。

谢谢楼上的大佬们，首先估计比较重的几个框架会被排除，ROR 他们都不会，Laravel 个人感觉无异于是重新发明了一门语言，多少都需要一点学习成本的，我自己估计也要看几天才能上手，说不定有什么坑也不知道。

其次非常感谢 @defunct9 @WuwuGin @leisurelylicht 三位大佬帮我重新定义了安全，这是一个体系而不是做到一两条比如防注入防跨站就能解决的，要注意的地方很多，我可能把这一块看得简单了一点。

最后感谢 @ebony0319 和 @cevincheung 两位大佬提醒数据库方面的坑，他们没有特别的存储过程，这个确实当时有很多人喜欢把业务逻辑做到数据库里用存储过程实现，不过他这个应该是太简单了以至于忘记了挖这个坑。数据库还是用 MySQL 吧，基本上我搞过的几个项目都是 MySQL，对这块熟悉一点，而且配合 PHPMyAdmin 维护起来也简单一点。

我估计最后还是无脑选 Django，开箱即用，python 入门也简单，就不知道里面的各个内置模块有没有什么特别的坑了。再次感谢各位大佬的热情回复和支持。

@loading

倒不会跑在 windows 2000 上，不过按照他们的做法，应该是这次改版了就用这个版本用到死的。。。

@loginv2 会挂到网上的，试运营的时候估计是买个 vps 然后部署上去，然后让几个国外的仓库登录了试试。

@bobuick
@leisurelylicht
@wujunze
@haozibi

谢谢各位，Java 应该是不会考虑的，一是他们没人会 Java，不懂就不好评论；第二个是他们可能后续还会自己做二次开发，他们主要是一群写 C 的，然后有几个会 Python，那些个写 C 的对 PHP 具有天生的亲近感，Python 他们也用来写测试脚本，也还行。业务 CRUD 这一块，可能会拉他们的人来帮忙减轻点工作量。

多用户登录是不是直接用 OAuth 就够了？还需要其他注意的地方么？

最后，希望大佬们解答的时候不要只说语言和框架，多讲讲能够说服人的论点，最好有案例什么的。

继续吐槽巧克力键盘。其实大厂们在 HMI 方面是做过了大量的实验的，经典的键盘构型设计，都是有实验数据支撑的。我知道的，有明确数据表明巧克力反人类的地方，说两点：

1，普通键盘还有以前笔记本使用的经典键盘（比如 Thinkpad 的老七行键盘），在键帽上都是有一定的弯曲弧度的，中间低四周高，而且这个弧度每个键位都不一样的，这是为了拟合人的手指的弧度，让整个接触面受力分布更加均匀而特意设计的，这样手指在接触键帽的时候，感觉更舒适。巧克力键盘直接无视这一条。

2，第一条提到的弧度，实际上即使是同一个手指接触的不同的键帽，弧度深浅也不一样。规律是，越靠近中心位置（手指经常停放的位置，键帽中心下沉弧度越深（比如 FGHJK 这几个键），越靠近外围，键帽越平台，比如左右 Ctrl ），这也是考虑了手指在打字过程中的运动方式而特意设计的，巧克力键盘不具有这样的特性。

3，键盘靠近下方的键帽高度要比靠近上方的键帽高度要低，也就是 Ctrl 键，空格键这一排的高度实际上要比最上面 1234...数字键的高度稍微低一点，这也是考虑到人在打字的时候会将手掌根部泊在(park)键盘下方，打字过程中整个手掌实际是稍微上翘然后向下击键的，这样的斜率保证了手指在击打最上方 1234 数字键和击打最下方的 zxcv 键的力度尽可能不要有太大变化，同时方便大拇指更容易的停靠在空格键上。而巧克力键盘没有这种倾斜式的设计，也无法让大拇指停泊在空格键位上。

其实最早在 SONY 给 OEM 提出巧克力键盘（当时也叫浮岛式键盘）的设计时，几个大厂都讨论过，特别是自身有一定设计实例的，HMI 方面有一定功底的厂商，都反复比较过，结果大家也都心知肚明，然后没有大规模推广。后来被苹果这个设计具有强势话语权的外貌党给彻底带歪了，几个大厂横向一看风向都是往巧克力键盘那边吹的，结果就都一起被带歪了。苹果自己吹的什么 X 构架、蝴蝶架构，省省吧，自己拆一拆老的 Thinkpad 的 T 系列就知道是怎么回事了，不过是被苹果有一次重新发明 /定义了键盘而已。

都是吹的，机械键盘又硬，声音又大，能说道说道的好处是耐用，长期使用触感变化较小。其实最最重要的是有 xx 轴的光环加成，信仰起码占成本 90%。

我是从 AST 的 PC/AT 大圆口开始用的，机械键盘可以看成是这种键盘的袖珍版，阅键盘也算是有几百了，个人感觉用过最好的是 SUN 工作站上面原配的键盘，激光蚀刻键帽，触感柔和，静音，防水设计，背部有钢板里衬，独立编码芯片。整体感觉用力过猛，over build 了。

后来觉得还可以的，主要是旭丽代工的 HP 或者 Dell 键盘，从经济学的角度讲，这个键盘在成本、质量、体验取得了很好的平衡了。Dell，Lenovo，HP 这几大家的键盘基本上都是由旭丽 SILITEK，群光 CHICONY，美蓓亚 NMB，英群 BTC 四家代工的。

NMB 沿袭了日系的精致，但是估计是报价较贵，成本下不来，用的比较少。群光 CHICONY 沿袭了富士康的精准质量和成本控制，量最大，手感普遍偏硬。旭丽 SILITEK 也是沿袭了 LITE-ON 的一贯风格，整体不错。BTC 略逊一筹，但质量绝对还是有保证的。

键盘真没必要追求机械键盘，机械键盘也是信仰加成厉害，IBM，HP，Dell 这种大厂在工作站上都是舍得花血本的，最早都是机械键盘，但后来无一例外都换成了电容式普通键盘，自然是有他们的道理的。工作站上是绝对不会偷工减料耍花样省键盘这点小钱的，毕竟做砸了直接毁招牌被打脸的。

最后，整个键盘行业，都 tm 被苹果一家带歪了，巧克力是最反人类效率最低的键盘，为了轻薄为了好看而特意设计的。有老外做过这方面的数据统计，巧克力键盘实际使用感受、打字效率、击键误触等方面都远远比不上传统键盘。

@CitizenR T430 和 T430s 是第一代巧克力键盘的机器，首次摈弃传统经典 7 行键盘，设计上的重大缺陷远不止无大小写灯。已知的 HMI 方面存在的问题如下：

1，不是无 Caps Lock，而是把几乎所有的指示灯改为了 OSD 显示，包括音量、亮度等，这个只有在正确安装了驱动之后才能正常显示。
2，取消了 Break 实体键，这个对于某些耗时较长的程序调试、不小心写出了死循环的情况，特别是经常用到 while(1)死循环的嵌入式是致命的。后来联想给出了解决方案是使用 Fn+B 或者 Ctrl + L + B （具体忘记了）
3，F1 - F12 键位排布有缺陷，正常的键盘会将 F1-F4, F5-F8 ……这样四个键为一组，而 T430/T430s 没有这样分组，让用户更容易按错，另外这种排布对于视力有缺陷的盲人是非常不合适的。这一点，在 T440 之后得到了改正。

以上只是 T430/T430s 在键盘这一个方面存在的 HMI 设计上的缺陷，还有其他部件上有更多问题。

这是联想第一代为了设计而设计，为了追逐轻薄的潮流，放弃自身专业工具定位，迎合主流市场而诞生的一个产品。事实上，这种趋势在后续产品继续存在，以至于现在大家普遍反映 Thinkpad 已经不是那个 Thinkpad 了。

HMI 相关的设计很多都是要长时间使用之后才能体会到背后的原理，普通人只会渐渐觉得这个东西不太好用，不合手，其实就是 HMI 做的不好。

顺便 @honeycomb

@shy666 先谢谢了。因为业务的需要、安全方面的考虑以及存取资料的便捷性考虑，我的设备一般都是开 ZeroTier 连到国内家里的服务器再使用各项服务的，以前用 Stripe 和美股账户也是因为海外异地登录被限制使用过，为了避免不必要的麻烦都默认开启了 ZeroTier。

不过还是希望微博能够改进一下业务流程，昨天好像 web 端密码找回时发送短信验证码仍然提示繁忙。Anyway，Thank you very much。

已经被冻结几次了，海外手机无法收验证码，点击获取手机验证码的时候弹出“抱歉，系统繁忙。” 话说渣浪都不考核 KPI 的么？

转自 wiki，中文翻译是人话版，大家凑合看。

Kernel page-table isolation
From Wikipedia, the free encyclopedia

Kernel page-table isolation (KPTI, previously called KAISER) is a hardening technique in the Linux kernel to improve security by better isolating user space and kernel space memory.[1][2] KPTI was merged into Linux kernel version 4.15,[3][4] to be released in early 2018, and backported into Linux Kernel 4.14.10. Windows implemented an identical feature in version 17035 (RS4)[5].

内核分页表隔离(KPTI，以前叫做 KAISER)是 Linux 内核中的一项加固技术，将用户空间(User Space)和内核空间(Kernel Space)的内存进行更好的隔离以增强安全。

Background[edit]
Prior to KPTI, whenever executing user space code (applications), Linux would also keep its entire kernel memory mapped in page tables, although protected from access. The advantage is that when the application makes a system call into the kernel or an interrupt is received, kernel page tables are always present, so most context switching-related overheads (TLB flush, page table swapping, etc) can be avoided.[1]

In 2005, the Linux kernel adopted address space layout randomization (KASLR), which makes it more difficult to exploit kernel vulnerabilities,[6][7] which relies on kernel addresses remaining hidden from user space. Despite prohibiting access to these kernel mappings, it turns out there are several side-channel attacks in current Intel x86 processors (as of December 2017) that can leak the location of this memory, making it possible to work around KASLR.[2][8][9][10] AMD processors are not affected by these attacks and don't need KPTI to mitigate them.[11]

背景
在 KPTI 引入之前，每次执行用户空间代码（应用）时，Linux 虽然（对内核存储区域（ Kernel Memory ））进行了访问保护，但还是会继续将整个内核存储区域（ Kernel Memory ）映射在分页表（ page table ）中。这样做的好处是，应用程序（ Application ）在请求内核系统调用（ make a system call ）或者触发一个中断（ interrupt ）时，内核的分页表一直处于可用状态，这样绝大多数上下文切换相关的开销（ TLB Flush，page table swapping，等）可以避免。

在 2005 年，Linux 内核引入了地址空间随机排布技术（ KASLR ），让内核地址对用户空间不可见，从而增加了发现内核漏洞的难度。虽然（已经）禁止了对这些内核映射的访问，但最后发现在现有的 Intel X86 处理器（到 2017 年 12 月为止）上可能会泄漏这些内存的位置，有一些旁路攻击（ side-channel attacks ）可以绕过 KASLR （这里是指通过 Kernel Page Table 里面的映射关系，能获取到 Kernel 内存区域的地址）。AMD 的处理器则不会受到这些攻击的影响因此无需使用 KPTI 进行改善。

Implementation[edit]
KPTI fixes these leaks by separating user space and kernel space page tables entirely. On recent x86 processors, a TLB flush can be avoided using the process context identifiers (PCID) feature, but even then it comes at a significant performance cost particularly in syscall-heavy and interrupt-heavy workloads. The overhead[clarification needed] was measured to be 0.28% according to KAISER's original authors,[2] but roughly 5% for most workloads by a Linux developer.[1]

KPTI can be disabled with the "nopti" kernel boot option. Also provisions were created to disable KPTI if newer processors fix the information leaks.[3]

实现
KPTI 通过对用户空间和内核空间的分页表进行完全隔离来修复这项漏洞。在最新的 X86 处理器中，使用 PCID （进程上下文标识符）来避免产生 TLB flush，即使这样，仍然会带来显著降低性能，特别是频繁使用系统调用和频繁使用中断的应用程序。由此带来的开销根据 KAISER 的原作者测量约 0.28%；一位 Linux 开发人员的测量结果是大多数工况下有 5%。

KPTI 可以通过 nopti 内核启动选项进行关闭。此外也做了未来如果新的处理器修复了此项漏洞，对 KPTI 进行关闭的准备。

--------------------------------------------------------

个人理解，问题可能是出在 Intel 处理器的 MMU 上，page table 的映射以及 address translation 是通过硬件实现的，可能是这一块出了问题，不得不用软件进行一些预处理。

@jasontse 谢谢，刚看到 vs 2017 安装还要在线下载了，不提供完整 iso 了，也是厉害了。微软真是各种跑偏了。

@Shazoo 嵌入式准备还是用这个老 xp 系统伺候了，Keil 系列好说，其实大厂的都好说，但是客户不好说啊。有的客户用不起新的东西，老的东西也能用，还得给他用老的。比如风河的 Workbench 很好用，但是老用户不想花钱升级，还在跑 Tornado，你不跟他们一样出了问题，撕起来还是要给他还原成 xp 系统，从头给他来一遍让他心服口服的。再说老外信奉 if it is not broken, dont fix it.

嵌入式不可能像桌面系统这样频繁更新的，一般都是几十年的生命周期，所以有一条“抽屉原则”是普遍遵循的，产品某个交付版本对应的 build 环境（硬件+软件）要封存至少一套，生命周期内，任何时候该版本出了问题，直接将这一套系统从“抽屉”里面取出来重新 build 还原，然后开始 root cause analysis。我现在还见过有全新的 Pentium MMX 处理器的主机在仓库里吃灰呢。

@XiaoFaye 这我知道啊。。 我的意思是我想把银行全家桶放在虚拟机里面收拾啊，但是做不到啊，一堆插件一堆 UKey 什么的，虚拟机伺候不了。

我的做法是单独装一个系统伺候银行全家桶，银行的东西平时基本不用，但是需要的时候肯定要立刻能用。这些插件和 Ukey 驱动什么的不仅占空间，还占 CPU 资源（邮储的 UKey 固定占 12%-20%的 CPU 占用率，也是蛮厉害）