linux-kernel - Re: How to verify linux-next

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170929215007.kpea2kan6hg7jzcw@thunk.org>
Date:   Fri, 29 Sep 2017 17:50:07 -0400
From:   Theodore Ts'o <tytso@....edu>
To:     Pintu Kumar <pintu.ping@...il.com>
Cc:     Damian Tometzki <damian.tometzki@...oud.com>,
        Valdis Kletnieks <valdis.kletnieks@...edu>,
        linux-kernel@...r.kernel.org, kernelnewbies@...nelnewbies.org
Subject: Re: How to verify linux-next

On Fri, Sep 29, 2017 at 07:56:41PM +0530, Pintu Kumar wrote:
> BTW, I am more interested in my another query about QEMU arm.
> This will be much quicker and easy for me.
> But the problem is I wanted to use multiple ssh shell on qemu.
> Also I needed a pre-built rootfs image for qemu-arm, cortex-a9
> versatilepb machine.

If you want to get more useful help, it might be interesting if you
were to specify exactly what kind of "verification" you are interested
in doing.  What sort of kernel testing are you interested in doing?
What part of the kernel are you interested in testing?  The fact that
you are trying to test both a Ubuntu x86 box as will as a virtual ARM
box makes it unclear what part of the kernel you are most intested in
testing.

In particular, why do you care about accessing the VM via ssh /
networking?  What sort of testing do you plan to do after manage to
get the kernel running?   And do you care what distribution you use?

I have a huge amount of test automation built for testing kernel file
systems.  This includes building root_fs images for x86 for use with
kvm[1], and arm chroots for use in testing Android systems[2].  There
is also a turn-key images for running tests using the Google Cloud
Platform[3], and even a Dockerfile[4] so people can run kernel tests
using a private Kubernetes cluster.

[1] https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-xfstests.md
[2] https://thunk.org/android-xfstests
[3] https://thunk.org/gce-xfstests
[4] https://github.com/tytso/xfstests-bld/blob/master/kvm-xfstests/Dockerfile

If you don't have a file-system centric view of the world, and want to
do more generalized kernel testing, the above might not be as
interesting to you, although some of the utilities in the xfstests-bld
git tree for setting up and building in build chroots, using
debootstrap to create root_fs.img files, scripts for manipulating
xUnit test result files (the XML format used by Jenkins), using 9p to
communicate between the host system running qemu/kvm and the test VM,
etc.

The point is that if you really want to get serious about kernel
testing, you should really think hard about test automation.  And in
that world, using networking often makes things harder, not easier.
For kvm-xfstests we just do our communications using the serial port,
which made it easy for us to adapt things for android-xfstests, where
we comunicate test runner script via "adb shell".   For gce-xfstests
things _do_ get a bit more complicated, where the test summary gets
e-mail'ed back to the developer, while the full set of test artifacts
are archived on Google Cloud Storage.  But one of the most powerful
things about my setup is vast majority of the test automation code
stays the same regardless of whether the kernel being tested is being
run in KVM, on a physical Android hardware, or in the Cloud using
GCE.

> 2) Let, please point me to a pre-built qemu-arm busy box image with
> full features.

Define "full features".  Busy box images are generally _not_ full
featured.  There is a reason why I use a minimal Debian system; a lot
of the tests I run require bash, and modern shell utilities, and
Python so I can have scripts which manipulate xUnit XML files.
Nevertheless, the complete x86 test VM is still only 87 megs, which is
still small enough that it doesn't cause me any problems.

On the other hand, since I find networking in the test VM to be
completely superfluous (and in fact, gets in the way, since a VM which
is on the corporate network can be a security problem, and may run
afoul of corporate I/T security policies --- and if you don't have
those kinds of security policies, you really should....).  So my
root_fs's general have no networking support whatsoever.  It keeps
$WORK's secops team *much* happier.  :-)

					- Ted