Grsecurity and Custom Kernel Maintenance

Zorbik · 2017-01-20 01:03:56

I use grsecurity for its security benefits that you are hard pressed to find anywhere else. I thought it would be plug and play, and for the most part it is (but this is Arch lets be real. I signed up for this xD), however I have a laptop with a GTX 960M in it.
Next thing I know, I'm compiling a custom kernel so I can use bumblebee and nvidia-grsec. I only changed one option: I turned off code RAP. I named the kernel linux-grsec-custom to make sure I didn't get confused for whatever reason. Well, sure
enough the actual linux-grsec was installed while installing nvidia-grsec since it's a dependency. So I didn't think everything through, and I'm also new to maintaining a custom kernel, which leads me to my questions:

1. If I don't rename the kernel, will it keep other packages from installing the actual linux-grsec kernel through a dependency?
2. How often should I compile the kernel to keep my system up-to-date and patched, but not have to spend a large part of my day compiling a kernel every week or so.
3. Besides letting makepkg use all 4 cores on my laptop, is there anything else I can do to speed up compile time?
4. What other tips or best-practices should I be using to my advantage when maintaining a custom kernel?

Thanks as always for the intelligent advice you guys/gals offer

eschwartz · 2017-01-20 06:32:02

Generally speaking, when compiling a custom kernel you will have to compile the thirdparty modules yourself as well -- if for no other reason than that the extramodules directory contains the uname -r so the repo modules will be in the wrong location.

It's also unwise to try loading modules that weren't built against the exact kernel you are using although if you merely made trivial changes to the .config you can probably get away with it (I think).

If you want the package to serve as a drop-in replacement, you should set the provides and replaces arrays in the PKGBUILD to provide and replace linux-grsec. Either way, the linux kernel is one of the very few packages that doesn't actually cause "partial update" problems -- the kernel is essentially standalone, and any version will work just as well as far as the rest of the system is concerned. (Note: Do not take that as an excuse to install the 2.6 kernel it will bite you.)

modprobed-db from the AUR can record the kernel modules you use over time, and "make localmodconfig" can disable building the modules you don't actually use. This can drastically speed up the time it takes to compile a new kernel.

Zorbik · 2017-01-20 12:40:04

Eschwartz wrote:

Generally speaking, when compiling a custom kernel you will have to compile the thirdparty modules yourself as well -- if for no other reason than that the extramodules directory contains the uname -r so the repo modules will be in the wrong location.
It's also unwise to try loading modules that weren't built against the exact kernel you are using although if you merely made trivial changes to the .config you can probably get away with it (I think).
If you want the package to serve as a drop-in replacement, you should set the provides and replaces arrays in the PKGBUILD to provide and replace linux-grsec. Either way, the linux kernel is one of the very few packages that doesn't actually cause "partial update" problems -- the kernel is essentially standalone, and any version will work just as well as far as the rest of the system is concerned. (Note: Do not take that as an excuse to install the 2.6 kernel it will bite you.)
modprobed-db from the AUR can record the kernel modules you use over time, and "make localmodconfig" can disable building the modules you don't actually use. This can drastically speed up the time it takes to compile a new kernel.

So if I am understanding this correctly, any modules or drivers I would have installed on my own that didnt ship with the linux-grsec kernel need to be compiled manually using this.

Also, I believe that nvidia-grsec was built against the compiled kernel as that was what I had loaded at the time, however I could be wrong and it was built against the non-custom linux-grsec as it was installed. IIRC, nvidia-grsec is not compatible with the stock linux-grsec due to the code RAP which led me to all of this in the first place. Also, I did only change just the single setting in the .config, something which I doubt would cause modules to break, however, point noted and I will most likely follow this logic in the future.

As for the provides and replaces array, that would just be a simple addition of a package name correct? In which case I could name it whatever I wanted to as long as I said that this provides and replaces linux-grsec? Also thank you for clarifying that not updating my kernel every time a new one was shipped will not break my system. I guess a bi-weekly update will probably be the case.

Thank you for the advice. I appreciate it.

Last edited by Zorbik (2017-01-20 12:43:29)

eschwartz · 2017-01-22 04:41:48

The nvidia-grsec package would have been built against the repo package for linux-grsec. If your kernel config changes were to ensure that nvidia worked in the first place, chances are the changes will affect the nvidia moduole somehow, so you may just want to use nvidia-dkms.

You can indeed name your custom kernel whatever you want (and adding "linux-grsec" as a provides and replaces means pacman considers it to have been installed in case a package requires it -- and if you use a custom repo your kernel will "replace" the official one automatically).

Zorbik · 2017-01-22 17:02:28

Ahh I see thank you

So, given the fact that linux remains unused immediately after I boot into my custom kernel, is there a way to forgo installing it in the first place? Or is this a bad practice? If it is, then would there be any downside to just completely uninstalling the base kernel from my machine after I have everything set up? I checked the packages linux is required by, and it appears that any of those packages that I would use there need to be recompiled against my custom kernel anyways. I could see how it would reduce the attack area of my system, however, with changes to the grub config, nobody would be able to boot into the base kernel anyways.

eschwartz · 2017-01-22 17:32:55

Uninstalling the stock kernel (core/linux) accomplishes nothing other than saving space. Which is okay to want.
It does mean you won't have a backup kernel in case this one becomes unbootable due to unforeseen issues though. Backup kernels are never a bad idea.

The only reason it is installed in the first place, is because the base group includes everything it takes to boot up to to a working system, which includes "a kernel, somehow". It is one of the few things which can be totally removed and/or replaced by AUR packages while essentially still being supported by the community, so go right ahead.

Zorbik · 2017-01-22 18:26:21

Awesome. Thank you so much for the advice Learned a lot that will definitely help me out in the near future

Arch Linux

#1 2017-01-20 01:03:56

Grsecurity and Custom Kernel Maintenance

#2 2017-01-20 06:32:02

Re: Grsecurity and Custom Kernel Maintenance

#3 2017-01-20 12:40:04

Re: Grsecurity and Custom Kernel Maintenance

#4 2017-01-22 04:41:48

Re: Grsecurity and Custom Kernel Maintenance

#5 2017-01-22 17:02:28

Re: Grsecurity and Custom Kernel Maintenance

#6 2017-01-22 17:32:55

Re: Grsecurity and Custom Kernel Maintenance

#7 2017-01-22 18:26:21

Re: Grsecurity and Custom Kernel Maintenance

Board footer