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  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:   Fri, 18 Dec 2020 12:10:36 -0800
From:   Dave Hansen <>
To:     Ira Weiny <>,
        Thomas Gleixner <>
Cc:     Ingo Molnar <>, Borislav Petkov <>,
        Andy Lutomirski <>,
        Peter Zijlstra <>,
        Dave Hansen <>,
        Fenghua Yu <>,,,
        Andrew Morton <>,,,,,
        Dan Williams <>,
        Greg KH <>
Subject: Re: [PATCH V3 04/10] x86/pks: Preserve the PKRS MSR on context switch

On 12/18/20 11:42 AM, Ira Weiny wrote:
> Another problem would be if the kmap and kunmap happened in different
> contexts...  :-/  I don't think that is done either but I don't know for
> certain.

It would be really nice to put together some surveillance patches to
help become more certain about these things.  Even a per-task counter
would be better than nothing.

On kmap:
On kunmap:
	WARN_ON(current->kmaps < 0);
On exit:

That would at least find imbalances.  You could take it even further by
having a little array, say:

struct one_kmap {
	struct page *page;
	depot_stack_handle_t handle;


	 struct task_struct {
	+	struct one_kmap kmaps[10];

On kmap() you make a new entry in current->kmaps[], and on kunmap() you
try to find the corresponding entry.  If you can't find one, in the
current task you can even go search all the other tasks and see who
might be responsible.  If something goes and does more than 10
simultaneous kmap()s in one thread, dump a warning and give up.  Or,
dynamically allocate the kmaps[] array.

Then you can dump out the stack of the kmap() culprit if it exits after
a kmap() but without a corresponding kfree().

Something like that should be low overhead enough to get it into things
like the 0day debug kernel.  It should be way cheaper than something
like lockdep.

Powered by blists - more mailing lists