linux-kernel - Re: [RFC PATCH V2 13/22] x86/intel_rdt: Support schemata write

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]

Message-ID: <2db87a79-e13f-ad6b-c399-1ad58585f38e@oracle.com>
Date:   Tue, 20 Feb 2018 17:58:46 -0800
From:   Mike Kravetz <mike.kravetz@...cle.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        Reinette Chatre <reinette.chatre@...el.com>
Cc:     fenghua.yu@...el.com, tony.luck@...el.com, gavin.hindman@...el.com,
        vikas.shivappa@...ux.intel.com, dave.hansen@...el.com,
        mingo@...hat.com, hpa@...or.com, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH V2 13/22] x86/intel_rdt: Support schemata write -
 pseudo-locking core

On 02/20/2018 03:21 PM, Thomas Gleixner wrote:
> On Tue, 20 Feb 2018, Reinette Chatre wrote:
>> On 2/20/2018 9:15 AM, Thomas Gleixner wrote:
>>> On Tue, 13 Feb 2018, Reinette Chatre wrote:
>>>
>>> Now the remaining thing is the memory allocation and the mmap itself. I
>>> really dislike the preallocation of memory right at setup time. Ideally
>>> that should be an allocation of the application itself, but the horrid
>>> wbinvd stuff kinda prevents that. With that restriction we are more or less
>>> bound to immediate allocation and population.
>>
>> Acknowledged. I am not sure if the current permissions would support
>> such a dynamic setup though. At this time the system administrator is
>> the one that sets up the pseudo-locked region and can through
>> permissions of the character device provide access to these regions to
>> user space applications.
> 
> You still would need some interface, e.g. character device which allows you
> to hand in the pointer to the user allocated memory and do the cache
> priming. So you could use the same permission setup for that character
> device.
> 
> The other problem is that we'd need to have MAP_CONTIG first so you
> actually can allocate physically contigous memory from user space. Mike is
> working on that, but it's not available today. The only way to do so today
> (with lots of waste) would be MAP_HUGETLB, which might be an acceptable
> constraint up to the point where MAP_CONTIG is available.

Just to clarify, there is not any activity on exposing a general purpose
MAP_CONTIG interface to user space.  When initially proposed, MAP_CONTIG
was shot down and the suggestion was to create a new in kernel interface
to make allocation of contiguous pages easier.  The initial use case was
a driver which could use the new internal interface as part of it's
mmap() routine to give contiguous regions to user space.

Reinette is using this new interface, but that must be for the ?immediate
allocation? case you are trying to move away from.  Sorry, I have not been
following development of this feature.

If you would have to create a device to accept a user buffer, could you
perhaps use the same device to create/hand out a contiguous mapping?
-- 
Mike Kravetz