pkgbuild: provide a sample

Fix pkgbuild to work with the new project and provide a sample
building the patch for GHOST vulnerability of the glibc.

Change-Id: I6efc3b60edb798e611f2330cfaa5635e70389687
Signed-off-by: Pavel Boldin <pboldin@cloudlinux.com>

Author: paboldin

docker/kernelcare/centos7/gcc-4.8.2-16.el7/Dockerfile

@@ -0,0 +1,4 @@
+FROM centos:centos7
+RUN yum install -y --enablerepo=C7.0.1406-base gcc rpm-build xmlto "perl(ExtUtils::Embed)" patchutils redhat-rpm-config asciidoc elfutils-devel zlib-devel binutils-devel newt-devel python-devel audit-libs-devel perl bison flex hmaccalc tar gzip bzip2 vim python-setuptools ncurses-devel make net-tools bc openssl pesign numactl-devel pciutils-devel gettext kmod hostname libunwind-devel
+RUN yum downgrade -y --enablerepo=C7.0.1406-base gcc-4.8.2-16.el7 cpp-4.8.2-16.el7 kernel-headers-3.10.0-123.el7 libgomp-4.8.2-16.el7 cpp-4.8.2-16.el7 binutils-2.23.52.0.1-16.el7 binutils-devel-2.23.52.0.1-16.el7
+RUN easy_install pyelftools

docs/libcare.rst

@@ -132,6 +132,137 @@ Congratulations on going through the sample! Go on and learn how the magic of
 `kpmake`_ script works, read how the patch is `build under the hood`_ and how
 it is applied by the `kpatch_user`_. Or even jump to our `hacking guide`_!
 
+RHEL7 ``glibc`` sample
+----------------------
+
+.. _`glibc sample`:
+
+Most of the binaries in the system are coming from distribution packages so
+building patches for them is different from the above. Here is how to do it.
+
+This example builds ``glibc`` patch for old fashioned CVE-2015-0235 GHOST_
+vulnerability for RHEL7. The build is done using `scripts/pkgbuild`_ and
+package files are stored in ``../packages/rhel7/glibc/glibc-2.17-55.el7``.
+
+Preparing environment
+~~~~~~~~~~~~~~~~~~~~~
+
+First, we need the exactly the versions of tools and libs. Let's build a
+docker_ image and container for that:
+
+.. code:: console
+
+        $ docker build docker/kernelcare/centos7/gcc-4.8.2-16.el7 \
+                -t kernelcare/centos7:gcc-4.8.2-16.el7
+        ...
+        $ docker run -v $PWD:/libcare --cap-add SYS_PTRACE -it \
+                kernelcare/centos7:gcc-4.8.2-16.el7 /bin/bash
+        [root@... /]#
+
+Now, from inside the container let's install vulnerable version of glibc:
+
+.. code:: console
+
+        [root@... /]# yum downgrade -y --enablerepo=C7.0.1406-base \
+                glibc-2.17-55.el7 glibc-devel-2.17-55.el7 \
+                glibc-headers-2.17-55.el7 glibc-common-2.17-55.el7
+        ...
+
+Build the ``libcare`` tools:
+
+.. code:: console
+
+        [root@... /]# make -C /libcare/src clean all
+        ...
+
+Now build and run the sample GHOST app that runs 16 threads to constantly check
+whether the ``glibc`` is vulnerable to GHOST_ and prints a dot every time it founds
+it still is:
+
+.. code:: console
+
+        [root@... /]# cd /libcare/samples/ghost
+        [root@... ghost]# make
+        ...
+        [root@... ghost]# ./GHOST
+        ............^C
+
+Press Ctrl-C to get your console back and let's start building the patch for
+``glibc``.
+
+Building the patch
+~~~~~~~~~~~~~~~~~~
+
+The build is done in two stages.
+
+First, the original package build is repeated with all the `intermediate
+assembly files`_ stored and saved for later. This greatly helps to speed up
+builds against the same base code. Run the following from inside our docker
+container to prebuild ``glibc`` package:
+
+.. code:: console
+
+        [root@... /]# cd /libcare/
+        [root@... /libcare]# ./scripts/pkgbuild -p packages/rhel7/glibc/glibc-2.17-55.el7
+        ...
+
+This should download the package, do a regular RPM build with ``kpatch_cc``
+wrapper substituted for GCC and store the pre-built data into archive under
+``/kcdata`` directory:
+
+.. code:: console
+
+        [root@... /libcare]# ls /kcdata
+        build.orig-glibc-2.17-55.el7.x86_64.rpm.tgz  glibc-2.17-55.el7.src.rpm
+
+Now let's build the patch, output will be verbose since it contains tests run
+by the ``kp_patch_test`` defined in ``packages/rhel7/glibc/glibc-2.17-55.el7/info``:
+
+.. code:: console
+
+        [root@... /libcare]# ./scripts/pkgbuild packages/rhel7/glibc/glibc-2.17-55.el7
+        ...
+        [root@... /libcare]# ls /kcdata/kpatch*
+        /kcdata/kpatch-glibc-2.17-55.el7.x86_64.tgz
+
+Unwrap build patches and run the GHOST_ sample:
+
+.. code:: console
+
+        [root@... /libcare]# cd /kcdata
+        [root@... /kcdata]# tar xf kpatch*
+        [root@... /kcdata]# /libcare/samples/ghost/GHOST 2>/dev/null &
+        [root@... /kcdata]# patient_pid=$!
+
+And, finally, patch it. All the threads of sample should stop when the GHOST
+vulnerability is finally patched:
+
+.. code:: console
+
+        [root@... /kcdata]# /libcare/src/kpatch_user -v patch -p $patient_pid \
+                        root/kpatch-glibc-2.17-55.el7.x86_64
+        ...
+        1 patch hunk(s) have been successfully applied to PID '...'
+        (Press Enter again)
+        [1]+  Done                    /libcare/samples/ghost/GHOST 2> /dev/null
+
+You can patch any running application this way:
+
+.. code:: console
+
+        [root@... /kcdata]# sleep 100 &
+        [root@... /kcdata]# patient_pid=$!
+        [root@... /kcdata]# /libcare/src/kpatch_user -v patch -p $patient_pid \
+                        root/kpatch-glibc-2.17-55.el7.x86_64
+        ...
+        1 patch hunk(s) have been successfully applied to PID '...'
+
+Congratulations on finishing this rather confusing sample!
+
+.. _GHOST: https://access.redhat.com/articles/1332213
+.. _docker: https://www.docker.com/
+
+
 
 .. contents::
 
