
Linux Kernel 5.3 - AlexDGe
https://www.omgubuntu.co.uk/2019/09/linux-5-3-kernel-release-features
======
thestoicattack
An interesting discussion in Linus's release announcement email about
userspace regressions:
[https://lkml.org/lkml/2019/9/15/241](https://lkml.org/lkml/2019/9/15/241)

~~~
duckerude
More technical details here:
[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.3&id=72dbcf72156641fde4d8ea401e977341bfd35a05)

~~~
rHcsgjuuHw
> Do we just make it act like /dev/urandom by default, and add a new flag for
> "wait for entropy"?

Dear God. The CSPRNG situation on Linux is deeply depressing.

/dev/urandom is useless because it spews non-random data if it hasn't been
seeded yet.

/dev/random is useless because it starts blocking if you try to read too much
data from it, because of a mistaken belief that a properly seeded CSPRNG can
run out of entropy.

Plus they're both slow as hell, so people try to implement their own PRNGs,
often having bugs in the generator or seeding, leading to security issues.

Meanwhile the BSDs have handled this correctly for years. But inexplicably,
instead of actually fixing /dev/(u)random, the Linux engineers decide to add a
new getrandom() syscall which implements the correct behaviour of only
blocking if the PRNG hasn't been seeded.

So finally with getrandom() Linux has a way to securely generate random data
without unnecessarily blocking, and now Linus seems to be floating the idea to
break it again!

The kernel has plenty of ways to securely seed a PRNG at boot on modern
systems; IRQ timings, multicore tricks, sensor data, etc. Run some statistical
tests on it to ensure you have a couple hundred bits of randomness and you're
done.

~~~
ploxiln
> So finally with getrandom() Linux has a way to securely generate random data
> without unnecessarily blocking, and now Linus seems to be floating the idea
> to break it again!

Yes, getrandom() works pretty much the "right" way. But the problem is that it
still can block during boot, indefinitely. And nobody really wants their
computer to just stop working, because it can't _guarantee_ that the entropy
is not theoretically possibly "bad". Real users do not want this. But it
happens.

The root of this is security paranoia. Security people didn't want the RDRAND
instruction to be trusted. SystemD didn't credit the entropy pool when adding
the saved seed file from the previous boot, until very recently it got an
option to credit the entropy pool. These things are all mixed into the pool,
and on any desktop machine /dev/urandom is absolutely fine, but security
expert pressure has forced these systems to not trust that real entropy has
been added from the many sources that are already implemented. You might be
surprised how many people make this problem go away by running havaged, which
provides very dubious entropy.

~~~
jlgaddis
> _You might be surprised how many people make this problem go away by running
> havaged,_ [sic] _which provides very dubious entropy._

My personal favorite is:

    
    
      # rngd -r /dev/urandom -o /dev/random

~~~
masklinn
TBF that's a proper fix for the stupidity that is the entropy estimator.

------
djhworld
> 2015 era MacBooks and MacBook Pros get working keyboard and touchpad support
> with this release, courtesy of the Apple SPI driver

Anyone know if the audio for >=2016 era macbooks will ever be made to work?
[https://github.com/Dunedan/mbp-2016-linux](https://github.com/Dunedan/mbp-2016-linux)

~~~
Dunedan
Btw: The quoted changes for MacBooks are slightly inaccurate. MacBook Pro's
from 2015 already had working keyboards and touchpads as they have them
connected via USB as well. The models which got support now are:

\- MacBook 2015

\- MacBook 2016

\- MacBook 2017

\- MacBook Pro 2016

\- MacBook Pro 2017

Mind that MacBook Air's and MacBook Pro's from 2018 onward still don't have
upstream keyboard and touchpad support.

------
baybal2
What stand out is Google GVE driver. It's first of a kind:

1\. GVE host will never see the light of the day

2\. Never be used outside of Google's DCs

3\. Hardware that backs its is very likely of Broadcoms origin, with their
virtualisation API.

4\. It made it! Unlike dozens of attempts by other companies to do the same
for their proprietary in-DC hardware. How one does it?

------
swrobel
Sadly looks like WireGuard missed the cut again

~~~
simcop2387
There's still progress being made, but WireGuard does do a lot of things
to/for the in-kernel cryptography stuff. That's been the major holdup for
getting it in. There's some that don't like that a new api is being made at
all but I believe most are fine with that as long it shares as much internally
as possible with the existing code so that there's not two copies of
everything. A lot of that has been done last I heard but it wasn't quite ready
yet for mainlining in that fashion. I suspect we'll see another RFC for it in
the 5.4 merge window and maybe finally some traction at getting it into
staging or all the way in.

EDIT: see sibling comment about wireguard and 5.4, apparently not slated for
it this time but maybe 5.5.

------
l1n
I'm confused about the source, didn't Linux Journal just shut down (for the
second time)?

~~~
green0
OP/submitter signed up a month ago and has spent the past week spamming
nothing but links to his own splog, which uses old linuxjounal material for
99.9% of its content.

With this he has simply copied an article from Omgubuntu and spammed it via
his splog, where he even puts his own name on it.

The link should be changed to the correct Omgubuntu link to credit original
and up to date content and not lazy copy and paste spammers.

~~~
eropple
It helps if you email hn@ycombinator.com and tell them that. Dan replied to me
in about 60 seconds.

~~~
green0
Ah, thanks. I'll do that if there's a next time.

------
war1025
I for one am excited that 5.3 potentially includes a bug fix for the random
hard freezes I see ~daily on my laptop with a Baytrail cpu [1].

Had sort of given up on it ever being resolved, but sounds like a patch got
into 5.3 that may fix it. Installed 5.3-rc5 last night. Guess I'll wait and
see if it actually resolves the issue.

[1]
[https://bugzilla.kernel.org/show_bug.cgi?id=109051](https://bugzilla.kernel.org/show_bug.cgi?id=109051)

~~~
qidon
Installed Ubuntu Mate 19.10 daily 5 days ago on asus t100ta (Atom) and have
had absolutely no issues. Added bootia32 to liveusb as is the norm with this
machine.Still no camera, but no big deal for me. Everything else works
perfect. No c-state freezes and no workarounds needed. 5.3 seems to have fixed
the baytrail issues as advertised.

~~~
war1025
I also have not had a hard freeze since upgrading to 5.3. Very pleasantly
surprised. I've had a few times where things get very laggy, but they pull out
of it. I imagine those are the situations where it would freeze up before.

------
captn3m0
If you game on Linux, note that the 5.3 upgrade DualShock controllers. A
recent systemd upgrade also broke some udev rules for controllers. That is
easier to fix though:

    
    
        sudo modprobe uinput.
    

[https://www.gamingonlinux.com/articles/you-may-want-to-
hold-...](https://www.gamingonlinux.com/articles/you-may-want-to-hold-off-on-
linux-kernel-53-and-systemd-243-if-you-use-a-gamepad.15023)

------
trpc
does anybody know when Wireguard is going to be merged? can it be done before
the release that will be deployed in Ubuntu 20.04 next April or is it too
late?

~~~
geophertz
According to this article:
[https://www.phoronix.com/scan.php?page=news_item&px=WireGuar...](https://www.phoronix.com/scan.php?page=news_item&px=WireGuard-0.0.20190913)

Wireguard won't be in before 5.5.

5.5 should release in early february 2020 so it might be in Ubuntu 20.04.

~~~
trpc
Thanks, let's hope so, making it in Ubuntu 20.04 will be a huge success since
Ubuntu LTS versions are used heavily and supported by all major cloud vendors

------
shmerl
Navi support has finally arrived.

~~~
wronglebowski
In the Kernel, if you're not running the very specific version of Ubuntu they
compiled you still need a ton of custom packages from mesa-git and others. I
think we're still a few months from stable on all packages and then further
months from those packages making it into distros.

~~~
shmerl
Mesa 19.3-rc3 is enough. Besides, that you also need Navi firmware (not sure
why it's not in upstream repo yet¹):
[https://people.freedesktop.org/~agd5f/radeon_ucode/navi10/](https://people.freedesktop.org/~agd5f/radeon_ucode/navi10/)

That's about it. I wouldn't use Ubuntu for Navi though. Some rolling distro
makes more sense.

1\.
[https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...](https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-
firmware.git/tree/amdgpu/)

------
dreamcompiler
> makes 16 million new IPv4 addresses available

How is IPv4 address availability up to the Linux kernel?

~~~
dtparr
0.0.0.0/8 is now an allowed range

[https://hub.packtpub.com/linux-kernel-announces-a-patch-
to-a...](https://hub.packtpub.com/linux-kernel-announces-a-patch-to-
allow-0-0-0-0-8-as-a-valid-address-range/)

------
squeezingswirls
Original article is at [https://www.omgubuntu.co.uk/2019/09/linux-5-3-kernel-
release...](https://www.omgubuntu.co.uk/2019/09/linux-5-3-kernel-release-
features)

~~~
dang
Thanks! Url changed from [https://linuxjournal.rocks/post/linux-
kernel-53-released-thi...](https://linuxjournal.rocks/post/linux-
kernel-53-released-this-is-whats-new).

------
cestith
Since I'd need to create a new account on that site specifically to send this
correction...

Paragraph 6, s/Chromebook harder/Chromebook hardware/

Spellcheck is not a proofreader.

------
Scuds
Monolithic kernel means the changelist includes everything from file systems
to GPU drivers.

~~~
aprdm
It also means that everything either works or doesn't work.

A dependency tracking system with mix & match of versions of subcomponents of
the kernel that either work together or not looks like a nightmare to me.

~~~
Diederich
> It also means that everything either works or doesn't work

Isn't quite a large percentage of the Linux kernel in the form of loadable
modules, such that a given running system will only running a fraction of the
total code?

~~~
jraph
Yes but these modules are built from the exact same code version as the kernel
being used. No dependency hell.

But maybe such a solution could work with a micro-kernel architecture too. It
seems that a micro-kernel and its components could also be gathered in a same
code base. You would get the kind of changelog the first commenter of this
thread mentioned though. It seems we are speaking of two different things
here: code management and kernel architecture.

~~~
Diederich
Ok I misunderstood, having fallen into the trap of reading and reacting to the
first sentence before reading the rest. (: I didn't realize that the topic was
dependency management, but rather about 'kernel breakage'. My apologies.

I have professional experience in large organizations that use monorepos, and
have been impressed with the results.

