[PATCH 2/2] drm/amdgpu: Enable clear page functionality

Michel Dänzer michel.daenzer at mailbox.org
Thu Dec 14 11:14:06 UTC 2023


On 2023-12-14 11:31, Christian König wrote:
> Am 13.12.23 um 16:46 schrieb Michel Dänzer:
>> From a security PoV, the kernel should never return uncleared memory to (at least unprivileged) user space. This series seems like a big step in that direction.
> 
> Well please take a look at the MAP_UNINITIALIZED flag for mmap().

       MAP_UNINITIALIZED (since Linux 2.6.33)
              Don't  clear  anonymous pages.  This flag is intended to improve
              performance on embedded devices.  This flag is honored  only  if
              the  kernel was configured with the CONFIG_MMAP_ALLOW_UNINITIAL‐
              IZED option.  Because of the security implications, that  option
              is  normally  enabled  only  on  embedded devices (i.e., devices
              where one has complete control of the contents of user memory).


> We even have the functionality to return uninitialized system memory when the kernel compile option for this is set

>From mm/Kconfig:

config MMAP_ALLOW_UNINITIALIZED 
        bool "Allow mmapped anonymous memory to be uninitialized"
        depends on EXPERT && !MMU
        default n
        help
          Normally, and according to the Linux spec, anonymous memory obtained
          from mmap() has its contents cleared before it is passed to
          userspace.  Enabling this config option allows you to request that
          mmap() skip that if it is given an MAP_UNINITIALIZED flag, thus
          providing a huge performance boost.  If this option is not enabled,
          then the flag will be ignored.
          
          This is taken advantage of by uClibc's malloc(), and also by
          ELF-FDPIC binfmt's brk and stack allocator.
          
          Because of the obvious security issues, this option should only be
          enabled on embedded devices where you control what is run in
          userspace.  Since that isn't generally a problem on no-MMU systems,
          it is normally safe to say Y here.
        
          See Documentation/admin-guide/mm/nommu-mmap.rst for more information.


Both looks consistent with what I wrote.


> since this is an important optimization for many use cases.

Per above, it's available only on platforms without MMU.


-- 
Earthling Michel Dänzer            |                  https://redhat.com
Libre software enthusiast          |         Mesa and Xwayland developer



More information about the dri-devel mailing list