GNU C Library 2.36 released Posted Aug 2, 2022 15:11 UTC (Tue) by jmclnx (guest, #72456) [Link] Interesting, I for one am glad to see arc4random(). Even though I have work-arounds for this, having arc4random() will make my future development easier. GNU C Library 2.36 released Posted Aug 2, 2022 15:59 UTC (Tue) by linuxrocks123 (subscriber, #34648) [Link] (5 responses) So is glibc arc4random cryptographically secure or isn't it? GNU C Library 2.36 released Posted Aug 2, 2022 18:12 UTC (Tue) by geofft (subscriber, #59789) [Link] (4 responses) It looks like Jason's patch was applied before the 2.36 release: https://sourceware.org/git/?p=glibc.git;a=commit;h=eaad4f... The problem was what to do in situations where the PRNG needs to be reseeded/reinitialized, which the kernel has a much better handle on and glibc can maybe guess at. The patch removes a PRNG inside glibc seeded from the kernel one and instead directly relies on the kernel one: if the getrandom() system call is available, just use that, and if not, poll() for /dev/random to be readable to make sure the kernel PRNG is initialized, then read from /dev/urandom. This directly avoids any problems with duplicating in-glibc PRNG state via fork/clone/etc., because there is no more in-process PRNG state, and also helps with cases like resume-from-hibernate where the kernel decides to reseed the kernel PRNG. The patch also changes the documentation for the function to from "Although these functions provide higher random quality than ISO, BSD, and SVID functions, these still use a Pseudo-Random generator and should not be used in cryptographic contexts." to "These functions provide higher random quality than ISO, BSD, and SVID functions, and may be used in cryptographic contexts." So arc4random() in all released versions of glibc is (intended to be) cryptographically secure. GNU C Library 2.36 released Posted Aug 3, 2022 4:05 UTC (Wed) by wahern (subscriber, #37304) [Link] (3 responses) fork/clone wasn't a problem with the use of MADV_WIPEONFORK, available since the 4.14 kernel released nearly 5 years ago. GNU C Library 2.36 released Posted Aug 3, 2022 10:47 UTC (Wed) by njs (subscriber, #40338) [Link] (2 responses) That doesn't help when "forking" an entire VM though; currently only the kernel has any way to know when that's happened. GNU C Library 2.36 released Posted Aug 3, 2022 15:02 UTC (Wed) by zdzichu (subscriber, #17118) [Link] The article talking about this is https://lwn.net/Articles/887207/ (Random numbers and virtual-machine forks). GNU C Library 2.36 released Posted Aug 3, 2022 20:46 UTC (Wed) by wahern (subscriber, #37304) [Link] geofft had distinguished process forking from VM cloning. The implication of my comment was that the only remaining issue is VM cloning, or more generically a mechanism by which the kernel could asynchronously trigger reseeding of user PRNG state upon exogenous events. In theory another madvise flag could be added, e.g. MADV_EPHEMERALSECRET, to wipe a mapping on VM resume or similar event in addition to clone/fork. But a vDSO seems like a much better idea long-term, particularly because it would mean applications could benefit from future changes independent of libc version. There's also the related debate about keeping *any* PRNG state visible within the process. But IMO that seems like a regression back toward a bifurcated world of cryptographically strong and non-cryptographically strong interfaces, and we know that's a world that didn't work out--it's the whole reason for arc4random. The getrandom syscall may be fast, but it's never going to be fast enough. If the gettimeofday syscall isn't fast enough--and it isn't, at least by most people's priorities--then neither could getrandom be fast enough. Many modern protocols and applications consume randomness as heavily or more heavily than gettimeofday--e.g. on every message, every event loop, etc. People would continue bundling their own CSPRNGs just as they do now, which puts us back at square 0. And the value seems especially unclear considering that getrandom remains available all the same. DNS resolver or resolver option? Posted Aug 3, 2022 11:20 UTC (Wed) by fencekicker (guest, #140266) [Link] My reading of the release notes is that they've added an option to the existing DNS resolver, not that they have a new DNS resolver ('The “no-aaaa” DNS stub resolver option has been added.')
Posted Aug 2, 2022 15:11 UTC (Tue) by jmclnx (guest, #72456) [Link]
Posted Aug 2, 2022 15:59 UTC (Tue) by linuxrocks123 (subscriber, #34648) [Link] (5 responses)
GNU C Library 2.36 released Posted Aug 2, 2022 18:12 UTC (Tue) by geofft (subscriber, #59789) [Link] (4 responses) It looks like Jason's patch was applied before the 2.36 release: https://sourceware.org/git/?p=glibc.git;a=commit;h=eaad4f... The problem was what to do in situations where the PRNG needs to be reseeded/reinitialized, which the kernel has a much better handle on and glibc can maybe guess at. The patch removes a PRNG inside glibc seeded from the kernel one and instead directly relies on the kernel one: if the getrandom() system call is available, just use that, and if not, poll() for /dev/random to be readable to make sure the kernel PRNG is initialized, then read from /dev/urandom. This directly avoids any problems with duplicating in-glibc PRNG state via fork/clone/etc., because there is no more in-process PRNG state, and also helps with cases like resume-from-hibernate where the kernel decides to reseed the kernel PRNG. The patch also changes the documentation for the function to from "Although these functions provide higher random quality than ISO, BSD, and SVID functions, these still use a Pseudo-Random generator and should not be used in cryptographic contexts." to "These functions provide higher random quality than ISO, BSD, and SVID functions, and may be used in cryptographic contexts." So arc4random() in all released versions of glibc is (intended to be) cryptographically secure. GNU C Library 2.36 released Posted Aug 3, 2022 4:05 UTC (Wed) by wahern (subscriber, #37304) [Link] (3 responses) fork/clone wasn't a problem with the use of MADV_WIPEONFORK, available since the 4.14 kernel released nearly 5 years ago. GNU C Library 2.36 released Posted Aug 3, 2022 10:47 UTC (Wed) by njs (subscriber, #40338) [Link] (2 responses) That doesn't help when "forking" an entire VM though; currently only the kernel has any way to know when that's happened. GNU C Library 2.36 released Posted Aug 3, 2022 15:02 UTC (Wed) by zdzichu (subscriber, #17118) [Link] The article talking about this is https://lwn.net/Articles/887207/ (Random numbers and virtual-machine forks). GNU C Library 2.36 released Posted Aug 3, 2022 20:46 UTC (Wed) by wahern (subscriber, #37304) [Link] geofft had distinguished process forking from VM cloning. The implication of my comment was that the only remaining issue is VM cloning, or more generically a mechanism by which the kernel could asynchronously trigger reseeding of user PRNG state upon exogenous events. In theory another madvise flag could be added, e.g. MADV_EPHEMERALSECRET, to wipe a mapping on VM resume or similar event in addition to clone/fork. But a vDSO seems like a much better idea long-term, particularly because it would mean applications could benefit from future changes independent of libc version. There's also the related debate about keeping *any* PRNG state visible within the process. But IMO that seems like a regression back toward a bifurcated world of cryptographically strong and non-cryptographically strong interfaces, and we know that's a world that didn't work out--it's the whole reason for arc4random. The getrandom syscall may be fast, but it's never going to be fast enough. If the gettimeofday syscall isn't fast enough--and it isn't, at least by most people's priorities--then neither could getrandom be fast enough. Many modern protocols and applications consume randomness as heavily or more heavily than gettimeofday--e.g. on every message, every event loop, etc. People would continue bundling their own CSPRNGs just as they do now, which puts us back at square 0. And the value seems especially unclear considering that getrandom remains available all the same.
Posted Aug 2, 2022 18:12 UTC (Tue) by geofft (subscriber, #59789) [Link] (4 responses)
The problem was what to do in situations where the PRNG needs to be reseeded/reinitialized, which the kernel has a much better handle on and glibc can maybe guess at. The patch removes a PRNG inside glibc seeded from the kernel one and instead directly relies on the kernel one: if the getrandom() system call is available, just use that, and if not, poll() for /dev/random to be readable to make sure the kernel PRNG is initialized, then read from /dev/urandom. This directly avoids any problems with duplicating in-glibc PRNG state via fork/clone/etc., because there is no more in-process PRNG state, and also helps with cases like resume-from-hibernate where the kernel decides to reseed the kernel PRNG.
The patch also changes the documentation for the function to from "Although these functions provide higher random quality than ISO, BSD, and SVID functions, these still use a Pseudo-Random generator and should not be used in cryptographic contexts." to "These functions provide higher random quality than ISO, BSD, and SVID functions, and may be used in cryptographic contexts."
So arc4random() in all released versions of glibc is (intended to be) cryptographically secure.
GNU C Library 2.36 released Posted Aug 3, 2022 4:05 UTC (Wed) by wahern (subscriber, #37304) [Link] (3 responses) fork/clone wasn't a problem with the use of MADV_WIPEONFORK, available since the 4.14 kernel released nearly 5 years ago. GNU C Library 2.36 released Posted Aug 3, 2022 10:47 UTC (Wed) by njs (subscriber, #40338) [Link] (2 responses) That doesn't help when "forking" an entire VM though; currently only the kernel has any way to know when that's happened. GNU C Library 2.36 released Posted Aug 3, 2022 15:02 UTC (Wed) by zdzichu (subscriber, #17118) [Link] The article talking about this is https://lwn.net/Articles/887207/ (Random numbers and virtual-machine forks). GNU C Library 2.36 released Posted Aug 3, 2022 20:46 UTC (Wed) by wahern (subscriber, #37304) [Link] geofft had distinguished process forking from VM cloning. The implication of my comment was that the only remaining issue is VM cloning, or more generically a mechanism by which the kernel could asynchronously trigger reseeding of user PRNG state upon exogenous events. In theory another madvise flag could be added, e.g. MADV_EPHEMERALSECRET, to wipe a mapping on VM resume or similar event in addition to clone/fork. But a vDSO seems like a much better idea long-term, particularly because it would mean applications could benefit from future changes independent of libc version. There's also the related debate about keeping *any* PRNG state visible within the process. But IMO that seems like a regression back toward a bifurcated world of cryptographically strong and non-cryptographically strong interfaces, and we know that's a world that didn't work out--it's the whole reason for arc4random. The getrandom syscall may be fast, but it's never going to be fast enough. If the gettimeofday syscall isn't fast enough--and it isn't, at least by most people's priorities--then neither could getrandom be fast enough. Many modern protocols and applications consume randomness as heavily or more heavily than gettimeofday--e.g. on every message, every event loop, etc. People would continue bundling their own CSPRNGs just as they do now, which puts us back at square 0. And the value seems especially unclear considering that getrandom remains available all the same.
Posted Aug 3, 2022 4:05 UTC (Wed) by wahern (subscriber, #37304) [Link] (3 responses)
GNU C Library 2.36 released Posted Aug 3, 2022 10:47 UTC (Wed) by njs (subscriber, #40338) [Link] (2 responses) That doesn't help when "forking" an entire VM though; currently only the kernel has any way to know when that's happened. GNU C Library 2.36 released Posted Aug 3, 2022 15:02 UTC (Wed) by zdzichu (subscriber, #17118) [Link] The article talking about this is https://lwn.net/Articles/887207/ (Random numbers and virtual-machine forks). GNU C Library 2.36 released Posted Aug 3, 2022 20:46 UTC (Wed) by wahern (subscriber, #37304) [Link] geofft had distinguished process forking from VM cloning. The implication of my comment was that the only remaining issue is VM cloning, or more generically a mechanism by which the kernel could asynchronously trigger reseeding of user PRNG state upon exogenous events. In theory another madvise flag could be added, e.g. MADV_EPHEMERALSECRET, to wipe a mapping on VM resume or similar event in addition to clone/fork. But a vDSO seems like a much better idea long-term, particularly because it would mean applications could benefit from future changes independent of libc version. There's also the related debate about keeping *any* PRNG state visible within the process. But IMO that seems like a regression back toward a bifurcated world of cryptographically strong and non-cryptographically strong interfaces, and we know that's a world that didn't work out--it's the whole reason for arc4random. The getrandom syscall may be fast, but it's never going to be fast enough. If the gettimeofday syscall isn't fast enough--and it isn't, at least by most people's priorities--then neither could getrandom be fast enough. Many modern protocols and applications consume randomness as heavily or more heavily than gettimeofday--e.g. on every message, every event loop, etc. People would continue bundling their own CSPRNGs just as they do now, which puts us back at square 0. And the value seems especially unclear considering that getrandom remains available all the same.
Posted Aug 3, 2022 10:47 UTC (Wed) by njs (subscriber, #40338) [Link] (2 responses)
GNU C Library 2.36 released Posted Aug 3, 2022 15:02 UTC (Wed) by zdzichu (subscriber, #17118) [Link] The article talking about this is https://lwn.net/Articles/887207/ (Random numbers and virtual-machine forks). GNU C Library 2.36 released Posted Aug 3, 2022 20:46 UTC (Wed) by wahern (subscriber, #37304) [Link] geofft had distinguished process forking from VM cloning. The implication of my comment was that the only remaining issue is VM cloning, or more generically a mechanism by which the kernel could asynchronously trigger reseeding of user PRNG state upon exogenous events. In theory another madvise flag could be added, e.g. MADV_EPHEMERALSECRET, to wipe a mapping on VM resume or similar event in addition to clone/fork. But a vDSO seems like a much better idea long-term, particularly because it would mean applications could benefit from future changes independent of libc version. There's also the related debate about keeping *any* PRNG state visible within the process. But IMO that seems like a regression back toward a bifurcated world of cryptographically strong and non-cryptographically strong interfaces, and we know that's a world that didn't work out--it's the whole reason for arc4random. The getrandom syscall may be fast, but it's never going to be fast enough. If the gettimeofday syscall isn't fast enough--and it isn't, at least by most people's priorities--then neither could getrandom be fast enough. Many modern protocols and applications consume randomness as heavily or more heavily than gettimeofday--e.g. on every message, every event loop, etc. People would continue bundling their own CSPRNGs just as they do now, which puts us back at square 0. And the value seems especially unclear considering that getrandom remains available all the same.
Posted Aug 3, 2022 15:02 UTC (Wed) by zdzichu (subscriber, #17118) [Link]
Posted Aug 3, 2022 20:46 UTC (Wed) by wahern (subscriber, #37304) [Link]
There's also the related debate about keeping *any* PRNG state visible within the process. But IMO that seems like a regression back toward a bifurcated world of cryptographically strong and non-cryptographically strong interfaces, and we know that's a world that didn't work out--it's the whole reason for arc4random. The getrandom syscall may be fast, but it's never going to be fast enough. If the gettimeofday syscall isn't fast enough--and it isn't, at least by most people's priorities--then neither could getrandom be fast enough. Many modern protocols and applications consume randomness as heavily or more heavily than gettimeofday--e.g. on every message, every event loop, etc. People would continue bundling their own CSPRNGs just as they do now, which puts us back at square 0. And the value seems especially unclear considering that getrandom remains available all the same.
Posted Aug 3, 2022 11:20 UTC (Wed) by fencekicker (guest, #140266) [Link]
Copyright © 2022, Eklektix, Inc. Comments and public postings are copyrighted by their creators. Linux is a registered trademark of Linus Torvalds
LWN