Slashdot Mirror

"yelling very loudly at your hardware vendor and refusing to buy from them again unless they cut this crap out"

3.18 was released slightly over 2 years ago (7 Dec 2014). It went LTS 3 months later (2015/3/11). At the time, "it will be supported with patches for at least two more years from today." Now it's gone, less than 2 years later. And, 2 years isn't "long term" by any reasonable definition to begin with. Don't yell loudly at anyone who used it, yell loudly at Greg Kroah-Hartman and the other kernel maintainers for over-promising and under-delivering, who think 2 years is a long time and won't even keep that commitment. 3.16 (LTS) is projected to go to 2020, when it's 5 1/2 years old (kudos to Ben Hutchings, who's a bit more realistic about what "long term" means).

(and of course, anyone the size of Google should be able to put their own resource on maintaining a kernel they chose to use for longer if need be, not that they've figured out how to keep Android devices up-to-date anyway)

WTF (who) dared to mod me off topic?

Further readings:

https://www.kernel.org/doc/Doc...

https://www.kernel.org/doc/Doc...

https://en.wikipedia.org/wiki/...

WTF (who) dared to mod me off topic?

Further readings:

https://www.kernel.org/doc/Doc...

https://www.kernel.org/doc/Doc...

https://en.wikipedia.org/wiki/...

- Bump Linux kernel version from 4.6.0-1 to 4.7.0-1.

I understand that this is simply the installer, but the 4.7.x Kernel recently went EoL ...

https://www.kernel.org/.

-- kjh

This is an ancient bug that was actually attempted to be fixed once (badly) by me [Phil "not Paul" Oester] eleven years ago in commit 4ceb5db9757a ("Fix get_user_pages() race for write access") but that was then undone due to problems on s390 by commit f33ea7f404e5 ("fix get_user_pages bug").
In the meantime, the s390 situation has long been fixed, and we can now fix it by checking the pte_dirty() bit properly (and do it better).
The s390 dirty bit was implemented in abf09bed3cce ("s390/mm: implement software dirty bits") which made it into v3.9. Earlier kernels will have to look at the page state itself.
Also, the VM has become more scalable, and what used a purely theoretical race back then has become easier to trigger. To fix it, we introduce a new internal FOLL_COW flag to mark the "yes, we already did a COW" rather than play racy games with FOLL_WRITE that is very fundamental, and then use the pte dirty flag to validate that the FOLL_COW flag is still valid.

tl;dr? It only became a serious flaw recently. It's been fixed. Install the fix.
apt-get update&&apt-get -y upgrade&&reboot

I'm not surprised that a published vulnerability is being exploited. Nor am I surprised that problem has been fixed, (and the fix was available immediately instead of on Patch Tuesday), or that some people are running systems that haven't been updated with the fix.

There is. 2.6.32 had around 6 years of support. Looks like 3.16 will be supported until 2020. Longer would be nice, sure, but 5-6 years for long term seems reasonable for a not-paying-for-it product.

When you install a particular Linux distribution it will come with a Linux kernel version number. Over time you should be updating your particular Linux distribution and this means updating the kernel as well so as that distribution reaches "end of life" it's kernel will not be the same kernel the original distribution started with. This is no more different to what Microsoft does with it's products.

Why do you want longer? Linux distribution are normally free unless you wish to play for a service contract and even then the above paragraph still applies. With a Linux distribution you can upgrade from one major version to another or you can do a fresh install of the operating system, it's your choice. Again using a Windows comparison you can upgrade from Windows 7 or 8.1 to Windows 10 for free since you should have a legitimate license for the original software. With Linux distributions it's exactly the same except you don't need a license.

For those people who are going to pull "But I have an old laptop and I need my old operating system". My response is "Well no one is forcing you to upgrade but don't expect support". I actually have a 10-year-old HP dv6000 core duo laptop with 2GB of memory and it runs Fedora 24, KDE spin (released 21st June 2016) flawlessly. I even have a Skylake Core i7 16 GB DDR4 memory desktop which I am currently using and Fedora 24, Mint (virtual machine) and even Windows 10 (virtual machine) all run fine. Ok I don't like Windows 10 genuine malware edition so I don't use it.

There is. 2.6.32 had around 6 years of support. Looks like 3.16 will be supported until 2020. Longer would be nice, sure, but 5-6 years for long term seems reasonable for a not-paying-for-it product.

When you install a particular Linux distribution it will come with a Linux kernel version number. Over time you should be updating your particular Linux distribution and this means updating the kernel as well so as that distribution reaches "end of life" it's kernel will not be the same kernel the original distribution started with. This is no more different to what Microsoft does with it's products.

Why do you want longer? Linux distribution are normally free unless you wish to play for a service contract and even then the above paragraph still applies. With a Linux distribution you can upgrade from one major version to another or you can do a fresh install of the operating system, it's your choice. Again using a Windows comparison you can upgrade from Windows 7 or 8.1 to Windows 10 for free since you should have a legitimate license for the original software. With Linux distributions it's exactly the same except you don't need a license.

For those people who are going to pull "But I have an old laptop and I need my old operating system". My response is "Well no one is forcing you to upgrade but don't expect support". I actually have a 10-year-old HP dv6000 core duo laptop with 2GB of memory and it runs Fedora 24, KDE spin (released 21st June 2016) flawlessly. I even have a Skylake Core i7 16 GB DDR4 memory desktop which I am currently using and Fedora 24, Mint (virtual machine) and even Windows 10 (virtual machine) all run fine. Ok I don't like Windows 10 genuine malware edition so I don't use it.

There is. 2.6.32 had around 6 years of support. Looks like 3.16 will be supported until 2020. Longer would be nice, sure, but 5-6 years for long term seems reasonable for a not-paying-for-it product.

There is. 2.6.32 had around 6 years of support. Looks like 3.16 will be supported until 2020. Longer would be nice, sure, but 5-6 years for long term seems reasonable for a not-paying-for-it product.

The 4.6 kernel series is already end of life, 4.7 is only marked stable, and 4.8 hasn't yet been released.. Currently Linux Kernel 4.4 is the latest longterm Linux kernel and is projected to be supported until Feb. 2018. With the exception of kernel 3.2, support will end for the other Linux longterm kernels either this year or next year.

If you are creating a long term support release of a Linux distro, it makes sense to choose a longterm support kernel over either an EOL kernel release or an unreleased kernel (which likely bring its own set of issues). If the distro did choose to kernel without long term support, they would be on the hook for back porting critical patches into the kernel. Since they did choose a long term kernel release, they can focus on what sets Mint apart, maintaining their Cinnamon interface, rather than maintaining a custom kernel release.

On a related note, Alpine Linux and Slackware Linux also chose the 4.4 kernel.

The 4.6 kernel series is already end of life, 4.7 is only marked stable, and 4.8 hasn't yet been released.. Currently Linux Kernel 4.4 is the latest longterm Linux kernel and is projected to be supported until Feb. 2018. With the exception of kernel 3.2, support will end for the other Linux longterm kernels either this year or next year.

If you are creating a long term support release of a Linux distro, it makes sense to choose a longterm support kernel over either an EOL kernel release or an unreleased kernel (which likely bring its own set of issues). If the distro did choose to kernel without long term support, they would be on the hook for back porting critical patches into the kernel. Since they did choose a long term kernel release, they can focus on what sets Mint apart, maintaining their Cinnamon interface, rather than maintaining a custom kernel release.

On a related note, Alpine Linux and Slackware Linux also chose the 4.4 kernel.

Additionally I recall hearing on at least one occasion about needing everything in the boot loader's chain to be signed (e.g. drivers). I do not know how they would manage that once the kernel is running, but if that is the case then that is a significant problem, and any machine which Secure Boot cannot be disabled on is as such essentially Microsoft-owned hardware.

I can attest to that. On a computer with secure boot enabled, I can install and boot CentOS just fine. However, as soon as I throw in an Nvidia graphics card and install the NVIDIA drivers (which requires a module compile against the running kernel), it refuses to load it. It is not until I disable the secure boot before it will work properly. Nouveau driver works fine, because it comes with the distro. Just not NVIDIA. I would assume the same applies to AMD-supplied drivers, or any other drivers that require additional kernel modules (eg. VirtualBox host drivers, which I did find out does not work with secure boot on).

The reason for secure boot is to ensure no tampering from start up. I would surmise the reason why the kernel refuses to load the modules is to ensure zero tampering with them as well. If the module is not signed, it will not get loaded in a secure boot environment. Disabling secure boot will allow these external modules to load, but with a warning message in dmesg indicating tainted kernel ("module verification failed taints kernel"), in addition to the incompatible license ("License NVIDIA taints kernel").

So, getting back to your worry: No, I do not believe it would be an issue with drivers on computers with secure boot permanently turned on, as long as all the necessary modules are signed. Reading further, I assume one could even tell the kernel to allow unsigned modules to load (module.sig_enforce=0 perhaps?).

Ever heard about known vulnerabilities that get not fixed for a long, long time in closed-source software?

Yes.

And ever heard about the same thing in open source software?

Yes of course, if you haven't then you obviously have no idea about open source whatsoever. If you go through the enormous list of known bugs in what is probably the most high profile open source project in the world you will find various privilege issues, buffer overruns, etc. that have been in there for a long time. You really don't think this is even more prevalent in less well-known projects?

Open source is not some magic pill where all bugs are quickly found and fixed, it's that idiotic attitude that led to critical open source security failures like Heartbleed. There was the assumption that open source was safe and somebody had looked at the code and fixed any bugs but in truth this was used by a vast amount of companies and people and nobody was looking at the code at all. That doesn't bode well for less visible projects.

Open source has some great qualities but it's people like you who take it to a religious level and defend it as though you are being criticised personally that cause the whole idea to over-promise and under-deliver. By now it should be a given that open source is a superior development model but it ends up hotly debated because the advantages OSS would have if the conditions for it were ideal are presented as the average case when that is not only completely removed from reality but in most cases isn't even practical.

(Here's the patch from a more familiar source, kernel.org.)

>"Windows and Macs are not affected by the vulnerability."

Oh, cute comment in the summary. Here, let me fix/expand that for you...

"MS-Windows and MacOS are not affected by THIS vulnerability but are affected by many, many thousands of others, plus this obscure and unlikely-to-be-exploited security issue has already patched in Linux over a month ago."

Patch: http://git.kernel.org/cgit/lin...

Or you can fix it on any Linux system with a simple kernel variable change: 1) Open /etc/sysctl.conf, with an editor, such as vim. 2) Enter the line: net.ipv4.tcp_challenge_ack_limit = 999999999 3) Save the file. 4) Use the shell command "sysctl -p" to update the configuration.

