Re: Change in l4re_rm_attach behaviour?

On 8/27/21 11:18 PM, Paul Boddie wrote:
> On Friday, 27 August 2021 09:20:35 CEST Jakub Jermář wrote:
>>
>> On 8/27/21 1:45 AM, Paul Boddie wrote:
>>>
>>> Anyway, if anyone has any insight into why the attach operation behaviour
>>> is different, I would very much appreciate it!
>>
>> This behavior was introduced by the following commit in 2019:
>>
>> https://github.com/kernkonzept/l4re-core/commit/81edd6119c45be6f1448a5535b13
>> 78fbc9ce89b9
>>
>>     New dataspace and region map APIs
>>
>>     The new APIs allow 64bit offsets and size of dataspaces also on 32bit
>>     architectures. And have a clean and type-safe dataspace flags and
>>     region flags model including execute rights and the possibility of
>>     execute-only pages and so on.
>>
>>     Change-Id: I77273a5bb93c9891bca4f848c9b17db332b1b72a
> 
> That might seem like a while ago, but I put off migrating to the GitHub
> repositories for some time, partly due to issues I was having with my
> increasingly ancient system (it wasn't reliably computing SHA1 digests and
> thus Git was very unhappy), partly due to inertia and having a stable code
> base to work with, although I'm obviously having to catch up now.
> 
>> In general, you must specify the access rights of the attached region
>> explicitly now, otherwise the rights will be --- (empty) and it will not
>> be possible to access the region. Previously the default was RW access.
> 
> Is this to expose the rights more obviously to the client, make it "promise"
> to only access pages in a certain way, and to save the region manager the
> trouble of sending requests to the dataspace that will only end up being
> refused?

This was more like we added support for non-executable data mappings and 
while we were at it we also used that opportunity to fix the interface 
systematically. For example, the flags now have each their own type. 
Before they were all unsigned int's or something like that and so it was 
easy to pass a constant of a wrong type around and not be yelled at by 
the compiler.

Cheers,
Jakub

_______________________________________________
l4-hackers mailing list
[email protected]
https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers