Re: [Xen-devel] [PATCH 1/5] docs/qemu-deprivilege: Revise and update with status and future plans

[George Dunlap <George.Dunlap@xxxxxxxxxx>]

[Re-sending as this mail seems to have gone missing]

> On Oct 26, 2018, at 3:52 PM, George Dunlap <george.dunlap@xxxxxxxxxx> wrote:
> 
> On 10/26/2018 02:45 PM, Ian Jackson wrote:
>> George Dunlap writes ("[PATCH 1/5] docs/qemu-deprivilege: Revise and update 
>> with status and future plans"):
>>> docs/qemu-deprivilege.txt had some basic instructions for using
>>> dm_restrict, but it was incomplete, misleading, and stale.
>> 
>> Thanks for the updates to the unshare stuff.
>> 
>>> +### Device Model Deprivileging
>>> +
>>> +    Status, Linux: Tech Preview, with limited support
>>                    ^
>>                     dom0
> 
> "Deprivileging" only makes sense in a dom0 context; the definition in
> the first paragraph should make that clear.  I think adding 'dom0' would
> confuse the issue by implying that non-dom0 deprivileging is possible.
> 
>> I think this maybe needs
>> 
>>  +    Status, FreeBSD dom0: Unsupported
>> 
>> too ?  The usual default is supported and not listing it at all is
>> confusing.
> 
> Where do we say the default is supported?  I thought the default for a
> _feature_ not mentioned was "no information" (i.e., might be either
> supported or not -- if there's a question ask), and the default for a
> _configuration_ not mentioned was "unsupported".
> 
>>> +NOTE: Most modern systems have 32-bit UIDs, and so can in theory go up
>>> +to 2^31 (or 2^32 if uids are unsigned).  POSIX only guarantees 16-bit
>>> +UIDs however; UID 65535 is reserved for an invalid value, and 65534 is
>>> +normally allocated to "nobody".  Additionally, some container systems
>>> +have proposed using the upper 32 bits of the uid for a container ID.
>>                                 ^^
>>                                 16
> 
> Ack
> 
>> This is a good paragraph.
>> 
>> Can I suggest we pick a different example to 65536 ?  It's visually
>> similar to the familiar values of 65534 and 65535 and abuts them.
>> 
>> osstest uses 200000 but that's not a multiple of 2^16.
>> How about 131072 ?
> 
> Is the idea for making it a multiple of 2^16 that the values will then
> only take up one entry in the "container ID" space?
> 
> -George


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel