Consider whether tracking of VMAs can be removed from PAL altogether

[thomasknauth]

https://github.com/oscarlab/graphene/blob/e8ba52af50e076eb83f67fab6d41f1bdae17c21d/Pal/src/host/Linux-SGX/enclave_pages.c#L17

Relevant blurb from Slack:

I am thinking whether it's actually necessary to keep this VMA list. We can probably just track a few mappings like the PAL area and the exec area. The library OS has already tracked the VMA list.
3:10 PM
Assuming that the library OS has tracked the VMA list correctly, why don't we just give the library OS whatever addresses it asked for?
3:13 PM
The only reason to track VMAs in the PAL is to support DkVirtualMemoryAlloc(NULL, ...), which we no long do anymore.
3:13 PM
Any thought?

Michał Kowalczyk 3:14 PM
sounds good, but I haven't looked at this part of graphene for quite some time, so I'm not sure whether there aren't any problems with this approach (edited) 

dimakuv 3:46 PM
+1 to @chiache's idea of removing this VMA tracking at the PAL level.
3:47 PM
Indeed, all DkVirtualMemoryAlloc() invocations from LibOS already specify the address.
3:47 PM
However, what happens to malloc() which we have in some places in the Linux-SGX PAL?

[dimakuv]

This is a duplicate of some other issues (e.g. gramineproject/gramine#50), so closing this.