Author(s):	Dave Jones
Location	MCC1
Date	jan Wed 30	Days Raw Files
Start	10:40	First Raw Start	error-in-template
Duration	0:45:00	Offset	None
End	11:25	Last Raw End
Chapters
Total cuts_time	None min.

http://lca2013.linux.org.au/schedule/30216/view_talk
raw-playlist raw-mp4-playlist encoded-files-playlist mp4 svg png

assets release.pdf Trinity_A_Linux_kernel_fuzz_tester_and_then_some.json
logs
Admin: episode episode list cut list raw files day marks day marks day image_files

State:	--------- borked edit encode push to queue post richard review 1 email review 2 make public tweet to-miror conf done
Locked:	clear this to unlock
Locked by:	user/process that locked.
Start:	initially scheduled time from master, adjusted to match reality
Duration:	length in hh:mm:ss
Name:	Video Title (shows in video search results)
Emails:	email(s) of the presenter(s)
Released:	Unknown Yes No has someone authorised pubication
Normalise:
Channelcopy:	m=mono, 01=copy left to right, 10=right to left, 00=ignore.
Thumbnail:	filename.png
Description:	Started as a braindead fuzz-testing tool for calling system calls with random garbage, trinity has grown into a tool that (at time of writing) seems to be finding bugs in areas all over the kernel, from network protocols to filesystems, from virtual memory to virtualisation, and many more. While the idea of system call fuzzing has been around for a long time (dating back to days even pre-dating Linux), this tool now uses a number of interesting techniques to find corner-case bugs, and increase overall coverage testing. On startup, Trinity creates a lot of random metadata (sockets, file handles, memory mappings, etc), and passes them to syscalls as they request them. Results are stored, and passed on to other future syscalls (possibly made by different threads). All sorts of mayhem ensues. Will include a demo runthrough, and discussion of some of the more interesting bugs that have been found so far. markdown
Comment:	production notes