This change aims at increasing the default value of the vm.max_map_count sysctl
Owners, do not implement this work until the FESCo vote has explicitly ended. The Fedora Program Manager will create a tracking bug in Bugzilla for this Change, which is your indication to proceed. See the FESCo ticket policy and the Changes policy for more information.
REMINDER: This ticket is for FESCo members to vote on the proposal. Further discussion should happen in the devel list thread linked above.
+1
I think we should try and work with upstream here...
Hmm, there were important questions raised in the fedora-devel thread that didn't receive any real answers. ("Yes, this is an interesting question" is not a real answer ;) ).
In particular @fweimer wrote [1]:
You can play with the following program to overload the kernel with many mappings: ... In my experiments, the kernel OOM handler does not terminate this mapping-creating process, but random desktop services first.
[1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YGTDBA2XENG7GSMHFYZQNIIGCGS3LQCD/
and Roberto Ragusa wrote:
The right question is: is there a value that is high enough for apps (including Steam) and low enough to not be a security danger? I mean from 65530 to 2billion there is a lot of middle ground.
I think it's the role of the Change Owners to answer those questions. This would require some research, or maybe even a lot of research. Before that happens, the change seems very risky.
-1
This is a big hammer for a narrow use case. There's no mention of why this is required for Steam or any potential negative impact for the system.
I have to agree here. I would be open to raising the limit, but not just copying the huge value that SteamOS sets. The "HOWTO"s that are linked for various games use different values (1,048,576, 1,000,000, and 16,777,216, respectively), but all are much lower than the proposed limit of 2,147,483,642 (1-16 million vs. 2 billion).
-1 for setting the limit to vm.max_map_count=2147483642.
vm.max_map_count=2147483642
Agreed, the concerns in the devel thread were not addressed, and not enough justification is given for the proposed limit value. The limit could be, and perhaps should be, increased from its current value, but the work to determine and justify an appropriate new value has not been done.
devel
Tagging this for next FESCo meeting for further discussion
Metadata Update from @amoloney: - Issue tagged with: meeting
This will be discussed at today's meeting at 17:00 UTC.
This was discussed in today's FESCo meeting:
Metadata Update from @zbyszek: - Issue untagged with: meeting
Speaking of limits and safety.
Fully updated Fedora 38 can be killed using the simplest fork bomb:
fork() { fork | fork & } fork
So, if people are concerned about DoS attacks, maybe people should start getting concerned that Fedora out of the box is not foolproof at all.
@aleasto Any progress here?
As noted above the highest value "suggested" by the internets is 16,777,216 on Counter Strike 2, which I could run locally and verify that (at least in a match against bots) doesn't request more than 80,000 mappings. If we can assume that the other games I couldn't test work correctly with their respectively suggested values, then I suggest changing the proposed value to 1,048,576 (2^20), which gets nowhere near killing a 2GB memory machine when running the infamous reproducer.
Can anyone who have the game test Hogwarts Legacy with the settings from previous comment?
Metadata Update from @sgallagh: - Issue tagged with: meeting
Fully updated Fedora 38 can be killed using the simplest fork bomb: ...
...
Are you sure. I just tested this, and while the user cannot fork processes, the machine is stable and other users can log in and/or continue their sessions. Maybe describe your setup and what you mean by "killed".
Fully updated Fedora 38 can be killed using the simplest fork bomb: ... Are you sure. I just tested this, and while the user cannot fork processes, the machine is stable and other users can log in and/or continue their sessions. Maybe describe your setup and what you mean by "killed".
I don't know whether it's a sick joke or what.
I ran this code simple bash code on two of my PCs and both completely froze in less than 10 seconds. Both are running fully updated Fedora 38 installations with default settings with the only exception - no SWAP - I do not use it. I couldn't even start a new shell in a virtual console, as a typed "root", pressed "Enter" and I couldn't enter the password. CPUs were roaring. Ctrl + Alt + Del didn't work either. They were dead.
Should I record a video for you? Including a complete installation process using an official Fedora ISO?
No need to be so defensive. You could instead mention what environment you are using. Gnome?
You could instead mention what environment you are using. Gnome?
This is reproducible even without X.org running. This is reproducible at runlevel 1.
Here's Fedora 38 (Fedora-Xfce-Live-x86_64-38-1.6.iso) VM completely dying within 30 seconds of running this script:
https://mega.nz/file/S9shCAjQ#QPDAO40Opm_mY_plzB84uxZYp9Mb6EEkC0lUFbvqOnE
Takes less time on real hardware as VirtualBox struggles a little bit.
Should I edit the wiki page to reflect the agreed-upon value, and submit a pull request to src.fedoraproject.org? BTW I'm not sure which package should provide this config
Should I edit the wiki page to reflect the agreed-upon value
Yes.
and submit a pull request to src.fedoraproject.org?
BTW I'm not sure which package should provide this config
systemd.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SGPBK5IL5HJ4VMVVSZAXV2P3XZSQMKST/
Metadata Update from @churchyard: - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Metadata Update from @amoloney: - Issue untagged with: meeting - Issue tagged with: pending announcement
Log in to comment on this ticket.