linux-kernel - Re: [PATCH V7 1/4] perf/core: Add PERF_SAMPLE_DATA_PAGE

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

Date:   Thu, 17 Sep 2020 17:16:28 -0400
From:   "Liang, Kan" <kan.liang@...ux.intel.com>
To:     Dave Hansen <dave.hansen@...el.com>, peterz@...radead.org,
        mingo@...hat.com, acme@...nel.org, linux-kernel@...r.kernel.org
Cc:     mark.rutland@....com, alexander.shishkin@...ux.intel.com,
        jolsa@...hat.com, eranian@...gle.com, ak@...ux.intel.com,
        kirill.shutemov@...ux.intel.com, mpe@...erman.id.au,
        benh@...nel.crashing.org, paulus@...ba.org
Subject: Re: [PATCH V7 1/4] perf/core: Add PERF_SAMPLE_DATA_PAGE_SIZE



On 9/17/2020 3:00 PM, Dave Hansen wrote:
> On 9/17/20 6:52 AM, kan.liang@...ux.intel.com wrote:
>> +	mm = current->mm;
>> +	if (!mm) {
>> +		/*
>> +		 * For kernel threads and the like, use init_mm so that
>> +		 * we can find kernel memory.
>> +		 */
>> +		mm = &init_mm;
>> +	}
> 
> I think it might be better to use current->active_mm instead of
> current->mm.  Kernel threads can "take over" the mm of the threads that
> switched to them, so they're not actually using all of the page tables
> from the init_mm all the time.
> 
> It's not _common_, thought.  The only time that I think they can diverge
> is when vmalloc PGD sync'ing needs to be done, and there's even an
> effort to remove that.
> 
> But, it's probably more more precise to just use ->active_mm since
> that's what will actually be more consistent with the values loaded into
> CR3.
> 
> I _think_ ->active_mm is always non-NULL, too.
>

Thanks. yes, active_mm looks better here. I will use active_mm to 
replace the mm and &init_mm.

> One last concern as I look at this: I wish it was a bit more
> future-proof.  There are lots of weird things folks are trying to do
> with the page tables, like Address Space Isolation.  For instance, if
> you get a perf NMI when running userspace, current->mm->pgd is
> *different* than the PGD that was in use when userspace was running.
> It's close enough today, but it might not stay that way.  But I can't
> think of any great ways to future proof this code, other than spitting
> out an error message if too many of the page table walks fail when they
> shouldn't.
> 

If the page table walks fail, page size 0 will return. So the worst case 
is that the page size is not available for users, which is not a fatal 
error.

If my understanding is correct, when the above case happens, there is 
nothing we can do for now (because we have no idea what it will become), 
except disabling the page size support and throw an error/warning.

 From the user's perspective, throwing an error message or marking the 
page size unavailable should be the same. I think we may leave the code 
as-is. We can fix the future case later separately.

Thanks,
Kan