Hacker News Reader

Comment by Tomte | Hacker News Reader

(Author)

Keep in mind that Linux 5.6 is imminent, and I haven't found time to investigate it beyond some short reporting in LWN, let alone update the article.

But it's still my intention to do that, with some restructuring along the way.

The more changes Linux makes (for the better!) and the more time passes and later versions are in common use, the less the format "tell everyone how bad it is and then backpeddle with sections about every improvement made" works, and the less the title itself stays relevant.

I don't have a good answer for that structural problem, yet, so I'm kind of procrastinating.

View on HN

It’s really quite different. I got rid of all but the block-once-at-boot behavior of /dev/random.

If you know you are targeting a new kernel, using /dev/random is reasonable. Better yet: use getrandom()/getentropy().

On that note, would it kill the OpenBSD guys to get on the getrandom(2) train? I get it, they're dying on the “arc4random is better” hill (and, yes, I agree), but they're literally the last people in the way of making getrandom(2) the new default across not only the usual BSDs and illumos, but also glibc/Linux.

OpenBSD has the getentropy(2) syscall which is pretty much the same. There is no "flags" parameter like in Linux. But the original rationale for having it be a syscall and not a device [not having an extra open(2) call that can fail] is addressed.

arc4random_buf(3) etc. also uses getentropy(2).

From a practical standpoint, I agree (I've started abusing getentropy(2) as a more portable replacement), but it violates the use case though: getentropy(2) is only intended to seed userspace RNGs. Breaking the usage scenario means breaking the API contract.

Doesn't `getrandom(2)` use `RDRAND`? Should hardware RNGs on ME or PSP enabled CPUs be inherently be trusted - I mean don't the BSD folks recommend not enabling hyperthreading due to Spectre, etc.

> Doesn't `getrandom(2)` use `RDRAND`?

Not by itself, no.

> Should hardware RNGs on ME or PSP enabled CPUs be inherently be trusted?

Don't really have any choice. You can't defend against them.

> Doesn't `getrandom(2)` use `RDRAND`?

No.

Would it kill glibc to add arc4random?

No, it wouldn't, but they've made abundantly clear they're not interested in doing anything reasonable the BSDs propose.

You think it's reasonable to have a function called arc4random, even though we know arc4 is insecure and creates biased (i.e. not pseudorandom) output, yet as we know that arc4random really is not "random numbers based on (a)rc4", because internally it's using something secure? So you'd have to actually know that this function named after an insecure stream cipher is a secure way to get random numbers?

I glanced at an online man page for this several minutes ago which informs that though this was originally RC4 based, it now stands for the "a replacement call for random".

Do you work with embedded systems that use glibc? It's bloated.

It's bad enough keeping up with the cruft dreamed up by POSIX; why add BSD functions that nobody uses outside of the BSD microcosm.

Glibc is monolithic; functions that nothing in your system uses are still sitting there in the .so image.

Would it kill the developer to add:

  #if !HAVE_ARC4RANDOM
  uint32_t arc4random_uniform(uint32_t upper_bound)
  {
     // ...
  }
  #endif

to their code? :)

I trust the OpenBSD team to get security right more than I do any other open source group. So no, I don't think a bandwagon argument is going to persuade them.

https://www.openwall.com/lists/oss-security/2020/01/28/3

https://www.openwall.com/lists/oss-security/2020/02/24/5

"Alas, Windows has no such mechanism."

* https://web.archive.org/web/20180825052853/http://jdebp.info...

"At last, [...] Windows has such a mechanism."

* http://jdebp.uk./FGA/capture-console-win32.html

(-:

Reply on news.ycombinator.com