Microsoft answer!

Why wouldn't he simply codify his preferences?

https://www.kernel.org/doc/Doc...

Chapter 8: Commenting
....
When commenting the kernel API functions, please use the kernel-doc format.
See the files Documentation/kernel-doc-nano-HOWTO.txt and scripts/kernel-doc for details.

Why wouldn't he simply codify his preferences?

https://www.kernel.org/doc/Doc...

Chapter 8: Commenting
....
When commenting the kernel API functions, please use the kernel-doc format.
See the files Documentation/kernel-doc-nano-HOWTO.txt and scripts/kernel-doc for details.

you mean something like this: https://www.kernel.org/doc/Documentation/CodingStyle ?

Set a password for the drive and issue an ATA secure erase using hdparm. This will get all the remapped sectors as well. Procedure documented here

https://ata.wiki.kernel.org/in...

only a few linux versions are "supported"

no linux "versions" are supported by anyone, ever

linux distributions are supported

when one version is set to be EOL, people are warned to upgrade to one of the supported version, usually the latest

makes NO SENSE at all. Please review how RHEL etc actually function if you can manage to get your head out of your ass

I'm not sure where you've gotten your information, but you seem to be very certain of yourself for some reason.

Several kernel versions are marked for stable fixes or even "longterm" fixes (aka longer-lasting stable branches). These have a dedicated maintainer and critical fixes from mainline are backported. Many people, including myself, consider this "supported".

