linux-kernel - Re: How much of a mess does OpenVZ make? ;) Was: What can OpenVZ do?

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: <20090226162755.GB1456@x200.localdomain>
Date:	Thu, 26 Feb 2009 19:27:56 +0300
From:	Alexey Dobriyan <adobriyan@...il.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Dave Hansen <dave@...ux.vnet.ibm.com>, mpm@...enic.com,
	containers@...ts.linux-foundation.org, hpa@...or.com,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	viro@...iv.linux.org.uk, linux-api@...r.kernel.org, mingo@...e.hu,
	torvalds@...ux-foundation.org, tglx@...utronix.de, xemul@...nvz.org
Subject: Re: How much of a mess does OpenVZ make? ;) Was: What can OpenVZ
	do?

Regarding interactions of C/R with other code:

1. trivia
1a. field in some datastructure is removed

	technically, compilation breaks

	Need to decide what to do -- from trivial compile fix
	by removing code to ignoring some fields in dump image.

1b. field is added

	This is likely to happen silently, so maintainers
	will have to keep an eye on critical data structures
	and general big changes in core kernel.

	Need to decide what to do with new field --
	anything from 'doesn't matter' to 'yeah, needs C/R part'
	with dump format change.

2. non-trivia
2a. standalone subsystem added (say, network protocol)

    If submitter sends C/R part -- excellent.
    If he doesn't, well, don't forget to add tiny bit of check
	and abort if said subsystem is in use.

2b. massacre inside some subsystem (say, struct cred introduction)

	Likely, C/R non-trivially breaks both in compilation and
	in working, requires non-trivial changes in algorithms and in
	C/R dump image.

For some very core data structures dump file images should be made
fatter than needed to more future-proof, like
a) statistics in u64 regardless of in-kernel width.
b) ->vm_flags in image should be at least u64 and bits made append-only
	so dump format would survive flags addition, removal and
	renumbering.
and so on.



So I guess, at first C/R maintainers will take care of all of these issues
with default policy being 'return -E, implement C/R later',
but, ideally, C/R will have same rights as other kernel subsystem, so people
will make non-trivial changes in C/R as they make their own non-trivial
changes.

If last statement isn't acceptable, in-kernel C/R is likely doomed from
the start (especially given lack of in-kernel testsuite).
--
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/