1Name 2 3 EXT_protected_textures 4 5Name Strings 6 7 GL_EXT_protected_textures 8 9Contributors 10 11 Maurice Ribble 12 Mohan Maiya 13 Craig Donner 14 Alex Wong 15 Jan-Harald Fredriksen 16 Daniel Koch 17 Prabindh Sundareson 18 Jesse Hall 19 Ray Smith 20 Jonathan Putsman 21 22Contact 23 24 Jeff Leger (jleger 'at' qti.qualcomm.com) 25 26IP Status 27 28 No known IP claims. 29 30Status 31 32 Complete 33 34Version 35 36 May 17, 2017 37 38Number 39 40 OpenGL ES Extension #256 41 42Dependencies 43 44 OpenGL ES 3.0 is required. 45 46 This extension requires the EGL_EXT_protected_content extension or 47 similar. 48 49 This extension is written against the OpenGL ES 3.2 specification. 50 51 Interacts with EXT_sparse_texture. 52 53Overview 54 55 This extension requires another extension like EGL_EXT_protected_content to 56 have created a protected context. A protected context enables the 57 driver to put the GPU into a protected mode where it is able to operate on 58 protected surfaces. 59 60 This extension enables allocating standard GL textures as protected 61 surfaces. Previously these textures would have had to have been created as 62 special EGL surfaces. This allows use-cases such as depth, stencil, or 63 mipmapped textures to be supported as destinations for rendering within 64 a protected context. 65 66 An explanation of undefined behavior in this extension: Several places 67 in this extension mention undefined behavior can result, which can 68 include program termination. The reason for this is because one way 69 to handle protected content is by using a protected virtual to physical 70 memory translation layer. With this sort of solution a system may generate 71 read or write faults when a non-protected context tries to access the 72 buffer. Depending on the system these faults might be ignored or they might 73 cause process termination. This undefined behavior should not include 74 actually allowing copying any protected content to a non-protected surface. 75 76 This extension does not guarantee that the implementation abides by a 77 system's digital rights management requirements. It must be verified beyond 78 the existence of this extension that the implementation of this extension is 79 trustworthy according to the requirements of a content protection system. 80 81New Procedures and Functions 82 83 None 84 85New Tokens 86 87 Returned by GetIntegerv when <pname> is CONTEXT_FLAGS: 88 89 GL_CONTEXT_FLAG_PROTECTED_CONTENT_BIT_EXT 0x00000010 90 91 Accepted as a value for <pname> for the TexParameter{if} and 92 TexParameter{if}v commands and for the <value> parameter of 93 GetTexParameter{if}v: 94 95 GL_TEXTURE_PROTECTED_EXT 0x8BFA 96 97 Accepted as a value to <param> for the TexParameter{if} and 98 to <params> for the TexParameter{if}v commands with a <pname> of 99 TEXTURE_PROTECTED_EXT; returned as possible values for <data> when 100 GetTexParameter{if}v is queried with a <value> of TEXTURE_PROTECTED_EXT: 101 102 FALSE 0x0 103 TRUE 0x1 104 105Add the following to the end of section 8.18 (Immutable-Format Texture Images) 106in the OpenGL ES 3.2 Specification: 107 108 To use protected textures a context must be a protected context. 109 To check if your context supports protected content you can 110 query the context by calling GetIntegerv with pname CONTEXT_FLAGS, as 111 described in section 20.2. 112 113 Texture usage can be specified via the TEXTURE_PROTECTED_EXT value 114 for the <pname> argument to TexParameter{if}[v]. In order to take effect, 115 the texture usage must be specified before the texture contents are 116 defined by TexStorage*. 117 118 Possible values for <params> when <pname> is TEXTURE_PROTECTED_EXT are: 119 120 FALSE - the default. The texture is not protected. 121 122 TRUE - the texture is protected. 123 124 The definition of protected and non-protected access is up to the 125 implementation and is out of scope of this specification. To read/write a 126 protected surface, it is required that the context also be protected. 127 128 CONTEXT_FLAG_PROTECTED_CONTENT_BIT_EXT is set when the context is 129 created in protected mode with an extension such as 130 EGL_EXT_protected_context. 131 132Add a new section "Protected Content" to Chapter 2 "OpenGL ES Operation": 133 134 If the context is protected, the pipeline stages are executed in the 135 following manner: 136 - The fragment stage is always protected 137 - For all other stages, it is implementation defined whether that stage is 138 protected or not protected. 139 140 Permitted operations in protected and not protected mode are out of the 141 scope of this specification. Refer to EGL_EXT_protected_context, if 142 applicable, for more information. 143 144Add a new row to Table 8.19 (Texture parameters and their values): 145 146 Name | Type | Legal Values 147 ------------------------------------------------------------ 148 TEXTURE_PROTECTED_EXT | bool | FALSE, TRUE 149 150Errors 151 152 If TexParameter{if} or TexParamter{if}v is called with a <pname> 153 of TEXTURE_PROTECTED_EXT and the value of <param> or <params> is not 154 TRUE or FALSE the error INVALID_VALUE is generated. 155 156 [[ The following is only added if EXT_sparse_texture is supported. ]] 157 158 Add to the errors that may be generated by TexStorage*: 159 160 An INVALID_OPERATION error is generated if the texture's 161 TEXTURE_SPARSE_EXT parameter is TRUE and the value of its 162 TEXTURE_PROTECTED_EXT parameter is TRUE. 163 164Issues 165 1) Should this work with all texture functions or only the new texture 166 storage allocations? 167 168 RESOLVED - Only supporting a new texture storage allocation method is much 169 simpler than trying to alter every texture-related entry-point. 170 171 172 2) Some paths like TexSubImage may have GPU and CPU paths. Should those 173 types of operations be supported in this extension. 174 175 PROPOSED - Yes. While protected surfaces can't be updated with 176 non-secure GPU/CPU operations, an implementation is expected to either use 177 trusted GPU or CPU operations to accomplish this. 178 179 3) What target should all the texture bind and parameter setting API calls 180 use? 181 182 RESOLVED - They will use the non *_PROTECTED targets. This was done to 183 reduce the amount of code change in apps. The only calls using *_PROTECTED 184 targets are the texStorage allocation calls. 185 186 4) What happens if readPixels is performed on a protected surface? 187 188 RESOLVED - Results will not actually get the surface data, but 189 otherwise the results are undefined up to and including app termination. 190 191 5) Can you create an EGLImage from a protected texture? 192 193 RESOLVED - Yes, but only if the EGLImage is created in a protected context. 194 195 6) Should all textures on a protected context be protected by default? 196 197 RESOLVED - No, several implementations have limited amounts of protected 198 memory so the API will require opting into protected memory. 199 200 7) How should protected memory be exposed? 201 202 RESOLVED - Options discussed where target *_PROTECTED, using 203 TexStorage*WithFlags, and adding a new texture parameter. The group decided 204 to add a new texture parameter. 205 206 8) If an FBO attachment is protected, must all of the attachments be 207 protected? 208 209 RESOLVED - Yes, if any of the FBO attachments are protected then they all 210 must be protected or the results are undefined. If this is being used 211 in conjunction with the EGL_EXT_protected_content extension that extension 212 states all outputs must be protected for a protected context, and that 213 inputs can be mixed. 214 215 9) Are occlusion, timer, and other types of queries allowed when using the 216 the EGL_EXT_protected_content extension? 217 218 RESOLVED - No, these will result in undefined behavior with this extension. 219 These features require writing to a buffer and a protected context can only 220 write to a protected surface. There are no protected buffers so this isn't 221 possible. Even if there were protected buffers that data wouldn't be 222 visible on the CPU. 223 224 10) What is the interaction between EXT_protected_textures and 225 EXT_sparse_texture? 226 227 RESOLVED - It is forbidden to create a texture which is both protected and 228 sparse. This is problematic on some platforms and there is no known 229 compelling use case. 230 231Revision History 232 233 Rev. Date Author Changes 234 ---- -------- -------- ---------------------------------------------- 235 1 03/07/16 mribble Initial draft. 236 2 03/10/16 mribble Cleanup. 237 3 03/18/16 mribble Fix issues brought up by Khronos group. 238 4 03/25/16 mribble Changed to tex parameter method. Other cleanup. 239 5 03/30/16 mribble Added issues 8 and 9. Other cleanup. 240 6 04/08/16 rsmith Added section on Protected Content defining the 241 protection state of each pipeline stage, as 242 required by EGL_EXT_protected_content. 243 7 04/10/16 mribble Minor cleanup. 244 8 04/11/16 mribble Clarify issue 9. 245 9 04/11/16 Jon Leech Add missing _EXT suffix to context flag. 246 10 05/17/17 jleger Add issue 10 and the corresponding error. 247