linux-kernel - Re: [PATCH V8 42/44] dax: Stray access protection for dax_direct

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 3 Feb 2022 21:19:58 -0800
From:   Dan Williams <dan.j.williams@...el.com>
To:     "Weiny, Ira" <ira.weiny@...el.com>
Cc:     Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Fenghua Yu <fenghua.yu@...el.com>,
        Rick Edgecombe <rick.p.edgecombe@...el.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V8 42/44] dax: Stray access protection for dax_direct_access()

On Thu, Jan 27, 2022 at 9:55 AM <ira.weiny@...el.com> wrote:
>
> From: Ira Weiny <ira.weiny@...el.com>
>
> dax_direct_access() provides a way to obtain the direct map address of
> PMEM memory.  Coordinate PKS protection with dax_direct_access() of
> protected devmap pages.
>
> Introduce 3 new dax_operation calls .map_protected .mk_readwrite and
> .mk_noaccess. These 3 calls do not have to be implemented by the dax
> provider if no protection is implemented.
>
> Threads of execution can use dax_mk_{readwrite,noaccess}() to relax the
> protection of the dax device and allow direct use of the kaddr returned
> from dax_direct_access().  The dax_mk_{readwrite,noaccess}() calls only
> need to be used to guard actual access to the memory.  Other uses of
> dax_direct_access() do not need to use these guards.
>
> For users who require a permanent address to the dax device such as the
> DM write cache.  dax_map_protected() indicates that the dax device has
> additional protections and that user should create it's own permanent
> mapping of the memory.  Update the DM write cache code to create this
> permanent mapping.
>
> Signed-off-by: Ira Weiny <ira.weiny@...el.com>
[..]
> diff --git a/include/linux/dax.h b/include/linux/dax.h
> index 9fc5f99a0ae2..261af298f89f 100644
> --- a/include/linux/dax.h
> +++ b/include/linux/dax.h
> @@ -30,6 +30,10 @@ struct dax_operations {
>                         sector_t, sector_t);
>         /* zero_page_range: required operation. Zero page range   */
>         int (*zero_page_range)(struct dax_device *, pgoff_t, size_t);
> +
> +       bool (*map_protected)(struct dax_device *dax_dev);
> +       void (*mk_readwrite)(struct dax_device *dax_dev);
> +       void (*mk_noaccess)(struct dax_device *dax_dev);

So the dax code just recently jettisoned -the >copy_{to,from}_iter()
ops and it would be shame to grow more ops. Given that the
implementation is pgmap generic I think all that is needed is way to
go from a daxdev to a pgmap and then use the pgmap helpers directly
rather than indirecting through the pmem driver just to get the pgmap.