linux-kernel - Re: A set of "standard" virtual devices?

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]

Date:	Mon, 02 Apr 2007 14:49:55 -0700
From:	Roland Dreier <rdreier@...co.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	mathiasen@...il.com
Subject: Re: A set of "standard" virtual devices?

 > > > Obviously, anyone who adheres to the published interface can
 > > > use one of these VID:DIDs -- as far as I'm concerned, even
 > > > hardware vendors; we'll use the SID to distinguish between
 > > > implementations.

 > > I think for this to work, some attempt at a conformance testing
 > > program is required...

 > How would you propose one goes about that?  It seems to me the only
 > plausible thing is "does it work with the unmodified driver included
 > in the Linux kernel?"  What else can one realistically do?

Well, even "works with the Linux driver" can be formalized with a test
plan that describes how to say it works.  But one can also imagine a
test harness that drives the virtual hardware with synthetic test data
and makes sure it does what it's supposed to.

It also helps when writing the spec to try and write lots of anal
"compliance statements" that can be tested in the suite.

But really, I just think we need a stick to shake at people to force
them to fix bugs in their virtual devices, to avoid a big mess of
quirks that defeats the purpose of the whole exercise.

 - R.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/