我昨天发现了这一点，因为它在原本空闲的 Ubuntu 14.04 桌面机器上产生了系统负载。
今天，我在另一个 Ubuntu 实例（Virtualbox VM 中的 17.10）上也确认了这种行为
命令行中的子进程如下所示（我故意将其放在下面的图片中以防止 askubuntu.com 更改/转义内容）
在我看来，它看起来像是漏洞/恶意软件。或者至少有一些东西需要隐藏。
即使是 url 也会发生这种情况https://www.google.com/
答案1
这与 Firefox 的多进程功能有关，请通过以下官方链接进行操作。
https://support.mozilla.org/en-US/questions/1147868#answer-938004
关于此问题还有许多其他 Linux 线程，其输出与您发布的相同，都与 Firefox 的多进程功能有关。
答案2
Firefox 的最新版本正在运行多进程而不是单进程。
多进程适用于所有 Firefox 用户，因为Firefox 54 于 2017 年 6 月首次亮相。 这多进程 Firefox文档中描述了 Firefox 在与 Web 内容不同的进程中运行浏览器 UI。因此，用户可能会在进程列表中看到“可疑子进程”。
许多最终用户似乎对子流程的神秘部分感到担忧，正如mozillaZine 上的这个论坛和Mozilla 支持上的此论坛主题；太多了，无法在此引用。
直接答案
对我来说，它看起来像漏洞/恶意软件（子进程是恶意的吗？）
不，最近版本的 Firefox 行为就是这样的。
或者至少有一些东西需要隐藏（有什么需要隐藏吗？）
不。最终用户看到的内容可能与开发人员看到的内容不同；很少有用户可能注意到没有任何隐藏内容。
如何确定
有两个原因我们可以确定：
开发人员没有费心解释子进程的细节，这就是我们可以肯定这不是恶意的原因。至少，到目前为止我还没有发现这样的细节。
这是 Stack Overflow 上 TT Farreo 的部分回答在 2017 年末暗示子进程的神秘部分与 Mozilla 的黑名单字符列表有关。
来自 Stack Overflow 的部分答案：
奇怪的角色列表似乎与http://kb.mozillazine.org/Network.IDN.blacklist_chars[...]
现在我们可以理解这些奇怪的字符了：
- 看到那些分数字符了吗？检查过了。
- 看到那些二进制块字符了吗？检查过了。
- 看到那些看不见的空间了吗？检查过了。
- 看到那个被压扁的弧度单位了吗？已经检查过了。
- 看到黑色菱形问号了吗？已检查。
Stack Overflow 上的答案还包含 Firefox 使用的内容处理源代码的链接。最终用户通常不会深入研究那么多细节，这就是为什么 Ask Ubuntu 上的这个答案本身就足够好了。
子流程正常，一切正常。
答案3
我昨晚注意到了同样的事情，并开始用它检查xxd。我最好的猜测是会一直认为这是传达指向共享资源的指针或识别自身的方式（相邻的虚拟位置和恒定的长度会导致周期性），但有几件事让我相信并非如此。
c783 cb90 3f3f d689 d68a d783
d7b4 d889 d88a d9aa db94 dc81
dc82 dc83 dc84 e185 9fe1 85a0
e19c b5e2 8080 e280 81e2 8082
e280 83e2 8084 e280 85e2 8086
e280 87e2 8088 e280 89e2 808a
3f3f 3fe2 8090 e280 99e2 80a4
e280 a73f 3f3f 3f3f 3f3f e280
afe2 80b9 e280 bae2 8181 e281
84e2 8192 e281 9fe2 8593 e285
94e2 8595 e285 96e2 8597 e285
98e2 8599 e285 9a3f e285 9ce2
859d e285 9ee2 859f e288 95e2
88b6 e28e aee2 95b1 e2a7 b6e2
a7b8 e2ab bbe2 abbd e2bf b0e2
bfb1 e2bf b2e2 bfb3 e2bf b4e2
bfb5 e2bf b6e2 bfb7 e2bf b8e2
bfb9 e2bf bae2 bfbb e380 80e3
8082 e380 94e3 8095 e380 b3e3
82a0 e385 a4e3 889d e388 9ee3
8eae e38e afe3 8f86 e38f 9fea
9e89 efb8 94ef b895 efb8 bfef
b99d efb9 9e3f efbc 8eef bc8f
efbd a1ef bea0 3f3f 3fef bfbc
efbf bd0a
我修剪到前一个换行符（并将其保留0a在末尾）。我仅根据重复来对齐它，即每行 12 个字节，直到第 25 行的部分。我以这种方式分隔字节的原因是为了显示（看起来像）UTF8 延续（底部的表格。）但是，值得一提的是，遵循已建立的和众所周知的编码惯例提供了相同的好处：您可以表示大值，但保持小值紧凑。另一方面，由于某种原因，它们似乎串在一起?，只有大于 80 的字节。该维基百科页面的下一部分显示，此范围内有可打印字符，但数量更少，间隔更远。我不认为目标与编写非常宽的 UTF8 字符有任何关系，而是他们似乎在避免使用 ASCII 集中更普遍可打印的字符。此时我能想到的最好的是，他们知道他们必须编码和嵌入任意长度的字符串，即“stringPrefs”，并且可能选择使用夹在低字节之间的高字节，只是为了更容易提取。据我所知，它们?既用作分隔符，又用作填充。
我并不满意，但我也没什么可以提供的了。为了我自己的利益，我开始替换最常见的字符，这样更容易看出发生了什么：
c783 cb90 d689 d68a d783
d7b4 d889 d88a d9aa db94 dc81
dc82 dc83 dc84 e185 9fe1 85a0
e19c b5++ ---- ++-- 81++ --82
++-- 83++ --84 ++-- 85++ --86
++-- 87++ --88 ++-- 89++ --8a
++ --90 ++-- 99++ --a4
++-- a7 ++--
af++ --b9 ++-- ba++ 8181 ++81
84++ 8192 ++81 9f++ 8593 ++85
94++ 8595 ++85 96++ 8597 ++85
98++ 8599 ++85 9a ++85 9c++
859d ++85 9e++ 859f ++88 95++
88b6 ++8e ae++ 95b1 ++a7 b6++
a7b8 ++ab bb++ abbd ++bf b0++
bfb1 ++bf b2++ bfb3 ++bf b4++
bfb5 ++bf b6++ bfb7 ++bf b8++
bfb9 ++bf ba++ bfbb e3-- --e3
--82 e3-- 94e3 --95 e3-- b3e3
82a0 e385 a4e3 889d e388 9ee3
8eae e38e afe3 8f86 e38f 9fea
9e89 efb8 94ef b895 efb8 bfef
b99d efb9 9e efbc 8eef bc8f
efbd a1ef bea0 ef bfbc
efbf bd0a
我看到的加密和编码字符串的结构比我预期的要多得多，除非这是某种隐写术。如果有人能接过接力棒，我会很感激，这不仅仅是因为我很好奇——如果有什么事情发生，我希望早点知道值得躲在那里。