# Deblobbed kernel has security issues?

## gorg86

Hi,

Can somebody please explain this?

 *Quote:*   

> * Deblobbed kernels may not be up-to-date security-wise
> 
>  * as they depend on external scripts.
> 
>  * This means that it is likely to be vulnerable to recent security issues.
> ...

 

According to that a deblobbed kernel is more of a security risk than a kernel with proprietary firmware.

That would defeat the purpose of a deblobbed kernel, or is that message total baloney?

----------

## eccerr0r

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.

----------

## Hu

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

IMO:

If the kernel is free software

 *https://www.kernel.org/category/faq.html wrote:*   

> Linux kernel is released under GNU GPL version 2 and is therefore Free Software

 then it's maintainers should innately provide a deblobbed kernel (including the most recent version).

----------

## cord

What can you say about this?

----------

## NeddySeagoon

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.

----------

## cord

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

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.

----------