Regards,
a kernel developer

After 20 years in the business you can't seem to show us a respectable program you've ever done raymorris. You're all talk.

You might have heard of this little program called "the Linux kernel".

https://www.kernel.org/pub/lin...

Ohhh...burn

You might have heard of this little program called "the Linux kernel".

https://www.kernel.org/pub/lin...

Theo Tso fixed it back in 2012 by just using it as an additional (but not sole) source of entropy:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c2557a303ab6712bb6e09447df828c557c710ac9

Yeah it just works... When you're lucky.
I'm a die-hard Linux user but even I gets saddened when I see the multitude of users with low-end Intel BayTrail-based devices that have been suffering for many month because of the infamous bug 109051

are you sure you're looking at the leftmost column in powertop's "Idle Stats"? what you're saying should not be possible. things are slowly starting to move in 4.6 kernel ( http://git.kernel.org/cgit/lin... ) . it should not be possible with 4.4.7.

Those who use a real computer, can run USBGuard: https://dkopecek.github.io/usb...

It provides a very simple way to control the devices that are allowed to hook to your machine via a kernel security feature that has been there for many a year: https://www.kernel.org/doc/Doc...

That's why we have USB authorization. Since 2007.

https://git.kernel.org/cgit/li...
"This is being written to try to explain why Linux does not have a binary
kernel interface, nor does it have a stable kernel interface."

