linux-kernel - cache flushing or cache line invalidation on page mapping changes

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>] [day] [month] [year] [list]

Date:   Mon, 26 Sep 2016 13:28:32 -0400
From:   HONGIL YOON <hongil.theselfishgene@...il.com>
To:     linux-kernel@...r.kernel.org
Subject: cache flushing or cache line invalidation on page mapping changes

Hello,

I have read kernel codes to understand details of kernel operations
when virtual to physical page mappings are changed or removed,
especially for TLB and cache (line) invalidations (or flushes).

Basically, my understanding is that dirty data from a page which is
unmapped should be written back to memory. Thus invalidations of cache
lines from the page or cache flushing is necessary. Otherwise,
up-to-date data will be lost.

To see how the operations are performed, I checked how WBINVD and
CLFLUSH instructions (for x86) are used by tracking callers of the
instructions (e.g., change_page_attr_set_clr -> set_memory_array_*). I
could not see any functions that call the interfaces. Plus, I also
follow ummap operations. Some of cache flush interfaces are called but
they are not defined for x86.

Plus, documentation/cachetlb.txt file says "...for example, the
physically indexed physically tagged caches of IA32 processors have no
need to implement these interfaces since the caches are fully
synchronized and have no dependency on translation information.".

I think, regardless of cache organization, that the invalidation or
cache flushing is required because of the dirty data.

Am I missing something? I would appreciate it if you could give me any
help or idea.

Thank you, in advance.

Best regards,

Hongil