linux-kernel - Re: [PATCH 06/17] x86, mpx: trace attempts to find bounds tables

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]

Date:	Fri, 27 Mar 2015 07:08:05 -0700
From:	Dave Hansen <dave@...1.net>
To:	Borislav Petkov <bp@...en8.de>
CC:	linux-kernel@...r.kernel.org, x86@...nel.org, tglx@...utronix.de,
	dave.hansen@...ux.intel.com
Subject: Re: [PATCH 06/17] x86, mpx: trace attempts to find bounds tables

On 03/27/2015 05:32 AM, Borislav Petkov wrote:
>> > This event traces any time we go looking to unmap a bounds table
>> > for a given virtual address range.  This is useful to ensure
>> > that the kernel actually "tried" to free a bounds table versus
>> > times it succeeded.
>> > 
>> > It might try and fail if it realized that a table was shared
>> > with an adjacent VMA which is not being unmapped.
> Would it make sense to extend this tracepoint to also dump the error
> values returned from unmap_edge_bts() and unmap_single_bt() inside
> mpx_unmap_tables()?

Both of the paths below this point (the "real" unmap and the zap) also
have tracepoints.  It might also get confusing to see -ENOENT in the
success case.  Also, in practice, you can see the siginfo get generated
and tell that something bad happened.

I think I'd rather leave it as-is.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/