LWN: Comments on "Blacklisting insecure filesystems in openSUSE"

Blacklisting insecure filesystems in openSUSE

Rudd-O — Fri, 12 Apr 2019 08:56:14 +0000

Communism, of course.

Blacklisting insecure filesystems in openSUSE

Wol — Fri, 22 Feb 2019 19:15:36 +0000

And in practice it very often isn't!

It's basically down to supply and demand. Why did we have the Renaissance? Because average *median* wealth rose dramatically as a result of the Black Death. That was what brought down the feudal system in a large chunk of Europe. We had the same effect after the First and Second World Wars.

Sadly now we have the opposite effect, where we have too many people chasing too little work, and even while the average *mean* wealth may be rising, the *median* wealth is falling. And politicians love to talk about the mean, while forgetting that in a skewed distribution like incomes, it has very little meaning.

Cheers,
Wol

Blacklisting insecure filesystems in openSUSE

Cyberax — Mon, 18 Feb 2019 00:21:14 +0000

And it actually works just fine most of the time, if Rust's current limitations are acceptable.

Blacklisting insecure filesystems in openSUSE

intgr — Sun, 17 Feb 2019 14:03:55 +0000

What?! Microkernels are from the stone age, clearly today the solution is to Rewrite it in Rust.

Blacklisting insecure filesystems in openSUSE

Cyberax — Fri, 15 Feb 2019 19:01:01 +0000

I have just lost data from a btrfs RAID5 NAS. We had power outages going and the external enclosure was b0rked by it, causing drives to appear and disappear. BTRFS has corrupted the filesystem beyond repair.

I do have a secondary cloud backup so it's all good.

However, there's no way I'm going to trust btrfs with ANYTHING important.

Blacklisting insecure filesystems in openSUSE

jhhaller — Fri, 15 Feb 2019 16:46:29 +0000

The btrfs status page gives a high level view of RAID56, the details are more subtle. There are a combination of issues related to the write hole potentially corrupting metadata, and no unclean dismount flags suggesting a log replay is needed. But if one uses RAID10 for metadata and RAID 5 for data, the problem should be no worse than other filesystems when there is an unclean dismount. RAID 6 doesn't really support multi-drive failure when the metadata is RAID 10, as one can only lose one drive before there is a possibility of data loss in the RAID 10 metadata. The most recent status is a thread in the email archives here: https://lore.kernel.org/linux-btrfs/5d7f63b2-d340-7c3a-67... - follow the thread.

Blacklisting insecure filesystems in openSUSE

rahulsundaram — Fri, 15 Feb 2019 02:07:26 +0000

> Well, that's not *necessarily* the case, but in practice it very often is.

What is the source of said belief?

Blacklisting insecure filesystems in openSUSE

kmweber — Fri, 15 Feb 2019 01:21:31 +0000

> Just because one person gains wealth doesn't mean that somebody else must be made poorer.

Well, that's not *necessarily* the case, but in practice it very often is.

Blacklisting insecure filesystems in openSUSE

nix — Thu, 14 Feb 2019 16:41:58 +0000

I was wondering why the NCSDK chose LEON, not why the ESA chose to make LEON a SPARC implementation. :)

Blacklisting insecure filesystems in openSUSE

k8to — Wed, 13 Feb 2019 22:31:31 +0000

Hmm, if you mean an arch with a neutral consortium etc guiding it, then I'm not aware of many arches that have met that bar in any point in time. Are there any besides Sparc and I guess hyper-v?

If you mean something with a lot of manufacturers where you could get parts in whatever form you wanted, I think MIPS had hit that stride by 1991. Don't think anything else was close.

Blacklisting insecure filesystems in openSUSE

johannbg — Wed, 13 Feb 2019 19:36:16 +0000

Looks like it's getting disabled instead of fixed thou but if it builds ship it! ;)

Blacklisting insecure filesystems in openSUSE

roblucid — Wed, 13 Feb 2019 16:18:47 +0000

Broken code gets shipped so someone else fixes it :)

Blacklisting insecure filesystems in openSUSE

johannbg — Tue, 12 Feb 2019 22:32:23 +0000

Downstreams should not have to make the types of discussions and decisions.

Is this not failure on behalf of the kernel community?

I mean is it not it's responsability to remove insecure code and or drop it if they cant or if it's unmaintained and just shows that the upstream kernel community deprecation policies, aren't effective enough or non-existant?

How long does a module have to be unmaintained before it eventually gets removed from the kernel?

Which team is responable for the filesystem layer in the kernel community or the modules in question?

So fourth and so on...

Blacklisting insecure filesystems in openSUSE

marcH — Tue, 12 Feb 2019 06:38:59 +0000

https://space.stackexchange.com/questions/729/why-did-the... has pointers.

The choice was made in 1991. What other open and mature ISA was there at the time?

Blacklisting insecure filesystems in openSUSE

xorbe — Mon, 11 Feb 2019 21:22:59 +0000

Apparently a message was posted for 48 hours prior to F2FS being blacklisted. Turns out some users were unhappy about that. Who knew that 48 hours on a devel mailing list might have not reached a wide enough user base audience for comment? The mind boggles!

