<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">Yeah. Big changes from i586 to i686. I had forgotten your, um, embedded in the embedded space ;-). You and I work at opposite ends of the Linux world! Totally different challenges.<br><br>Code bloat. Install kernels are huge. But to keep security patches respected, custom kernels are not used. The loss of ram is not as costly as the support time. But for super small systems ram size is a critical issue so every byte removed is a win.<br><br>Lib sizes have increased as the cpu instruction set size has increased. <br><br>Your build process looks very exacting. I've not faced the issues you have with emulating much older cpu and having the real newer one's specs bleed through. <br><br>You should write a book on working in tiny compute space with obsolete hardware. What you have constructed is quite unique and the principles are applicable across several regions. Of course only in your copious spare time :-)<br><br><div class="gmail_quote">On May 9, 2021 11:25:15 PM EDT, Chris Fowler <cfowler@outpostsentinel.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
Correct, hardware not supported by a modern distro. i586 that looks like this:</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<span style="font-family: "Courier New", monospace;">processor : 0</span>
<div><span style="font-family: "Courier New", monospace;">vendor_id : Genuine RDC</span></div>
<div><span style="font-family: "Courier New", monospace;">cpu family : 5</span></div>
<div><span style="font-family: "Courier New", monospace;">model : 8</span></div>
<div><span style="font-family: "Courier New", monospace;">model name : 05/08</span></div>
<div><span style="font-family: "Courier New", monospace;">stepping : 6</span></div>
<div><span style="font-family: "Courier New", monospace;">cpu MHz : 999.924</span></div>
<div><span style="font-family: "Courier New", monospace;">fdiv_bug : no</span></div>
<div><span style="font-family: "Courier New", monospace;">hlt_bug : no</span></div>
<div><span style="font-family: "Courier New", monospace;">f00f_bug : no</span></div>
<div><span style="font-family: "Courier New", monospace;">coma_bug : no</span></div>
<div><span style="font-family: "Courier New", monospace;">fpu : yes</span></div>
<div><span style="font-family: "Courier New", monospace;">fpu_exception : yes</span></div>
<div><span style="font-family: "Courier New", monospace;">cpuid level : 1</span></div>
<div><span style="font-family: "Courier New", monospace;">wp : yes</span></div>
<div><span style="font-family: "Courier New", monospace;">flags : fpu tsc cx8 mmx up</span></div>
<div><span style="font-family: "Courier New", monospace;">bogomips : 1999.84</span></div>
<div><span style="font-family: "Courier New", monospace;">clflush size : 32</span></div>
<div><span style="font-family: "Courier New", monospace;">cache_alignment : 32</span></div>
<div><span style="font-family: "Courier New", monospace;">address sizes : 32 bits physical, 32 bits virtual</span></div>
<span style="font-family: "Courier New", monospace;">power management:</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<span><br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<span>Not much variety in the instruction list. The newest Ubuntu disti that will run on it is !0.04. I did not notice how old CentOS 5 is until I built newer disti that was still i586. Thats the LFS-7.7 in the script and I'd it runs newer packages than
CentOS 7.</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<span><br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<span>The 2nd CentOS 5 root is a pristine copy of the same install as the first, but only used for svn co before it is backed up. The first C% root is the work area and dirty.
<br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<span><br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<span>The challenge is maintaining the i586 build as i586 on a system that is really x86_64. /bin/uname is not the only way to identify a system. The C5 roots and even the LFS-7.7 root has a fake /bin/uname that will determine if I'm building. If so, it
returns BS info to the caller. If not, it execs the real one from coreutils. Next, I run a module named 'unam_hack'. It replaces utsname() in the running kernel. This works great, but do not do an apt-get update in the host. The whole desktop reports
back as i586.</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<span><br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<span>Those two methods have worked great. I believe that GCC compiles some assembly ad-hoc and runs it to query the CPU. I can't fake that. I can inform GCC during a normal compile to pass arguments to AS that will stop the build if any contra-band instruction
tries to get past. If a C program uses inline assembly to execute CMOV, AS will error and refuse assembly. I can then look at the offender and try to determine why it is doing that even though it's on configure told it to build on i586. Everyone will tell
you to just leave targets, CFLAGS, LDFLAGS, etc to ./configure, but I'll tell you that the Makefile of many packages have problems with authority, so I like to "head them off at the pass" but forcing specific behavior in the development tools. If you build
700 packages and prefix each one with CFLAGS I guarantee that they will be offenders who will ignore you and tell you to pound sand on that idea. This is especially true if the libraries you are building against are somewhere else than /lib and /usr/lib.
The only thing not built from scratch is /lib/libc and a few friends. I am still taking them from the dev host.
<br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<span><br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<span>To make the LFS-7.7 as true to i586 as possible and not wait a week, I built the /tools (what is used to build the disti) using the native hardware and told GCC to go 'native'. That build takes 23 hours. The next stage (build the whole distribution)
on the native hardware takes 63 hours. My workstation will build it in 2.5 hours using Samsung fast SSD, and all 12 threads going to make -j12. Did I fool it enough that there are no illegal instructions? I'll do a search for all ELFs, dissamble them,
and the search that for illegal instructions. If I find one, I have to go to the source and fund out why.
<br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<span><br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<span>That hardware runs OpenSSL 1.1.1f with all the CVEs applied. I had to patch many of the other programs because they were written for 0.9.8f and 1.1.1f had some major changes in architecture. Some pks I was able to update, and they would still compile
with GCC 4.1.2. Seme PKGs require the SCL toolset #2 to compile. <br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<span><br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<span>The downside to the newer software is that it brings in bloat. The image that runs on the device is only 50M in size and runs as a ramdisk. Device has 1G of ram. The tempalte (product of a full build) I create that 50M squashfs image off of is 2.2G
in size. I use a packaging system during build which created dev, doc, extra, etc packages for each package compiled. To make the image, I rsync copy the template. I then back out all the packages that will not be needed. That includes all those marked
as 'dev'. I need headers and other stuff to do the build. 50M goes to "firmware". The remaining are PKG tarballs that are uploaded to a repo. I can use a program on the device that can download off the repo and store on ext4 with persistent data, like
logs. At each boot, the pkgs in that directory are installed into /, a union of /dev/ram0 (ro) and a tmpfs (rw). The goal here is to never worry about data integrity due to power loss. Simply pull the plug! Rest the box and it is as it was when it last
booted. Pristine. The logs space is not mounted as a union into /, like what Ubuntu does with the casper image on a USB stick. That means that most of /etc is built each boot out of a config system. If a device fails, you simply replace it with another
and then 'restore cloud' using the failed device's serial. I got sick of bricking units during development with my mistakes, so I added that little feature.<br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<span><br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<span>The i586 devices are not made by the manufacturer now. I still have a few hundred deployed so I' trying to support them a little longer. I use a J1900 device a a replacement that runs the same firmware image. My plan is to switch from C5 to the LFS-7.7
root for building the firmware. Test and cut a release from within that root. Test the i586 device under the LFS-8.0 i586 root. I will split off the J1900 and go x86_64 on it. The RDC will only get minor updates, no features.</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<span><br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<span>What's neat about that LFS-8.0 is that I've scripted it just like I did the LFS-7.7. To have LFS-8.0 i586, you need LFS-7.7 i586. To have that, you need Ubuntu 10.04-4 i386. It's all scripted and chained to create an i586 and x86_64 distis for each.<br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<span><br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<span>On my Ubuntu 18.04 x86_64 I'll insmod uname_hack.ko and then run make-disit-all.</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<ol>
<li><span> Downloads a tarball of a / of Ubuntu 10.04-4</span></li><li><span> Unpacks into a directory.</span></li><li><span> Downloads all the build scripts and sources for LFS 7.7</span></li><li><span> chroot into that and builds /tools and then the whole disiti.</span></li><li><span>if KEEP_GOING=0 it starts sshd using daemon in the LFS 7.7 root and then stops. I can now ssh into a pristine root to validate. </span></li><li><span>KEEP_GOING=1 means it downloads the scripts needed to make 8.0 and the sources</span></li><li><span>It builds /tools using its environment</span></li><li><span>It chroots into a directory that only contains /sources and the /tools and it uses /tools it just built to build 8.0</span></li></ol>
<div>You could do it in large steps all the way up to LFS 2021 as long as GCC 10 does not tell you to pound sand using i586.</div>
<div><br>
</div>
<div><br>
</div>
<div>You could use a project like buildout to do some of this, but the RDC is not an anemic device. The original intention of the manufacture is to use the RDC as thin clients, POS, etc. They'll run Windows for that CPU and they'll run any Linux disti that
supports i586 and non-PAE. When I talk about the RDC I call it an "embedded" device. It is treated like an appliance, but more resources than most appliances built during its time.</div>
<div><br>
</div>
<div>I still have java related project that is till 32 bit and runs in CentOS 5 or 6. I'm in the process of upgrading it to 64bit. It's a big project because it contains everything required to run the web app while only needed access to /lib on the host for
a few items. I guess it was like snaps, before snaps was a thing. I can't really get a CentOS 6 droplet from Digital Ocean now. I can install one in VMWare, upload the vmdk, but they don't real support it. They also require cloud-init-0.7.7, C6 runs 0.7.5.
I have a few C6 droplets that have been running for 7 years at DO. I upgraded the oldest (6.5) to 6.10 and created a snapshot. DO allows you to build a droplet off a snapshot. That 6.5 was so old that it was using dracut. The system accepted the snapshot
for the new droplet, but there was no data center that could run it. I uploaded a pristine C6 vmdk image and ran into issues booting it to net. Using the web console, I was able to fix all that. I don't feel good about it and DO does a great job of making
it clear that you will always be solely responsible for custom images. I can only take C6 so far. I have LFS-7.7 close to being ready for a droplet. Cloud-int, etc. DO has great documentation, but every email is more about "we don't support custome images
and we are doing you a favor by sending a reply".</div>
<div><br>
</div>
<div>It's a non-issue really because I'm far along in the x86_64 upgrade for that project. When it comes down to brass tacks with "if it ain't broke you don't fix", as long as you can address CVEs , you don't do something so drastic as a tear down and replace.
You address the CVE. Moving from OpenSSL 0.9.8f on the i586 device to 1.1.1f allows me to address the ones that a truly exploitable on the device. If you're in the business of distributing rootkits, you need to target the lowest common denominator and be
prepared that a reboot makes it as if you were never there to even get onto that RDC. The life of your rootkit is limited to that boot. <br>
</div>
<div><br>
</div>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<span><br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<span><br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<span><br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<span></span><br>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Jim Kinney <jim.kinney@gmail.com><br>
<b>Sent:</b> Sunday, May 9, 2021 7:05 PM<br>
<b>To:</b> Atlanta Linux Enthusiasts <ale@ale.org>; Chris Fowler via Ale <ale@ale.org>; ale@ale.org <ale@ale.org><br>
<b>Cc:</b> Chris Fowler <cfowler@outpostsentinel.com><br>
<b>Subject:</b> Re: [ale] Using a namespace to manage a chroot.</font>
<div> </div>
</div>
<style type="text/css" style="display:none">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">Wow. Really cool stuff. Jchroot looks like a way to solve some real bozo uses of containers and perhaps a non-cgroup way of isolating processes for HPC work.<br>
<br>
Why still centos 5? Specific hardware issues with later stuff?<br>
<br>
<div class="x_gmail_quote">On May 9, 2021 4:47:50 PM EDT, Chris Fowler via Ale <ale@ale.org> wrote:
<blockquote class="x_gmail_quote" style="margin:0pt 0pt 0pt 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
For years I've been running SSH via chroot inside Linux installs on my workstation regardless of the version of Ubuntu the workstation currently runs. This allows me to upgrade my workstation, while still compiling code inside a CentOS distribution.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
At boot I'll do something like this to prepare each chroot.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<span style="font-family:"Courier New",monospace">START_PORT=55;</span><br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<span style="font-family:"Courier New",monospace">for ii in CentOS-5-1 CentOS5-2 LFS-7.7; do</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<span style="font-family:"Courier New",monospace"> for iii in dev dev/pts proc sys; do</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<span style="font-family:"Courier New",monospace"> TEMPLATE="/opt/devel/${ii}"</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<span style="font-family:"Courier New",monospace"> mount -o bind /${iii} ${TEMPLATE}/${ii}</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<span style="font-family:"Courier New",monospace"> sed -i 's#^Port 22.*$#Port '${START_PORT}'#g' ${TEMPLATE}/etc/ssh/sshd_config</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<span style="font-family:"Courier New",monospace"> chroot ${TEMPLATE}/${ii} /etc/init.d/sshd start</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<span style="font-family:"Courier New",monospace"> START_PORT=$(( ${START_PORT} + 1 ))</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<span style="font-family:"Courier New",monospace"> done</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<span style="font-family:"Courier New",monospace">done</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
After boot, My Ubuntu 18.04 workstation will be running 3 other distributions. I'll use SSH to access them as a regular user. Tmux automatically runs on first login, other logins will attach to that session.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
I am thinking I can use unshare to create a namespace and a control group attached to the SSHD start. On death of the SSHD, all processes would automatically be killed, and all mounts be unmount. I'm not 100% sure how to change over to this. Docker is
a no-go because containers are not designed to run a whole disti that requires persistent storage on its /. My workstation supports KVM and I considered this, but when I compile in these system I need all the power the workstation can give in CPU and I/O.
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
If I need to run 'ssh -D' in each one instead for the unshare, I could use daemon to do it. On the host, I could just use 'daemon --name=sshd-1 --stop' to tear down the chroot?</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
I found this last night <a href="https://github.com/vincentbernat/jchroot" id="LPlnk">
https://github.com/vincentbernat/jchroot</a> <br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
It is interesting and works fine under a running 2.6.38 kernel. Creates mounts, runs /bin/bash, on exit the mounts do not exist. On 4.15.0 it does not tear down the mounts on exit. I don't see any errors during strace either. I could use that as the
program daemon runs to start the SSD. daemon --name=devel-sshd01 -- /sbin/jchroot -f /opt/devel/CentOS-5-1/etc/fstab /opt/devel/CentOS-5-1 /usr/sbin/sshd -D -p 55</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
To tear it all up: daemon --name=devel-sshd01 --stop</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<br>
</div>
<div class="x__Entity x__EType_OWALinkPreview x__EId_OWALinkPreview x__EReadonly_1">
<div id="LPBorder_GTaHR0cHM6Ly9naXRodWIuY29tL3ZpbmNlbnRiZXJuYXQvamNocm9vdA.." class="x_LPBorder989734" style="width:100%; margin-top:16px; margin-bottom:16px; max-width:800px; min-width:424px">
<table id="LPContainer989734" role="presentation" style="padding:12px 36px 12px 12px; width:100%; border-width:1px; border-style:solid; border-color:rgb(200,200,200); border-radius:2px">
<tbody>
<tr valign="top" style="border-spacing:0px">
<td>
<div id="LPImageContainer989734" style="margin-right:12px; height:160px; overflow:hidden">
<a target="_blank" id="LPImageAnchor989734" href="https://github.com/vincentbernat/jchroot"><img id="LPThumbnailImageId989734" alt="" width="160" height="160" style="display:block" src="https://avatars1.githubusercontent.com/u/631446?s=400&v=4"></a></div>
</td>
<td style="width:100%">
<div id="LPTitle989734" style="font-size:21px; font-weight:300; margin-right:8px; font-family:"wf_segoe-ui_light","Segoe UI Light","Segoe WP Light","Segoe UI","Segoe WP",Tahoma,Arial,sans-serif; margin-bottom:12px">
<a target="_blank" id="LPUrlAnchor989734" href="https://github.com/vincentbernat/jchroot" style="text-decoration:none">GitHub - vincentbernat/jchroot: a chroot with more isolation</a></div>
<div id="LPDescription989734" style="font-size:14px; max-height:100px; color:rgb(102,102,102); font-family:"wf_segoe-ui_normal","Segoe UI","Segoe WP",Tahoma,Arial,sans-serif; margin-bottom:12px; margin-right:8px; overflow:hidden">
jchroot: a chroot with more isolation. Recent Linux kernels are now able to provide a new PID namespace to a newly created process. The process becomes PID 1 in its own namespace and all processes created in this namespace will be killed when the first process
terminates.</div>
<div id="LPMetadata989734" style="font-size:14px; font-weight:400; color:rgb(166,166,166); font-family:"wf_segoe-ui_normal","Segoe UI","Segoe WP",Tahoma,Arial,sans-serif">
github.com</div>
</td>
</tr>
</tbody>
</table>
</div>
</div>
<br>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<br>
</div>
</blockquote>
</div>
</div></blockquote></div><br>-- <br>Computers amplify human error<br>Super computers are really cool</body></html>