@@ -224,6 +355,8 @@ First, the original code is built as is either via make or via packaging
 system. The build is done with compiler substituted to ``kpatch_cc`` wrapper.
 Wrapper's behaviour is configured via environment variables.
 
+.. _`intermediate assembly files`:
+
 When ``kpatch_cc`` is invoked with ``KPATCH_STAGE=original`` it simply builds
 the project while keeping intermediate assembly files under name
 ``.kpatch_${filename}.original.s`` invoking real compiler twice: first with the
@@ -347,6 +480,8 @@ Note that ``kpmake`` uses ``kpatch_cc`` under the hood. Read about it
 Building patch for a package via ``scripts/pkgbuild``
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
+.. _`scripts/pkgbuild`:
+
 The ``scripts/pkgbuild`` is responsible for the building of the patch
 and prebuilding the original package and assembly files. At the moment
 it only supports building of the RPM-based packages.
@@ -374,6 +509,7 @@ The project directory contains three main files:
    packages URL and Docker container images with toolchain
    (GCC/binutils) version required to properly build the package.
 
+   This is not used at the moment and left as information source for the users.
 
 The Doctor: ``kpatch_user``
 ---------------------------
@@ -1001,7 +1137,7 @@ Manual Patch Creation
 Throughout this section availability of the kpatch tools are assumed. To
 build them and add them into PATH do:
 
-.. code:: shell
+.. code:: console
 
     $ make -C src
     $ export PATH=$PWD/src:$PATH

packages/rhel7/glibc/glibc-2.17-55.el7/info

@@ -9,6 +9,7 @@ KP_PROJECT_SPEC=glibc.spec
 KP_PROJECT_DIR=$KP_PROJECT_BUILD_ROOT/BUILD/glibc-2.17-c758a686
 KP_PROJECT_BUILD_DIR=$KP_PROJECT_DIR/build-x86_64-redhat-linux
 
+KP_PROJECT_SOURCE_URL=ftp://bo.mirror.garr.it/2/scientific/7x/SRPMS/vendor/glibc-2.17-55.el7.src.rpm
 KP_PROJECT_SOURCE=glibc-2.17-55.el7.src.rpm
 KP_PROJECT_BINARY=glibc-2.17-55.el7.$ARCH.rpm
 
@@ -71,7 +72,7 @@ _install_originals() {
 }
 
 _run_tests() {
-	export LD_PRELOAD=/kernelcare/user/execve/execve.so
+	export LD_PRELOAD=/libcare/execve/execve.so
 
 	local ld_linux="$KP_PROJECT_BUILD_DIR/elf/ld*"
 
@@ -106,8 +107,9 @@ _run_tests() {
 kp_patch_test() {
 	_install_originals
 
+	KPATCH_TOOLS=/libcare/src		\
 	PATCH_ROOT=/root/${KP_PROJECT_PATCH%.*} \
-		/kernelcare/user/execve/listener >/root/test.log 2>&1 & :
+		/libcare/execve/listener >/root/test.log 2>&1 & :
 	LISTENER_PID=$!
 
 	pushd $KP_PROJECT_BUILD_DIR