update docs

Signed-off-by: Nannie_wangli <annie.wangli@huawei.com>

en/readme/Security.md

+# Security<a name="EN-US_TOPIC_0000001087014383"></a>
+
+
+## Introduction<a name="section11660541593"></a>
+
+The security subsystem provides system, data, and application security capabilities to protect system and user data of OpenHarmony.
+
+Its functions include application integrity verification, application permission management, device authentication, OpenHarmony Universal KeyStore (HUKS) key management, and data transfer management.
+
+## Architecture<a name="section342962219551"></a>
+
+**Figure 1** Security subsystem architecture<a name="fig4460722185514"></a> 
+
+![](figures/security-architecture.png)
+
+The security subsystem consists of the following functional modules:
+
+- Interface layer: provides APIs to developers, some of which are only available for system applications
+
+- Application permission management: implements permission management for the application framework subsystem and provides APIs for applications to request permissions and query the permission granting status.
+
+- Application integrity verification: verifies application integrity during application signing and installation.
+- Device authentication: provides key agreement and trusted device management capabilities for interconnections between devices in a distributed network.
+
+- HUKS key management: provides the key management service for basic device authentication.
+
+- Data transfer management: provides API definitions related to data transfer management and control.
+
+## Directory Structure<a name="section92711824195113"></a>
+
+```
+/base/security
+├── appverify                       # Application integrity verification
+├── dataclassification              # Data transfer management
+├── device_auth                     # Device authentication
+├── huks                            # HUKS key management
+└── permission                      # Permission management
+```
+
+## Constraints<a name="section7715171045219"></a>
+
+-   In the current version, application permission management is available only for local applications. (The stub mode is used for joint commissioning of upper-layer distributed services.)
+-   Device authentication includes authentication for devices with the same account and peer-to-peer device authentication. Currently, only the latter is available. (The stub mode is used for joint commissioning of upper-layer distributed services.)
+-   OpenHarmony-specific certificates are used for application integrity verification. The corresponding public key certificates and private keys are preset in the open-source code repositories of OpenHarmony to provide offline signing and verification capabilities for the open-source community. The public key certificates and the corresponding private keys need to be replaced in commercial versions that are based on OpenHarmony.
+
+## Usage<a name="section2057642312536"></a>
+
+**Application Permission Management**
+
+In OpenHarmony, applications and system services run in independent sandboxes. Both processes and data are isolated from each other to protect the security of application data. However, services or applications running in the sandboxes provide some APIs to implement specific functionalities. To access these APIs across processes, applications in other sandboxes need the required permissions, which are granted and managed based on a permission management mechanism.
+
+Application permission management provides a mechanism for defining permissions, allowing system services and applications to define new permissions for their sensitive APIs. To access these APIs, other applications need the required permissions.
+
+Application permission management also allows applications to request permissions that are defined by the system or other applications. Upon obtaining the permissions, applications can access the sensitive APIs provided by the system or other applications.
+
+In addition, application permission management allows users to view and manage the permission granting status.
+
+**Application Integrity Verification**
+
+OpenHarmony allows installation of applications. To ensure the integrity and trustworthiness of the applications to be installed in OpenHarmony, the applications must be signed and their signatures must be verified.
+
+After developing an application and generating the installation package during the application development process, you must sign the installation package to prevent it from being tampered with when released on devices. The OpenHarmony application integrity verification module provides the signature tool, specifications for generating the signing certificate, and required public key certificate for you to sign the application packages. A public key certificate and a corresponding private key are preset in OpenHarmony to easy your operation. You need to replace the public key certificate and private key in your commercial version of OpenHarmony.
+
+In the application installation process, the OpenHarmony application framework subsystem installs applications. Upon receiving an application installation package, the application framework subsystem parses the signature of the installation package, and verifies the signature using the application integrity verification APIs. The application can be installed only after the verification is successful. During the verification, the application integrity verification module uses the preset public key certificate to verify the signature.
+
+**Device Authentication and HUKS**
+
+A unified device binding and authentication solution that covers 1+8+N devices is available. Generally, device authentication provides support for cross-device communication implemented by DSoftBus, rather than directly interacting with applications. Device authentication provides the following functionalities:
+
+- Building and maintaining unified trust relationship for a group of devices using different accounts 
+
+  Devices with different accounts can set up a local trust group after a trust relationship is built by certain means such as scanning a QR code. Services can call APIs to query the group information.
+
+- Implementing unified device authentication 
+
+  A unified authentication solution is provided to discover devices and perform connection authentication and key agreement for encrypted, end-to-end sessions through DSoftBus for the devices in a trust group.
+
+HUKS provides credentials for device authentication and algorithms for key agreement protocols.
+
+**Data Transfer Management**
+
+In OpenHarmony, the data transfer management module provides cross-device data transfer management and control policies for distributed services. The data transfer management module defines a sef of APIs to provide management and control policies for cross-device data transfer and obtain the highest risk level of data to be sent to the peer device.
+
+## Repositories Involved<a name="section155556361910"></a>
+
+Security subsystem
+
+base/security

en/readme/driver.md

