Category Archives: Linux

Information about Red Hat live kernel patch (kpatch)

Leave a reply

Kernel live patching has been around since about 2010 through various forms in Linux distributions.

Even with Oracle’s ksplice and so on, there have been other people who has been using the live patch capabilities.

However, as a RH employee, I always had a more skeptical view on safety of it.

Recently I had a customer asking for more detailed information, and had a chance to do bit of research on this topic.

First Red Hat’s kpatch;
https://access.redhat.com/solutions/2206511

  • It has formally released and supported from RHEL 8.1, RHEL 7.7; RHEL-7.6, and the kernel-3.10.0-957.35.1.el7.
  • RH does not provide kpatch for all kernel patches but available for selected Important and Critical CVEs.
  • Kpatch patches are cumulative. – You can’t pick and choose! – It means that when you get a new live kernel patch for the kernel, it will have all the fixes of the previous live kernel patch, along with the new fixes. You can safely upgrade the loaded live kernel patch to a newer version.
  • Starting with RHEL 8.5 and kernel-3.10.0-1160.45.1.el, kernels will receive live kernel patches for 6 months. Therefore customers will need to upgrade the kernel and reboot at least twice per year.

How does kpatch work?

If you’re running a kernel version that supports it, you can (and should) take advantage of live kernel patching. This code execution method works alongside kernel probes and function tracing. Instead of relying on redirection using a breakpoint for kernel probes or a predefined location (in the case of function tracing), live patching is generally done by redirecting the code as close to the function entry as possible.

This new method allows for a function to be immediately redirected through a ftrace handler, so instead of calling an older, vulnerable function, it is redirected to a patched version of the function.

To reiterate it;
The kpatch kernel patching solution uses the livepatch kernel subsystem to redirect old functions to new ones. When a live kernel patch is applied to a system, the following things happen:

  1. The kernel patch module is copied to the /var/lib/kpatch/ directory and registered for re-application to the kernel by systemd on next boot.
  2. The kpatch module is loaded into the running kernel and the new functions are registered to the ftrace mechanism with a pointer to the location in memory of the new code.
  3. When the kernel accesses the patched function, it is redirected by the ftrace mechanism which bypasses the original functions and redirects the kernel to patched version of the function.

What’s the differences between kpatch and other live kernel patch solution?

For kpatch vs kGraft, there has been detailed discussion at the linuxplumber conference in 2014.

https://blog.linuxplumbersconf.org/2014/wp-content/uploads/2014/10/LPC2014_LivePatching.txt

More to read:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/managing_monitoring_and_updating_the_kernel/index#applying-patches-with-kernel-live-patching_managing-monitoring-and-updating-the-kernel

Prep’ng a RDS Database instance for Satellite 6 installation

Leave a reply

This is a note for myself on what had to be done to prep RDS database to connect it with Red Hat Satellite 6 installation.

UPDATE:
Currently, Red Hat Satellite using RDS doesn’t work for 2 reasons;
* For Red Hat Satellite 6.10, Postgresql 12.1 the only version of DB supported as an external DB
https://access.redhat.com/documentation/en-us/red_hat_satellite/6.10/html/installing_satellite_server_from_a_disconnected_network/performing-additional-configuration#postgresql-as-an-external-database-considerations_satellite

While I was trying to install oldest Postgresql available was 12.5.

  • Require “rh-postgresql12-postgresql-evr” pkg
    Installation will fail saying ;
    rh-postgresql12-postgresql-evr pkg with a matching version with the RDS, which doesn’t exist.
postgres=> GRANT foreman to postgres;
GRANT ROLE
postgres=> GRANT candlepin to postgres;
GRANT ROLE
postgres=> GRANT pulp to postgres;
GRANT ROLE
  • Create databases

Satellite 6 and its partitions

Leave a reply

This is a note for my own to remember partitions and recommended sizing that I have been using. Below partition table was created to be inline with various security benchmarks. e.g. CIS/Essential 8

OS Partition - 75 - 80 G Required

/boot - 1GiB
/ - 15 GiB
/home - 10GiB
/tmp - 5GiB
/usr - 15 GiB
/var  - 5 GiB
/var/log - 10GiB
/var/log/audit - 10GiB
/var/tmp - 5GiB
swap - 2G
Satellite
Satellite - 650G - 1 TB required
/var/cache/pulp/ - 20 GiB
/var/lib/pulp/ - 480 GiB
/var/lib/mongodb/ - 60 GiB
/var/opt/rh/rh-postgresql12 - 20 GiB
/var/spool/squid/ - 15 GiB

NOTE: From Red Hat Satellite 6.10, Pulp 3 is being used, MongoDB will be deprecated and it will be consolidated to PostgreSQL.

So from 6.10, the recommendations will be to increase PostgreSQL to 45G and remove /var/lib/mongodb.

To create a random password & also create a SHA512 hashed password

Leave a reply

While I work, I need to create random passwords as well as create SHA512 hashed password so it can be added into places like kickstart and so on.

To create a random password

# date +%s | sha512sum | base64 | head -c 32 ; echo</strong>
MjE2NmQwZDQwMWUzMzQ5Yjk2ZDliMGJj

To create a SHA512 hashed password

This is based on https://access.redhat.com/solutions/221403
However, with python3, “print” needs to be in “print ()” form.

# python3 -V</strong>
Python 3.9.2
# python3 -c 'import crypt,getpass; print (crypt.crypt(getpass.getpass()))'</strong>
Password:
$6$21eDal65kOhgvewf$EZLptcc4dOaC3/Fk8Js.seOslXTvt5JQF5TqPssft1tLCmoAZANMdGaqeZidGSVJ7X1RBIn/2xByfTvI9XAzg/