Blacklisting insecure filesystems in openSUSE

marcH — Mon, 11 Feb 2019 20:44:01 +0000

tl;dr : if your expectations for this mailing list were higher than for social media, lower them.

Blacklisting insecure filesystems in openSUSE

clump — Mon, 11 Feb 2019 18:44:35 +0000

I am really impressed developers got Linux working on things like SPARC32 hardware. I've run Linux distros on old SPARC machines, one PA-RISC machine, an SGI Indigo, and others. To the best of my knowledge, most of the porting and maintenance was volunteer work.

Nowadays Linux runs on just about everything, but there are strong economic reasons for this. I don't really have the desire or space for older hardware. A Raspberry Pi is remarkably inexpensive and makes a very capable, low-power Linux device.

Blacklisting insecure filesystems in openSUSE

khim — Mon, 11 Feb 2019 13:58:10 +0000

RAID56 is not just "advanced". It's red on Status page. And always was red. The fact that people are trying to use it (and are then burned) so often makes me wonder: why attempt to use it does not cause warning in CAPITAL LETTERS from kernel?

Blacklisting insecure network protocols?

epa — Mon, 11 Feb 2019 12:34:55 +0000

Those have to be explicitly enabled. They don't get run when you insert a USB stick. Which is all the SuSE developers are proposing here -- an explicit step to enable these ancient filesystems.

Blacklisting insecure filesystems in openSUSE

mjthayer — Mon, 11 Feb 2019 09:35:06 +0000

Linux distributions always have a few questions for the user at install time. How about adding a simple security-level question? "Do you want security or flexibility? If the second, do not use this system for anything which requires logging in to anything."

Blacklisting insecure filesystems in openSUSE

mjthayer — Mon, 11 Feb 2019 09:32:07 +0000

> Filesystem implementations that are meant for enabling access to legacy media should not be in the kernel, they should be implemented using FUSE.

I could see that happening for more things in the kernel than just filesystems (someone mentioned Decnet and amateur radio protocols below). At the point where people decide its less work than keeping them at kernel-level security. And these days people are building up lots of experience with lots of forms of virtualisation. In the long term I could well see the Linux kernel becoming much more micro-kernel-like than it is today (though not in an academically clean way). Maybe.

Blacklisting insecure filesystems in openSUSE

viiru — Mon, 11 Feb 2019 09:21:41 +0000

> I'd still love to see the long tail of filesystem drivers converted to FUSE filesystems, which would allow mounting them by default with
> a security-isolated driver. (The code could still come from the existing kernel driver.)

Indeed, this is what I think the "helpful" suggestion "Another "helpful" participant repeatedly told the community to implement a microkernel model for filesystems so that security problems could be contained." should be read as. Filesystem implementations that are meant for enabling access to legacy media should not be in the kernel, they should be implemented using FUSE.

Blacklisting insecure network protocols?

shemminger — Mon, 11 Feb 2019 04:47:17 +0000

What about Decnet, and all the amateur radio protocols?
Syskiller keeps finding holes in every one of the old protocols it touches.

Blacklisting insecure filesystems in openSUSE

nix — Mon, 11 Feb 2019 00:26:17 +0000

Interesting! (And it says something about the march of technology that this medium-big-iron architecture first found its way into satellites and now into *part* of a USB-key-sized neural-net contraption. I wonder why they chose LEON... low power requirements, probably. I can't believe they cared about radiation hardening :) )

Blacklisting insecure filesystems in openSUSE

drag — Sun, 10 Feb 2019 05:31:06 +0000

There are a lot of people who have a zero-level grasp of economics.

One of the first really basic things to understand is that wealth is not a zero sum game. Just because one person gains wealth doesn't mean that somebody else must be made poorer. That is not now the world works. That isn't how wealth works.

It's also not how Open Source software works.

There are over 7 billion of people on the planet. There are hundreds of thousands of new people born every day. There are hundreds of millions of people approaching the age were they can start using computers in a meaningful way on their own. There are hundreds of millions of people getting to the point were they are technically aware and can have the ability to choose their own operating system.

For OpenSUSE to become more popular it does not require that it steals users from Debian or Ubuntu. It's not even desirable or useful to think of things in that way either. Ubuntu existing and being popular has made OpenSUSE a better operating system. Redhat succeeding and becoming popular in the enterprise has made OpenSUSE a better operating system.

You are really all on the same team here. Competition is good and diversity is good. But it competition doesn't mean that you are in a combat or war against a adversary. Diversity doesn't mean you need to engage in group politics and fear those that are different. You can gain from your competition even if they gain more then you do. Nobody has to lose anything.

For OpenSUSE to 'Win' all it needs to do is:

1. Create compelling reasons to use OpenSUSE.

2. Make sure that people are aware of these reasons.

3. Live up to the expectations they create in the minds of new users.

I expect, as far as the file system stuff goes, that new users expect that their brand new Linux operating system is secure enough that they can plug in that random USB key the found in the parking lot and not get immediately owned by a attacker.

Probably what is needed is to provide a desktop notification and dmesg output that states that the file system module has been blacklisted because it is known to be insecure. Then provide a way for users to learn a work around if they really really want to do it. You don't have to make it easy for people to screw themselves over, but you can't afford to make them frustrated and confused about what is going on.

Blacklisting insecure filesystems in openSUSE

bjacob — Sat, 09 Feb 2019 23:28:19 +0000

LEON is popular in more than just satellites. It is part of Intel's (acquired) Movidius hardware platform for embedded AI applications.
https://movidius.github.io/ncsdk/ncs.html

Blacklisting insecure filesystems in openSUSE

dezgeg — Sat, 09 Feb 2019 22:49:06 +0000

Well, I guess someone needs to be the first one. Sounds like a perfect time for someone from the openSUSE community to try ;)

