分类 软件开发 下的文章

编者按:近些年来 Rust 语言由于其内存安全性和性能等优势得到了很多关注,尤其是 Linux 内核也在准备将其集成到其中,因此,我们特邀阿里云工程师苏子彬为我们介绍一下如何在 Linux 内核中集成 Rust 支持。

2021 年 4 月 14 号,一封主题名为《Rust support》的邮件出现在 LKML 邮件组中。这封邮件主要介绍了向内核引入 Rust 语言支持的一些看法以及所做的工作。邮件的发送者是 Miguel Ojeda,为内核中 Compiler attributes、.clang-format 等多个模块的维护者,也是目前 Rust for Linux 项目的维护者。

Rust for Linux 项目目前得到了 Google 的大力支持Miguel Ojeda 当前的全职工作就是负责 Rust for Linux 项目。

长期以来,内核使用 C 语言和汇编语言作为主要的开发语言,部分辅助语言包括 Python、Perl、shell 被用来进行代码生成、打补丁、检查等工作。2016 年 Linux 25 岁生日时,在对 Linus Torvalds 的一篇 采访中,他就曾表示过:

这根本不是一个新现象。我们有过使用 Modula-2 或 Ada 的系统人员,我不得不说 Rust 看起来比这两个灾难要好得多。

我对 Rust 用于操作系统内核并不信服(虽然系统编程不仅限于内核),但同时,毫无疑问,C 有很多局限性。

在最新的对 Rust support 的 RFC 邮件的回复中,他更是说:

所以我对几个个别补丁做了回应,但总体上我不讨厌它。

没有用他特有的回复方式来反击,应该就是暗自喜欢了吧。

目前 Rust for Linux 依然是一个独立于上游的项目,并且主要工作还集中的驱动接口相关的开发上,并非一个完善的项目。

项目地址: https://github.com/Rust-for-Linux/linux

为什么是 Rust

Miguel Ojeda 的第一个 RFC 邮件中,他已经提到了 “Why Rust”,简单总结下:

  • 安全子集 safe subset 中不存在未定义行为,包括内存安全和数据竞争;
  • 更加严格的类型检测系统能够进一步减少逻辑错误;
  • 明确区分 safeunsafe 代码;
  • 更加面向未来的语言:sum 类型、模式匹配、泛型、RAII、生命周期、共享及专属引用、模块与可见性等等;
  • 可扩展的独立标准库;
  • 集成的开箱可用工具:文档生成、代码格式化、linter 等,这些都基于编译器本身。

编译支持 Rust 的内核

根据 Rust for Linux 文档,编译一个包含 Rust 支持的内核需要如下步骤:

  1. 安装 rustc 编译器。Rust for Linux 不依赖 cargo,但需要最新的 beta 版本的 rustc。使用 rustup命令安装:
rustup default beta-2021-06-23
  1. 安装 Rust 标准库的源码。Rust for Linux 会交叉编译 Rust 的 core 库,并将这两个库链接进内核镜像。
rustup component add rust-src
  1. 安装 libclang 库。libclangbindgen 用做前端,用来处理 C 代码。libclang 可以从 llvm 官方主页 下载预编译好的版本。
  2. 安装 bindgen 工具,bindgen 是一个自动将 C 接口转为 RustFFI 接口的库:
cargo install --locked --version 0.56.0 bindgen
  1. 克隆最新的 Rust for Linux 代码:
git clone https://github.com/Rust-for-Linux/linux.git
  1. 配置内核启用 Rust 支持:
Kernel hacking
  -> Sample kernel code
    -> Rust samples
  1. 构建:
LIBCLANG_PATH=/path/to/libclang make -j LLVM=1 bzImage

这里我们使用 clang 作为默认的内核编译器,使用 gcc 理论上是可以的,但还处于 早期实验 阶段。

Rust 是如何集成进内核的

目录结构

为了将 Rust 集成进内核中,开发者首先对 Kbuild 系统进行修改,加入了相关配置项来开启/关闭 Rust 的支持。

此外,为了编译 rs 文件,添加了一些 Makefile 的规则。这些修改分散在内核目录中的不同文件里。

Rust 生成的目标代码中的符号会因为 Mangling 导致其长度超过同样的 C 程序所生成符号的长度,因此,需要对内核的符号长度相关的逻辑进行补丁。开发者引入了 “大内核符号”的概念,用来在保证向前兼容的情况下,支持 Rust 生成的目标文件符号长度。

其他 Rust 相关的代码都被放置在了 rust 目录下。

在 Rust 中使用 C 函数

Rust 提供 FFI( 外部函数接口 Foreign Function Interface )用来支持对 C 代码的调用。Bindgen 是一个 Rust 官方的工具,用来自动化地从 C 函数中生成 Rust 的 FFI 绑定。内核中的 Rust 也使用该工具从原生的内核 C 接口中生成 Rust 的 FFI 绑定。

quiet_cmd_bindgen = BINDGEN $@
      cmd_bindgen = \
    $(BINDGEN) $< $(shell grep -v '^\#\|^$$' $(srctree)/rust/bindgen_parameters) \
        --use-core --with-derive-default --ctypes-prefix c_types \
        --no-debug '.*' \
        --size_t-is-usize -o $@ -- $(bindgen_c_flags_final) -DMODULE

$(objtree)/rust/bindings_generated.rs: $(srctree)/rust/kernel/bindings_helper.h \
    $(srctree)/rust/bindgen_parameters FORCE
    $(call if_changed_dep,bindgen)

ABI

Rust 相关的代码会单独从 rs 编译为 .o,生成的目标文件是标准的 ELF 文件。在链接阶段,内核的链接器将 Rust 生成的目标文件与其他 C 程序生成的目标文件一起链接为内核镜像文件。因此,只要 Rust 生成的目标文件 ABI 与 C 程序的一致,就可以无差别的被链接(当然,被引用的符号还是要存在的)。

Rust 的 alloccore

目前 Rust for Linux 依赖于 core 库。在 core 中定义了基本的 Rust 数据结构与语言特性,例如熟悉的 Option<>Result<> 就是 core 库所提供。

这个库被交叉编译后被直接链接进内核镜像文件,这也是导致启用 Rust 的内核镜像文件尺寸较大的原因。在未来的工作中,这两个库会被进一步被优化,去除掉某些无用的部分,例如浮点操作,Unicode 相关的内容,Futures 相关的功能等。

之前的 Rust for Linux 项目还依赖于 Rust 的 alloc 库。Rust for Linux 定义了自己的 GlobalAlloc 用来管理基本的堆内存分配。主要被用来进行堆内存分配,并且使用 GFP_KERNEL 标识作为默认的内存分配模式。

不过在在最新的 拉取请求 中,社区已经将移植并修改了 Rust的 alloc 库,使其能够在尽量保证与 Rust 上游统一的情况下,允许开发者定制自己的内存分配器。不过目前使用自定义的 GFP_ 标识来分配内存依然是不支持的,但好消息是这个功能正在开发中。

“Hello World” 内核模块

用一个简单的 Hello World 来展示如何使用 Rust 语言编写驱动代码,hello_world.rs:

#![no_std]
#![feature(allocator_api, global_asm)]

use kernel::prelude::*;

module! {
    type: HelloWorld,
    name: b"hello_world",
    author: b"d0u9",
    description: b"A simple hello world example",
    license: b"GPL v2",
}

struct HelloWorld;

impl KernelModule for HelloWorld {
    fn init() -> Result<Self> {
        pr_info!("Hello world from rust!\n");

        Ok(HelloWorld)
    }
}

impl Drop for HelloWorld {
    fn drop(&mut self) {
        pr_info!("Bye world from rust!\n");
    }
}

与之对应的 Makefile

obj-m := hello_world.o

构建:

make -C /path/to/linux_src M=$(pwd) LLVM=1 modules

之后就和使用普通的内核模块一样,使用 insmod 工具或者 modprobe 工具加载就可以了。在使用体验上是没有区别的。

module! { }

这个宏可以被认为是 Rust 内核模块的入口,因为在其中定义了一个内核模块所需的所有信息,包括:AuthorLicenseDescription 等。其中最重要的是 type 字段,在其中需要指定内核模块结构的名字。在这个例子中:

module! {
    ...
    type: HelloWorld,
    ...
}

struct HelloWorld;

module_init()module_exit()

在使用 C 编写的内核模块中,这两个宏定义了模块的入口函数与退出函数。在 Rust 编写的内核模块中,对应的功能由 trait KernelModuletrait Drop 来实现。trait KernelModule 中定义 init() 函数,会在模块驱动初始化时被调用;trait Drop 是 Rust 的内置 trait,其中定义的 drop() 函数会在变量生命周期结束时被调用。

编译与链接

所有的内核模块文件会首先被编译成 .o 目标文件,之后由内核链接器将这些 .o 文件和自动生成的模块目标文件 .mod.o 一起链接成为 .ko 文件。这个 .ko 文件符合动态库 ELF 文件格式,能够被内核识别并加载。

其他

完整的介绍 Rust 是如何被集成进内核的文章可以在 我的 Github 上找到,由于写的仓促,可能存在一些不足,还请见谅。


作者:苏子彬,阿里云 PAI 平台开发工程师,主要从事 Linux 系统及驱动的相关开发,曾为 PAI 平台编写 FPGA 加速卡驱动。

了解有关项目编程语言的详细信息。

 title=

近来,GitHub 添加了一个小指标来展示项目的细节,包括项目使用的编程语言。在这之前,对一个新的贡献者来说,了解他们感兴趣的项目的信息是较为困难的。

这个补充很有帮助,但是如果您想知道有关本地存储库中项目的相同信息该怎么办呢? 这正是 Tokei 派上用场的地方。这是一个当你想和精通不同语言的人想要构建一个项目时可以告诉你项目的代码数据的特别有用的工具。

探索 Tokei

据其 README,“Tokei 是一个可以展示你的代码数据的程序。Tokei 将会展示文件的数量,和这些文件中不同语言的代码、注释、空白的行数。”它的 v.12.1.0 版本 elaborates 是这样子介绍的,“Tokei 是一个快速准确的代码分析 CLI 工具和库,可以使你轻松快速地在你的代码库中看到有多少空白、评论和代码行”。它能够识别超过 150 种编程语言。

$ ./tokei ~/exa/src ~/Work/wildfly/jaxrs
==================
Language   Files Lines Code Comments Blank
Java        46    6135  4324  945     632
XML         23    5211  4839  473     224
---------------------------------
Rust
Markdown
-----------------------------------
Total

安装 Tokei

在 Fedora 上安装 Tokei:

$ sudo dnf install tokei

用 Rust's Cargo 包管理器安装:

$ cargo install tokei

使用 Tokei

要列出当前目录中的代码统计:

$ tokei
===============================================================================
 Language            Files        Lines         Code     Comments       Blanks
===============================================================================
 Ada                    10         2840         1681          560          599
 Assembly                4         2508         1509          458          541
 GNU Style Assembly      4         2751         1528          748          475
 Autoconf               16         2294         1153          756          385
 Automake                1           45           34            0           11
 BASH                    4         1895         1602          133          160
 Batch                   2            4            4            0            0
 C                     330       206433       150241        23402        32790
 C Header              342        60941        24682        29143         7116
 CMake                  48         4572         3459          548          565
 C#                      9         1615          879          506          230
 C++                     5          907          599          136          172
 Dockerfile              2           16           10            0            6
 Fish                    1           87           77            5            5
 HTML                    1          545          544            1            0
 JSON                    5         8995         8995            0            0
 Makefile               10          504          293           72          139
 Module-Definition      12         1183         1046           65           72
 MSBuild                 1          141          140            0            1
 Pascal                  4         1443         1016          216          211
 Perl                    2          189          137           16           36
 Python                  4         1257          949          112          196
 Ruby                    1           23           18            1            4
 Shell                  15         1860         1411          222          227
 Plain Text             35        29425            0        26369         3056
 TOML                   64         3180         2302          453          425
 Visual Studio Pro|     30        14597        14597            0            0
 Visual Studio Sol|      6          655          650            0            5
 XML                     1          116           95           17            4
 YAML                    2           81           56           12           13
 Zsh                     1           59           48            8            3
