19 ms·

Linux Kernel 5.3

190 points by AlexDGe 7y ago

thestoicattack 7y ago
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 7y ago
  More technical details here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.3&id=72dbcf72156641fde4d8ea401e977341bfd35a05 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
  - leni536 7y ago
    > The correct fix is to fix getrandom() to not block when it's not appropriate,... I'm not a cryptography expert, but this suggestion doesn't look right. Edit: IMO the main problem is the lack of a forward progress guarantee for entropy generation, even if there are suitable sources for entropy in the system.
    - banachtarski 7y ago
      I've worked in crypto before (not now though) and your statement is actually a common misconception. The information about whether the randomness is sourced from "true" entropy or not is in and of itself a form of entropy from the perspective of an assailant. It's enough that given some period of time, "some" amount of entropy is present and how much is dependent on the degree to which the system is used. You can use a game theoretic approach to determine how much that is. edit: to clarify, occasionally not using /dev/random when it may block is not actually a security issue (in most cases)
      - ses1984 7y ago
        How do we know which cases?
        deleted 7y ago
        [deleted]
        masklinn 7y ago
        The only case where it could be an issue is at bootup, when the subsystem simply does not have enough entropy. OpenBSD solved that by storing a seed for next bootup at the end of boot and during shutdown.
        simonh 7y ago
        I hope the seed is very well protected.
        VibrantClarity 7y ago
        wdym? if an attacker can access your filesystem its already game over
        iforgotpassword 7y ago
        The same could be said for some of the entropy sources that were nerfed or removed over time due to security concerns. That's the main reason why we even are in this situation today.
        asamarin 7y ago
        So what happens at the very first boot (e.g. after system installation, or cloud instance just being spawned)? Is that the only circumstance where it would be OK to block? Does OpenBSD trust RdRand for such occasions?
        ChrisSD 7y ago
    - trasz 7y ago
      PRNG needs entropy, but it doesn't consume it. You don't need to feed entropy into it continuously.
      - msla 7y ago
        > PRNG needs entropy, but it doesn't consume it. You don't need to feed entropy into it continuously. In the extreme case, this means you can run a PRNG with a fixed seed indefinitely, which is definitely wrong because such a PRNG will necessarily loop. That might not be feasible to exploit, however.
        stouset 7y ago
        > such a PRNG will necessarily loop Given infinite time, energy, and computing power, yes. Given computers made out matter and running on energy for use by meat-based intelligences, no. This is really analogous to saying "technically a 256-bit encryption key is brute-forceable". In fact, this is so close to being the actual underlying situation it's barely even an analogy.
    - pmoriarty 7y ago
      Something else I'd wonder is whether there are other sources of entropy that could be used here other than the disk -- as improving disk IO is what seems to have caused this particular issue in the first place.
    - dmitrygr 7y ago
      > even if there are suitable sources for entropy in the system What might those be on, say, a freshly booted RasPi that hasn't even brought up much of userspace besides systemd?
      - jlgaddis 7y ago
        The Raspberry Pi has a HWRNG onboard.
        dmitrygr 7y ago
        Do you trust it?
        tatersolid 7y ago
        You’re forced to trust the maker of your CPU, mainboard, etc. if you can’t trust your hardware you’re toast. There’s nothing special about RNGs in this regard.
      - leni536 7y ago
        The problematic commit reduced the number of disk IO at bootup which resulted in starving getrandom() from the necessary entropy. If disk IO is already considered a reliable source of entropy then there is no reason to not actively exercise it when entropy is needed.
  - danieldk 7y ago
    And before people start bashing systemd, the cause for boot hangs was actually collection of randomness for a Xorg/Xwayland MIT cookie through gdm. So, Linus' e-mail linked by the parent is somewhat inaccurate. https://lore.kernel.org/linux-ext4/20190915081747.GA1058@darwi-home-pc/ https://lore.kernel.org/linux-ext4/20190915081747.GA1058@dar... https://lore.kernel.org/linux-ext4/20190916014050.GA7002@darwi-home-pc/ https://lore.kernel.org/linux-ext4/20190916014050.GA7002@dar...
    - ldng 7y ago
      Yet it is implicitly directed at Systemd that have not hesitate in the past to break userspace. More than once.
  - devit 7y ago
    Hmm, isn't the solution to do something proactively to increase entropy when getrandom() is waiting for it? (especially for the first bytes) Like inserting arbitrary reads of any available SSD or hard disk that has already been spun up, or something better if possible. And in newer userspace, just properly save and restore a seed.
    - JoshTriplett 7y ago
      What does "arbitrary" mean if you don't have any randomness? Response times of devices are getting increasingly predictable.
      - ryacko 7y ago
        The timer entropy daemon has been around for a while. At minimum one has access to a hardware random number with an output of 256 bits per second by waiting for an interrupt from a timer.
  - rHcsgjuuHw 7y ago
    > 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.
    - xyzzyz 7y ago
      /dev/urandom is useless because it spews non-random data if it hasn't been seeded yet. Does it? Under what circumstances? Where can I read about it?
      - yjftsjthsd-h 7y ago
        `man 4 random` states, > When read during early boot time, /dev/urandom may return data prior to the entropy pool being initialized. If this is of concern in your application, use getrandom(2) or /dev/random instead.
      - CodeHz 7y ago
        it happened in my system in last boot, dmesg says dbus-daemon tried (twice!) to read urandom before its seeded, and the next message (same second, about 200ms) is about urandom has been seeded, it is a race condition!
    - ploxiln 7y ago
