From nobody Sun Sep 04 12:00:09 2022 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ML9FQ0cx7z4bTwZ for ; Sun, 4 Sep 2022 12:00:10 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ML9FP72WJz3RLg; Sun, 4 Sep 2022 12:00:09 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1662292810; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=0POQk8V4XGJcgjqkN5WMQco9PTOthnIM2B8Fwv6XA+o=; b=oEssgeVDKlpaKI2NGdCaGxZNTrMxJ8MijLiLTZfQ50l2wsLgyE337HtHCU6+uSD225xHbV Jtl6f9zh1NLHbZHm7gjCJ4FcZ30r+19eWdNNTd1+8Ydz/L7jCS8Hv7c51tNZnxU5prc+LJ wSZShreWZ5Od9R44skj+cZj7yUjBNfpABmYau/skqbX1bwvKk268fyzaTvVIPBcq91r025 st8/kS6NKfGGXSx/9R+smwYoZbWAMaMhLCZTFi2ysEmEcEqDT6c1HbitPFStFOMYdsc4lk 85QM9f8jIZxnovV5GXZ8TaI6ZJLLzsbV/k1NYwVf9HlfQYJ7LyT+AkXTSkGaSQ== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4ML9FP66NyzTLK; Sun, 4 Sep 2022 12:00:09 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 284C09KF090334; Sun, 4 Sep 2022 12:00:09 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 284C09cI090330; Sun, 4 Sep 2022 12:00:09 GMT (envelope-from git) Date: Sun, 4 Sep 2022 12:00:09 GMT Message-Id: <202209041200.284C09cI090330@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Gordon Bergling Subject: git: c2284083a9 - main - Documentation: Correct some typos List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: gbe X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: c2284083a9814706c43b3d1afa2dd12ce23d7b44 Auto-Submitted: auto-generated ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1662292810; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=0POQk8V4XGJcgjqkN5WMQco9PTOthnIM2B8Fwv6XA+o=; b=av4gA2P+X2er9eZRK8CSUBwQCekd1KBGP2vPS7xylYnpVrfhgVR7tIjeybFVzKOBS+poqW n52QPZC8Pmd1nnpaIL/uNYfQxYfyo+4hTZc+XgdcyCFZcA05U+DmzqM1H4g1PHSVSlGkl7 MGPdO33DUwtEcH5qBvn2/Al4Z1ig2YwEwTSjV0jOyew83L4Zwq6YKbkXj+bTDrCuEEIcpx 5p5PiuaP7hTpaaI+jLi050DQgqcK6hr+fuezEuopzVCipO3aJ0k/55JtOshV/IZthaRN1W ze3PTn4lZ3wDUh8MR5osz2rTtszwpk1TXotA3ePSpysr2j0prLMpmW08bkw6gg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1662292810; a=rsa-sha256; cv=none; b=Hct7x2yFVHmsXnSz8mCmLdmh7B8LwVmpV0mrdRyD7bKTNRqg5PJogk75MnptCBfriUQj0w BH50vDR19G0/PtprsFHpYmkuQelPzhWs7OJCIpZpT/vTdEf3TKGeHrhA1AxAUbhGGV2yHx WzJtoFgQS+ZaUPDo6wr/CI14plSnJZ1RRqh6WKewnSjAlgd6U5552LncJfPdFr4ZyHri9q AvyCxpB9kH7nwuaevM4rz3DWEScptxfHSSPzxgxy5RLCqlxK/lFDCWMHyGUxeCdPoS6OKJ CRvKL2zGI6y8Ld0NfbElgDsrKbrb4OXHEW+cQeuh0eksoMCu3kQMuxkF0rfXKw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by gbe: URL: https://cgit.FreeBSD.org/doc/commit/?id=c2284083a9814706c43b3d1afa2dd12ce23d7b44 commit c2284083a9814706c43b3d1afa2dd12ce23d7b44 Author: Gordon Bergling AuthorDate: 2022-09-04 11:59:58 +0000 Commit: Gordon Bergling CommitDate: 2022-09-04 11:59:58 +0000 Documentation: Correct some typos - s/occured/occurred/ --- documentation/content/el/books/handbook/security/_index.adoc | 2 +- documentation/content/it/books/handbook/security/_index.adoc | 2 +- website/content/en/status/report-2017-07-2017-09.html | 2 +- website/content/en/status/report-2019-07-2019-09.html | 4 ++-- website/content/en/status/report-2021-10-2021-12/membarrier-rseq.adoc | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-) diff --git a/documentation/content/el/books/handbook/security/_index.adoc b/documentation/content/el/books/handbook/security/_index.adoc index 33114a15cf..615a41c964 100644 --- a/documentation/content/el/books/handbook/security/_index.adoc +++ b/documentation/content/el/books/handbook/security/_index.adoc @@ -189,7 +189,7 @@ A good security script will also check for changes to user and staff members acc If you have a huge amount of user disk space, it may take too long to run through every file on those partitions. In this case, setting mount flags to disallow suid binaries and devices on those partitions is a good idea. The `nodev` and `nosuid` options (see man:mount[8]) are what you want to look into. You should probably scan them anyway, at least once a week, since the object of this layer is to detect a break-in attempt, whether or not the attempt succeeds. -Process accounting (see man:accton[8]) is a relatively low-overhead feature of the operating system which might help as a post-break-in evaluation mechanism. It is especially useful in tracking down how an intruder has actually broken into a system, assuming the file is still intact after the break-in has occured. +Process accounting (see man:accton[8]) is a relatively low-overhead feature of the operating system which might help as a post-break-in evaluation mechanism. It is especially useful in tracking down how an intruder has actually broken into a system, assuming the file is still intact after the break-in has occurred. Finally, security scripts should process the log files, and the logs themselves should be generated in as secure a manner as possible - remote syslog can be very useful. An intruder will try to cover his tracks, and log files are critical to the sysadmin trying to track down the time and method of the initial break-in. One way to keep a permanent record of the log files is to run the system console to a serial port and collect the information to a secure machine monitoring the consoles. diff --git a/documentation/content/it/books/handbook/security/_index.adoc b/documentation/content/it/books/handbook/security/_index.adoc index e57891ac4c..57c8b7e3aa 100644 --- a/documentation/content/it/books/handbook/security/_index.adoc +++ b/documentation/content/it/books/handbook/security/_index.adoc @@ -189,7 +189,7 @@ A good security script will also check for changes to user and staff members acc If you have a huge amount of user disk space, it may take too long to run through every file on those partitions. In this case, setting mount flags to disallow suid binaries and devices on those partitions is a good idea. The `nodev` and `nosuid` options (see man:mount[8]) are what you want to look into. You should probably scan them anyway, at least once a week, since the object of this layer is to detect a break-in attempt, whether or not the attempt succeeds. -Process accounting (see man:accton[8]) is a relatively low-overhead feature of the operating system which might help as a post-break-in evaluation mechanism. It is especially useful in tracking down how an intruder has actually broken into a system, assuming the file is still intact after the break-in has occured. +Process accounting (see man:accton[8]) is a relatively low-overhead feature of the operating system which might help as a post-break-in evaluation mechanism. It is especially useful in tracking down how an intruder has actually broken into a system, assuming the file is still intact after the break-in has occurred. Finally, security scripts should process the log files, and the logs themselves should be generated in as secure a manner as possible - remote syslog can be very useful. An intruder will try to cover his tracks, and log files are critical to the sysadmin trying to track down the time and method of the initial break-in. One way to keep a permanent record of the log files is to run the system console to a serial port and collect the information to a secure machine monitoring the consoles. diff --git a/website/content/en/status/report-2017-07-2017-09.html b/website/content/en/status/report-2017-07-2017-09.html index af02ff0be7..6ca1fdf2b0 100644 --- a/website/content/en/status/report-2017-07-2017-09.html +++ b/website/content/en/status/report-2017-07-2017-09.html @@ -880,7 +880,7 @@ This uses the recently added NT_LWPINFO note to extract signal information from process cores.

