linux-kernel - [ANNOUNCE] RaceHound 1.0 - data race detector for the kernel

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Date:	Thu, 21 May 2015 11:56:37 +0300
From:	Eugene Shatokhin <eugene.shatokhin@...alab.ru>
To:	LKML <linux-kernel@...r.kernel.org>
CC:	Nikita Komarov <nikita@...ov.ru>
Subject: [ANNOUNCE] RaceHound 1.0 - data race detector for the kernel

Hi,

RaceHound 1.0 has been released.

This tool can be used to detect data races in the kernel code in runtime 
on x86. It may miss races but should produce no false alarms.

Suppose it is needed to check if an instruction that accesses data in 
memory may race for these data with some other code. RaceHound operates 
as follows.

1. Place a software breakpoint (Kprobe, actually) on the instruction.
2. When the software breakpoint hits, determine the address and size of 
the data the instruction is about to access.
3. Arm a hardware breakpoint to detect the conflicting accesses to these 
data (writes if the instruction only reads the data, both reads and 
writes otherwise). The hardware breakpoint may cover only a limited 
amount of memory but that is OK for now.
4. Make a delay (the length is configurable).
5. If the hardware breakpoint hits during the delay, report a race.
6. Disarm the hardware breakpoint and let the code execution continue 
normally.

In addition, RaceHound checks if the accessed data have been modified 
during the delay. This also helps detect races if the hardware 
breakpoints have missed them.

The ideas behind all this are similar to those implemented in 
DataCollider tool for MS Windows [1].

In this version, RaceHound was rewritten to use Kprobes for software 
breakpoints as well as to be able to monitor almost any place in the 
kernel where a Kprobe can be placed. So it can now monitor not only the 
instructions in the loadable modules like before, but also in the kernel 
proper or the built-in modules.

Although the tool can now only monitor the instructions supplied by the 
user, I think, I could later implement some kind of automated "sweeping" 
through the given area of code, checking the memory accesses there. May 
be, something similar to what they do on MS Windows [1].

The code of RaceHound is available at https://github.com/winnukem/racehound.
The instructions on how to setup and use it are also there: 
https://github.com/winnukem/racehound/blob/master/README

References:
[1] John Erickson et. al., "Effective Data-Race Detection for the 
Kernel" - Proc. 9th USENIX Symposium on Operating Systems Design and 
Implementation (OSDI'10).

Regards,

Eugene
-- 
Eugene Shatokhin, ROSA
www.rosalab.com
--
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/