- pedrocr 7y ago
  There's a limit to how far you can go with that policy but it does seem that in this case the regression was fairly obvious. As always there's a xkcd about it: https://xkcd.com/1172/ https://xkcd.com/1172/
- dev_dull 7y ago
  What is with anything with the words “release notes” in the title being completely unreadable on a mobile device?
- new_realist 7y ago
  Great; and while we’re reverting obvious breakages of userspace performance, perhaps Linus can also un-break ZFS SIMD.
  - AstralStorm 7y ago
    ZFS on Linux is neither mainline nor userspace. Feel free to either fix it or contact its maintainers. If they're lagging behind kernel versions, it's their fault.
- Topgamer7 7y ago
  Love the spelling joke in there.
  - jjoonathan 7y ago
    Only the finest speling will do for the LKML.
Scuds 7y ago
Monolithic kernel means the changelist includes everything from file systems to GPU drivers.
- aprdm 7y ago
  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 7y ago
    > 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 7y ago
      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.
      - jschwartzi 7y ago
        It definitely works with a micro-kernel. The issue in question fits under the umbrella of "software configuration management." In other words, how do you make sure that you are running versions of all of your components which are the same as when you tested? And how do you establish a known-good set of components in the first place? A competent engineering team should have a way to verify that all the important components of their system are controlled so that a different version can't sneak in. This could be through the revision control system, or it could be through some design notes and a verification activity. But you have to do something to make sure your system is built from a known-working set of artifacts. And in a lot of cases your software configuration extends to your build system. I've been burned before by build system and host operating system changes that result in the software configuration of my embedded images changing and introducing bugs.
shmerl 7y ago
Navi support has finally arrived.
- wronglebowski 7y ago
  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 7y ago
    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/linux-firmware.git/tree/amdgpu/ https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...
- cptskippy 7y ago
  Are you referring to the AMD Drivers?
  - shmerl 7y ago
    amdgpu in particular.
swrobel 7y ago
Sadly looks like WireGuard missed the cut again
- NullPrefix 7y ago
  Wouldn't expect something like that to be merged as late as as rc8.
- geophertz 7y ago
  Probably won't be in before 5.5: https://www.phoronix.com/scan.php?page=news_item&px=WireGuard-0.0.20190913 https://www.phoronix.com/scan.php?page=news_item&px=WireGuar...
- simcop2387 7y ago
  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.
- tssva 7y ago
  Last patch set I remember seeing was v9 submitted to the mailing list in March. There was some feedback regarding the new zinc crypto interface and replacement crypto implementations. Jason indicated he would address them for the next patch submission which I don't believe has been made yet.
l1n 7y ago
I'm confused about the source, didn't Linux Journal just shut down (for the second time)?
- squeezingswirls 7y ago
  OP points to a domain name different than the Linux Journal Magazine's https://www.linuxjournal.com/ https://www.linuxjournal.com/
