Computer Science student.

Sunday, May 27, 2012

Introduction to Arena :

The main problem we want to solve is how to make it easier for users to apply memory protection attributes in a flexible way. Developer who want to control this area of memory and apply/modify or even delete memory protection attributes should make use of libmmu [1] (the result of previous GSoC2009/2011 projects that provide memory protection through mmu). But developer has to know how to work with this API and some low-level knowledge about how the core implements memory protection. To satisfy the need for usable memory protection, I am introducing arenas, which control memory protection attributes of an area of memory. Arena only has the start address and size of an area of memory and needed memory protection attributes to be applied on this area. No libmmu or low-level knowledge is required by a developer who uses Arena to apply memory protection, only the memory area description and memory protection attributes.

Arena could be created by a developer by passing the chunk of memory that needs to have memory protection attributes. Arena can support sharing if there is an area of memory that a developer wants to share between many tasks with the same access attributes (i.e code segment ). Arena could be defined as a construct which specifies memory attributes that could be shared among tasks.

Arenas and tasks have a many-to-many symmetric relationship. All tasks having access to an Arena are "attached" to that Arena. Also a set of Arenas that a specific task has access to are said to be its "Attached Arenas". Context switch code deactivates all Arenas the current task is attached to, and activates the next task’s attached Arenas therefore the CS code needs a way to access all of the arenas attached to a given task. Representing attached Arenas for a task in a linked list/array to keep track of relationship between a task and its attached Arenas is useful so that a context switch code can know which Arenas to deactivate by just have a pointer to current task’s attached Arenas list in its TCB and walk through it to deactivate all the list. When Arena is deleted, all attached tasks TCBs must be updated by deleting this Arena from their lists. The process of updating TCBs could be done by representing attached tasks in a linked list of pointers to TCBs in the ACB, So when an Arena is deleted it traverses the list and updates each attached task’s TCB.

Further (optional) goal is to embed an allocator to an Arena which could be. Then an Arena could be used to allocate memory from its pool, providing tasks a way to share and divide protected memory regions efficiently. Another further goal is to provide Posix mmap support and implementing it using arenas. Also i consider adding naming capability to an Arena.

// The TCB would have a pointer to an array of the following struct.struct Arena_Per_task { /* node of the task in attached_arena->attached_tasks list */ Chain_Node node; /* pointer to a specific Arena which this task is attached to. */ Arena_Control *attached_arena;}

Arena_Status _Arena_Initialize( ) ;/* This function will apply setup fields in Arena_Control and apply memory protectionattributes using libmmu API. Also initializing an empty list of attached_tasks. */Arena_Control* _Arena_Create(void* start_address , size_t size , uint32 attributes ) ; /* This function returns attributes of a given Arena */ uint32_t _Arena_Get_attributes (Arena_Control*);/* This function returns the starting address of that Arena in memory void* _Arena_Get_start_address (Arena_Control* Arena) ;/* This function returns the size of the Arena size_t _Arena_Get_size (Arena_Control* Arena);/* This function update the current attributes for an Arena with new_attributes , could be used for deleting protection */ Arena_Status _Arena_Update_attributes(Arena_Control* , uint32_t new_attributes) ;/* This function create a link between an Arena and a task by adding a pointer to ACB in TCB’s attached arenas list and By adding a pointer to TCB in ACB by adding a pointer to attached task list */ Arena_Status _Arena_Attach(Arena_Control* , Thread_Control* task);/* This function cut the link between a given Arena one of its attached tasks */ Arena_Status _Arena_Detach(Arena_Control* , Thread_Control* task);/* This function mark an Arena as Deactivated when the current task use it and a context switch happens, so that the next task can not access this deactivated Arena. */ Arena_Status _Arena_Deactivate(Arena_Control*) ; /* This function mark an Arena as Activated when a context switch happens, and the next task is attached to that Arena */ Arena_Status _Arena_Activate(Arena_Control*); /* This function delete the Arena and update the Arena list in every attached task TCB by deleting the ACB entry of the deleted Arena */Arena_Status _Arena_Delete(Arena_Control* );

Optional interfaces :

Arena_Control* _Arena_Create_with_allocation(void* xxx_control , uint32 attrib ) ; -xxx_control : is the control struct like heap_controlattrib may consist of the following - attributes : that indicates rwx of that Arena and other attributes - used allocator : that indicates the allocator used by this arena ( if it relies on an allocator ) - The other bits are to be filled (optional)

Arena_Status arena_allocate ( Arena_Control* , uint32 size ) ;

Arena_Status arena_free ( Arena_Control* , void* adress);

// Would we define ARENA_MAX_NUMBER and it initialization declare Arena_Control structs ?