Good God, that's tripe:

Executive Summary
-----------------
You think you want a stable kernel interface, but you really do not, and
you don't even know it. What you want is a stable running driver, and
you get that only if your driver is in the main kernel tree. You also
get lots of other good benefits if your driver is in the main kernel
tree, all of which has made Linux into such a strong, stable, and mature
operating system which is the reason you are using it in the first
place.

How fucking arrogant does one have to be to tell me what I want?

How stupid do you have to be to realize that what you want may not be what you need?

https://git.kernel.org/cgit/li...
"This is being written to try to explain why Linux does not have a binary
kernel interface, nor does it have a stable kernel interface."

Good God, that's tripe:

Executive Summary
-----------------
You think you want a stable kernel interface, but you really do not, and
you don't even know it. What you want is a stable running driver, and
you get that only if your driver is in the main kernel tree. You also
get lots of other good benefits if your driver is in the main kernel
tree, all of which has made Linux into such a strong, stable, and mature
operating system which is the reason you are using it in the first
place.

How fucking arrogant does one have to be to tell me what I want?

https://git.kernel.org/cgit/li...
"This is being written to try to explain why Linux does not have a binary
kernel interface, nor does it have a stable kernel interface."

Linus explicitly removed the section from the original GPLv2 that stated you as an end user of the code could apply any later GPL license to the code, locking it to the GPLv2 forever, Tivoization notwithstanding.

Huh? First I've heard of it.

"This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version."

https://www.kernel.org/pub/linux/kernel/COPYING

Many times open source someone has already asked the question and it's been answered answered: https://www.kernel.org/doc/Doc...

Jesus Christ... This is standard procedure for Linux kernels. It was not a LTS kernel - it was not intended to be a LTS kernel. If you want long term support then use a f'ing LTS kernel. Or use the one your distribution maintains which is also just fine and probably contains lots of back ports. Linux kernels have been like this for a very long time.

https://www.kernel.org/categor...

When did slashdot get so stupid???

I'll stick with BTRFS thanks. It gives me all those features, is GPL and has been trouble free for me on many TB of disks for several years.

Encryption? Oh yeah:

Btrfs does not support native file encryption (yet), and there's nobody actively working on it. It could conceivably be added in the future.

"Nobody actively working on it" is a big problem with BTRFS.

BTRFS comes from Oracle - pre-Sun purchase. It was Oracle's answer to ZFS. And now Oracle owns ZFS and doesn't need a copy of the original. It's not quite abandonware, but the central impetus for it's creation and advancement is gone.

And most of all:

Is btrfs stable?

Short answer: Maybe.

Ouch. That's the official BTRFS wiki page.

kernel.org has an article on GPLv2 compliance that explains it. Have you actually looked at the information in RemixOS wrt licensing?

Stephen Smalley at NSA has added code to the Linux kernel.

http://git.kernel.org/cgit/lin...

There is a lot of NSA code in Linux.

http://git.kernel.org/cgit/lin...

https://www.nsa.gov/research/s...

I am not saying that it causes the security problems the AC was writing about, but it is there.

Not sure why i got Troll, but this is what i referenced.

https://www.kernel.org/pub/lin...

"WHAT IS LINUX?
Linux is a Unix clone written from scratch by Linus Torvalds with assistance from a loosely-knit team of hackers across the Net. It aims towards POSIX compliance."

https://www.synology.com/en-us/dsm/Btrfs

Synology disagree.

Lame BTRFS file system is lame.

I'm, not defending the code, but you're missing the point:
The compiler fallback had been added:
http://git.kernel.org/cgit/lin...

The problem was the inherent unreadability of the code. Using little known compiler-specific functions makes the code much harder to read.

Linus Torvalds did that in one summer, by himself;

https://www.kernel.org/pub/linux/kernel/Historic/linux-0.01.tar.gz

Go for it. Let me know how long it takes you to get that working on a current generation computer.

HURD's problem is not that they didn't write it in the summer, it's that technical changes had always outpaced it's production and it never had resources behind it to keep up. Linux would be no different if it were left exclusively up to Linus in his spare time.

At my first job, 30 years ago, experienced people were bullying inexperienced people, just because they had a little bit more knowledge.