-------------------------------------------------------------------------------
 Markdown               55         4677            0         3214         1463
 |- C                    1            2            2            0            0
 |- Rust                19          336          268           20           48
 |- TOML                23           61           60            0            1
 (Total)                           5076          330         3234         1512
-------------------------------------------------------------------------------
 Rust                  496       210966       188958         5348        16660
 |- Markdown           249        17676         1551        12502         3623
 (Total)                         228642       190509        17850        20283
===============================================================================
 Total                1523       566804       408713        92521        65570
===============================================================================
$

下面的命令打印出了支持的语言和拓展:

$ tokei -l
ABNF
ABAP
ActionScript
Ada
Agda
Alex
Alloy
Arduino C++
AsciiDoc
ASN.1
ASP
ASP.NET
Assembly
GNU Style Assembly

如果你在两个文件夹上运行 tokei 并指定其位置作为参数,它将以先入先出的规则打印单个文件的统计数据:

 title=

默认情况下,tokei 仅仅输出有关语言的数据,但是使用 --files 标记可提供单个文件统计信息:

$ tokei ~/exa/src --files
===========================================================================================
 Language                              Files      Lines      Code             Comments     Blanks
===========================================================================================
 Rust                                   54          9339        7070             400       1869
 |- Markdown                            33          1306           0            1165        141
 (Total)                                           10645        7070        1565       2010
-------------------------------------------------------------------------------------------
 /home/ssur/exa/src/theme/default_theme.rs           130         107           0         23
 /home/ssur/exa/src/output/render/times.rs            30          24           0          6
 /home/ssur/exa/src/output/render/users.rs            98          76           0         22
 /home/ssur/exa/src/output/render/size.rs            182         141           3         38
 /home/ssur/exa/src/output/render/octal.rs           116          88           0         28
 /home/ssur/exa/src/output/render/mod.rs              33          20           3         10
 /home/ssur/exa/src/output/render/inode.rs            28          20           0          8
 /home/ssur/exa/src/output/render/links.rs            87          65           0         22
 /home/ssur/exa/src/output/render/groups.rs          123          93           0         30
 |ome/ssur/exa/src/output/render/filetype.rs          31          26           0          5
 /home/ssur/exa/src/output/render/blocks.rs           57          40           0         17
 /home/ssur/exa/src/output/render/git.rs             108          87           0         21
 |/ssur/exa/src/output/render/permissions.rs         204         160           3         41
 /home/ssur/exa/src/output/grid.rs                    67          51           3         13
 /home/ssur/exa/src/output/escape.rs                  26          18           4          4
 /home/ssur/exa/src/theme/lsc.rs                     235         158          39         38
 /home/ssur/exa/src/options/theme.rs                 159         124           6         29
 /home/ssur/exa/src/options/file_name.rs              46          39           0          7
 /home/ssur/exa/src/options/flags.rs                  84          63           6         15
 /home/ssur/exa/src/fs/mod.rs                         10           8           0          2
 /home/ssur/exa/src/fs/feature/mod.rs                 33          25           0          8
-- /home/ssur/exa/src/output/time.rs ---------------------------------------------------------------
 |- Rust                                             215          170          5         40
 |- Markdown                                          28            0         25          3

总结

我发现使用 tokei 来了解我的代码统计数据十分容易。另一个使用 tokei 的好处就是它可以用作为一个很容易集成到其他项目的库。访问 Tokei 的 Crate.io pageDocs.rs 网站来了解其更多用法。如果你想参与其中,你也可以通过它的 GitHub 仓库 来为 Tokei 作贡献。

你是否觉得 Tokei 很有用呢?可以在下方的评论区告诉我们。


via: https://opensource.com/article/21/6/tokei

作者:Sudeshna Sur 选题:lujun9972 译者:zepoch 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

第一步是选择配置文件的格式:INI、JSON、YAML 或 TOML。

 title=

有时,程序需要足够的参数,将它们全部作为命令行参数或环境变量既不让人愉快也不可行。 在这些情况下,你将需要使用配置文件。

有几种流行的配置文件格式。其中包括古老的(虽然有时定义不明确)INI 格式,虽然流行但有时难以手写的 JSON 格式,使用广泛但有时在细节方面令人意外的 YAML 格式,以及很多人还没有听说过的最新出现的 TOML。

你的首要任务是选择一种格式,然后记录该选择。解决了这个简单的部分之后就是时候解析配置了。

有时,在配置中拥有一个与“抽象“数据相对应的类是一个不错的想法。因为这段代码不会对配置做任何事情,所以这是展示解析逻辑最简单的方式。

想象一下文件处理器的配置:它包括一个输入目录、一个输出目录和要提取的文件。

配置类的抽象定义可能类似于:

from __future__ import annotations
import attr

@attr.frozen
class Configuration:
    @attr.frozen
    class Files:
        input_dir: str
        output_dir: str
    files: Files
    @attr.frozen
    class Parameters:
        patterns: List[str]
    parameters: Parameters

为了使特定于格式的代码更简单,你还需要编写一个函数来从字典中解析此类。请注意,这假设配置将使用破折号,而不是下划线。 这种差异并不少见。

def configuration_from_dict(details):
    files = Configuration.Files(
        input_dir=details["files"]["input-dir"],
        output_dir=details["files"]["output-dir"],
    )
    parameters = Configuration.Paraneters(
        patterns=details["parameters"]["patterns"]
    )
    return Configuration(
        files=files,
        parameters=parameters,
    )

JSON