-

Hangs that occured when GDB's kill command was used +

Hangs that occurred when GDB's kill command was used were fixed in FreeBSD in r313992.

Open tasks:

  1. Figure out why the powerpc kgdb targets are not able to unwind the stack past the initial frame.
  2. Test support for sparc64 binaries and kernels.
  3. Add support for debugging powerpc vector registers.
  4. Implement info proc commands.
  5. Implement info os commands.

Ports

Changes affecting the Ports Collection, whether sweeping diff --git a/website/content/en/status/report-2019-07-2019-09.html b/website/content/en/status/report-2019-07-2019-09.html index 190fad2639..f2e48e4fd7 100644 --- a/website/content/en/status/report-2019-07-2019-09.html +++ b/website/content/en/status/report-2019-07-2019-09.html @@ -1794,14 +1794,14 @@ and December only and the report will probably be out in mid January.

-- L the faulting instruction is restarted. If fault cannot be handled for any reason, the next action depends on the mode in which - the fault occured. + the fault occurred. If it was in kernel, and the kernel installed a helper, then the helper is called instead of returning to the faulting instruction. Otherwise, a kernel-mode page fault causes a panic.

-

If the unhandled fault occured in usermode, then all +

If the unhandled fault occurred in usermode, then all Unixes send a signal to the thread whose execution caused the exception. POSIX (or diff --git a/website/content/en/status/report-2021-10-2021-12/membarrier-rseq.adoc b/website/content/en/status/report-2021-10-2021-12/membarrier-rseq.adoc index a0362524e1..814598c6aa 100644 --- a/website/content/en/status/report-2021-10-2021-12/membarrier-rseq.adoc +++ b/website/content/en/status/report-2021-10-2021-12/membarrier-rseq.adoc @@ -86,7 +86,7 @@ system-global context switches. Instead, if the process registered for rseq(2), on any return to user mode we check if any exceptional events happened while the thread was in the kernel (context switches may happen only while the thread is in kernel mode), and if a context switch indeed -occured, we fire an ast to check whether the program counter is inside the +occurred, we fire an ast to check whether the program counter is inside the critical section and jump to the abort handler if it is. The implementations of membarrier(2) and rseq(2) are clean-room: I used