ZSystems/QAndALinuxONE

LinuxONE 实例的问答

这应该是一个问题和答案的集合，新用户在首次使用 LinuxONE 实例时可能会遇到。

各种问题（及其各自的答案）

=== 问题： 作为 Linux 用户，所有工具看起来都与我的“正常”笔记本电脑/PC/... 相同。那么，有什么不同？我需要注意哪些 s390x 特定的事情？ ===

答案

除非您特别注意，否则您不会注意到 - 使用诸如 df、dmesg、lsmod 之类的命令。请参阅下面的项目以获取更多详细信息

字节顺序是大端字节序

维基百科关于字节序的文章

大端

各种 z 相关的提示在 dmesg 输出中

setup: Linux is running as a z/VM guest operating system in 64-bit mode
[...]
[    2.862483] zpci: PCI is not supported because CPU facilities 69 or 71 are not available
[...]
[   13.968627] systemd[1]: Configuration file /usr/lib/systemd/system/zvmguestconfigure.service...
[...]
[    8.195237] dasd-fba 0.0.0100: New FBA DASD 9336/10 (CU 6310/80) with 102400 MB and 512 B/blk
[    8.269081] qeth: loading core functions
[    8.290952]  dasda:(nonl) dasda1
[    9.445010] EXT4-fs (dasda1): mounted filesystem 8b6b381b-7e74-4634-ab7e-330b20ab1b6d with ordered data mode. Quota mode: none.
[...]
[   17.960600] qeth: register layer 2 discipline
[   18.014944] qeth 0.0.1000: CHID: ff00 CHPID: 0
[   18.029199] qeth 0.0.1002: qdio: OSA on SC 2 using AI:1 QEBSM:0 PRI:1 TDD:1 SIGA:RW 
[   18.064899] qeth 0.0.1000: Device is a Virtual NIC QDIO card (level: V724)
               with link type Virt.NIC QDIO.
[   18.087252] qeth 0.0.1000: MAC address 02:c1:21:88:50:bc successfully registered
[   18.181707] vmur: z/VM virtual unit record device driver loaded.
[   18.282210] qeth 0.0.1000 eth1000: renamed from eth0

摘要： z/VM (vmur), zpci (由于缺少 CPU 功能[1] 不支持), qeth, dasd, zvmguestconfigure.service

[1]: CPU 本身并不缺少这些功能 69 和 71；它们只是在 z/VM 中“未启用”（至少对于我们的 LinuxONE 实例而言）

来自 dracut：initrd 镜像的不同模块

dracut: *** Including module: zipl ***
dracut: *** Including module: dasd_mod ***
dracut: *** Including module: dasd_rules ***
[...]
dracut: Stored kernel commandline:
dracut: rd.cio_accept=0.0.1000,0.0.1001,0.0.1002,0.0.1000,0.0.1001,0.0.1002
dracut: rd.dasd=0.0.0100
dracut:  root=/dev/disk/by-path/ccw-0.0.0100-part1 rootfstype=ext4 rootflags=rw,relatime

s390x 系统有两种类型的磁盘。通常的磁盘，如 /dev/sd[a-z][0-9]+，以及其他磁盘，如 /dev/dasd<x>。您看到的内容取决于系统管理员的配置。
cat /proc/cpuinfo 或 lscpu 输出差异很大（不应感到惊讶，因为我们不在 x86_x64 上，但仍然值得一提）
(类似地，对于 uname：)

uname -m
s390x

注意 lsmod 命令输出中的 s390 特定模块。更确切地说

lsmod | grep s390
s390_trng              16384  0
crc32_vx_s390          16384  2
ghash_s390             16384  0
chacha_s390            20480  0
libchacha              16384  1 chacha_s390
aes_s390               28672  0
des_s390               20480  0
libdes                 28672  1 des_s390
sha3_512_s390          16384  0
sha3_256_s390          16384  0
sha512_s390            16384  0
sha256_s390            16384  0
sha1_s390              16384  0
sha_common             16384  5 sha3_256_s390,sha512_s390,sha256_s390,sha1_s390,sha3_512_s390
rng_core               24576  2 zcrypt,s390_trng

lsmod | grep dasd
dasd_diag_mod          20480  0
dasd_fba_mod           20480  4
dasd_mod              172032  4 dasd_diag_mod,dasd_fba_mod

lsmod | grep qeth                                                                                                               0:53:16
qeth_l2                61440  1
qeth                  155648  1 qeth_l2
ccwgroup               24576  1 qeth
qdio                   53248  1 qeth
bridge                344064  2 br_netfilter,qeth_l2