- green0 7y ago
  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 7y ago
    It helps if you email hn@ycombinator.com and tell them that. Dan replied to me in about 60 seconds.
    - green0 7y ago
      Ah, thanks. I'll do that if there's a next time.
trpc 7y ago
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?
- TrueDuality 7y ago
  Far too late unfortunately.
- geophertz 7y ago
  According to this article: https://www.phoronix.com/scan.php?page=news_item&px=WireGuard-0.0.20190913 https://www.phoronix.com/scan.php?page=news_item&px=WireGuar... 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 7y ago
    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
djhworld 7y ago
> 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 7y ago
  There has been a lot of progress regarding audio in the past few weeks. Rudimentary audio support is there now and I'm confident we'll see better support soon. Check out https://github.com/Dunedan/mbp-2016-linux/issues/111 https://github.com/Dunedan/mbp-2016-linux/issues/111 for more details.
- Dunedan 7y ago
  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.
squeezingswirls 7y ago
Original article is at https://www.omgubuntu.co.uk/2019/09/linux-5-3-kernel-release-features https://www.omgubuntu.co.uk/2019/09/linux-5-3-kernel-release...
- dang 7y ago
  Thanks! Url changed from https://linuxjournal.rocks/post/linux-kernel-53-released-this-is-whats-new https://linuxjournal.rocks/post/linux-kernel-53-released-thi....
cestith 7y ago
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.
war1025 7y ago
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 7y ago
  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 7y ago
    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.
baybal2 7y ago
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?
dreamcompiler 7y ago
> makes 16 million new IPv4 addresses available How is IPv4 address availability up to the Linux kernel?
- denormalfloat 7y ago
  They were previously allowed by the IP RFCs, but limitted by the kernel. They are in the 0/8 block.
- dtparr 7y ago
  0.0.0.0/8 is now an allowed range https://hub.packtpub.com/linux-kernel-announces-a-patch-to-allow-0-0-0-0-8-as-a-valid-address-range/ https://hub.packtpub.com/linux-kernel-announces-a-patch-to-a...
captn3m0 7y ago
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-off-on-linux-kernel-53-and-systemd-243-if-you-use-a-gamepad.15023 https://www.gamingonlinux.com/articles/you-may-want-to-hold-...

190 points by AlexDGe 7y ago

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 7y ago
More technical details here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.3&id=72dbcf72156641fde4d8ea401e977341bfd35a05 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
- leni536 7y ago
  > The correct fix is to fix getrandom() to not block when it's not appropriate,... I'm not a cryptography expert, but this suggestion doesn't look right. Edit: IMO the main problem is the lack of a forward progress guarantee for entropy generation, even if there are suitable sources for entropy in the system.
  - banachtarski 7y ago
    I've worked in crypto before (not now though) and your statement is actually a common misconception. The information about whether the randomness is sourced from "true" entropy or not is in and of itself a form of entropy from the perspective of an assailant. It's enough that given some period of time, "some" amount of entropy is present and how much is dependent on the degree to which the system is used. You can use a game theoretic approach to determine how much that is. edit: to clarify, occasionally not using /dev/random when it may block is not actually a security issue (in most cases)
    - ses1984 7y ago
      How do we know which cases?
      - deleted 7y ago
        [deleted]
      - masklinn 7y ago
        The only case where it could be an issue is at bootup, when the subsystem simply does not have enough entropy. OpenBSD solved that by storing a seed for next bootup at the end of boot and during shutdown.
        simonh 7y ago
        I hope the seed is very well protected.
        VibrantClarity 7y ago
        wdym? if an attacker can access your filesystem its already game over
        iforgotpassword 7y ago
        The same could be said for some of the entropy sources that were nerfed or removed over time due to security concerns. That's the main reason why we even are in this situation today.
        asamarin 7y ago
        So what happens at the very first boot (e.g. after system installation, or cloud instance just being spawned)? Is that the only circumstance where it would be OK to block? Does OpenBSD trust RdRand for such occasions?
        ChrisSD 7y ago
  - trasz 7y ago
    PRNG needs entropy, but it doesn't consume it. You don't need to feed entropy into it continuously.
    - msla 7y ago
      > PRNG needs entropy, but it doesn't consume it. You don't need to feed entropy into it continuously. In the extreme case, this means you can run a PRNG with a fixed seed indefinitely, which is definitely wrong because such a PRNG will necessarily loop. That might not be feasible to exploit, however.
      - stouset 7y ago
        > such a PRNG will necessarily loop Given infinite time, energy, and computing power, yes. Given computers made out matter and running on energy for use by meat-based intelligences, no. This is really analogous to saying "technically a 256-bit encryption key is brute-forceable". In fact, this is so close to being the actual underlying situation it's barely even an analogy.
  - pmoriarty 7y ago
    Something else I'd wonder is whether there are other sources of entropy that could be used here other than the disk -- as improving disk IO is what seems to have caused this particular issue in the first place.
  - dmitrygr 7y ago
    > even if there are suitable sources for entropy in the system What might those be on, say, a freshly booted RasPi that hasn't even brought up much of userspace besides systemd?
    - jlgaddis 7y ago
      The Raspberry Pi has a HWRNG onboard.
      - dmitrygr 7y ago
        Do you trust it?
        tatersolid 7y ago
        You’re forced to trust the maker of your CPU, mainboard, etc. if you can’t trust your hardware you’re toast. There’s nothing special about RNGs in this regard.
    - leni536 7y ago
      The problematic commit reduced the number of disk IO at bootup which resulted in starving getrandom() from the necessary entropy. If disk IO is already considered a reliable source of entropy then there is no reason to not actively exercise it when entropy is needed.