+# Driver<a name="EN-US_TOPIC_0000001052619216"></a>
+
+## Overview<a name="section11660541593"></a>
+
+The OpenHarmony driver subsystem is constructed using the C object-oriented programming \(OOP\). It provides a unified driver platform through platform decoupling, kernel decoupling, and compatible kernels. This unified driver architecture platform is designed to provide a more precise and efficient development environment, where you develop a driver that can be deployed on different systems supporting HDF.
+
+The OpenHarmony driver subsystem provides the following key features and capabilities to shorten the driver development period and make third-party device driver integration much easier:
+
+-   Flexible framework capabilities
+
+    Based on the traditional driver framework, the OpenHarmony driver subsystem builds flexible framework capabilities to deploy terminal products with the capacity ranging from hundreds KB to hundreds MB of memory.
+
+
+-   Standardized driver APIs
+
+    The OpenHarmony driver subsystem provides you with abundant and stable driver APIs, which are compatible with those of future-proof smartphones, tablets, smart TVs.
+
+
+-   Component-based driver models
+
+    The OpenHarmony driver subsystem supports component-based driver models. It provides more refined driver management to dismantle components, enabling you to focus on the interaction between the hardware and driver.
+
+    The subsystem also presets some template-based driver model components, such as the network device models.
+
+
+-   Normalized configuration GUIs
+
+    The OpenHarmony driver subsystem provides a unified configuration GUI and a cross-platform tool for configuration conversion and generation to implement seamless switchover across platforms.
+
+
+You can use DevEco to manage driver projects, generate driver templates, and manage settings to make the development of OpenHarmony drivers easier.
+
+## Architecture<a name="section101721227145613"></a>
+
+The OpenHarmony driver framework adopts the primary/secondary mode and is developed based on the framework, model, competence library, and tool.
+
+**Figure  1**  Driver subsystem architecture<a name="fig1077923710115"></a>  
+![](figures/driver-subsystem-architecture.png "driver-subsystem-architecture")
+
+-   Driver framework stored in the  **framework/core**  directory
+    -   Loads and starts drivers.
+    -   Deploys and expands the driver framework flexibly through the object manager.
+
+-   Driver model stored in the  **framework/model**  directory
+    -   Provides model-based driving capabilities, such as network device models.
+
+-   Driver capability library stored in the  **framework/ability**  directory
+    -   Provides basic driver models, such as the I/O communication model.
+
+-   Driver tools stored in the  **framework/tools**  directory
+    -   Provides tools for HDI API conversion, and driver configuration and driver compilation.
+
+-   Driver APIs stored in the  **lite/hdi**  directory
+    -   Provides standardized driver APIs.
+
+-   Support stored in the  **framework/support**  directory
+    -   Provides platform driver APIs and system APIs with normalized abstraction capabilities.
+
+
+## Directory Structure<a name="section1464106163817"></a>
+
+```
+drivers
+├── adapter               # Adaptation code for differentiated platforms
+├── framework             # Core code of the HDF
+└── peripheral            # Peripheral driver code 
+```
+
+## Use<a name="section8496817141616"></a>
+
+**Figure  2**  Interaction between the driver and framework<a name="fig1356181413429"></a>  
+![](figures/interaction-between-the-driver-and-framework.png "interaction-between-the-driver-and-framework")
+
+Driver loading is mostly done by the driver framework, and you only need to register and configure required APIs. The driver framework will load and initialize the driver based on the parsing content.
+
+Driver development based on the HDF consists of the following three parts:
+
+1. Driver: Develop the functions.
+
+2. Information configuration: Present the loading information of the driver.
+
+3. Resource configuration: Configure the hardware information of the driver.
+
+The driver mainly aims to develop the functions.
+
+The first part that catches your eyes is the driver entry, which is described through  **DriverEntry**.
+
+Three APIs are available, namely  **bind**,  **init**, and  **release**.
+
+```
+struct HdfDriverEntry g_deviceSample = {
+    .moduleVersion = 1,
+    .moduleName = "sample_driver", 
+    .Bind = SampleDriverBind,
+    .Init = SampleDriverInit,
+    .Release = SampleDriverRelease,
+};
+```
+
+**Bind**: This API is used to bind driver devices and its functions.
+
+```
+int32_t SampleDriverBind(struct HdfDeviceObject *deviceObject)
+{
+    // TODO: Bind device service to device object.
+    // And you can also initialize device resources here.
+    return HDF_SUCCESS;
+}
+```
+
+**Init**: When devices are successfully bound, the framework calls  **Init**  to initialize the driver. After initialization is complete, the driver framework will determine whether to create external service interfaces based on the configuration file. If the driver fails to be initialized, the driver framework will automatically release the created device interface.
+
+```
+int32_t SampleDriverInit(struct HdfDeviceObject *deviceObject)
+{
+    // TODO: Init hardware or other resources here.
+    return HDF_SUCCESS;
+}
+```
+
+**Release**: When you need to uninstall a driver, the driver framework calls this function to release the driver resources. Then, other internal resources will be released.
+
+```
+void SampleDriverRelease(struct HdfDeviceObject *deviceObject)
+{
+    // Release all resources.
+    return;
+}
+```
+
+## Installation<a name="section14778154275818"></a>
+
+The OpenHarmony driver is mainly deployed in the kernel space using the static link mode. It is compiled and packed with the kernel subsystem and system image.
+
+**Figure  3**  Driver installation<a name="fig20119729154211"></a>  
+![](figures/driver-installation.png "driver-installation")
+
+## Repositories Involved<a name="section134812226297"></a>
+
+**Driver subsystem**
+
+[drivers\_framework](https://gitee.com/openharmony/drivers_framework/blob/master/README.md)
+
+[drivers\_adapter](https://gitee.com/openharmony/drivers_adapter/blob/master/README.md)
+
+[drivers\_adapter\_khdf\_linux](https://gitee.com/openharmony/drivers_adapter_khdf_linux/blob/master/README.md)
+
+[drivers\_peripheral](https://gitee.com/openharmony/drivers_peripheral/blob/master/README.md)
+