On 20 October 2014 18:25, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > On 20 October 2014 18:16, Andrew Fish <af...@apple.com> wrote: >> >>> On Oct 20, 2014, at 4:36 AM, Ard Biesheuvel <ard.biesheu...@linaro.org> >>> 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. >
After reading more carefully (apologies), I suppose mapping code as write protected may cause trouble for static read-write data then? But mapping data as execute protected should be feasible ... -- 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 >>> edk2-devel@lists.sourceforge.net >>> 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 >> edk2-devel@lists.sourceforge.net >> 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 edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
