From bc42dfdb73727081e010b7a4d83c14e56b018f22 Mon Sep 17 00:00:00 2001 From: Brooks Davis Date: Fri, 24 Apr 2020 10:13:36 -0700 Subject: [PATCH] Catch up with VM map reservations. As of CTSRD-CHERI/cheribsd@d25a09ef1436400ef903118d2d9e06294c160fe3 we don't need to pad mmap requests, the kernel does it for us. --- cheri-c-programming.tex | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/cheri-c-programming.tex b/cheri-c-programming.tex index 4a32331..adbe1aa 100644 --- a/cheri-c-programming.tex +++ b/cheri-c-programming.tex @@ -1525,10 +1525,11 @@ \subsection{POSIX API changes} \item[\cfunc{mmap} bounds] In CheriABI, the \cfunc{mmap} system call returns a bounded capability to the allocated address space. - The requested mapping must be rounded up in length to ensure that the - returned capability does not overlap with unallocated (or otherwise - allocated) regions. - This currently requires code changes in consumers of \cfunc{mmap}. + To ensure the capability does not overlap other allocations, + lengths that would otherwise be unrepresentable are rounded up + and padded with a new type of guard pages. + These guard pages fault on access and may not be mapped over. + They are unmapped when the rest of the mapping is unmapped. \item[\cfunc{mmap} permissions] The permissions of the capability returned by \cfunc{mmap} are determined by a combination of the