Deblobbed kernel has security issues?

gorg86 · Apprentice Joined: 20 May 2011 Posts: 299

Hi,

Can somebody please explain this?

eccerr0r · Posted: Tue Jun 09, 2015 3:38 pm Post subject:

This is a problem with all old kernels, if there's no active maintainer, it may very well not be patched for recent security issues that pop up - not related to the blobs.

There are a lot of 'entry points' for security, the blobs tend to be hardware manufacturer entry points. But what the comment is - this is dealing with external hacker based entry points, more likely with network.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

Hu · Moderator Joined: 06 Mar 2007 Posts: 21635

To elaborate on eccerr0r's point, a deblobbed old kernel is the same security risk as a blobs-included old kernel of the same version, ignoring any security bugs in the firmware. The message is because blobs-included kernels may be updated for security issues faster than a deblobbed kernel, so if you need the latest kernel release to patch some security bug, you might only be able to get that version in a blobs-included form. Eventually, the deblob maintainer will catch up and provide a matching deblobbed kernel with the security fix. That message indicates that "eventually" may be measured in days, rather than in minutes, depending on the free time of the deblob maintainer(s).

as.gentoo · Guru Joined: 07 Aug 2004 Posts: 319

IMO:

If the kernel is free software

cord · Guru Joined: 28 Apr 2007 Posts: 344

What can you say about this?

NeddySeagoon · Posted: Sat Jul 25, 2015 8:22 pm Post subject:

It all depends why you want a deblobbed kernel.

In practical terms, hardware that needs the binary blobs in the kernel is rare. If you have some you need its blob(s).
Then the only reason for using a deblodbed is free/open software zelotory.
Now, where do you stop ... USB devices that need closed firmware, your BIOS ...

If you can use a deblobbed kernel, you don't actually need it as you won't be using any of the blobs anyway.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

cord · Guru Joined: 28 Apr 2007 Posts: 344

Well, it's meaning 'blob-dependent security' in case using blobs. And blob-independent security is OK on hardened-sources, right?
If so, I understood now.
As for deblobbed kernels, can you use or you can't, there is interesting link.

NeddySeagoon · Posted: Sun Jul 26, 2015 9:03 am Post subject:

cord,

Thats an interesting read. It misses the point about CPU microcode though.

The CPU will do nothing without some microcode from somewhere. For a long time now, CPUs have emulated the Intel/AMD instruction set by using microcode.
The microcode is stored in ROM inside the CPU and loaded inte RAM (inside the CPU) for execution as a part of the CPU power up sequence
The RAM is much faster than ROM, this approach is required as the microcode is used at the core clock speed of the CPU.

The binary blob microcode distributed by CPU vendors simply replaces the microcode distributed with the CPU, inside the microcode RAM internal to the CPU.
So like it or not, you are using some version of the microcode.

A long time ago, before Intel CPUs had updatable microcode, there was a FPU microcode bug in some Intel CPUs.
Intel replaced these CPUs on request. Today, they would issue a microcode update.

I suspect the same is true for some of the other blobs.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.