On Wed, Feb 03, 2021 at 01:09:30PM +0100, Michal Hocko wrote:
On Tue 02-02-21 10:55:40, James Bottomley wrote:
On Tue, 2021-02-02 at 20:15 +0200, Mike Rapoport wrote:
On Tue, Feb 02, 2021 at 03:34:29PM +0100, David Hildenbrand wrote:
On 02.02.21 15:32, Michal Hocko wrote:
Well the safest security statement is that we never expose the data to the kernel because it's a very clean security statement and easy to enforce. It's also the easiest threat model to analyse. Once we do start exposing the secret to the kernel it alters the threat profile and the analysis and obviously potentially provides the ROP gadget to an attacker to do the same. Instinct tells me that the loss of security doesn't really make up for the ability to swap or migrate but if there were a case for doing the latter, it would have to be a security policy of the user (i.e. a user should be able to decide their data is too sensitive to expose to the kernel).
The security/threat model should be documented in the changelog as well. I am not a security expert but I would tend to agree that not allowing even temporal mapping for data copying (in the kernel) is the most robust approach. Whether that is generally necessary for users I do not know.
From the API POV I think it makes sense to have two modes. NEVER_MAP_IN_KERNEL which would imply no migrateability, no copy_{from,to}_user, no gup or any other way for the kernel to access content of the memory. Maybe even zero the content on the last unmap to never allow any data leak. ALLOW_TEMPORARY would unmap the page from the direct mapping but it would still allow temporary mappings for data copying inside the kernel (thus allow CoW, copy*user, migration). Which one should be default and which an opt-in I do not know. A less restrictive mode to be default and the more restrictive an opt-in via flags makes a lot of sense to me though.
The default is already NEVER_MAP_IN_KERNEL, so there is no explicit flag for this. ALLOW_TEMPORARY should be opt-in, IMHO, and we can add it on top later on.