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: <20090819204821.GA27292@elte.hu>
Date:	Wed, 19 Aug 2009 22:48:21 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Avi Kivity <avi@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>,
	Anthony Liguori <anthony@...emonkey.ws>, kvm@...r.kernel.org,
	alacrityvm-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	"Michael S. Tsirkin" <mst@...hat.com>,
	"Ira W. Snyder" <iws@...o.caltech.edu>,
	Joel Becker <joel.becker@...cle.com>
Subject: Re: configfs/sysfs


* Avi Kivity <avi@...hat.com> wrote:

> You may argue, correctly, that syscalls and ioctls are 
> not as flexible.  But this is because no one has 
> invested the effort in making them so.  A struct passed 
> as an argument to a syscall is not extensible.  But if 
> you pass the size of the structure, and also a bitmap 
> of which attributes are present, you gain extensibility 
> and retain the atomicity property of a syscall 
> interface.  I don't think a lot of effort is needed to 
> make an extensible syscall interface just as usable and 
> a lot more efficient than configfs/sysfs.  It should 
> also be simple to bolt a fuse interface on top to 
> expose it to us commandline types.

FYI, an example of such a syscall design and 
implementation has been merged upstream in the .31 merge 
window, see:

 kernel/perf_counter.c::sys_perf_counter_open()

SYSCALL_DEFINE5(perf_counter_open,
                struct perf_counter_attr __user *, attr_uptr,
                pid_t, pid, int, cpu, int, group_fd, unsigned long, flags)

We embedd a '.size' field in struct perf_counter_attr. We 
copy the attribute from user-space in an 
'auto-extend-to-zero' way:

        ret = perf_copy_attr(attr_uptr, &attr);
        if (ret)
                return ret;

where perf_copy_attr() extends the possibly-smaller 
user-space structure to the in-kernel structure and 
zeroes out remaining fields.

This means that older binaries can pass in older 
(smaller) versions of the structure.

This syscall ABI design works very well and has a lot of 
advantages:

 - is extensible in a flexible way

 - it is forwards ABI compatible

 - the kernel is backwards compatible with applications

 - extensions to the ABI dont uglify the interface.

 - new applications can fall back gracefully to older ABI 
   versions if they so choose. (the kernel will reject 
   overlarge attr.size) So full forwards and backwards 
   compatibility can be implemented, if an app wants to.

 - 'same version' ABI uses dont have any interface quirk 
   or performance penalty. (i.e. there's no increasingly 
   complex maze of add-on ABI details for the syscall to 
   multiplex through)

 - the system call stays nice and readable

We've made use of this property of the perfcounters ABI 
and extended it in a compatible way several times 
already, with great success.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