linux-kernel - Re: [Xen-devel] [RFC PATCH 28/33] Add Xen grant table support

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:	Wed, 19 Jul 2006 11:04:10 +0100
From:	Harry Butterworth <harry@...utterworth.freeserve.co.uk>
To:	Chris Wright <chrisw@...s-sol.org>
Cc:	linux-kernel@...r.kernel.org, Andrew Morton <akpm@...l.org>,
	Zachary Amsden <zach@...are.com>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	xen-devel@...ts.xensource.com, Ian Pratt <ian.pratt@...source.com>,
	Rusty Russell <rusty@...tcorp.com.au>, Andi Kleen <ak@...e.de>,
	virtualization@...ts.osdl.org,
	Christian Limpach <Christian.Limpach@...cam.ac.uk>
Subject: Re: [Xen-devel] [RFC PATCH 28/33] Add Xen grant table support

I don't think that the current grant-table API/implementation quite
meets the requirements for revocation.

Specifically I think the requirements are that:

1) When a domain starts to reclaim a set of resources it allocated for
inter-domain communication this process is guaranteed to complete
without cooperation from any other domain.

2) When a domain reclaims resources it allocated for inter-domain
communication it can't cause a page fault or other exception in any
other domain.

The current API/implementation meets the second requirement but not the
first.

It's possible to make the current implementation meet the first
requirement if you relax it a bit and allow the superuser to kill an
offending domain via domain 0 but this expands the scope of the failure
from a single inter-domain communication channel to a whole domain which
is undesirable.

Another potential issue with grant-tables is support for efficient N-way
communication but I haven't investigated that personally.

A final point is that quite a lot of fairly tricky code is required to
combine grant-tables, event-channels and xenbus before you can create an
inter-domain communication channel which can be correctly disconnected
and reconnected across module load and unload.

It's appropriate to have a low-level API at the hypervisor because it
keeps the hypervisor as small as possible and therefore easier to audit.

But, whatever the low-level API, whether grant-tables or something which
has better support for revocation and n-way communication, I think there
needs to be a small library to implement a higher level API that is more
convenient for driver authors to use directly.

-
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/