-
-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Kernel: Use write(2) to /dev/(u)random as entropy source #24992
Conversation
Is there an actual use case for this? I don't see any userspace program using this functionality. |
620103c
to
aada144
Compare
Linux and BSDs allow writes to /dev/(u)random to fill the entropy pool (via rng-tools or something fancy like radioactive decay and CCTV footage of lava lambs). Entropy should not be pulled down in case of repetitive input since events get hashed before being sent to RNG and other sources still can get into pool. One mitigation would be changing file perms for random devices |
The fact that you add support for this in the kernel is not an issue. |
If anyone wants to supply software generated/collected entropy or aims to port rng-tools, this feature allows that. Might be used for an userspace driver |
I will probably give this another review in Thursday or Friday. Anyway, we should aim at adding some sort of userspace code to use this functionality. Maybe some port can be added for this? Or just our own code… |
I still have mixed feelings on the topic. On one hand, I really want to see some userspace code doing something useful with this feature. On the other hand, it's really not a big change, so maybe we should just merge it as-is and think about this later on, if you say you will work on it in the future. I will let the maintainers decide on this :) |
b538524
to
b49c330
Compare
Hello! One or more of the commit messages in this PR do not match the SerenityOS code submission policy, please check the |
a write syscall from userspace can now supply entropy pool. This change stands in line with other UNIX-like systems.
We restrict write access to /dev/(u)random. So only root can feed the kernel entropy pool. This is a common practice for hardening.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 on the "I would like to see something use this" front.
@@ -124,7 +124,7 @@ static ErrorOr<void> prepare_bare_minimum_devtmpfs_directory_structure() | |||
TRY(populate_device_node_with_symlink(DeviceNodeType::Character, "/dev/mem"sv, 0600, 1, 1)); | |||
TRY(populate_device_node_with_symlink(DeviceNodeType::Character, "/dev/null"sv, 0666, 1, 3)); | |||
TRY(populate_device_node_with_symlink(DeviceNodeType::Character, "/dev/full"sv, 0666, 1, 7)); | |||
TRY(populate_device_node_with_symlink(DeviceNodeType::Character, "/dev/random"sv, 0666, 1, 8)); | |||
TRY(populate_device_node_with_symlink(DeviceNodeType::Character, "/dev/random"sv, 0644, 1, 8)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there even such a thing as bad entropy? As far as I know/heard, you can't actually hurt the randomness of the RNG by mixing in bad data as long as it is mixed in properly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
RHEL and FreeBSD restrict writes to /dev/random for the sake of hardening so we might adopt this as well
(Or maybe no, there is much more to harvest in user apps)
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions! |
This feature allows userspace to supply the kernel's random event pool by using the
write(2)
system call on random device nodes. This functionality is widely adopted by other UNIX-like systems and allows the use of software events as an entropy source. To mitigate the potential effects of repetitive or malicious input, writing to random device nodes is restricted to the root user.