GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — GitHub - cloudlinux/libcare: libcare -- Patch Userspace Code in Live Processes

BranchesTags
Open more actions menu

Latest commit

 

History

131 Commits
131 Commits

Folders and files

NameName
Last commit message
Last commit date
dist
dist
 
 
docker/kernelcare/centos7/gcc-4.8.2-16.el7
docker/kernelcare/centos7/gcc-4.8.2-16.el7
 
 
docs
docs
 
 
packages/rhel7/glibc/glibc-2.17-55.el7
packages/rhel7/glibc/glibc-2.17-55.el7
 
 
patches/glibc/2.17
patches/glibc/2.17
 
 
samples
samples
 
 
scripts
scripts
 
 
src
src
 
 
tests
tests
 
 
.gitattributes
.gitattributes
 
 
.gitignore
.gitignore
 
 
.travis.yml
.travis.yml
 
 
LICENSE
LICENSE
 
 
Makefile
Makefile
 
 
README.rst
README.rst
 
 
Vagrantfile
Vagrantfile
 
 
vagrant_boxes
vagrant_boxes
 
 

Repository files navigation

LibCare -- Patch Userspace Code on Live Processes

https://travis-ci.org/cloudlinux/libcare.svg?branch=master

Welcome to LibCare --- Live Patch Updates for Userspace Processes and Libraries.

LibCare delivers live patches to any of your Linux executables or libraries at the runtime, without the need for restart of your applications. Most frequently it is used to perform critical security updates such as glibc's GHOST (aka CVE-2015-0235, see how we deal with it in GHOST sample) and QEMU's CVE-2017-2615, but can also be used for serious bug fixes on the fly to avoid interruption of service (see server sample).

See https://kernelcare.com for live Linux Kernel updates also.

FAQ

How the live patches are generated?

We use the same code generating procedure we used in production for years in kernelcare.com:

  1. both original and patched source code are translated to assembler,
  2. corresponding assembler files are compared and new instrumented assembler code is generated, where patches are stored into special ELF sections,
  3. instrumented assembler code is compiled using target project's build system while patch ELF sections are collected in binaries',
  4. binary patch files are extracted from the ELF sections.

The libcare-patch-make script is a handy script for the patch generation for a makeable project. Just do:

$ src/libcare-patch-make some_serious_bug.patch

And find binary patches for all the deliverables of the project in the patchroot directory. See our simple server for usage sample.

For more details follow to the patch preparation chapter of the internals.

How the live patches are applied?

It is a lot like loading a shared library into another process' memory:

  1. our binary libcare-ctl (the doctor) attaches to a patient via ptrace(2),
  2. patient's objects are examined by the doctor,
  3. doctor puppets the patient to allocate patch memory near the original object,
  4. references in the patch are resolved by the doctor, the patch code is ready to be executed now,
  5. doctor rewrites targeted original functions with unconditional jumps to the appropriate patched versions, ensuring that no thread of patient is executing them first.

Now the patient executes patched versions of the functions.

For more details follow to the Patching chapter of the internals.

Will my patches re-apply if I restart the process?

Not at the moment. We only track start of the new processes for the tests, see here.

Does live patching affect performance?

Negligibly. Since code patches simply redirect execution from original code functions to the new ones the overhead is small and comparable to additional “jmp” instruction.

Installation and dependencies

All the Linux-distros with available libunwind, elfutils and binutils packages are supported.

However, the libcare is only tested on Ubuntu from 12.04 to 16.04 and on CentOS from 6.8 to 7.x.

Dependencies

To install the dependencies on RHEL/CentOS do the following:

$ sudo yum install -y binutils elfutils elfutils-libelf-devel libunwind-devel

To install the dependencies on Debian/Ubuntu do the following:

$ sudo apt-get install -y binutils elfutils libelf-dev libunwind-dev

Building libcare

To build libcare emit at project's root dir:

$ make -C src
...

This should build all the utilities required to produce a patch out of some project's source code.

It is highly recommended to run the tests as well, enabling Doctor libcare-ctl to attach ptracecles to any of the processes first:

$ sudo setcap cap_sys_ptrace+ep ./src/libcare-ctl
$ make -C tests && echo OK
...
OK

Now all the required tools are built and we can build some patches. Skip to server sample for that.

How does it work?

Internals are quite confusing and are described here.

About

libcare -- Patch Userspace Code in Live Processes

Topics

livepatchuserspace

Resources

Readme
GPL-2.0 license
Activity
Custom properties

Stars

154 stars

Watchers

12 watching

Forks

59 forks
Report repository

Releases

Packages

Used by

Contributors

Languages

You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.