This is WRONG in the first place. He has not bullied any inexperienced person.
Aww, all I saw around the web is people's yelling about how bad Linus this week, from whom never really actual read what the context of his comments, whom he talked with, etc.
(Links of conversations of Linus, Google, Slashdot, LKML) You may or may not agree with him, but you've brought the wrong experience on him.

Just read all these comments, I think Linus is right to choose straight speaking, when "professional communication" will spend you much more energy on Internet. But he has rule:
https://www.kernel.org/doc/Doc...

Chapter 5: Things to avoid

Your post is not wrong after all, but not about Linus himself.

For me, lack of RAID-5 is enough reason to consider BTRFS deficient. The glowing accolades as to the reliability and accuracy of fsck tools for BTRFS leave a bit to be desired: https://btrfs.wiki.kernel.org/...

I looked long & hard at BTRFS about four months ago and was considering migrating from ZFS. It blew my mind how much was lacking in BTRFS in comparison and that anyone would consider it superior in any way other than that it's in-tree.

ZFS is more battle tested. BTRFS is a very fine file system, but it is still stabilizing. They just recently added support for RAID 5 and 6, a quite big features with lots of changes. A file system just takes a few years in the wild, before it can be considered stable. There are just weird corner cases, misbehaving hardware, subtile bugs and so on that you will only find in the wild. When BTRFS with RAID 5 is about 5 to 10 years old, it can be considered stable. Until then, ZFS is the first choice for everything that holds real data.

I don't know what your definition of "significant" is, but the BTRFS wiki says "The one missing piece, from a reliability point of view, is that it is still vulnerable to the parity RAID 'write hole', where a partial write as a result of a power failure may result in inconsistent parity data." ZFS RAIDZ is expressly free from the write hole. That is very significant to me.

RAIDZ's write hole advantage is a product of three specifics: (1) RAID5 has n data disks plus one dedicated parity-only disk; ZFS distributes all data and all parity across all disks - (2) ZFS updates metadata before data; RAID5 has no concept of metadata - and (3) COW (both have this).

And before you object "but UPS" - UPSs and power supplies can fail, too - and a kernel panic is essentially a "power failure" too; one which a UPS is powerless to prevent.

If that Wiki should be out of date, you can show me something that isn't, but all I find out there is a lot of outdated stuff.

Raid support has been built into btrfs for ages now. It's been rock stable for me for over a year with an 8 disk array in raid 5 configuration. But the simplicity with which you can add and subtract drives, parity drives and others makes btrfs a total winner IMO.

https://btrfs.wiki.kernel.org/...

FYI, *patches* will be moderated by someone other than me. As this is my *kernel*, not a government entity, I have the right to replace any *patch* I feel like with “fart fart fart fart”.

Matthew will soon add this to his new Management Style document.

Unlike the 'filthy, violent' old one:
https://www.kernel.org/doc/Doc...

Maybe if Eich wasn't a bigot, DRM wouldn't be in Mozilla right now. Lesson: Don't be a bigot.

Yet DRM is in the Linux kernel.

He has never been (a dick) (and may will never be).
It's just that his style is not suited with someone, and he/she quits. This is just normal.

The kind of stories about "Linus bullying" has appears four or five a years, but each times, there are people jump out and claim, likely they never ever read these stories before (not about you). So each topic about "Linus bullying", the *same patterns* of discussion appear again and again.
BTW, there was a Slashdot user (he is/was also "a newbie" kernel developer) said that Linus is very nice and friendly toward newbies, unexperienced developers.

He was clearly described the style of discussion (as he described, say louder not insult):
https://www.kernel.org/doc/Doc...
or here,
http://arstechnica.com/busines...
or here,
http://arstechnica.com/busines...
Some may say that he is rude, but in fact, I see he's straight, but his words were putted out of the context. Remember the "F you, Nvidia! (and pointed finger)" incident, he right after added "Don't get me wrong...", but the later usually never mentioned. But the progress of Nvidia action later proved his style works.

While Sarah seemed to be allergic with the style (see the chains of discussions):
http://marc.info/?t=1373580445...
started with Linus' shouting:
http://marc.info/?l=linux-kern...
appeared in story:
http://linux.slashdot.org/stor...

Or, the Linus' "victim" does not have problem with his style:
start with:
https://lkml.org/lkml/2013/2/2...
"victim" respond:
https://lkml.org/lkml/2013/2/2...
appeared in:
http://linux.slashdot.org/stor...