- danieldk 7y ago
  And before people start bashing systemd, the cause for boot hangs was actually collection of randomness for a Xorg/Xwayland MIT cookie through gdm. So, Linus' e-mail linked by the parent is somewhat inaccurate. https://lore.kernel.org/linux-ext4/20190915081747.GA1058@darwi-home-pc/ https://lore.kernel.org/linux-ext4/20190915081747.GA1058@dar... https://lore.kernel.org/linux-ext4/20190916014050.GA7002@darwi-home-pc/ https://lore.kernel.org/linux-ext4/20190916014050.GA7002@dar...
  - ldng 7y ago
    Yet it is implicitly directed at Systemd that have not hesitate in the past to break userspace. More than once.
- devit 7y ago
  Hmm, isn't the solution to do something proactively to increase entropy when getrandom() is waiting for it? (especially for the first bytes) Like inserting arbitrary reads of any available SSD or hard disk that has already been spun up, or something better if possible. And in newer userspace, just properly save and restore a seed.
  - JoshTriplett 7y ago
    What does "arbitrary" mean if you don't have any randomness? Response times of devices are getting increasingly predictable.
    - ryacko 7y ago
      The timer entropy daemon has been around for a while. At minimum one has access to a hardware random number with an output of 256 bits per second by waiting for an interrupt from a timer.
- rHcsgjuuHw 7y ago
  > 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.
  - xyzzyz 7y ago
    /dev/urandom is useless because it spews non-random data if it hasn't been seeded yet. Does it? Under what circumstances? Where can I read about it?
    - yjftsjthsd-h 7y ago
      `man 4 random` states, > When read during early boot time, /dev/urandom may return data prior to the entropy pool being initialized. If this is of concern in your application, use getrandom(2) or /dev/random instead.
    - CodeHz 7y ago
      it happened in my system in last boot, dmesg says dbus-daemon tried (twice!) to read urandom before its seeded, and the next message (same second, about 200ms) is about urandom has been seeded, it is a race condition!
  - ploxiln 7y ago
pedrocr 7y ago
There's a limit to how far you can go with that policy but it does seem that in this case the regression was fairly obvious. As always there's a xkcd about it: https://xkcd.com/1172/ https://xkcd.com/1172/
dev_dull 7y ago
What is with anything with the words “release notes” in the title being completely unreadable on a mobile device?
new_realist 7y ago
Great; and while we’re reverting obvious breakages of userspace performance, perhaps Linus can also un-break ZFS SIMD.
- AstralStorm 7y ago
  ZFS on Linux is neither mainline nor userspace. Feel free to either fix it or contact its maintainers. If they're lagging behind kernel versions, it's their fault.