(我知道这些可能不是所有 s390 特定模块。如果我遗漏了任何模块，请告诉我。提前感谢。)

了解有关您的 s390x/LinuxONE 实例的更多信息的关键软件包：s390-tools

问题： `lscpu` 告诉我 `s390x` 架构也受到 Spectre v1/v2 的影响。为什么？不是 Spectre 漏洞仅限于 Intel CPU 并且是 `x86-64` 架构吗？

答案： 我通过各种邮件从 Marcus Meisser（SUSE 安全团队成员）那里获得了非常有趣的答案。我请求他允许我在此引用他的答案

lscpu outputs what the kernel reports via sysfs in
/sys/devices/system/cpu/vulnerabilities/, so it is "truth".

Some details:

Spectre v1 is a class vulnerability affecting all modern CPUs that have
transient execution. (e.g. where the CPU speculatively executes code
ahead and does data prefetches based on speculative results).

Spectre v2 is also a class vulnerability affecting some classes of CPUs,
including IBM Z, where transient execution / speculation happens over
indirect (computed) jumps.

Both affect and need to be addressed not just in host also in guest kernels.

- Spectre v1 will likely never be fixed CPU wise, as this would otherwise
  lose LOTS of performance.

  Instead software has been made responsible to avoid these Spectre v1
  problem code patterns on selected privileged software parts, like the
  Linux Kernel.

- Spectre v2 can be fixed CPU side, but depending on Vendor and their
  schedule. Until the CPU is fixed, or if the vendor decided not to fix
  the CPU, again specific workaround code patterns must be used in
  privileged software.


As you see in the output above "Mitigation: ..." means that the guest
kernel has been supplied with mitigations / workarounds for both issues
and so is not affected anymore.

Spectre v1 will NEVER be fixed on the CPU side as I wrote, as
speculation is a core part of the performance of current CPUs.

So for Spectre v1 there is always need for Mitigations / adjusted
Software.

For Spectre v2 it depends on the CPU vendor, they might also chose
to require specific software adjustments, perhaps this is the final
state on IBM side.

I did some quick google but it did not find the IBM Z guidance on Spectre v2.
I think etokens are the final mitigation for it though.


So to be clear:

- CPUS continue to be AFFECTED (intentionally to not lose performance).
- Software is however applying MITIGATIONS to these issues where needed.

I would be interested on a pointer to IBM Z on Spectre v2 programming
guidance, but otherwise I think everything is right.

关于我的评论

> The "all modern CPUs" is decisive here - I honestly wasn't aware of that
> (read: I had the (obviously false) impression that it's an "Intel only"
> thing). So, if I draw the right conclusion: There's NO modern CPU that's NOT
> affected by Spectre v1/2 vulns by default - it concerns ALL CPUs by default.
> Is my conclusion correct?

Spectre v1, yes.

I am not 100% up to date on all CPUs, but this kind of transient
execution is usually a "performance feature".

        Intel, IBM Z, IBM Power, Arm AArch64 do that at least.

Spectre v2 ... it depends a bit on the CPU, not sure if all of the
modern ones still have the problem.
 (e.g. if they have a speculative barrier on an indirect jump)

关于我的问题

> But why can a software solution in the kernel get by (almost) WITHOUT performance
> loss whereas if the bug were fixed in CPU microcode, it would cost LOTS of
> performance?

In the CPU you would need to stop the speculative execution at nearly any kind
of data accesses as the CPU does not know which could be exploited and
which not.

These days, the speculative pipelines can look 100+ instructions ahead
and do computations already.

If you would stop it, the look ahead would go down to perhaps something
around 5 instructions, leading to a severe loss of performance.

On the software side though there is an additional fix. Simplified:

Instead of:

        if (a < maxsize) {
                return b[a];
        }
where the speculation would already access b[a] regardless of the check
on a, the new code does:

        if (a < maxsize) {
                a = a & bit_mask_based_on(a,maxsize);
                return b[a];
        }

The bit_mask_based_on() function is a weird function, which will return
0 if a >= maxsize, and a full sized 1111 pattern if not.

include/linux/nospec.h from the Kernel:
         return ~(long)(index | (size - 1UL - index)) >> (BITS_PER_LONG - 1);

so basically the speculation takes also the array size via a logical
expression and this removes the out of bounds speculative read possibilities.

This piece of code causes a very slight overhead, but fully avoids the
speculation overread. A out of bounds index is never going into the
address calculation as it is would be masked to 0.

