Linux 6.4 Slated To Start Removing Old, Unused & Unmaintained PCMCIA Drivers

[jabl]

Oh and why is scsi superior to other standards ?

Scsi was the pro dude thing in the 90 it was serial and ide was parralel, and then came sata, serial transfers and sas and whatever.

SCSI was parallel back in the day too, it was only with SAS that it switched to serial, SAS being a shorthand for SERIAL attached SCSI.

Actually Pata(ide) was allready superior to scsi back then you only had to terminat 1 drive, 1 was master 2 was slave and you only could have 2 devcies on one slot.

Scsi allowed you like 7 drives ? you had to terminate every drive on the cable, so how was scsi ever superior to the ata standard in a real world situation?

Like you said, SCSI allowed more devices per controller, which was important for RAID arrays and such. SCSI had command queing long before it was eventually added to the IDE/PATA/SATA family (IIRC it was only added in some version of the SATA spec). SCSI supported things like multi-porting (AFAIU still not possible with SATA) and hotplugging.

Now there was eventually a convergence, SATA adopted many features inspired by SCSI, and today both consumer and enterprise drives work with the same NVME command set.

[Weasel]

Are you aware that some part of the kernel are not loadable as modules? You are absolutely sure, that these drivers don't require such code?

E.g. config ISA_BUS is not tristate.

What has that to do with my reply? I was replying to his bullshit misinformation about modules still being "loaded" or even worse "executed". Because computers are magic for him.

Memory management, DMA, threads, scheduling, locking, namespacing etc. are not kernel interfaces. There are many internals that are subject of updates and you need all the drivers that use anything like this to keep in par.

You obviously have no idea what an interface is. It's how the driver works with those "internals", most of them are supposed to be a black box that you just interface with.

Fortunately in this thread we've already found the second volunteer to do this. Because you are not lazy.

BTW please spare more of your free time and keep updating the udev rules. Especially for the pre-PnP devices (you know the "Plug and Play"?).

Why should I? I don't care at all about these old drivers. I never said they shouldn't be removed, either.

I just corrected a gross misinformation because I'm sick of parrots who think security exploits can come from unloaded data on your hard drive. Just because they like to keep it "lean" while they hold gigabytes for other bloated garbage. It's beyond cringe.

[Weasel]

It is nice that you have found a "safe place" to be needlessly confrontational.

Try maintaining code first. This is ~20 yr old code for devices and even standards that have not been in play for well over a decade. Yes an unloaded module has no direct affect on a running kernel, however there re so many edge cases in software dev called "side effects" that cannot be foreseen or in many cases even tested for. It is always better to reduce a code base than to expand it.

If this is such a personal affront to your beliefs then go maintain the drivers, you are free to do so. If that is not some burning desire, then let them go. If you cant maintain them, yet you have a need for them, then use the legacy kernel... its not like Linus is deleting all the archived kernels!

Heck I have an SBC around here that requires a 2.4 era kernel! Its not like I will be screaming to get it into a 6.4 version!

As I said, I never said these shouldn't be removed. I'm telling you the real reason they are, not his bullshit that has no basis in reality and yet people believe it because they are sheep.

I couldn't care less about these drivers, I just cringe when I see people complain of a few kilobytes of code sitting on their 1 TB harddrives and then they bloat it up with gigabytes of crap. And they truly think that the code is the reason their PC is slow!!!

[gotar]

What has that to do with my reply? I was replying to his bullshit misinformation about modules still being "loaded" or even worse "executed". Because computers are magic for him.

He didn't write such thing. His statements were:
- "Actually they could be hurting people and they dont even know it!": true - modules might require the (dualstate) code compiled into the kernel itself, modules might be unexpectedly loaded via aliases or some weird probing,
- "If these drivers are getting compiled in, or even compiled as modules they do get to interface with the kernel": trueish - I'm not sure what that supposed to mean exactly, but in some sense this might be valid.
- "Sure a module driver that is "unloaded" [...], but if it gets loaded and its no longer being maintained that's a very big issue": true - as already explained.

You obviously have no idea what an interface is. It's how the driver works with those "internals", most of them are supposed to be a black box that you just interface with.

Uhm, right. Just grab some random out-of-tree kernel module and grep for:

#if (KERNEL_VERSION(3, 19, 0) > LINUX_VERSION_CODE)

- this might enlighten you a bit about the "black boxing" and the work required for keeping the drivers up to date.

I just corrected a gross misinformation because I'm sick of parrots who think security exploits can come from unloaded data on your hard drive.

They can. Coming from loaded code that was required by these "unloaded" modules. And the "unloaded" modules can become loaded in many funny ways, unless you do lockdown the kernel.

