From a87f55960b1c75aa2372576b6bcae0d003ace8a9 Mon Sep 17 00:00:00 2001 From: Davidlohr Bueso Date: Tue, 6 Jun 2023 13:57:27 -0700 Subject: docs: typo fixes Fix various typos within the documentation directory. --- docs/akaros/README.md | 2 +- docs/contributing.md | 6 +++--- docs/coverage.md | 6 +++--- docs/linux/external_fuzzing_network.md | 4 ++-- docs/linux/reporting_kernel_bugs.md | 6 +++--- docs/linux/setup_linux-host_isolated.md | 2 +- docs/linux/setup_ubuntu-host_odroid-c2-board_arm64-kernel.md | 2 +- docs/linux/setup_ubuntu-host_vmware-vm_x86-64-kernel.md | 2 +- docs/netbsd/README.md | 4 ++-- docs/setup_syzbot.md | 4 ++-- docs/strace.md | 2 +- docs/syscall_descriptions.md | 2 +- docs/syzbot.md | 8 ++++---- 13 files changed, 25 insertions(+), 25 deletions(-) diff --git a/docs/akaros/README.md b/docs/akaros/README.md index f49662c02..ec89711bc 100644 --- a/docs/akaros/README.md +++ b/docs/akaros/README.md @@ -7,7 +7,7 @@ re kernel building/running. Akaros does not support Go at the moment (except for a broken [1.3 port](https://github.com/akaros/go-akaros)). Full Go support is planned -for Akaros. Until that happens running on Akaros is challening. However, +for Akaros. Until that happens running on Akaros is challenging. However, `syz-stress` can be run as follows: ```shell diff --git a/docs/contributing.md b/docs/contributing.md index fa60d0b16..915eae7f8 100644 --- a/docs/contributing.md +++ b/docs/contributing.md @@ -81,7 +81,7 @@ in the same commit. ### How to create a pull request on Github -- First, you need an own git fork of syzkaller repository. Nagivate to +- First, you need an own git fork of syzkaller repository. Navigate to [github.com/google/syzkaller](https://github.com/google/syzkaller) and press `Fork` button in the top-right corner of the page. This will create `https://github.com/YOUR_GITHUB_USERNAME/syzkaller` repository. @@ -103,8 +103,8 @@ This adds git origin `my-origin` with your repository and checks out new branch - Commit changes locally. For this you need to run `git add` for all changed files, e.g. `git add sys/linux/sys.txt`. You can run `git status` to see what files were changed/created. When all files are added (`git status` shows no files in `Changes not staged for commit` section and no relevant files in `Untracked files` section), run `git commit` and enter commit description in your editor. - Run tests locally (`make install_prerequisites` followed by `make presubmit`). - Push the commit to your fork on github with `git push my-origin my-branch`. -- Nagivate to [github.com/google/syzkaller](https://github.com/google/syzkaller) and you should see green `Compare & pull request` button, press it. Then press `Create pull request`. Now your pull request should show up on [pull requests page](https://github.com/google/syzkaller/pulls). -- If you don't see `Create pull request` button for any reason, you can create pull request manually. For that nagivate to [pull requests page](https://github.com/google/syzkaller/pulls), press `New pull request`, then `compare across forks` and choose `google/syzkaller`/`master` as base and `YOUR_GITHUB_USERNAME/syzkaller`/`my-branch` as compare and press `Create pull request`. +- Navigate to [github.com/google/syzkaller](https://github.com/google/syzkaller) and you should see green `Compare & pull request` button, press it. Then press `Create pull request`. Now your pull request should show up on [pull requests page](https://github.com/google/syzkaller/pulls). +- If you don't see `Create pull request` button for any reason, you can create pull request manually. For that navigate to [pull requests page](https://github.com/google/syzkaller/pulls), press `New pull request`, then `compare across forks` and choose `google/syzkaller`/`master` as base and `YOUR_GITHUB_USERNAME/syzkaller`/`my-branch` as compare and press `Create pull request`. - If you decided to rebase commits in `my-branch` (e.g. to rebase them onto updated master) after you created a pull-request, you will need to do a force push: `git push -f my-origin my-branch`. ### Using syz-env diff --git a/docs/coverage.md b/docs/coverage.md index 42cba097c..66c3859c4 100644 --- a/docs/coverage.md +++ b/docs/coverage.md @@ -32,13 +32,13 @@ If you click on percentage number of any listed source file you will get cover p ### Covered: black (#000000) -All PC values associated to that line are covered. There is number on the left side indicating how many programs have triggered executing the PC values assocaciated to this line. You can click on that number and it will open last executed program. Example below shows how single line which is fully covered is shown. +All PC values associated to that line are covered. There is number on the left side indicating how many programs have triggered executing the PC values associated to this line. You can click on that number and it will open last executed program. Example below shows how single line which is fully covered is shown. ![Code line is fully covered](coverage_covered.png?raw=true) ### Both: orange (#c86400) -There are several PC values associated to the line and not all of these are executed. Again there is number left to the source code line that can clicked to open last program triggering associated PC values. Example below shows single line which has both excuted and non-executed PC values associated to it. +There are several PC values associated to the line and not all of these are executed. Again there is number left to the source code line that can clicked to open last program triggering associated PC values. Example below shows single line which has both executed and non-executed PC values associated to it. ![Code line has executed and not executed PC values](coverage_both.png?raw=true) @@ -46,7 +46,7 @@ There are several PC values associated to the line and not all of these are exec Function (symbol) this line is in doesn't have any coverage. I.e. the function is not executed at all. Please note that if compiler have optimized certain symbol out and made the code inline instead symbol associated with this line is the one where the code is compiled into. This makes it sometimes real hard to figure out meaning of coloring. Example below shows how single line which is uncovered and PC values associated to it are in function(s) that are not executed either is shown. -![PC values associated to the line are not exexuted and these PC values are in functions that are not executed either](coverage_weak-uncovered.png?raw=true) +![PC values associated to the line are not executed and these PC values are in functions that are not executed either](coverage_weak-uncovered.png?raw=true) ### Uncovered: red (#ff0000) diff --git a/docs/linux/external_fuzzing_network.md b/docs/linux/external_fuzzing_network.md index 03463f876..e6b0d4d73 100644 --- a/docs/linux/external_fuzzing_network.md +++ b/docs/linux/external_fuzzing_network.md @@ -12,10 +12,10 @@ See `initialize_tun()` in [executor/common_linux.h](/executor/common_linux.h) fo The template descriptions can be found in [sys/linux/vnet.txt](/sys/linux/vnet.txt). At this moment there are 2 fake syscalls: `syz_emit_ethernet` and `syz_extract_tcp_res`. The first one externally sends a packet through the virtual interface. -The second one tries to externally receive a packet back and parse TCP sequence numbers from it for use in subseqent packets. +The second one tries to externally receive a packet back and parse TCP sequence numbers from it for use in subsequent packets. There are many protocols or protocol extensions that are not described yet, so the additions are welcome! -Since fuzzing may be done in mutiple executor proccesses within the same VM instance, we need a way to isolate the virtual networks for different executors. +Since fuzzing may be done in multiple executor processes within the same VM instance, we need a way to isolate the virtual networks for different executors. Right now this is done by creating one virtual interface per executor and assigning different MAC, IPv4 and IPv6 addresses to each of these interfaces. Then the template descriptions make use of the `proc` type to generate proper addresses for each executor. diff --git a/docs/linux/reporting_kernel_bugs.md b/docs/linux/reporting_kernel_bugs.md index 689f7d67f..4d7547a8e 100644 --- a/docs/linux/reporting_kernel_bugs.md +++ b/docs/linux/reporting_kernel_bugs.md @@ -14,18 +14,18 @@ If there are stalls or hangs, only report them if they are frequent enough or ha Overall, bugs without reproducers are way less likely to be triaged and fixed. If the bug is reproducible, include the reproducer (C source if possible, otherwise a syzkaller program) and the `.config` you used for your kernel. -If the reprocucer is available only in the form of a syzkaller program, please link [the instructions on how to execute them](/docs/executing_syzkaller_programs.md) in your report. +If the reproducer is available only in the form of a syzkaller program, please link [the instructions on how to execute them](/docs/executing_syzkaller_programs.md) in your report. Check that the reproducer works if you run it manually. Syzkaller tries to simplify the reproducer, but the result might not be ideal. You can try to simplify or annotate the reproducer manually, that greatly helps kernel developers to figure out why the bug occurs. -If you want to get extra credit, you can try to undestand the bug and develop a fix yourself. +If you want to get extra credit, you can try to understand the bug and develop a fix yourself. If you can't figure out the right fix, but have some understanding of the bug, please add your thoughts and conclusions to the report, that will save some time for kernel developers. ## Reporting security bugs If you believe that a found bug poses potential security threat, consider following the instructions below. -Note, that these instructions are a work-in-progress and based on my current undestanding of the disclosure proccess. +Note, that these instructions are a work-in-progress and based on my current understanding of the disclosure process. This instruction is now being discussed [here](http://seclists.org/oss-sec/2017/q3/242). If you don't want to deal with this complex disclosure process you can either: diff --git a/docs/linux/setup_linux-host_isolated.md b/docs/linux/setup_linux-host_isolated.md index 2d36ca495..205eeff4c 100644 --- a/docs/linux/setup_linux-host_isolated.md +++ b/docs/linux/setup_linux-host_isolated.md @@ -94,7 +94,7 @@ Don't forget to update: - `workdir` (path to the workdir) - `kernel_obj` (path to kernel build directory) - `sshkey` You can setup an sshkey (optional) - - `vm.targets` List of hosts to use for fufzzing + - `vm.targets` List of hosts to use for fuzzing - `vm.target_dir` Working directory on the target host - `vm.target_reboot` Reboot the machine if remote process hang (useful for wide fuzzing, false by default) diff --git a/docs/linux/setup_ubuntu-host_odroid-c2-board_arm64-kernel.md b/docs/linux/setup_ubuntu-host_odroid-c2-board_arm64-kernel.md index 6ecf5a894..c03af9968 100644 --- a/docs/linux/setup_ubuntu-host_odroid-c2-board_arm64-kernel.md +++ b/docs/linux/setup_ubuntu-host_odroid-c2-board_arm64-kernel.md @@ -186,7 +186,7 @@ index 9576775a86f6..8bc4eb36fc1b 100644 ifeq ($(call cc-option, $(CFLAGS_KASAN_MINIMAL) -Werror),) ``` -Configure the kernel (you might wan't to enable more configs as listed [here](kernel_configs.md)): +Configure the kernel (you might want to enable more configs as listed [here](kernel_configs.md)): ``` bash make defconfig # Edit .config to enable the following configs: diff --git a/docs/linux/setup_ubuntu-host_vmware-vm_x86-64-kernel.md b/docs/linux/setup_ubuntu-host_vmware-vm_x86-64-kernel.md index 1b2daf328..2aabb5a32 100644 --- a/docs/linux/setup_ubuntu-host_vmware-vm_x86-64-kernel.md +++ b/docs/linux/setup_ubuntu-host_vmware-vm_x86-64-kernel.md @@ -51,7 +51,7 @@ Assuming you want to create the new VM in `$VMPATH`, complete the wizard as foll * Virtual Disk Type: IDE * Disk: select "Use an existing virtual disk" * Existing Disk File: enter the path of `disk.vmdk` created above -* Select "Cusomize Hardware..." and remove the "Printer" device if you have one. Add a new "Serial Port" device. For the serial port connection choose "Use socket (named pipe)" and enter "serial" for the socket path. At the end it should look like this: +* Select "Customize Hardware..." and remove the "Printer" device if you have one. Add a new "Serial Port" device. For the serial port connection choose "Use socket (named pipe)" and enter "serial" for the socket path. At the end it should look like this: ![Virtual Machine Settings](vmw-settings.png?raw=true) diff --git a/docs/netbsd/README.md b/docs/netbsd/README.md index c59f02ed4..e33c26274 100644 --- a/docs/netbsd/README.md +++ b/docs/netbsd/README.md @@ -201,8 +201,8 @@ ssh -i netbsd-image.key -p 10022 -o IdentitiesOnly=yes root@localhost /sbin/rebo ## Missing things -- Automating the configuation changes (like appending to config files), generating the json config file on the fly (with customizable values to the keys using command line parameters) and calling syz-manager with `anita` using just a single command. +- Automating the configuration changes (like appending to config files), generating the json config file on the fly (with customizable values to the keys using command line parameters) and calling syz-manager with `anita` using just a single command. - System call descriptions. `sys/netbsd/*.txt` is a dirty copy from `sys/linux/*.txt` with everything that does not compile dropped. We need to go through syscalls and verify/fix/extend them, including devices/ioctls/etc. - Currently only `amd64` arch is supported. Supporting `386` would be useful, because it should cover compat paths. Also, we could do testing of the linux-compatibility subsystem. - `pkg/host` needs to be taught how to detect supported syscalls/devices. -- On Linux we have emission of exernal networking/USB traffic into kernel using tun/gadgetfs. Implementing these for NetBSD could uncover a number of high-profile bugs. +- On Linux we have emission of external networking/USB traffic into kernel using tun/gadgetfs. Implementing these for NetBSD could uncover a number of high-profile bugs. diff --git a/docs/setup_syzbot.md b/docs/setup_syzbot.md index 5c33ab56a..060efcc6d 100644 --- a/docs/setup_syzbot.md +++ b/docs/setup_syzbot.md @@ -15,7 +15,7 @@ This doc assumes that you: - ran `gcloud auth login` to run authenticated gcloud commands - read [go/syzbot-setup](https://goto.google.com/syzbot-setup) if you are a Googler -While most syzkaller bits happily run on various operating systems, the syzbot dashboard does not. The dashboard is a Google App Engine or GAE project. GAE allows developers to develop web applications without needing to worry about the underlying servers. Instead developers just push their code and GAE takes care of web servers, load balancers and more. Hence this document is more Google Cloud focussed than the rest of our documentation. +While most syzkaller bits happily run on various operating systems, the syzbot dashboard does not. The dashboard is a Google App Engine or GAE project. GAE allows developers to develop web applications without needing to worry about the underlying servers. Instead developers just push their code and GAE takes care of web servers, load balancers and more. Hence this document is more Google Cloud focused than the rest of our documentation. We will also deploy a syz-ci instance. syz-ci keeps track of the syzkaller and kernel repositories and continuously rebuilds the kernel under test, itself and other syzkaller components when new commits land in the upstream repositories. syz-ci also takes care of (re)starting syz-manager instances, which in turn (re)start VMs fuzzing the target kernel. For simplicity we will run everything in this doc on GCP even though syz-ci could run elsewhere. @@ -223,7 +223,7 @@ gcloud services enable cloudscheduler.googleapis.com --project $PROJECT gcloud app deploy ./dashboard/app/cron.yaml --project $PROJECT --quiet # Create required Datastore indexes. Requires a few minutes to -# generate before they (and hence syzbot) become useable +# generate before they (and hence syzbot) become usable gcloud datastore indexes create ./dashboard/app/index.yaml --project $PROJECT --quiet cat < ./dashboard/app/config_not_prod.go diff --git a/docs/strace.md b/docs/strace.md index d88256eb8..b959b91be 100644 --- a/docs/strace.md +++ b/docs/strace.md @@ -31,7 +31,7 @@ The resulting binary can be found at `src/strace`. It's possible to instruct `syz-crush` to run the attached repro under strace. In order to do so, make sure `strace_bin` is specified in the syz-manager config -file and pass an extra `-strace` arugment to the command arguments. +file and pass an extra `-strace` argument to the command arguments. ## syz-repro diff --git a/docs/syscall_descriptions.md b/docs/syscall_descriptions.md index 3c6a67862..9b4101a8b 100644 --- a/docs/syscall_descriptions.md +++ b/docs/syscall_descriptions.md @@ -168,7 +168,7 @@ close(r0) Syscall arguments are always `in`, return values are `out` and pointer indirections have explicit direction as `ptr` type attribute. Also, it is possible to specify direction attribute individually for struct fields to account for more complex -producer/consumer scenarious with structs that include both input/output resources. +producer/consumer scenarios with structs that include both input/output resources.
diff --git a/docs/syzbot.md b/docs/syzbot.md index f4e554376..568a53612 100644 --- a/docs/syzbot.md +++ b/docs/syzbot.md @@ -432,7 +432,7 @@ propagation of uninitialized values through memory and registers and only flags actual eventual uses of uninitialized values. For example, `KMSAN` will detect a branch on or a `copy_to_user()` of values that transitively come from uninitialized memory created by heap/stack allocations. This ensures -/theoretical/ absense of both false positives and false negatives (with some +/theoretical/ absence of both false positives and false negatives (with some implementation limitations of course). Note that `KMSAN` requires `clang` compiler. `KMSAN` is not upstream yet, though, we want to upstream it later. For now, @@ -450,7 +450,7 @@ and attach/inline your test patch in the same email. Report explanation. The first call trace points to the `use` of the uninit value (which is usually a branching or copying it to userspace). Then there are 0 or more "Uninit was stored to memory at:" stacks which denote how the unint value -travelled through memory. Finally there is a "Uninit was created at:" +traveled through memory. Finally there is a "Uninit was created at:" section which points either to a heap allocation or a stack variable which is the original source of uninitialized-ness. @@ -516,11 +516,11 @@ There are several reasons for this: - custom patches may not apply tomorrow - custom patches may not apply to all of the tested git trees - it's hard to communicate exact state of the code with bug reports (not just hash anymore) -- line numbers won't match in reports (which always brings suspecion as to the quality of reports) +- line numbers won't match in reports (which always brings suspicion as to the quality of reports) - custom patches can also introduce bugs, and even if they don't a developer may (rightfully) question validity of and may not want to spend time on reports obtained with a number of out-of-tree patches -- order of patch application generatelly matters, and at some point patches +- order of patch application generally matters, and at some point patches need to be removed, there is nobody to manage this We've experimented with application of custom patches in the past and it lead -- cgit mrf-deployment