# Kernel security and updates

## Proinsias

I have an ~amd64 desktop install I've been happily running for around 6 months. I had been compiling and rebooting into new kernels as and when portage provided them but this has become a little time consuming and I suspect not entirely necessary. I recently started using emerge with --exclude=sys-kernel/gentoo-sources and whilst everything is running just fine I gather it may not be overly wise to be running a kernel longterm without changes as security issues are discovered. 

After a little time duckduckgoing and poking around the wiki and gentoo sites I can't find much information on when my kernel security may need attention and how to address this. If a kernel security issue appears and is fixed/patched is there a simple way to keep a track of this and action the fix? Are all kernel releases on ~arch given security patches? if so how do find out about them and apply them.

I've not been using genkernel, just the manual method, and have a .config that seems to work for me, if in need of a little trimming. I was thinking I could just add a patch, recompile and make install but I've never patched a kernel in gentoo and don't really understand when I would be able to accomplish this with modules on a running kernel or need a reboot.

tl:dr

Picking and sticking with a kernel, whilst keeping it relatively secure. How to?

----------

## ian.au

 *Proinsias wrote:*   

> I have an ~amd64 desktop install I've been happily running for around 6 months. I had been compiling and rebooting into new kernels as and when portage provided them but this has become a little time consuming and I suspect not entirely necessary. I recently started using emerge with --exclude=sys-kernel/gentoo-sources and whilst everything is running just fine I gather it may not be overly wise to be running a kernel longterm without changes as security issues are discovered. 
> 
> After a little time duckduckgoing and poking around the wiki and gentoo sites I can't find much information on when my kernel security may need attention and how to address this. If a kernel security issue appears and is fixed/patched is there a simple way to keep a track of this and action the fix? Are all kernel releases on ~arch given security patches? if so how do find out about them and apply them.
> 
> I've not been using genkernel, just the manual method, and have a .config that seems to work for me, if in need of a little trimming. I was thinking I could just add a patch, recompile and make install but I've never patched a kernel in gentoo and don't really understand when I would be able to accomplish this with modules on a running kernel or need a reboot.
> ...

 

If you must run ~arch - I'd say pick a winner in the long-term stable kernel stakes, (4.9 last time I looked) mask everything above it and allow portage to supply any back-ported security updates via emerge? You're then going to have to manually manage the mask file when you do choose to upgrade. 

Is there a reason you are trying to do this on an ~arch system? It instinctively doesn't seem a great plan if minimising admin is the goal. 

On my stable systems 4.4.x has seen 2 updates in six months... I run ~arch where necessary for packages I need - just not on the kernel, can't remember the last time it caused a problem. Every now and then something bites and requires some juggling of package.accept_keywords - but I've found this method requires the least maintenance overall.

```
ian@lw3 ~ $ genlop -e --date 180 days ago sys-kernel/gentoo-sources

 * sys-kernel/gentoo-sources

     Mon Aug 22 03:16:17 2016 >>> sys-kernel/gentoo-sources-4.4.19

     Sun Oct  9 12:37:16 2016 >>> sys-kernel/gentoo-sources-4.4.21

     Sun Oct 23 19:21:58 2016 >>> sys-kernel/gentoo-sources-4.4.26
```

----------

## NTU

 *Proinsias wrote:*   

> 
> 
> tl:dr
> 
> Picking and sticking with a kernel, whilst keeping it relatively secure. How to?

 

This is exactly why I'm working on backporting all the new kernel security features (such as usercopy) from 4.8 and 4.9 mainline to LTS branches. I've been working on breaking up the PaX/Grsec kernel patch as well and splitting up the features into separate files, that way I won't need to keep jumping to new kernel releases. I asked myself the same question!  :Very Happy: 

----------

## Proinsias

 *ian.au wrote:*   

> 
> 
> If you must run ~arch - I'd say pick a winner in the long-term stable kernel stakes, (4.9 last time I looked) mask everything above it and allow portage to supply any back-ported security updates via emerge? You're then going to have to manually manage the mask file when you do choose to upgrade.

 

Thanks, I didn't realize portage supplied back-ported security updates via emerge. Managing the mask file on upgrades is fine.

 *ian.au wrote:*   

> Is there a reason you are trying to do this on an ~arch system? It instinctively doesn't seem a great plan if minimising admin is the goal.

 

I was seeing a lot of kernel updates, October was when it felt like a lot of work:

```
   Mon Oct  3 22:45:06 2016 >>> sys-kernel/gentoo-sources-4.8.0

     Thu Oct 13 00:25:04 2016 >>> sys-kernel/gentoo-sources-4.8.1

     Mon Oct 17 21:38:07 2016 >>> sys-kernel/gentoo-sources-4.8.2

     Fri Oct 21 23:00:24 2016 >>> sys-kernel/gentoo-sources-4.8.3

     Sun Oct 23 21:35:16 2016 >>> sys-kernel/gentoo-sources-4.8.4

     Sun Oct 30 20:51:51 2016 >>> sys-kernel/gentoo-sources-4.8.5

     Mon Oct 31 21:37:32 2016 >>> sys-kernel/gentoo-sources-4.8.6

```

By the time I'd build a new kernel and cleaned out an older one there was another waiting to go. It was also taking up quite a bit of space and time sorting out alongside keeping virtualbox modules running smoothly.

I moved to ~arch as I was accumulating a lot of packages on ~arch anyway and aside from what occasionally seemed like a barrage of kernel updates the pace and stability seems fine so far.

----------

## Ant P.

Just be responsible. 4.8 was a rough period but you don't need to keep up with every bleeding-edge zero day, once or twice a month is enough.

Attackers don't care about the 4.8 on your desktop; the 2.4 kernel in your router/modem is usually a much easier target.

----------

## Proinsias

Thanks Ant, seems sensible.

----------