Blacklisting insecure filesystems in openSUSE

nix — Sat, 09 Feb 2019 21:54:07 +0000

Yeah, it's been over a decade since SPARC32 kernels really worked. Not terribly surprising, given that more or less the only SPARC32 processor in actual use any more is the LEON, and you're not going to be using one of those unless you're building a satellite.

Blacklisting insecure filesystems in openSUSE

mangix — Sat, 09 Feb 2019 19:46:50 +0000

I've previously reported the f2fs error. No comment. The code actually has several endian related bugs from a quick glance at fsck output as well as the code.

Reported the btrfs issue just now. Given that my issue has probably been there for a long time, I'm not hopeful.

Blacklisting insecure filesystems in openSUSE

mageta — Sat, 09 Feb 2019 14:41:56 +0000

Did you report them? I've been using btrfs with SLES12 and 15 on s390x for 3+ years now (as it is the default filesystem on SLES), and have not seen a single panic/warning, or at least I can't remember one. I didn't use any advanced features like raid and such, but at least snapshots worked also fine.

Blacklisting insecure filesystems in openSUSE

josh — Sat, 09 Feb 2019 13:30:12 +0000

Are any distributions using that by default, though?

Blacklisting insecure filesystems in openSUSE

warrax — Sat, 09 Feb 2019 12:20:23 +0000

Something something microkernels something :)

Blacklisting insecure filesystems in openSUSE

pabs — Sat, 09 Feb 2019 09:24:07 +0000

Is anyone working on merging LKL into Linux mainline these days?

Blacklisting insecure filesystems in openSUSE

dezgeg — Sat, 09 Feb 2019 07:58:01 +0000

lklfuse from https://github.com/lkl/linux allows this today.

Blacklisting insecure filesystems in openSUSE

josh — Sat, 09 Feb 2019 06:35:38 +0000

I'd still love to see the long tail of filesystem drivers converted to FUSE filesystems, which would allow mounting them by default with a security-isolated driver. (The code could still come from the existing kernel driver.)

Blacklisting insecure filesystems in openSUSE

mangix — Sat, 09 Feb 2019 06:15:13 +0000

I have. From kernel 3.18 to 4.19.

Blacklisting insecure filesystems in openSUSE

flussence — Sat, 09 Feb 2019 04:06:34 +0000

>To thrive, Linux distros have to attract users from other Linux distros.

I can't tell if this diatribe over a hypothetical mass migration between Linux On The Desktop™ distros by angry weirdos demanding slick graphical automount of flash drives containing filesystems from before flash drives existed is supposed to be satirical or not. On top of that, it's bizarre to see someone so openly talk about FOSS ecosystem projects infighting and cannibalising each other like it's a good thing when security is at stake.

Microsoft disabled autorun.inf ACE by default over a decade ago, IIRC. I doubt they lost even one millionth of a percent of market share to SUSE over that decision.

Blacklisting insecure filesystems in openSUSE

jeffm — Sat, 09 Feb 2019 03:57:07 +0000

We ship btrfs as the default root file system for SLE12 and SLE15 on all architectures including s390x, which is big endian. The hiccups we have encountered aren't endian related, but rather in the way s390x handles page dirtying. I haven't seen an s390x-specific btrfs bug in some time and it's not for lack of deployments.

Blacklisting insecure filesystems in openSUSE

clump — Sat, 09 Feb 2019 00:49:39 +0000

If a distribution allows some feature, a user could reasonably expect that the feature is supported. I'd rather have something be unavailable than have a false impression of support or security updates.

Perhaps similar to your example, I'd tried compiling upstream kernels on Debian running on SPARC32 quite a while ago. Unfortunately for me, SPARC32 wasn't really well supported even when I wasn't doing unsupported things. My kernels failed to compile and I learned that nobody expected them to. But that's a different story than the distro itself providing something that nobody expects to work.

Blacklisting insecure filesystems in openSUSE

flewellyn — Fri, 08 Feb 2019 20:00:21 +0000

> "... it's probably still fair to say that few people expected the massive discussion that resulted..."

Really? It's been my experience that, no matter how ill-used a piece of code or a feature is, no matter how ancient or obsolete, no matter how bug-ridden and insecure, if a project considers deprecating it, much less removing it, there is going to be SOMEONE out there who insists that this will irrevocably disrupt their workflow. Probably multiple someones. And every single one of those someones is going to descend on the mailing list and make noise.

XKCD even has a comic about this: https://xkcd.com/1172/