[Re: [libseccomp-discuss] [PATCH 0/3] Install tests for later use] On 13.10.09 (Wed 15:06) Paul Moore wrote:
> On Monday, October 07, 2013 11:42:47 AM Joe MacDonald wrote: > > [Re: [libseccomp-discuss] [PATCH 0/3] Install tests for later use] On > 13.10.03 (Thu 17:06) Paul Moore wrote: [...] > > > FWIW, I currently have some patches queued up which will enable a "check" > > > target in the top level makefile which will run the regression tests and > > > return an error code based on pass/fail. The idea is to make the RPM/Deb > > > based package self-tests a bit easier. Once I resolve a few other things > > > I'll be pushing these patches to the repository. > > > > Will this work for a cross-compile environment? Ultimately that's what > > I'm trying to accomplish here, having something I can use to test the > > ARM packages I build on my x86_64 build system. > > No, the tests will not currently work in a cross-compiled environment. Aside > from running in an ARM VM I don't think that will ever be possible. We do > provide tests that verify a number of architectures, but they are still > running using the *native* library; I'm not sure if that is what you want or > not. > > Is there any *compiled* binary/library that does offer testing in a cross- > compiled environment? I want to know how they do that. Off-hand I don't know of any that do compiled testing in a x-compile environment that you can still run on your host. I can imagine ways to try doing it, but they'd all be pretty Rube Goldberg. qemu supports a great range of architectures these days, but feeding it something to be able to test for a non-native arch seems pretty hairy. > > > > Looking at what libseccomp includes, I think it would fit well with > > > > that model and help me identify regressions that may either be due to > > > > packaging or cross-compilation that I wouldn't be able to (easily) > > > > find otherwise. > > > > > > Are these done at package build time or by an admin during normal runtime? > > > > Typically these are done at package build time, and in the case of bash, > > as I recall it even had a 'check' makefile target that would run them > > all on the built source. The intent being that you can test your > > newly-built shell before you install it and render /bin/sh inert. > > > > The way it is used in Yocto, however, is a separate package gets > > created (eg. <pkg>-ptest.rpm) and it is then possible to install that on > > the target, run the self-tests and remove it using the package > > management system. > > Hmmm, okay, we might be able to do something with that. I've not had much time to look at it this week, but I can absolutely share what I've done to support that already if you're interested. The base I'm working from is the libseccomp recipe already in Yocto's meta-security layer: http://git.yoctoproject.org/cgit/cgit.cgi/meta-security/tree/recipes-security/libseccomp/libseccomp_2.1.0.bb If you're not familiar with Yocto already, that link probably won't help much, the build recipe is pretty simple, but that's where I'll be submitting changes to specifically add ptest support into that package. > > > > They're not the sort of thing that would ever be installed by default in > > > > any regular build, but something that could be brought in for special > > > > case testing and, as in my case, a possible validation step before > > > > calling it done. > > > > > > Hmmm, pointer to more information please. > > > > Sure thing. https://wiki.yoctoproject.org/wiki/Ptest > > > > Further to the information at the above link, The test results from > > libseccomp aren't in the format required by ptest, but I also didn't > > intend to submit any more patches to make them ptest-friendly. The > > results are extremely well structured as they are, so my intention was > > to process them in my own run-ptest script, included as part of the > > recipe, to fit into the required format. > > Agreed, I'm not sure I want to bother with changing the test output right > now, > but if the ptest output is well defined, I'm not opposed to including scripts > and/or Makefile targets to allow libseccomp to play better with Yocto/ptest. > > Care to post a RFC patch, or would you rather maintain it privately? Sure, I'll be happy to post an RFC patch. Essentially, the output for ptest tests is free-form, except they expect to see something like this: [PASS|FAIL|SKIP]: <test-name> That's easily accomplished with the structure of the existing libseccomp tests. So, just to sum up my current plan. I'll put together a script that'll produce output in the format ptest expects. It'll just be a wrapper around the existing test cases in libseccomp and I won't be making any changes to the existing test cases for format. That, I'll send out to the list. I'll also finish up the bit of stuff I was doing to the existing libseccomp recipe to support packaging the tests independent of the library. I can send that to the list too as an FYI, if you (or anyone else) is interested. Depending on what you think, I intend to send that to the meta-security layer for inclusion. I'll likely hold off on that anyway, though, until you get the bugfix release of libseccomp out and get an updated recipe in meta-security first. -- -Joe MacDonald. :wq
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
_______________________________________________ libseccomp-discuss mailing list libseccomp-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libseccomp-discuss
