Merge "CDD: Update Section 5.5.1 for 8-bit, float and multichannel PCM, 48/96kHz" into pi-dev
diff --git a/2_device-types/2_3_television-reqs.md b/2_device-types/2_3_television-reqs.md
index 1ce2d6b..0cf24ed 100644
--- a/2_device-types/2_3_television-reqs.md
+++ b/2_device-types/2_3_television-reqs.md
@@ -82,83 +82,69 @@
### 2.3.2\. Multimedia
-Television device implementations MUST support the following audio encoding:
+Television device implementations MUST support the following audio encoding formats:
* [[5.1](#5_1_media-codecs)/T-0-1] MPEG-4 AAC Profile (AAC LC)
* [[5.1](#5_1_media-codecs)/T-0-2] MPEG-4 HE AAC Profile (AAC+)
* [[5.1](#5_1_media-codecs)/T-0-3] AAC ELD (enhanced low delay AAC)
-Television device implementations MUST support the following video encoding:
+Television device implementations MUST support the following video encoding formats:
-* [[5.2](#5_2_video-encoding)/T-0-1] H.264 AVC
+* [[5.2](#5_2_video-encoding)/T-0-1] H.264
* [[5.2](#5_2_video-encoding)/T-0-2] VP8
Television device implementations:
* [[5.2](#5_2_video-encoding).2/T-SR] Are STRONGLY RECOMMENDED to support
-H.264 encoding of 720p and 1080p resolution videos.
-* [[5.2](#5_2_video-encoding)2/T-SR] Are STRONGLY RECOMMENDED to support H.264
-encoding of 1080p resolution video at 30 frame-per-second (fps).
+H.264 encoding of 720p and 1080p resolution videos at 30 frames per second.
-Television device implementations MUST support the following video decoding:
+Television device implementations MUST support the following video decoding formats:
-* [[5.3](#5_3_video-decoding)/T-0-1] H.264 AVC
-* [[5.3](#5_3_video-decoding)/T-0-2] H.265 HEVC
-* [[5.3](#5_3_video-decoding)/T-0-3] MPEG-4 SP
-* [[5.3](#5_3_video-decoding)/T-0-4] VP8
-* [[5.3](#5_3_video-decoding)/T-0-5] VP9
+* [[5.3.3](#5_3_video-decoding)/T-0-1] MPEG-4 SP
+* [[5.3.4](#5_3_video-decoding)/T-0-2] H.264 AVC
+* [[5.3.5](#5_3_video-decoding)/T-0-3] H.265 HEVC
+* [[5.3.6](#5_3_video-decoding)/T-0-4] VP8
+* [[5.3.7](#5_3_video-decoding)/T-0-5] VP9
Television device implementations are STRONGLY RECOMMENDED to support the
-following video decoding:
+following video decoding formats:
-* [[5.3](#5_3_video-decoding)/T-SR] MPEG-2
+* [[5.3.1](#5_3_video-decoding)/T-SR] MPEG-2
+Television device implementations MUST support H.264 decoding, as detailed in Section 5.3.4,
+at standard video frame rates and resolutions up to and including:
-If Television device implementations support H.264 decoders, they:
+* [[5.3.4](#5_3_video-decoding).4/T-1-1] HD 1080p at 60 frames per second with Basline Profile
+* [[5.3.4](#5_3_video-decoding).4/T-1-2] HD 1080p at 60 frames per second with Main Profile
+* [[5.3.4](#5_3_video-decoding).4/T-1-3] HD 1080p at 60 frames per second with High Profile Level 4.2
-* [[5.3](#5_3_video-decoding).4/T-1-1] MUST support High Profile Level 4.2 and
-the HD 1080p (at 60 fps) decoding profile.
-* [[5.3](#5_3_video-decoding).4/T-1-2] MUST be capable of decoding videos with
-both HD profiles as indicated in the following table and encoded with either the
-Baseline Profile, Main Profile, or the High Profile Level 4.2
+Television device implementations with H.265 hardware decoders MUST support H.265 decoding,
+as detailed in Section 5.3.5, at standard video frame rates and resolutions up to and including:
-If Television device implementations support H.265 codec and the HD 1080p
-decoding profile, they:
+* [[5.3.5](#5_3_video-decoding).4/T-1-1] HD 1080p at 60 frames per second with Main Profile Level 4.1
-* [[5.3](#5_3_video-decoding).5/T-1-1] MUST support the Main Profile Level 4.1
-Main tier.
-* [[5.3](#5_3_video-decoding).5/T-SR] Are STRONGLY RECOMMENDED to support 60
-fps video frame rate for HD 1080p.
+If Television device implementations with H.265 hardware decoders support
+H.265 decoding and the UHD decoding profile, they:
-If Television device implementations support H.265 codec and the UHD decoding
-profile, then:
-
-* [[5.3](#5_3_video-decoding).5/T-2-1] The codec MUST support Main10 Level 5
+* [[5.3.5](#5_3_video-decoding).5/T-2-1] MUST support UHD 3480p at 60 frames per second with Main10 Level 5
Main Tier profile.
-If Television device implementations support VP8 codec, they:
+Television device implementations MUST support VP8 decoding, as detailed in Section 5.3.6,
+at standard video frame rates and resolutions up to and including:
-* [[5.3](#5_3_video-decoding).6/T-1-1] MUST support the HD 1080p60 decoding
-profile.
+* [[5.3.6](#5_3_video-decoding).4/T-1-1] HD 1080p at 60 frames per second decoding profile
-If Television device implementations support VP8 codec and support 720p, they:
+Television device implementations with VP9 hardware decoders MUST support VP9 decoding, as detailed in Section 5.3.7,
+at standard video frame rates and resolutions up to and including:
-* [[5.3](#5_3_video-decoding).6/T-2-1] MUST support the HD 720p60 decoding
-profile.
+* [[5.3.7](#5_3_video-decoding).4/T-1-1] HD 1080p at 60 frames per second with profile 0 (8 bit colour depth)
+If Television device implementations with VP9 hardware decoders support VP9 decoding and the UHD decoding
+profile, they:
-If Television device implementations support VP9 codec and the UHD video
-decoding, they:
-
-* [[5.3](#5_3_video-decoding).7/T-1-1] MUST support 8-bit color depth and
-SHOULD support VP9 Profile 2
-(10-bit).
-
-If Television device implementations support VP9 codec, the 1080p profile and
-VP9 hardware decoding, they:
-
-* [[5.3](#5_3_video-decoding).7/T-2-1] MUST support 60 fps for 1080p.
+* [[5.3.7](#5_3_video-decoding).5/T-2-1] MUST support UHD 3480p at 60 frames per second with profile 0 (8 bit colour depth).
+* [[5.3.7](#5_3_video-decoding).5/T-2-1] Are STRONGLY RECOMMENDED to support UHD 3480p at 60 frames per second with profile 2 (10 bit colour depth).
Television device implementations:
diff --git a/9_security-model/9_7_kernel-security-features.md b/9_security-model/9_7_kernel-security-features.md
index a6a5d8d..33151fb 100644
--- a/9_security-model/9_7_kernel-security-features.md
+++ b/9_security-model/9_7_kernel-security-features.md
@@ -35,18 +35,25 @@
* [C-0-8] MUST implement strict kernel memory protections where executable
code is read-only, read-only data is non-executable and non-writable, and
writable data is non-executable (e.g. `CONFIG_DEBUG_RODATA` or `CONFIG_STRICT_KERNEL_RWX`).
+* [C-0-9] MUST implement static and dynamic object size
+bounds checking of copies between user-space and kernel-space
+(e.g. `CONFIG_HARDENED_USERCOPY`) on devices originally shipping with API level
+28 or higher.
+* [C-0-10] MUST NOT execute user-space memory when executing
+in the kernel mode (e.g. hardware PXN, or emulated via
+`CONFIG_CPU_SW_DOMAIN_PAN` or `CONFIG_ARM64_SW_TTBR0_PAN`) on devices
+originally shipping with API level 28 or higher.
+* [C-0-11] MUST NOT read or write user-space memory in the
+kernel outside of normal usercopy access APIs (e.g. hardware PAN, or
+emulated via `CONFIG_CPU_SW_DOMAIN_PAN` or `CONFIG_ARM64_SW_TTBR0_PAN`)
+on devices originally shipping with API level 28 or higher.
+* [C-0-12] MUST implement kernel page table isolation on all devices with CPUs
+vulnerable to CVE-2017-5754 (Meltdown), and on all devices with kernel versions
+4.4 or higher on devices originally shipping with API level 28 or higher
+(e.g. `CONFIG_PAGE_TABLE_ISOLATION` or `CONFIG_UNMAP_KERNEL_AT_EL0).
* [SR] STRONGLY RECOMMENDED to keep kernel data
which is written only during initialization marked read-only after
initialization (e.g. `__ro_after_init`).
-* [SR} STRONGLY RECOMMENDED to implement static and dynamic object size
-bounds checking of copies between user-space and kernel-space
-(e.g. `CONFIG_HARDENED_USERCOPY`).
-* [SR] STRONGLY RECOMMENDED to never execute user-space memory when running
-in the kernel (e.g. hardware PXN, or emulated via
-`CONFIG_CPU_SW_DOMAIN_PAN` or `CONFIG_ARM64_SW_TTBR0_PAN`).
-* [SR] STRONGLY RECOMMENDED to never read or write user-space memory in the
-kernel outside of normal usercopy access APIs (e.g. hardware PAN, or
-emulated via `CONFIG_CPU_SW_DOMAIN_PAN` or `CONFIG_ARM64_SW_TTBR0_PAN`).
* [SR] STRONGLY RECOMMENDED to randomize the layout of the kernel code and
memory, and to avoid exposures that would compromise the randomization
(e.g. `CONFIG_RANDOMIZE_BASE` with bootloader entropy via the
@@ -64,6 +71,9 @@
within the system/sepolicy folder provided in the upstream Android Open Source
Project (AOSP) and the policy MUST compile with all neverallow rules present,
for both AOSP SELinux domains as well as device/vendor specific domains.
+* [C-1-5] MUST run third-party applications targeting API level 28 or higher
+in per-application SELinux sandboxes with per-app SELinux restrictions on each
+application's private data directory.
* SHOULD retain the default SELinux policy provided in the system/sepolicy
folder of the upstream Android Open Source Project and only further add to this
policy for their own device-specific configuration.
@@ -72,4 +82,4 @@
If device implementations use kernel other than Linux, they:
* [C-2-1] MUST use an mandatory access control system that is
-equivalent to SELinux.
\ No newline at end of file
+equivalent to SELinux.