On 20 October 2014 18:16, Andrew Fish <[email protected]> wrote: > >> On Oct 20, 2014, at 4:36 AM, Ard Biesheuvel <[email protected]> >> wrote: >> >> Hello all, >> >> I am currently investigating what would be the best way to make sure >> Runtime Services regions are never mapped both writable and executable >> by the arm64 Linux kernel, as a security enhancement. This is >> especially important under kexec, as the UEFI memory ranges may >> survive many reboots. >> >> It would seem inappropriate to me to just apply the WP bit to RT code >> regions and the XP bit to RT data regions, so I am trying to figure >> out how UEFI uses those bits. The spec lists the EFI_MEMORY_WP and >> EFI_MEMORY_XP bits as indicating whether the hardware that backs a >> memory region supports being configured as the respective type. >> However, those bits are only set based on the nature of the system >> RAM, and inherited by all the allocations that are done from it. I >> can't find any logic that manipulates any of those bits base on the >> code/data nature of the allocation. >> >> So what kind of logic should be applied to this data? Is it in fact >> appropriate to, for instance, write protect a code region just based >> on its type and its attribute having EFI_MEMORY_WP set? >> > > EfiRuntimeServicesData is malloc’ed data used at runtime. > EfiRuntimeServicesCode is the memory allocated to load the PE/COFF image. > Thus it includes the C data and text regions. > > The default linker config for EFI PE/COFF images is to have 32 byte section > alignment to save space, it is not 4K aligned as is typical in the OS. >
Thanks for your reply. However, the question was about write-protected and execute-protected data. While the UEFI spec describes those bits, it is unclear to me if I can legally map the runtime code sections as read-only and the runtime data sections as execute protected, which is preferable from security point of view. Currently, all regions (except the MMIO ones) are mapped read-write-execute, which means an exploit can cause much more damage than necessary, especially considering the fact that Linux has kexec(), which implements reboot without going through a firmware reset. -- Ard. >> >> ------------------------------------------------------------------------------ >> Comprehensive Server Monitoring with Site24x7. >> Monitor 10 servers for $9/Month. >> Get alerted through email, SMS, voice calls or mobile push notifications. >> Take corrective actions from your mobile device. >> http://p.sf.net/sfu/Zoho >> _______________________________________________ >> edk2-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/edk2-devel > > > ------------------------------------------------------------------------------ > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://p.sf.net/sfu/Zoho > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
