Steps to Build a Custom/Hardened Kernel-default on openSUSE SLE12 SP3

Hello openSUSE community,

I need guidance on building a custom kernel-default on openSUSE SLE 12.3 via kernel-source. My goal is to ensure ASLR and LSB compliance while working inside a VM environment.

Environment Details:

  • OS: openSUSE SLE 12.3
  • Architecture: x86_64
  • Running in: Virtual Machine
  • Kernel Version : kernel-source-4.4.180

What I’ve Tried:

  • Installed kernel-source and development tools using zypper.
  • Extracted the kernel-souce to genrate dthe kernel-default.spec
  • Reviewed some generic Linux kernel build guides, but I’m unsure about the openSUSE-specific steps for configuration and compilation.

Questions:

  1. What is the recommended process for configuring and compiling the kernel on openSUSE?
  2. Are there any official SUSE documentation links or best practices for building a custom kernel without breaking the package manager?
  3. Should I use the gereated kernel-default.spec after extracting the kernel-source?

Any guidance, scripts, or links to official resources would be greatly appreciated.

Thanks in advance!

There is no such product as “openSUSE SLE 12.3” - there’s either openSUSE Leap/Tumbleweed, or there’s SLE. If you’re working with SLE, then you need to ask over at forums.suse.com.

openSUSE did have a 12.3 release that was EOL about 10 years ago, and is no longer supported. SLE my have come with long term support, but that is provided by SUSE, not by the openSUSE community.

Working with the OpenSUSE 12.3 version which was ended 10 years ago . For that kernel , I needed the help since there are no official repos available .

The sources are all there on https://build.opensuse.org/. But openSUSE 12.3 came with kernel 3.7.10. Kernel 4.4.18 (not 180!) might indicate Leap 42.2 (released with kernel 4.4 LTS), end of life in January 2018.

All of that is way outdated and missing all security fixes since then.

Kernel 4.4.180 came with SLES 12 SP3, end of life 2019-06-30.

1 Like

With no repos available, using the build service public instance isn’t going to be feasible or probably even possible - though shundhammer’s response seems to indicate it might be possible.

You might be able to do this with a private instance, but any hardening to be done, you’ll have to do yourself, as the code hasn’t been maintained - so you’ll be responsible for backporting any and all security patches released after the EOL date. What you’re looking to is non-trivial by a long ways - upgrading to a supported release is going to be easier in the long run.