Re: [PATCH for-next V2 02/22] IB/core: change pkey table lookups to support full and partial membership for the same pkey

[Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1840 bytes --]

On 09/12/2012 03:56 AM, Jack Morgenstein wrote:
> On the Hypervisor, however, we assume that if both versions of the pkey are in its pkey table,
> then for its own infiniband operation (as opposed to performing its pkey virtualizing function),
> it should operate with the highest membership type in its table for a given 15-bit pkey.

That's what I was looking for.  So, how can you know this assumption is
correct?  It seems to me that if someone wanted to restrict membership
of the hypervisor as part of a security lockdown, then give full
membership to a guest because that guest is some high security, single
task guest, then this assumption would break things (the user would be
able to assign the full membership key to the guest OK, but regardless
of how they wanted the hypervisor to be subscribed to that particular
pkey, it would always get the full membership from the guest).

>> Shouldn't we pick the
>> pkey that's appropriate for the vHCA sending the message?
> 
> We do. When QPs on the guests are created, the modify-qp commands are not executed on the guest,
> but rather are passed to the PPF for processing. The PPF replaces the guest-provided virtual pkey-index
> value with the appropriate physical pkey-index value.  See procedure "update_pkey_index" in file
> resource_tracker.c, and all the places it is called (i.e., in the wrapper functions for the various
> modify-qp firmware commands).

That's fine for the guest, but I don't see how this solves the
assumption issue.  My concern is that I could see a valid scenario that
a user might want to implement for security reasons that I think makes
your assumption above incorrect.


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD
	      http://people.redhat.com/dledford



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 897 bytes --]