For example - module might get loaded by attacker plugging USB or PCIe device with prepared ID (easy job with some FPGA or CPLD devices, this takes as much as flashing single block, i.e. a few minutes with $70 hardware).
How many systems with disabled autoprobing have you seen? Do you disable autoprobing on each bus? (I do).
Have you actually tried to lockdown such system? Are you aware how hard it is to whitelist e.g. block devices (including the DM and all the virtuals)?
Ever heard about DMA attacks (and circumventing them by IOMMU)?

Unmaintaned kernel modules do pose a threat as long as they are loadable. And if they are laying around they are loadable.

[Weasel]

- "Actually they could be hurting people and they dont even know it!": true - modules might require the (dualstate) code compiled into the kernel itself, modules might be unexpectedly loaded via aliases or some weird probing,

No this is false. If it's not used, it's not hurting any user, it's only hurting devs for wasting time porting it to interface changes.

- "If these drivers are getting compiled in, or even compiled as modules they do get to interface with the kernel": trueish - I'm not sure what that supposed to mean exactly, but in some sense this might be valid.

It's true in the same way saying "water is wet". It's a captain obvious thing. Of course every module interfaces with the kernel when loaded, otherwise it wouldn't do anything. lol.

- "Sure a module driver that is "unloaded" [...], but if it gets loaded and its no longer being maintained that's a very big issue": true - as already explained.

But if it gets loaded it means you need it...? What's worse, loading an unmaintained driver, or not working at all?

Uhm, right. Just grab some random out-of-tree kernel module and grep for:

#if (KERNEL_VERSION(3, 19, 0) > LINUX_VERSION_CODE)

- this might enlighten you a bit about the "black boxing" and the work required for keeping the drivers up to date.

Sounds like bad design to me.

They can. Coming from loaded code that was required by these "unloaded" modules. And the "unloaded" modules can become loaded in many funny ways, unless you do lockdown the kernel.

For example - module might get loaded by attacker plugging USB or PCIe device with prepared ID (easy job with some FPGA or CPLD devices, this takes as much as flashing single block, i.e. a few minutes with $70 hardware).
How many systems with disabled autoprobing have you seen? Do you disable autoprobing on each bus? (I do).
Have you actually tried to lockdown such system? Are you aware how hard it is to whitelist e.g. block devices (including the DM and all the virtuals)?
Ever heard about DMA attacks (and circumventing them by IOMMU)?

Unmaintaned kernel modules do pose a threat as long as they are loadable. And if they are laying around they are loadable.

idk what you're talking about. To load a module you need privileges, and if someone has root privilege I don't care one bit about any extra security, it's compromised already.

If you mean auto loading it based on hardware, sure, but that's a config issue. I'm talking about the situation in which such a module is blacklist by default but still kept in case someone wants to load it manually. That's better than removing it if we ignore developer maintenance time.

Because my point was that was the entire issue. Its removal has nothing to do with USERS, unlike what he claimed. These removals shouldn't be praised by USERS because IT DOES NOT AFFECT THEM.

I can understand why they happen, but users celebrating as if it will change anything for them is fucking cringe to me.

[rogerx]

You're obviously not doing this kind of work. If you did, you would have known, that you cannot even put the old and new hardware into the same machine. Unless you do have some mysterious Xeon scalable motherboards with ISA slots (probably from the same sources, as Windows XP updates).



Then use it. Problem solved.
...


No problem! You've just volunteered to keep them up to date - open github account, fork the tree, keep going!
You know this git/hub things are free (as a beer) to use? You know what the "sources" ("Gentoo, a ... based ...") are, aren't you?

Tons ridicule and full of useless information.

[gotar]

But if it gets loaded it means you need it...? What's worse, loading an unmaintained driver, or not working at all?

Or attacker needs it. Fulfilling his needs is definitely way worse than having some hardware not working.
Hardware bugs is entirely different can of worms...

idk what you're talking about. To load a module you need privileges, and if someone has root privilege I don't care one bit about any extra security, it's compromised already.

You don't need privileges, only physical access to the machine. This is entire surface of attacks (like evil maid) we're trying to avoid using TPMs, FDE, secure boot and kernel signing. Signing vulnerable module is not wise.

Then, even the root account access doesn't need to expose the system. I've got both, ssh and getty access to root accounts which are basically locked down to the point I myself cannot either modify the system or read confidential data. There are capabilities, secure bits, LSMs (Smack is viable).
Setting this up for the first time takes a few hours, nothing special in general. It get's tricky to close different gaps, like dbus and PolKit (and CPU bugs), but these deserve their own CVEs.

If you mean auto loading it based on hardware, sure, but that's a config issue.

That's default. And it's not so easy to change it. Much easier to remove the offending modules entirely.

I'm talking about the situation in which such a module is blacklist by default but still kept in case someone wants to load it manually.

Blacklisted module can still be loaded automatically (when probed by another module). You need to alias it to some /bin/true, but then you cannot load it manually neither.

[gotar]

Tons ridicule and full of useless information.

A bit long, but otherwise looks like good nickname.