Update translated documentation (#1396)

Author: github-actions[bot]

docs/.translation_cache.json

@@ -306,7 +306,7 @@
     "hash": "71c15cea87dffe58f5d70da38390a083"
   },
   "en:kernel/memory_management/extable_safe_copy_design.md": {
-    "hash": "b337bca913e9e0de881ed5f81dcb5210"
+    "hash": "fabf6a20ce3a3d1974d678f039fa32b5"
   },
   "en:community/ChangeLog/V0.3.x/V0.3.0.md": {
     "hash": "a3b5ae01c7a5f3ad9d26f71b54d01790"

docs/locales/en/kernel/memory_management/extable_safe_copy_design.md

@@ -5,15 +5,15 @@ This document was automatically translated by `hunyuan-turbos-latest` model, for
 
 - Source document: kernel/memory_management/extable_safe_copy_design.md
 
-- Translation time: 2025-11-18 13:03:29
+- Translation time: 2025-11-21 06:28:18
 
 - Translation model: `hunyuan-turbos-latest`
 
 Please report issues via [Community Channel](https://github.com/DragonOS-Community/DragonOS/issues)
 
 :::
 
-# Design of Secure Memory Copy Scheme Based on Exception Table
+# Secure Memory Copy Scheme Based on Exception Table
 
 :::{note}
 
@@ -23,13 +23,13 @@ Author: Long Jin <[email protected]>
 
 ## Overview
 
-This document describes the core design concept of a secure memory copy scheme in DragonOS based on the Exception Table mechanism. This solution addresses the issue of safely accessing user-space memory in system call contexts, preventing kernel panics caused by accessing invalid user addresses.
+This document describes the core design of a secure memory copy scheme in DragonOS based on the Exception Table mechanism. This solution addresses the issue of safely accessing user-space memory in system call contexts, preventing kernel panics caused by accessing invalid user addresses.
 
 ## Design Background and Motivation
 
 ### Problem Definition
 
-During system call processing, the kernel needs to access pointers passed from user space (such as path strings, parameter structures, etc.). These accesses may fail due to:
+During system call processing, the kernel needs to access pointers passed from user space (such as path strings, parameter structures, etc.). These accesses may fail:
 
 1. **Unmapped address**: The user-provided address has no corresponding VMA (Virtual Memory Area)
 2. **Insufficient permissions**: The page exists but lacks required permissions
@@ -38,22 +38,22 @@ During system call processing, the kernel needs to access pointers passed from u
 ### Limitations of Traditional Solutions
 
 **TOCTTOU issues with pre-checking solutions:**
-- Addresses may be valid during check but modified by other threads when used
-- Race condition windows exist
+- An address may be valid during check but modified by other threads when used
+- Race condition window exists
 
-**Dilemma of direct access:**
+**Challenges with direct access:**
 - Cannot distinguish between "normal page fault" and "illegal access"
-- Page fault handlers cannot determine whether it's a kernel bug or user error
+- Page fault handler cannot determine whether it's a kernel bug or user error
 
-## Principles of Exception Table Mechanism
+## Exception Table Mechanism Principles
 
 ### Core Idea
 
-The Exception Table mechanism achieves secure user-space access through **compile-time marking + runtime lookup**:
+The exception table mechanism achieves secure user-space access through **compile-time marking + runtime lookup**:
 
-1. **Compile-time**: Generate exception table entries at instructions that may trigger page faults
+1. **Compile-time**: Generate exception table entries for instructions that may trigger page faults
 2. **Runtime**: When a page fault occurs, search the exception table and jump to fix-up code
-3. **Zero overhead**: No performance loss on normal paths
+3. **Zero overhead**: No performance loss on the normal path
 
 ### Architectural Diagram
 
@@ -76,7 +76,7 @@ The Exception Table mechanism achieves secure user-space access through **compil
 │                   │ 4. 修改指令指针(RIP)           │          │
 │                   │         ↓                    │          │
 │                   │ 5. 执行修复代码                │          │
-│                   │    └─ 设置错误码(-1)           │          │
+│                   │    └─ 返回剩余未拷贝字节数      │          │
 │                   │         ↓                    │          │
 │                   │ 6. 返回EFAULT给用户            │          │
 │                   └──────────────────────────────┘          │
@@ -85,15 +85,15 @@ The Exception Table mechanism achieves secure user-space access through **compil
 
 ### Core Data Structures
 
-**Exception Table Entry (8-byte aligned):**
+**Exception table entry (8-byte aligned):**
 ```
 ┌─────────────────┬──────────────────┐
 │  指令相对偏移     │  修复代码相对偏移   │
 │    (4 bytes)    │    (4 bytes)     │
 └─────────────────┴──────────────────┘
 ```
 
-**Design Highlights:**
+**Design highlights:**
 - Uses relative offsets to support ASLR (Address Space Layout Randomization)
 - 8-byte alignment improves cache performance
 - Stored in read-only segments to prevent tampering
@@ -114,14 +114,14 @@ The Exception Table mechanism achieves secure user-space access through **compil
                               │
                              是
                               ↓
-                    修改RIP到修复代码 ──→ 返回错误码
+                    修改RIP到修复代码 ──→ 返回剩余未拷贝字节数
 ```
 
 ## Typical Execution Scenarios
 
-### Scenario: System Call with Invalid Address
+### Scenario: System call with invalid address
 
-Taking the `open()` system call as an example, demonstrating the operation of the exception table:
+Taking the `open()` system call as an example, demonstrating the exception table's operation:
 
 ```
 用户程序: open(0x1000, O_RDONLY)  // 0x1000未映射
@@ -150,7 +150,7 @@ Taking the `open()` system call as an example, demonstrating the operation of th
          ↓
     ┌────────────────────────────────┐
     │ 4. 修改指令指针到修复代码          │
-    │    └─ 设置返回值为错误码          │
+    │    └─ 设置返回值为剩余未拷贝字节数  │
     └────────────────────────────────┘
          │
          ↓
@@ -162,42 +162,42 @@ Taking the `open()` system call as an example, demonstrating the operation of th
 用户程序: fd = -1, errno = EFAULT
 ```
 
-**Key Points:**
+**Key points:**
 - No need for pre-checking address validity
-- Page faults are automatically converted to error codes
-- Kernel won't panic, user programs receive clear error information
+- Page faults are automatically converted to returning the number of remaining uncopied bytes
+- The kernel won't panic, and user programs receive clear error information
 
 ## Usage Scenario Analysis
 
-### ✅ Suitable Scenarios for Exception Table Protection
+### ✅ Scenarios Suitable for Exception Table Protection
 
-#### 1. Small Data System Call Parameters
+#### 1. Small system call parameter data
 
 **Characteristics:**
 - Small data volume (typically < 4KB)
-- Single copy operation
+- One-time copy
 - Unknown data length (e.g., strings)
 
-**Typical Applications:**
+**Typical applications:**
 - Path strings: `open()`, `stat()`, `execve()`, etc.
 - Fixed-size structures: `sigaction`, `timespec`, `stat`, etc.
 - Small arrays: `iovec[]`, `pollfd[]`, etc.
 
 **Advantages:**
 - **Avoids TOCTTOU races**: No pre-checking needed
 - **High robustness**: User errors won't cause kernel panics
-- **Acceptable performance**: Small data volume, minimal impact even with extra copies
+- **Acceptable performance**: Small data volume; even multiple copies have minimal impact
 
-#### 2. Scenarios with Uncertain Address Validity
+#### 2. Scenarios with uncertain address validity
 
 When address validity cannot be verified by other means, the exception table is the safest choice:
 - Raw pointers directly provided by users
 - Addresses that may be concurrently modified in multi-threaded environments
 - Operations requiring atomicity guarantees
 
-### ❌ Unsuitable Scenarios for Exception Table Protection
+### ❌ Scenarios Unsuitable for Exception Table Protection
 
-#### 1. Large Data Transfers
+#### 1. Large data transfers
 
 **Anti-pattern: Double buffering in read/write system calls**
 ```
@@ -207,43 +207,43 @@ When address validity cannot be verified by other means, the exception table is
 **Issues:**
 - Memory waste: Requires additional kernel buffers
 - Double copying: Data is copied twice
-- OOM risk: Concurrent large reads/writes may exhaust memory
+- OOM risk: Large concurrent reads/writes exhaust memory
 
-**Correct Approach: Zero-copy**
+**Correct approach: Zero-copy**
 - Pre-validate addresses within valid VMAs
 - Operate directly on user buffers
 - Page faults trigger normal page fault handling (not errors)
 
-#### 2. Addresses Already Validated in VMAs
+#### 2. Addresses already validated within VMAs
 
-If addresses have been validated through VMA checks, the exception table is redundant:
+If addresses have been verified through VMA checks, the exception table is redundant:
 - Immediate access after `mmap()`
 - DMA buffers
 - Shared memory regions
 
-In these scenarios, page faults are **normal page fault handling** (like COW), not errors.
+In these scenarios, page faults are **normal page fault handling** (e.g., COW), not errors.
 
-#### 3. Performance-Critical Hot Paths
+#### 3. Performance-critical hot paths
 
 Avoid frequently calling functions protected by exception tables in loops:
-- **Batch processing**: Copy entire arrays at once rather than element-by-element
-- **Pre-validation**: Validate addresses outside loops, direct access inside loops
+- **Batch processing**: Copy entire arrays at once rather than element by element
+- **Pre-validation**: Validate addresses outside loops and access directly within loops
 
 ### Decision Matrix
 
-| Scenario Characteristics | Data Volume | Recommended Solution | Key Considerations |
-|--------------------------|-------------|----------------------|--------------------|
+| Scenario Characteristics | Data Volume | Recommended Solution | Core Considerations |
+|--------------------------|-------------|----------------------|---------------------|
 | Small system call parameters | < 4KB | Exception table protection | Avoid TOCTTOU, improve robustness |
-| File I/O | Variable (MB-level) | Zero-copy | Performance priority, avoid double buffering |
-| Access after mmap | Any | Direct access | VMA already validated, normal page fault |
+| File read/write | Variable (MB-level) | Zero-copy | Performance priority, avoid double buffering |
+| Access after mmap | Arbitrary | Direct access | VMA already validated, normal page fault |
 | Batch small data | Cumulative KB-level | Batch copy | Reduce system call count |
 | String parsing | Unknown | Exception table protection | Byte-by-byte scanning, requires robustness |
 
 ## Security Analysis
 
 ### Defensive Capabilities
 
-The Exception Table mechanism can defend against:
+The exception table mechanism can defend against:
 
 1. **Null pointer dereferencing**: Returns EFAULT instead of segmentation fault
 2. **Kernel address injection**: User-provided kernel addresses are safely rejected
@@ -252,15 +252,15 @@ The Exception Table mechanism can defend against:
 
 ### Security Boundaries
 
-The Exception Table **cannot** defend against:
+The exception table **cannot** defend against:
 
 1. **Kernel bugs**: Such as wild pointer dereferencing
 2. **Hardware failures**: Physical memory damage
 3. **Other exception types**: Only handles page faults
 
 ### Multi-layer Defense
 
-The Exception Table is part of defense in depth:
+The exception table is part of defense in depth:
 
 ```
 ┌─────────────────────────────────────┐
@@ -280,15 +280,15 @@ The Exception Table is part of defense in depth:
 
 1. **Relative offset encoding**: Supports address randomization (ASLR)
 2. **Binary search**: O(log n) time complexity for fast location
-3. **Inline assembly**: Precise control over instruction generation and exception table creation
-4. **Zero-overhead abstraction**: No performance loss on normal paths
+3. **Inline assembly**: Precise control over instruction and exception table generation
+4. **Zero-overhead abstraction**: No performance loss on the normal path
 
 ### Architecture Portability
 
-The Exception Table mechanism can be ported to other architectures:
+The exception table mechanism can be ported to other architectures:
 
 - **x86_64**: Uses `rep movsb` instruction
 - **ARM64**: Uses `ldp/stp` instruction sequence
 - **RISC-V**: Uses `ld/sd` instruction sequence
 
-The core concept remains unchanged, only assembly syntax needs adjustment.
+The core idea remains unchanged, requiring only adjustments to assembly syntax.