Topgamer7 7y ago
Love the spelling joke in there.
- jjoonathan 7y ago
  Only the finest speling will do for the LKML.

Scuds 7y ago

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

aprdm 7y ago
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 7y ago
  > 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 7y ago
    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.
    - jschwartzi 7y ago
      It definitely works with a micro-kernel. The issue in question fits under the umbrella of "software configuration management." In other words, how do you make sure that you are running versions of all of your components which are the same as when you tested? And how do you establish a known-good set of components in the first place? A competent engineering team should have a way to verify that all the important components of their system are controlled so that a different version can't sneak in. This could be through the revision control system, or it could be through some design notes and a verification activity. But you have to do something to make sure your system is built from a known-working set of artifacts. And in a lot of cases your software configuration extends to your build system. I've been burned before by build system and host operating system changes that result in the software configuration of my embedded images changing and introducing bugs.

shmerl 7y ago

Navi support has finally arrived.

wronglebowski 7y ago
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 7y ago
  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/linux-firmware.git/tree/amdgpu/ https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...
cptskippy 7y ago
Are you referring to the AMD Drivers?
- shmerl 7y ago
  amdgpu in particular.

swrobel 7y ago

Sadly looks like WireGuard missed the cut again

NullPrefix 7y ago
Wouldn't expect something like that to be merged as late as as rc8.
geophertz 7y ago
Probably won't be in before 5.5: https://www.phoronix.com/scan.php?page=news_item&px=WireGuard-0.0.20190913 https://www.phoronix.com/scan.php?page=news_item&px=WireGuar...
simcop2387 7y ago
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.
tssva 7y ago
Last patch set I remember seeing was v9 submitted to the mailing list in March. There was some feedback regarding the new zinc crypto interface and replacement crypto implementations. Jason indicated he would address them for the next patch submission which I don't believe has been made yet.

l1n 7y ago

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

squeezingswirls 7y ago
OP points to a domain name different than the Linux Journal Magazine's https://www.linuxjournal.com/ https://www.linuxjournal.com/
green0 7y ago
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 7y ago
  It helps if you email hn@ycombinator.com and tell them that. Dan replied to me in about 60 seconds.
  - green0 7y ago
    Ah, thanks. I'll do that if there's a next time.

trpc 7y ago

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?

TrueDuality 7y ago
Far too late unfortunately.
geophertz 7y ago
According to this article: https://www.phoronix.com/scan.php?page=news_item&px=WireGuard-0.0.20190913 https://www.phoronix.com/scan.php?page=news_item&px=WireGuar... 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 7y ago
  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

djhworld 7y ago

> 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 7y ago
There has been a lot of progress regarding audio in the past few weeks. Rudimentary audio support is there now and I'm confident we'll see better support soon. Check out https://github.com/Dunedan/mbp-2016-linux/issues/111 https://github.com/Dunedan/mbp-2016-linux/issues/111 for more details.
Dunedan 7y ago
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.

squeezingswirls 7y ago

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

dang 7y ago
Thanks! Url changed from https://linuxjournal.rocks/post/linux-kernel-53-released-this-is-whats-new https://linuxjournal.rocks/post/linux-kernel-53-released-thi....

cestith 7y ago

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.

war1025 7y ago

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 7y ago
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 7y ago
  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.

baybal2 7y ago

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?

dreamcompiler 7y ago

> makes 16 million new IPv4 addresses available How is IPv4 address availability up to the Linux kernel?

denormalfloat 7y ago
They were previously allowed by the IP RFCs, but limitted by the kernel. They are in the 0/8 block.
dtparr 7y ago
0.0.0.0/8 is now an allowed range https://hub.packtpub.com/linux-kernel-announces-a-patch-to-allow-0-0-0-0-8-as-a-valid-address-range/ https://hub.packtpub.com/linux-kernel-announces-a-patch-to-a...

captn3m0 7y ago

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-off-on-linux-kernel-53-and-systemd-243-if-you-use-a-gamepad.15023 https://www.gamingonlinux.com/articles/you-may-want-to-hold-...