JSON(JavaScript Object Notation)是一种类似于 JavaScript 的格式。

以下是 JSON 格式的示例配置:

json_config = """
{
    "files": {
        "input-dir": "inputs",
        "output-dir": "outputs"
    },
    "parameters": {
        "patterns": [
            "*.txt",
            "*.md"
        ]
    }
}
"""

解析逻辑使用 json 模块将 JSON 解析为 Python 的内置数据结构(字典、列表、字符串),然后从字典中创建类:

import json
def configuration_from_json(data):
    parsed = json.loads(data)
    return configuration_from_dict(parsed)

INI

INI 格式,最初只在 Windows 上流行,之后成为配置标准格式。

这是与 INI 相同的配置:

ini_config="""
[files]
input-dir = inputs
output-dir = outputs

[parameters]
patterns = ['*.txt', '*.md']
"""

Python 可以使用内置的 configparser 模块解析它。解析器充当类似 dict 的对象,因此可以直接传递给 configuration_from_dict

import configparser

def configuration_from_ini(data):
    parser = configparser.ConfigParser()
    parser.read_string(data)
    return configuration_from_dict(parser)

YAML

YAML(Yet Another Markup Language)是 JSON 的扩展,旨在更易于手动编写。为了实现了这一点,部分原因是有一个很长的规范。

以下是 YAML 中的相同配置:

yaml_config = """
files:
  input-dir: inputs
  output-dir: outputs
parameters:
  patterns:
  - '*.txt'
  - '*.md'
"""

要让 Python 解析它,你需要安装第三方模块。最受欢迎的是PyYAMLpip install pyyaml)。 YAML 解析器还返回可以传递给 configuration_from_dict 的内置 Python 数据类型。但是,YAML 解析器需要一个字节流,因此你需要将字符串转换为字节流。

import io
import yaml
def configuration_from_yaml(data):
    fp = io.StringIO(data)
    parsed = yaml.safe_load(fp)
    return configuration_from_dict(parsed)

TOML