问题：对于 `x86_64` 架构，有大量的文档可用于解释 CPU 特定的标志（在 `/proc/cpuinfo` 输出中找到）。但是对于 `s390x` 有类似的东西吗？

答案： 幸运的是，Ihno Krumreich 提供了一个列表（最初通过邮件；我明确请求允许我也在此处发布它（感谢 Ihno！非常感谢！）

**`s390x` 特定 CPU 功能标志**
标志（缩写）	含义（简短说明）
`dflt`	硬件加速压缩
`dfp`	十进制浮点指令，请参阅第 20 章，操作原理
`edat`	增强型动态地址转换 2 (`edat` 作为一项功能表示 1 MB 巨型页面支持)。
`msa`	消息安全辅助（支持签名和数据加密算法）=> 表明安装了 CPACF。
`sie`	启动解释性执行（Linux 实例可以是虚拟机管理程序；z/VM 实例）
`stfle`	存储在第二个操作数地址开始的双字处的一系列位提供有关设施的信息。
`vx`	指示可用向量扩展设施
`vxd`	向量十进制设施
`vxe`	向量增强设施 1
`vxe2`	向量增强设施 2
`vxp`	？（待定；很可能也以某种方式与向量相关）

问题：几个桌面环境/窗口管理器/图形应用程序也已移植到 `s390x`。我如何使用它们（远程）？

答案： 请参阅 ZSystems/GraphicalApplicationsLinuxONE 关于使用虚拟帧缓冲 X 服务器 (Xvfb；用于获取 DISPLAY) 以及 VNC 服务器（自动连接到找到的第一个 DISPLAY）和 SSH 隧道（用于防止以明文传输 VNC 密码）

待定： 等待 IBM 回答如何测试模拟的显卡以及它是否在我们的 LinuxONE 实例上可用（或者仅在 kvm 或 qemu 中可用）。

问题：如何让上游开源项目在 Github Actions 中集成 s390x 测试作为 CI/CD？

答案： IBM 已经在后台为 Github 和 Github Actions 提供了大型机。您可以集成不同架构的测试。您可以在 Github 参考指南中找到教程。

问题：为什么 `s390-tools` 包也为 `x86_64` 架构编译，而它实际上仅适用于/对 s390x 架构有用？

答案： （由 Miroslav "Mirek" Franc 在 ZSystems 邮件列表中提供；感谢/致敬/赞扬他 ;-)）

The reasons are the IBM secure execution features[1] related utilites such
as managing ultravisor secrets (pvsecret utility), generating secure
execution images (genprotimg utility) and managing attestations
(pvattest utility) which can be done from x86_64 workstation.[2][3] In
theory from any other architecture, but I assume x86_64 is the most
important one.


[1] https://www.ibm.com/docs/en/linuxonibm/pdf/lx24se04.pdf
[2] https://www.ibm.com/docs/en/linux-on-systems?topic=execution-attesting#t_attest
[3] https://video.ibm.com/recorded/132127046

链接

ZSystems/QAndALinuxONE

LinuxONE 实例的问答

各种问题（及其各自的答案）

问题： lscpu 告诉我 s390x 架构也受到 Spectre v1/v2 的影响。 为什么？ 不是 Spectre 漏洞仅限于 Intel CPU 并且是 x86-64 架构吗？

问题： 对于 x86_64 架构，有大量的文档可用于解释 CPU 特定的标志（在 /proc/cpuinfo 输出中找到）。 但是对于 s390x 有类似的东西吗？

问题： 几个桌面环境/窗口管理器/图形应用程序也已移植到 s390x。 我如何使用它们（远程）？

问题： 如何让上游开源项目在 Github Actions 中集成 s390x 测试作为 CI/CD？

问题： 为什么 s390-tools 包也为 x86_64 架构编译，而它实际上仅适用于/对 s390x 架构有用？

问题： `lscpu` 告诉我 `s390x` 架构也受到 Spectre v1/v2 的影响。为什么？不是 Spectre 漏洞仅限于 Intel CPU 并且是 `x86-64` 架构吗？

问题：对于 `x86_64` 架构，有大量的文档可用于解释 CPU 特定的标志（在 `/proc/cpuinfo` 输出中找到）。但是对于 `s390x` 有类似的东西吗？

问题：几个桌面环境/窗口管理器/图形应用程序也已移植到 `s390x`。我如何使用它们（远程）？

问题：如何让上游开源项目在 Github Actions 中集成 s390x 测试作为 CI/CD？

问题：为什么 `s390-tools` 包也为 `x86_64` 架构编译，而它实际上仅适用于/对 s390x 架构有用？