TOML(Tom's Own Markup Language)旨在成为 YAML 的轻量级替代品。其规范比较短,已经在一些地方流行了(比如 Rust 的包管理器 Cargo 就用它来进行包配置)。

这是与 TOML 相同的配置:

toml_config = """
[files]
input-dir = "inputs"
output-dir = "outputs"

[parameters]
patterns = [ "*.txt", "*.md",]
"""

为了解析 TOML,你需要安装第三方包。最流行的一种被简单地称为 toml。 与 YAML 和 JSON 一样,它返回基本的 Python 数据类型。

import toml
def configuration_from_toml(data):
    parsed = toml.loads(data)
    return configuration_from_dict(parsed)

总结

选择配置格式是一种微妙的权衡。但是,一旦你做出决定,Python 就可以使用少量代码来解析大多数流行的格式。


via: https://opensource.com/article/21/6/parse-configuration-files-python

作者:Moshe Zadka 选题:lujun9972 译者:zepoch 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

昨天我和一些人在闲聊的时候,他们说他们并不真正了解栈是如何工作的,而且也不知道如何去查看栈空间。

这是一个快速教程,介绍如何使用 GDB 查看 C 程序的栈空间。我认为这对于 Rust 程序来说也是相似的。但我这里仍然使用 C 语言,因为我发现用它更简单,而且用 C 语言也更容易写出错误的程序。

我们的测试程序

这里是一个简单的 C 程序,声明了一些变量,从标准输入读取两个字符串。一个字符串在堆上,另一个字符串在栈上。

#include <stdio.h>
#include <stdlib.h>

int main() {
    char stack_string[10] = "stack";
    int x = 10;
    char *heap_string;

    heap_string = malloc(50);

    printf("Enter a string for the stack: ");
    gets(stack_string);
    printf("Enter a string for the heap: ");
    gets(heap_string);
    printf("Stack string is: %s\n", stack_string);
    printf("Heap string is: %s\n", heap_string);
    printf("x is: %d\n", x);
}

这个程序使用了一个你可能从来不会使用的极为不安全的函数 gets 。但我是故意这样写的。当出现错误的时候,你就知道是为什么了。

第 0 步:编译这个程序

我们使用 gcc -g -O0 test.c -o test 命令来编译这个程序。

-g 选项会在编译程序中将调式信息也编译进去。这将会使我们查看我们的变量更加容易。

-O0 选项告诉 gcc 不要进行优化,我要确保我们的 x 变量不会被优化掉。

第一步:启动 GDB

像这样启动 GDB:

$ gdb ./test

它打印出一些 GPL 信息,然后给出一个提示符。让我们在 main 函数这里设置一个断点:

(gdb) b main

然后我们就可以运行程序:

(gdb) b main
Starting program: /home/bork/work/homepage/test
Breakpoint 1, 0x000055555555516d in main ()

(gdb) run
Starting program: /home/bork/work/homepage/test

Breakpoint 1, main () at test.c:4
4   int main() {

好了,现在程序已经运行起来了。我们就可以开始查看栈空间了。

第二步:查看我们变量的地址

让我们从了解我们的变量开始。它们每个都在内存中有一个地址,我们可以像这样打印出来:

(gdb) p &x
$3 = (int *) 0x7fffffffe27c
(gdb) p &heap_string
$2 = (char **) 0x7fffffffe280
(gdb) p &stack_string
$4 = (char (*)[10]) 0x7fffffffe28e

因此,如果我们查看那些地址的堆栈,那我们应该能够看到所有的这些变量!

概念:栈指针

我们将需要使用栈指针,因此我将尽力对其进行快速解释。

有一个名为 ESP 的 x86 寄存器,称为“ 栈指针 stack pointer ”。 基本上,它是当前函数的栈起始地址。 在 GDB 中,你可以使用 $sp 来访问它。 当你调用新函数或从函数返回时,栈指针的值会更改。

第三步:在 main 函数开始的时候,我们查看一下在栈上的变量

首先,让我们看一下 main 函数开始时的栈。 现在是我们的堆栈指针的值:

(gdb) p $sp
$7 = (void *) 0x7fffffffe270

因此,我们当前函数的栈起始地址是 0x7fffffffe270,酷极了。

现在,让我们使用 GDB 打印出当前函数堆栈开始后的前 40 个字(即 160 个字节)。 某些内存可能不是栈的一部分,因为我不太确定这里的堆栈有多大。 但是至少开始的地方是栈的一部分。

我已粗体显示了 stack_stringheap_stringx 变量的位置,并改变了颜色:

  • x 是红色字体,并且起始地址是 0x7fffffffe27c
  • heap_string 是蓝色字体,起始地址是 0x7fffffffe280
  • stack_string 是紫色字体,起始地址是 0x7fffffffe28e

你可能会在这里注意到的一件奇怪的事情是 x 的值是 0x5555,但是我们将 x 设置为 10! 那是因为直到我们的 main 函数运行之后才真正设置 x ,而我们现在才到了 main 最开始的地方。

第三步:运行到第十行代码后,再次查看一下我们的堆栈

让我们跳过几行,等待变量实际设置为其初始化值。 到第 10 行时,x 应该设置为 10

首先我们需要设置另一个断点:

(gdb) b test.c:10
Breakpoint 2 at 0x5555555551a9: file test.c, line 11.

然后继续执行程序:

(gdb) continue
Continuing.

Breakpoint 2, main () at test.c:11
11      printf("Enter a string for the stack: ");

好的! 让我们再来看看堆栈里的内容! gdb 在这里格式化字节的方式略有不同,实际上我也不太关心这些(LCTT 译注:可以查看 GDB 手册中 x 命令,可以指定 c 来控制输出的格式)。 这里提醒一下你,我们的变量在栈上的位置:

  • x 是红色字体,并且起始地址是 0x7fffffffe27c
  • heap_string 是蓝色字体,起始地址是 0x7fffffffe280
  • stack_string 是紫色字体,起始地址是 0x7fffffffe28e

在继续往下看之前,这里有一些有趣的事情要讨论。

stack_string 在内存中是如何表示的

现在(第 10 行),stack_string 被设置为字符串stack。 让我们看看它在内存中的表示方式。

我们可以像这样打印出字符串中的字节(LCTT 译注:可以通过 c 选项直接显示为字符):

(gdb) x/10x stack_string
0x7fffffffe28e: 0x73    0x74    0x61    0x63    0x6b    0x00    0x00    0x00
0x7fffffffe296: 0x00    0x00

stack 是一个长度为 5 的字符串,相对应 5 个 ASCII 码- 0x730x740x610x630x6b0x73 是字符 s 的 ASCII 码。 0x74t 的 ASCII 码。等等...

同时我们也使用 x/1s 可以让 GDB 以字符串的方式显示:

(gdb) x/1s stack_string
0x7fffffffe28e: "stack"

heap_stringstack_string 有何不同

你已经注意到了 stack_stringheap_string 在栈上的表示非常不同:

  • stack_string 是一段字符串内容(stack
  • heap_string 是一个指针,指向内存中的某个位置

这里是 heap_string 变量在内存中的内容:

0xa0  0x92  0x55  0x55  0x55  0x55  0x00  0x00

这些字节实际上应该是从右向左读:因为 x86 是小端模式,因此,heap_string 中所存放的内存地址 0x5555555592a0

另一种方式查看 heap_string 中存放的内存地址就是使用 p 命令直接打印 :

(gdb) p heap_string
$6 = 0x5555555592a0 ""

整数 x 的字节表示

x 是一个 32 位的整数,可由 0x0a 0x00 0x00 0x00 来表示。

我们还是需要反向来读取这些字节(和我们读取 heap_string 需要反过来读是一样的),因此这个数表示的是 0x000000000a 或者是 0x0a,它是一个数字 10;

这就让我把把 x 设置成了 10

第四步:从标准输入读取

好了,现在我们已经初始化我们的变量,我们来看一下当这段程序运行的时候,栈空间会如何变化:

printf("Enter a string for the stack: ");
gets(stack_string);
printf("Enter a string for the heap: ");
gets(heap_string);

我们需要设置另外一个断点:

(gdb) b test.c:16
Breakpoint 3 at 0x555555555205: file test.c, line 16.

然后继续执行程序:

(gdb) continue
Continuing.

我们输入两个字符串,为栈上存储的变量输入 123456789012 并且为在堆上存储的变量输入 bananas;

让我们先来看一下 stack_string(这里有一个缓存区溢出)

(gdb) x/1s stack_string
0x7fffffffe28e: "123456789012"

这看起来相当正常,对吗?我们输入了 12345679012,然后现在它也被设置成了 12345679012(LCTT 译注:实测 gcc 8.3 环境下,会直接段错误)。

但是现在有一些很奇怪的事。这是我们程序的栈空间的内容。有一些紫色高亮的内容。

令人奇怪的是 stack_string 只支持 10 个字节。但是现在当我们输入了 13 个字符以后,发生了什么?

这是一个典型的缓冲区溢出,stack_string 将自己的数据写在了程序中的其他地方。在我们的案例中,这还没有造成问题,但它会使你的程序崩溃,或者更糟糕的是,使你面临非常糟糕的安全问题。

例如,假设 stack_string 在内存里的位置刚好在 heap_string 之前。那我们就可能覆盖 heap_string 所指向的地址。我并不确定 stack_string 之后的内存里有一些什么。但我们也许可以用它来做一些诡异的事情。

确实检测到了有缓存区溢出

当我故意写很多字符的时候:

 ./test
Enter a string for the stack: 01234567891324143
Enter a string for the heap: adsf
Stack string is: 01234567891324143
Heap string is: adsf
x is: 10
*** stack smashing detected ***: terminated
fish: Job 1, './test' terminated by signal SIGABRT (Abort)

这里我猜是 stack_string 已经到达了这个函数栈的底部,因此额外的字符将会被写在另一块内存中。

当你故意去使用这个安全漏洞时,它被称为“堆栈粉碎”,而且不知何故有东西在检测这种情况的发生。

我也觉得这很有趣,虽然程序被杀死了,但是当缓冲区溢出发生时它不会立即被杀死——在缓冲区溢出之后再运行几行代码,程序才会被杀死。 好奇怪!

这些就是关于缓存区溢出的所有内容。

现在我们来看一下 heap_string

我们仍然将 bananas 输入到 heap_string 变量中。让我们来看一下内存中的样子。

这是在我们读取了字符串以后,heap_string 在栈空间上的样子:

需要注意的是,这里的值是一个地址。并且这个地址并没有改变,但是我们来看一下指向的内存上的内容。

(gdb) x/10x 0x5555555592a0
0x5555555592a0: 0x62    0x61    0x6e    0x61    0x6e    0x61    0x73    0x00
0x5555555592a8: 0x00    0x00

看到了吗,这就是字符串 bananas 的字节表示。这些字节并不在栈空间上。他们存在于内存中的堆上。

堆和栈到底在哪里?

我们已经讨论过栈和堆是不同的内存区域,但是你怎么知道它们在内存中的位置呢?

每个进程都有一个名为 /proc/$PID/maps 的文件,它显示了每个进程的内存映射。 在这里你可以看到其中的栈和堆。

$ cat /proc/24963/maps
... lots of stuff omitted ...
555555559000-55555557a000 rw-p 00000000 00:00 0                          [heap]
... lots of stuff omitted ...
7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0                          [stack]

需要注意的一件事是,这里堆地址以 0x5555 开头,栈地址以 0x7fffff 开头。 所以很容易区分栈上的地址和堆上的地址之间的区别。

像这样使用 gdb 真的很有帮助

这有点像旋风之旅,虽然我没有解释所有内容,但希望看到数据在内存中的实际情况可以使你更清楚地了解堆栈的实际情况。

我真的建议像这样来把玩一下 gdb —— 即使你不理解你在内存中看到的每一件事,我发现实际上像这样看到我程序内存中的数据会使抽象的概念,比如“栈”和“堆”和“指针”更容易理解。

更多练习

一些关于思考栈的后续练习的想法(没有特定的顺序):

  • 尝试将另一个函数添加到 test.c 并在该函数的开头创建一个断点,看看是否可以从 main 中找到堆栈! 他们说当你调用一个函数时“堆栈会变小”,你能在 gdb 中看到这种情况吗?
  • 从函数返回一个指向栈上字符串的指针,看看哪里出了问题。 为什么返回指向栈上字符串的指针是不好的?
  • 尝试在 C 中引起堆栈溢出,并尝试通过在 gdb 中查看堆栈溢出来准确理解会发生什么!
  • 查看 Rust 程序中的堆栈并尝试找到变量!
  • 噩梦课程 中尝试一些缓冲区溢出挑战。每个问题的答案写在 README 文件中,因此如果你不想被宠坏,请避免先去看答案。 所有这些挑战的想法是给你一个二进制文件,你需要弄清楚如何导致缓冲区溢出以使其打印出 flag 字符串。

via: https://jvns.ca/blog/2021/05/17/how-to-look-at-the-stack-in-gdb/

作者:Julia Evans 选题:lujun9972 译者:amwps290 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

比较不同的编程语言如何解决同一个问题是一个很有趣的事情,也很有指导意义。接下来,我们就来讲一讲如何用 Python 来解决。

 title=

在我这一系列的 第一篇文章 里,我描述了这样子的一个问题,如何将一大批的救助物资分为具有相同价值的物品,并将其分发给社区中的困难住户。我也曾写过用不同的编程语言写一些小程序来解决这样子的小问题以及比较这些程序时如何工作的。

在第一篇文章中,我是使用了 Groovy 语言来解决问题的。Groovy 在很多方面都与 Python 很相似,但是在语法上她更像 C 语言和 Java。因此,使用 Python 来创造一个相同的解决方案应该会很有趣且更有意义。

使用 Python 的解决方案

使用 Java 时,我会声明一个工具类来保存元组数据(新的记录功能将会很好地用于这个需求)。使用 Groovy 时,我就是用了该语言的映射功能,我也将在 Python 使用相同的机制。

使用一个字典列表来保存从批发商处批发来的货物:

packs = [
        {'item':'Rice','brand':'Best Family','units':10,'price':5650,'quantity':1},
        {'item':'Spaghetti','brand':'Best Family','units':1,'price':327,'quantity':10},
        {'item':'Sardines','brand':'Fresh Caught','units':3,'price':2727,'quantity':3},
        {'item':'Chickpeas','brand':'Southern Style','units':2,'price':2600,'quantity':5},
        {'item':'Lentils','brand':'Southern Style','units':2,'price':2378,'quantity':5},
        {'item':'Vegetable oil','brand':'Crafco','units':12,'price':10020,'quantity':1},
        {'item':'UHT milk','brand':'Atlantic','units':6,'price':4560,'quantity':2},
        {'item':'Flour','brand':'Neighbor Mills','units':10,'price':5200,'quantity':1},
        {'item':'Tomato sauce','brand':'Best Family','units':1,'price':190,'quantity':10},
        {'item':'Sugar','brand':'Good Price','units':1,'price':565,'quantity':10},
        {'item':'Tea','brand':'Superior','units':5,'price':2720,'quantity':2},
        {'item':'Coffee','brand':'Colombia Select','units':2,'price':4180,'quantity':5},
        {'item':'Tofu','brand':'Gourmet Choice','units':1,'price':1580,'quantity':10},
        {'item':'Bleach','brand':'Blanchite','units':5,'price':3550,'quantity':2},
        {'item':'Soap','brand':'Sunny Day','units':6,'price':1794,'quantity':2}]

大米有一包,每包中有 10 袋大米,意大利面条有十包,每包中有一袋意大利面条。上述代码中,变量 packs 被设置为 Python 字典列表。这与 Groovy 的方法非常相似。关于 Groovy 和 Python 之间的区别,有几点需要注意:

  1. 在 Python 中,无需关键字来定义变量 packs,Python 变量初始化时需要设置一个值。
  2. Python 字典中的词键(例如,itembrandunitspricequantity)需要引号来表明它们是字符串;Groovy 假定这些是字符串,但也接受引号。
  3. 在 Python 中,符号 { ... } 表明一个字典声明; Groovy 使用与列表相同的方括号,但两种情况下的结构都必须具有键值对。

当然,表中的价格不是以美元计算的。

接下来,打开散装包。例如,打开大米的单个散装包装,将产出 10 单元大米; 也就是说,产出的单元总数是 units * quantity。 Groovy 脚本使用一个名为 collectMany 的方便的函数,该函数可用于展平列表列表。 据我所知,Python 没有类似的东西,所以使用两个列表推导式来产生相同的结果:

units = [[{'item':pack['item'],'brand':pack['brand'],
        'price':(pack['price'] / pack['units'])}] *
        (pack['units'] * pack['quantity']) for pack in packs]
units = [x for sublist in units for x in sublist]

第一个列表可理解为(分配给单元)构建字典列表列表。 第二个将其“扁平化”为字典列表。 请注意,Python 和 Groovy 都提供了一个 * 运算符,它接受左侧的列表和右侧的数字 N,并复制列表 N 次。

最后一步是将这些单元的大米之类的重新包装到篮子(hamper)中以进行分发。 就像在 Groovy 版本中一样,你需要更具体地了解理想的篮子数,当你只剩下几个单元时,你最好不要过度限制,即可以做一些随机分配:

valueIdeal = 5000
valueMax = valueIdeal * 1.1

很好! 重新打包篮子。

import random
hamperNumber = 0              # 导入 Python 的随机数生成器工具并初始化篮子数
while len(units) &gt; 0:      # 只要有更多可用的单元,这个 `while` 循环就会将单元重新分配到篮子中:
    hamperNumber += 1
    hamper = []
    value = 0
    canAdd = True              # 增加篮子编号,得到一个新的空篮子(单元的列表),并将其值设为 0; 开始假设你可以向篮子中添加更多物品。
    while canAdd:              # 这个 `while` 循环将尽可能多地向篮子添加单元(Groovy 代码使用了 `for` 循环,但 Python 的 `for` 循环期望迭代某些东西,而 Groovy 则是为更传统的 C 形式的 `for` 循环形式):
        u = random.randint(0,len(units)-1)  # 获取一个介于 0 和剩余单元数减 1 之间的随机数。
        canAdd = False                      # 假设你找不到更多要添加的单元。
        o = 0                               # 创建一个变量,用于从你正在寻找要放入篮子中的物品的起点的偏移量。
        while o < len(units):               # 从随机选择的索引开始,这个 `while` 循环将尝试找到一个可以添加到篮子的单元(再次注意,Python `for` 循环可能不适合这里,因为列表的长度将在迭代中中发生变化)。
            uo = (u + o) % len(units)
            unit = units[uo]
            unitPrice = unit['price']          # 找出要查看的单元(随机起点+偏移量)并获得其价格。
            if len(units) < 3 or not (unit in hamper) and (value + unitPrice) < valueMax:
                                               # 如果只剩下几个,或者添加单元后篮子的价值不太高,你可以将此单元添加到篮子中。
                hamper.append(unit)
                value += unitPrice
                units.pop(u)                   # 将单元添加到篮子中,按单价增加 篮子数,从可用单元列表中删除该单元。
                canAdd = len(units) > 0
                break                          # 只要还有剩余单元,你就可以添加更多单元,因此可以跳出此循环继续寻找。
            o += 1                             # 增加偏移量。
                                            # 在退出这个 `while` 循环时,如果你检查了所有剩余的单元并且找不到单元可以添加到篮子中,那么篮子就完成了搜索; 否则,你找到了一个,可以继续寻找更多。
    print('')
    print('Hamper',hamperNumber,'value',value)
    for item in hamper:
        print('%-25s%-25s%7.2f' % (item['item'],item['brand'],item['price'])) # 打印出篮子的内容。
    print('Remaining units',len(units))                                       # 打印出剩余的单元信息。

一些澄清如上面的注释。

运行此代码时,输出看起来与 Groovy 程序的输出非常相似:

Hamper 1 value 5304.0
UHT milk                 Atlantic                  760.00
Tomato sauce             Best Family               190.00
Rice                     Best Family               565.00
Coffee                   Colombia Select          2090.00
Sugar                    Good Price                565.00
Vegetable oil            Crafco                    835.00
Soap                     Sunny Day                 299.00
Remaining units 148

Hamper 2 value 5428.0
Tea                      Superior                  544.00
Lentils                  Southern Style           1189.00
Flour                    Neighbor Mills            520.00
Tofu                     Gourmet Choice           1580.00
Vegetable oil            Crafco                    835.00
UHT milk                 Atlantic                  760.00
Remaining units 142

Hamper 3 value 5424.0
Soap                     Sunny Day                 299.00
Chickpeas                Southern Style           1300.00
Sardines                 Fresh Caught              909.00
Rice                     Best Family               565.00
Vegetable oil            Crafco                    835.00
Spaghetti                Best Family               327.00
Lentils                  Southern Style           1189.00
Remaining units 135

...

Hamper 21 value 5145.0
Tomato sauce             Best Family               190.00
Tea                      Superior                  544.00
Chickpeas                Southern Style           1300.00
Spaghetti                Best Family               327.00
UHT milk                 Atlantic                  760.00
Vegetable oil            Crafco                    835.00
Lentils                  Southern Style           1189.00
Remaining units 4

Hamper 22 value 2874.0
Sardines                 Fresh Caught              909.00
Vegetable oil            Crafco                    835.00
Rice                     Best Family               565.00
Rice                     Best Family               565.00
Remaining units 0

最后一个篮子在内容和价值上有所简化。

结论

乍一看,这个程序的 Python 和 Groovy 版本之间没有太大区别。 两者都有一组相似的结构,这使得处理列表和字典非常简单。 两者都不需要很多“样板代码”或其他“繁杂”操作。

此外,使用 Groovy 时,向篮子中添加单元还是一件比较繁琐的事情。 你需要在单元列表中随机选择一个位置,然后从该位置开始,遍历列表,直到找到一个价格允许的且包含它的单元,或者直到你用完列表为止。 当只剩下几件物品时,你需要将它们扔到最后一个篮子里。

另一个值得一提的问题是:这不是一种特别有效的方法。 从列表中删除元素、极其多的重复表达式还有一些其它的问题使得这不太适合解决这种大数据重新分配问题。 尽管如此,它仍然在我的老机器上运行。

如果你觉得我在这段代码中使用 while 循环并改变其中的数据感到不舒服,你可能希望我让它更有用一些。 我想不出一种方法不使用 Python 中的 map 和 reduce 函数,并结合随机选择的单元进行重新打包。 你可以吗?

在下一篇文章中,我将使用 Java 重新执行此操作,以了解 Groovy 和 Python 的工作量减少了多少,未来的文章将介绍 Julia 和 Go。


via: https://opensource.com/article/20/9/solve-problem-python

作者:Chris Hermansen 选题:lujun9972 译者:zepoch 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

你如何定义持续集成/持续部署管道取决于你组织的要求。

 title=

持续集成 continuous integration / 持续部署 continuous deployment (CI/CD)管道是每个 DevOps 计划的基础。 CI/CD 管道打破了传统的开发孤岛,使开发和运营团队能够在整个软件开发生命周期中进行协作。

更好的是,转向 DevOps 和 CI/CD 管道可以帮助你的组织以更高的速度更安全地 交付软件

拆解 CI/CD 管道

CI/CD 管道有很多定义,所以我总是建议组织定义自己的 CI/CD 管道版本和其他 DevOps 概念,而不是使用其他人的。开源 CI/CD 工具为你提供构建满足组织要求的 CI/CD 管道的自由和选择。

形成 CI/CD 管道的阶段是将不同的任务子集分组为 管道阶段。典型的管道阶段包括:

  • 构建:开发人员编译应用程序代码。
  • 测试:质量保证(QA)团队使用自动化测试工具和策略测试应用程序代码。
  • 发布:开发团队将应用程序代码交付到代码库。
  • 部署:DevOps 团队将应用程序代码分阶段投入生产。
  • 安全性和合规性:QA 团队根据项目要求验证构建。这是组织部署容器扫描工具的阶段,这些工具根据 常见漏洞和暴露 Common Vulnerabilities and Exposures (CVE)检查容器镜像的质量。

这些是 CI/CD 管道的标准阶段,但一些组织调整 CI/CD 管道模型以满足他们的要求。例如,为医疗保健市场构建应用程序的组织,具有严格的合规性标准,可以在整个工具链中分发测试、验证和合规性门槛。

其他示例可能是依赖于具有开源软件(OSS)的复杂软件供应链的组织。商业组件可能会设立一个门槛,开发团队成员可以在其中为 OSS 包生成 软件物料清单 software bill of materials (SBOM),或者外部商业软件供应商必须将 SBOM 作为其合同可交付成果的一部分进行交付。

CI/CD 管道的障碍

实施 CI/CD 管道会改变团队的流程和文化。尽管许多开发人员愿意接受某些任务和测试的自动化,但人员可能成为采用 CI/CD 的障碍。

从瀑布式流程转向 CI/CD 可能会动摇某些组织中基本的和隐含的权力结构。由于 CI/CD 管道提高了软件交付速度,旧手动流程的“守门人”可能会受到这种变化的威胁。

整合机会

随着你在文化、流程和工具中达到更高的 DevOps 成熟度水平,包含 CI/CD 工具链的工具的开源根源为一些激动人心的集成创造了机会。

分析公司 Forrester 在 2020 年预测, 即时学习 just-in-time learning 将加入 CI/CD 管道。如果你考虑一下,会发现这是有道理的。在当前远程工作的时代,甚至对于新员工的远程入职,这更有意义。例如,组织可以将文档 wiki 与内部流程文档集成到其管道中。

更雄心勃勃的组织可以将学习管理系统(LMS)(例如 Moodle)集成到其 CI/CD 管道中。它可以使用 LMS 发布有关新 DevOps 工具链功能的简短视频,开发人员在加入时或在整个管道中更新工具时需要学习这些功能。

一些组织正在将群聊和其他协作工具直接集成到他们的 CI/CD 管道中。聊天平台提供警报并支持团队之间的协作和沟通。将 Mattermost、Rocket.Chat 或其他 企业聊天 平台集成到你的 CI/CD 管道中需要预先规划和分析,以确保管道用户不会被警报淹没。

另一个需要探索的集成机会是将分析和高级报告构建到你的 CI/CD 管道中。这有助于你利用通过管道传输的数据。

总结

CI/CD 管道是 DevOps 的基础。开源使其能够适应并灵活地满足你在 DevOps 之旅中实施的运营变更所产生的新需求。

我希望看到对统一 DevOps 平台趋势的开源响应,在这种趋势中,组织寻求端到端的 CI/CD 解决方案。这种解决方案的要素就在那里。毕竟,GitLab 和 GitHub 将他们的平台追溯到开源根源。

最后,不要忘记每一个成功的 CI/CD 工具链背后的教育和外展。记录你的工具链和相关流程将改善开发人员入职和持续的 DevOps 团队培训。

你和你的组织如何定义你的 CI/CD 工具链?请在评论中分享你的反馈。


via: https://opensource.com/article/21/6/what-cicd-pipeline

作者:Will Kelly 选题:lujun9972 译者:baddate 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出