Print this page
Code review comments from jeffpc
7029 want per-process exploit mitigation features (secflags)
7030 want basic address space layout randomization (aslr)
7031 noexec_user_stack should be a secflag
7032 want a means to forbid mappings around NULL.
Split |
Close |
Expand all |
Collapse all |
--- old/usr/src/man/man4/core.4
+++ new/usr/src/man/man4/core.4
1 1 '\" te
2 2 .\" Copyright (C) 2008, Sun Microsystems, Inc. All Rights Reserved.
3 3 .\" Copyright 2012 DEY Storage Systems, Inc. All rights reserved.
4 4 .\" Copyright (c) 2013, Joyent, Inc. All rights reserved.
5 5 .\" Copyright 1989 AT&T
6 6 .\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License.
7 7 .\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific language governing permissions and limitations under the License.
8 8 .\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
9 -.TH CORE 4 "Mar 31, 2013"
9 +.TH CORE 4 "Jun 6, 2016"
10 10 .SH NAME
11 11 core \- process core file
12 12 .SH DESCRIPTION
13 -.sp
14 13 .LP
15 14 The operating system writes out a core file for a process when the process is
16 15 terminated due to receiving certain signals. A core file is a disk copy of the
17 16 contents of the process address space at the time the process received the
18 17 signal, along with additional information about the state of the process. This
19 18 information can be consumed by a debugger. Core files can also be generated by
20 19 applying the \fBgcore\fR(1) utility to a running process.
21 20 .sp
22 21 .LP
23 22 Typically, core files are produced following abnormal termination of a process
24 23 resulting from a bug in the corresponding application. Whatever the cause, the
25 24 core file itself provides invaluable information to the programmer or support
26 25 engineer to aid in diagnosing the problem. The core file can be inspected using
27 26 a debugger such as \fBdbx\fR(1) or \fBmdb\fR(1) or by applying one of the
28 27 \fBproc\fR(1) tools.
29 28 .sp
30 29 .LP
31 30 The operating system attempts to create up to two core files for each
32 31 abnormally terminating process, using a global core file name pattern and a
33 32 per-process core file name pattern. These patterns are expanded to determine
34 33 the pathname of the resulting core files, and can be configured by
35 34 \fBcoreadm\fR(1M). By default, the global core file pattern is disabled and not
36 35 used, and the per-process core file pattern is set to \fBcore\fR. Therefore, by
37 36 default, the operating system attempts to create a core file named \fBcore\fR
38 37 in the process's current working directory.
39 38 .sp
40 39 .LP
41 40 A process terminates and produces a core file whenever it receives one of the
42 41 signals whose default disposition is to cause a core dump. The list of signals
43 42 that result in generating a core file is shown in \fBsignal.h\fR(3HEAD).
44 43 Therefore, a process might not produce a core file if it has blocked or
45 44 modified the behavior of the corresponding signal. Additionally, no core dump
46 45 can be created under the following conditions:
47 46 .RS +4
48 47 .TP
49 48 .ie t \(bu
50 49 .el o
51 50 If normal file and directory access permissions prevent the creation or
52 51 modification of the per-process core file pathname by the current process user
53 52 and group ID. This test does not apply to the global core file pathname
54 53 because, regardless of the UID of the process dumping core, the attempt to
55 54 write the global core file is made as the superuser.
56 55 .RE
57 56 .RS +4
58 57 .TP
59 58 .ie t \(bu
60 59 .el o
61 60 Core files owned by the user \fBnobody\fR will not be produced. For example,
62 61 core files generated for the superuser on an NFS directory are owned by
63 62 \fBnobody\fR and are, therefore, not written.
64 63 .RE
65 64 .RS +4
66 65 .TP
67 66 .ie t \(bu
68 67 .el o
69 68 If the core file pattern expands to a pathname that contains intermediate
70 69 directory components that do not exist. For example, if the global pattern is
71 70 set to \fB/var/core/%n/core.%p\fR, and no directory \fB/var/core/`uname -n`\fR
72 71 has been created, no global core files are produced.
73 72 .RE
74 73 .RS +4
75 74 .TP
76 75 .ie t \(bu
77 76 .el o
78 77 If the destination directory is part of a filesystem that is mounted read-only.
79 78 .RE
80 79 .RS +4
81 80 .TP
82 81 .ie t \(bu
83 82 .el o
84 83 If the resource limit \fBRLIMIT_CORE\fR has been set to \fB0\fR for the
85 84 process, no per-process core file is produced. Refer to \fBsetrlimit\fR(2) and
86 85 \fBulimit\fR(1) for more information on resource limits.
87 86 .RE
88 87 .RS +4
89 88 .TP
90 89 .ie t \(bu
91 90 .el o
92 91 If the core file name already exists in the destination directory and is not a
93 92 regular file (that is, is a symlink, block or character special-file, and so
94 93 forth).
95 94 .RE
96 95 .RS +4
97 96 .TP
98 97 .ie t \(bu
99 98 .el o
100 99 If the kernel cannot open the destination file \fBO_EXCL\fR, which can occur if
101 100 same file is being created by another process simultaneously.
102 101 .RE
103 102 .RS +4
104 103 .TP
105 104 .ie t \(bu
106 105 .el o
107 106 If the process's effective user ID is different from its real user ID or if its
108 107 effective group ID is different from its real group ID. Similarly, set-user-ID
109 108 and set-group-ID programs do not produce core files as this could potentially
110 109 compromise system security. These processes can be explicitly granted
111 110 permission to produce core files using \fBcoreadm\fR(1M), at the risk of
112 111 exposing secure information.
113 112 .RE
114 113 .sp
115 114 .LP
116 115 The core file contains all the process information pertinent to debugging:
117 116 contents of hardware registers, process status, and process data. The format of
118 117 a core file is object file specific.
119 118 .sp
120 119 .LP
121 120 For ELF executable programs (see \fBa.out\fR(4)), the core file generated is
122 121 also an ELF file, containing ELF program and file headers. The \fBe_type\fR
123 122 field in the file header has type \fBET_CORE\fR. The program header contains an
124 123 entry for every segment that was part of the process address space, including
125 124 shared library segments. The contents of the mappings specified by
126 125 \fBcoreadm\fR(1M) are also part of the core image. Each program header has its
127 126 \fBp_memsz\fR field set to the size of the mapping. The program headers that
128 127 represent mappings whose data is included in the core file have their
129 128 \fBp_filesz\fR field set the same as \fBp_memsz\fR, otherwise \fBp_filesz\fR is
130 129 \fBzero\fR.
131 130 .sp
132 131 .LP
133 132 A mapping's data can be excluded due to the core file content settings (see
134 133 \fBcoreadm\fR(1M)), due to a failure, or due to a signal received after
135 134 core dump initiation but before its completion. If the data is excluded
136 135 because of a failure, the program header entry will have the
137 136 \fBPF_SUNW_FAILURE\fR flag
138 137 set in its \fBp_flags\fR field; if the data is excluded because of a signal,
139 138 the segment's \fBp_flags\fR field will have the \fBPF_SUNW_KILLED\fR
140 139 flag set.
141 140 .sp
142 141 .LP
143 142 The program headers of an \fBELF\fR core file also contain entries for two
144 143 \fBNOTE\fR segments, each containing several note entries as described below.
145 144 The note entry header and core file note type (\fBn_type\fR) definitions are
146 145 contained in <\fBsys/elf.h\fR>. The first \fBNOTE\fR segment exists for binary
147 146 compatibility with old programs that deal with core files. It contains
148 147 structures defined in <\fBsys/old_procfs.h\fR>. New programs should recognize
149 148 and skip this \fBNOTE\fR segment, advancing instead to the new \fBNOTE\fR
150 149 segment. The old \fBNOTE\fR segment is deleted from core files in a future
151 150 release.
152 151 .sp
153 152 .LP
154 153 The old \fBNOTE\fR segment contains the following entries. Each has entry name
155 154 \fB"CORE"\fR and presents the contents of a system structure:
156 155 .sp
157 156 .ne 2
158 157 .na
159 158 \fB\fBprpsinfo_t\fR\fR
160 159 .ad
161 160 .RS 16n
162 161 \fBn_type\fR: \fBNT_PRPSINFO\fR. This entry contains information of interest to
163 162 the \fBps\fR(1) command, such as process status, \fBCPU\fR usage, \fBnice\fR
164 163 value, controlling terminal, user-ID, process-ID, the name of the executable,
165 164 and so forth. The \fBprpsinfo_t\fR structure is defined in
166 165 <\fBsys/old_procfs.h\fR>.
167 166 .RE
168 167
169 168 .sp
170 169 .ne 2
171 170 .na
172 171 \fB\fBchar\fR array\fR
173 172 .ad
174 173 .RS 16n
175 174 \fBn_type\fR: \fBNT_PLATFORM\fR. This entry contains a string describing the
176 175 specific model of the hardware platform on which this core file was created.
177 176 This information is the same as provided by \fBsysinfo\fR(2) when invoked with
178 177 the command \fBSI_PLATFORM\fR.
179 178 .RE
180 179
181 180 .sp
182 181 .ne 2
183 182 .na
184 183 \fB\fBauxv_t\fR array\fR
185 184 .ad
186 185 .RS 16n
187 186 \fBn_type\fR: \fBNT_AUXV\fR. This entry contains the array of \fBauxv_t\fR
188 187 structures that was passed by the operating system as startup information to
189 188 the dynamic linker. Auxiliary vector information is defined in
190 189 <\fBsys/auxv.h\fR>.
191 190 .RE
192 191
193 192 .sp
194 193 .LP
195 194 Following these entries, for each active (non-zombie) light-weight process
196 195 (LWP) in the process, the old \fBNOTE\fR segment contains an entry with a
197 196 \fBprstatus_t\fR structure, plus other optionally-present entries describing
198 197 the LWP, as follows:
199 198 .sp
200 199 .ne 2
201 200 .na
202 201 \fB\fBprstatus_t\fR\fR
203 202 .ad
204 203 .RS 16n
205 204 \fBn_type\fR: \fBNT_PRSTATUS\fR. This structure contains things of interest to
206 205 a debugger from the operating system, such as the general registers, signal
207 206 dispositions, state, reason for stopping, process-ID, and so forth. The
208 207 \fBprstatus_t\fR structure is defined in <\fBsys/old_procfs.h\fR>.
209 208 .RE
210 209
211 210 .sp
212 211 .ne 2
213 212 .na
214 213 \fB\fBprfpregset_t\fR\fR
215 214 .ad
216 215 .RS 16n
217 216 \fBn_type\fR: \fBNT_PRFPREG\fR. This entry is present only if the \fBLWP\fR
218 217 used the floating-point hardware. It contains the floating-point registers. The
219 218 \fBprfpregset_t\fR structure is defined in <\fBsys/procfs_isa.h\fR>.
220 219 .RE
221 220
222 221 .sp
223 222 .ne 2
224 223 .na
225 224 \fB\fBgwindows_t\fR\fR
226 225 .ad
227 226 .RS 16n
228 227 \fBn_type\fR: \fBNT_GWINDOWS\fR. This entry is present only on a SPARC machine
229 228 and only if the system was unable to flush all of the register windows to the
230 229 stack. It contains all of the unspilled register windows. The \fBgwindows_t\fR
231 230 structure is defined in <\fBsys/regset.h\fR>.
232 231 .RE
233 232
234 233 .sp
235 234 .ne 2
236 235 .na
237 236 \fB\fBprxregset_t\fR\fR
238 237 .ad
239 238 .RS 16n
240 239 \fBn_type\fR: \fBNT_PRXREG\fR. This entry is present only if the machine has
241 240 extra register state associated with it. It contains the extra register state.
242 241 The \fBprxregset_t\fR structure is defined in <\fBsys/procfs_isa.h\fR>.
243 242 .RE
244 243
245 244 .sp
246 245 .LP
247 246 The new \fBNOTE\fR segment contains the following entries. Each has entry name
248 247 "\fBCORE\fR" and presents the contents of a system structure:
249 248 .sp
250 249 .ne 2
251 250 .na
252 251 \fB\fBpsinfo_t\fR\fR
253 252 .ad
254 253 .RS 20n
255 254 \fBn_type\fR: \fBNT_PSINFO\fR. This structure contains information of interest
256 255 to the \fBps\fR(1) command, such as process status, \fBCPU\fR usage, \fBnice\fR
257 256 value, controlling terminal, user-ID, process-ID, the name of the executable,
258 257 and so forth. The \fBpsinfo_t\fR structure is defined in <\fBsys/procfs.h\fR>.
259 258 .RE
260 259
261 260 .sp
262 261 .ne 2
263 262 .na
264 263 \fB\fBpstatus_t\fR\fR
265 264 .ad
266 265 .RS 20n
267 266 \fBn_type\fR: \fBNT_PSTATUS\fR. This structure contains things of interest to a
268 267 debugger from the operating system, such as pending signals, state, process-ID,
269 268 and so forth. The \fBpstatus_t\fR structure is defined in <\fBsys/procfs.h\fR>.
270 269 .RE
271 270
272 271 .sp
273 272 .ne 2
274 273 .na
275 274 \fB\fBchar\fR array\fR
276 275 .ad
277 276 .RS 20n
278 277 \fBn_type\fR: \fBNT_PLATFORM\fR. This entry contains a string describing the
279 278 specific model of the hardware platform on which this core file was created.
280 279 This information is the same as provided by \fBsysinfo\fR(2) when invoked with
281 280 the command \fBSI_PLATFORM\fR.
282 281 .RE
283 282
284 283 .sp
285 284 .ne 2
286 285 .na
287 286 \fB\fBauxv_t\fR array\fR
288 287 .ad
289 288 .RS 20n
290 289 \fBn_type\fR: \fBNT_AUXV\fR. This entry contains the array of \fBauxv_t\fR
291 290 structures that was passed by the operating system as startup information to
292 291 the dynamic linker. Auxiliary vector information is defined in
293 292 <\fBsys/auxv.h\fR>.
294 293 .RE
295 294
296 295 .sp
297 296 .ne 2
298 297 .na
299 298 \fB\fBstruct utsname\fR\fR
300 299 .ad
301 300 .RS 20n
302 301 \fBn_type\fR: \fBNT_UTSNAME\fR. This structure contains the system information
303 302 that would have been returned to the process if it had performed a
304 303 \fBuname\fR(2) system call prior to dumping core. The \fButsname\fR structure
305 304 is defined in <\fBsys/utsname.h\fR>.
306 305 .RE
307 306
308 307 .sp
309 308 .ne 2
310 309 .na
311 310 \fB\fBprcred_t\fR\fR
312 311 .ad
313 312 .RS 20n
314 313 \fBn_type\fR: \fBNT_PRCRED\fR. This structure contains the process credentials,
315 314 including the real, saved, and effective user and group IDs. The \fBprcred_t\fR
316 315 structure is defined in <\fBsys/procfs.h\fR>. Following the structure is an
317 316 optional array of supplementary group IDs. The total number of supplementary
318 317 group IDs is given by the \fBpr_ngroups\fR member of the \fBprcred_t\fR
319 318 structure, and the structure includes space for one supplementary group. If
320 319 \fBpr_ngroups\fR is greater than 1, there is \fBpr_ngroups - 1\fR \fBgid_t\fR
321 320 items following the structure; otherwise, there is no additional data.
322 321 .RE
323 322
324 323 .sp
325 324 .ne 2
326 325 .na
327 326 \fB\fBchar array\fR\fR
328 327 .ad
329 328 .RS 20n
330 329 \fBn_type\fR: \fBNT_ZONENAME\fR. This entry contains a string which describes
331 330 the name of the zone in which the process was running. See \fBzones\fR(5). The
332 331 information is the same as provided by \fBgetzonenamebyid\fR(3C) when invoked
333 332 with the numerical ID returned by \fBgetzoneid\fR(3C).
334 333 .RE
335 334
336 335 .sp
337 336 .ne 2
338 337 .na
339 338 \fB\fBprfdinfo_t\fR\fR
340 339 .ad
341 340 .RS 20n
342 341 \fBn_type\fR: \fBNT_FDINFO\fR. This structure contains information about
343 342 any open file descriptors, including the path, flags, and
344 343 \fBstat\fR(2) information. The \fBprfdinfo_t\fR structure is defined in
345 344 <\fBsys/procfs.h\fR>.
346 345 .RE
347 346
348 347 .sp
349 348 .ne 2
350 349 .na
351 350 \fB\fBstruct ssd\fR array\fR
352 351 .ad
353 352 .RS 20n
354 353 \fBn_type\fR: \fBNT_LDT\fR. This entry is present only on an 32-bit x86 machine
355 354 and only if the process has set up a Local Descriptor Table (LDT). It contains
356 355 an array of structures of type \fBstruct ssd\fR, each of which was typically
357 356 used to set up the \fB%gs\fR segment register to be used to fetch the address
358 357 of the current thread information structure in a multithreaded process. The
359 358 \fBssd\fR structure is defined in <\fBsys/sysi86.h\fR>.
360 359 .RE
361 360
362 361 .sp
363 362 .ne 2
364 363 .na
365 364 \fB\fBcore_content_t\fR\fR
366 365 .ad
367 366 .RS 20n
368 367 \fBn_type\fR: \fBNT_CONTENT\fR. This optional entry indicates which parts of
369 368 the process image are specified to be included in the core file. See
370 369 \fBcoreadm\fR(1M).
371 370 .RE
372 371
373 372 .sp
374 373 .LP
375 374 Following these entries, for each active and zombie \fBLWP\fR in the process,
376 375 the new \fBNOTE\fR segment contains an entry with an \fBlwpsinfo_t\fR structure
377 376 plus, for a non-zombie LWP, an entry with an \fBlwpstatus_t\fR structure, plus
378 377 other optionally-present entries describing the LWP, as follows. A zombie LWP
379 378 is a non-detached LWP that has terminated but has not yet been reaped by
380 379 another LWP in the same process.
381 380 .sp
382 381 .ne 2
383 382 .na
384 383 \fB\fBlwpsinfo_t\fR\fR
385 384 .ad
386 385 .RS 15n
387 386 \fBn_type\fR: \fBNT_LWPSINFO\fR. This structure contains information of
388 387 interest to the \fBps\fR(1) command, such as \fBLWP\fR status, \fBCPU\fR usage,
389 388 \fBnice\fR value, \fBLWP-ID\fR, and so forth. The \fBlwpsinfo_t\fR structure is
390 389 defined in <\fBsys/procfs.h\fR>. This is the only entry present for a zombie
391 390 LWP.
392 391 .RE
393 392
394 393 .sp
395 394 .ne 2
396 395 .na
397 396 \fB\fBlwpstatus_t\fR\fR
398 397 .ad
399 398 .RS 15n
400 399 \fBn_type\fR: \fBNT_LWPSTATUS\fR. This structure contains things of interest to
401 400 a debugger from the operating system, such as the general registers, the
402 401 floating point registers, state, reason for stopping, \fBLWP-ID\fR, and so
403 402 forth. The \fBlwpstatus_t\fR structure is defined in <\fBsys/procfs.h>\fR>.
404 403 .RE
405 404
406 405 .sp
407 406 .ne 2
408 407 .na
409 408 \fB\fBgwindows_t\fR\fR
410 409 .ad
411 410 .RS 15n
412 411 \fBn_type\fR: \fBNT_GWINDOWS\fR. This entry is present only on a SPARC machine
413 412 and only if the system was unable to flush all of the register windows to the
414 413 stack. It contains all of the unspilled register windows. The \fBgwindows_t\fR
415 414 structure is defined in \fB<sys/regset.h>\fR\&.
416 415 .RE
417 416
418 417 .sp
419 418 .ne 2
420 419 .na
421 420 \fB\fBprxregset_t\fR\fR
422 421 .ad
423 422 .RS 15n
424 423 \fBn_type\fR: \fBNT_PRXREG\fR. This entry is present only if the machine has
425 424 extra register state associated with it. It contains the extra register state.
426 425 The \fBprxregset_t\fR structure is defined in \fB<sys/procfs_isa.h>\fR\&.
427 426 .RE
428 427
429 428 .sp
430 429 .ne 2
431 430 .na
432 431 \fB\fBasrset_t\fR\fR
433 432 .ad
434 433 .RS 15n
435 434 \fBn_type\fR: \fBNT_ASRS\fR. This entry is present only on a SPARC V9 machine
436 435 and only if the process is a 64-bit process. It contains the ancillary state
437 436 registers for the \fBLWP.\fR The \fBasrset_t\fR structure is defined in
438 437 \fB<sys/regset.h>\fR\&.
439 438 .RE
440 439
441 440 .sp
442 441 .ne 2
443 442 .na
↓ open down ↓ |
420 lines elided |
↑ open up ↑ |
444 443 \fB\fBpsinfo_t\fR\fR
445 444 .ad
446 445 .RS 15n
447 446 \fBn_type\fR: \fBNT_SPYMASTER\fR. This entry is present only for an agent
448 447 LWP and contains the \fBpsinfo_t\fR of the process that created the agent
449 448 LWP. See the \fBproc\fR(4) description of the \fBspymaster\fR entry for
450 449 more details.
451 450 .RE
452 451
453 452 .sp
453 +.ne 2
454 +.na
455 +\fB\fBprsecflags_t\fR\fR
456 +.ad
457 +.RS 15n
458 +\fBn_type\fR: \fbNT_SECFLAGS\fR. This entry contains the process
459 +security-flags, see \fBsecurity-flags\fR(5), \fBproc\fR(4), and
460 +\fBpsecflags\fR(1M) for more information.
461 +.RE
462 +
463 +.sp
454 464 .LP
455 465 Depending on the \fBcoreadm\fR(1M) settings, the section header of an ELF core
456 466 file can contain entries for CTF, symbol table, and string table sections. The
457 467 \fBsh_addr\fR fields are set to the base address of the first mapping of the
458 468 load object that they came from to. This can be used to match those sections
459 469 with the corresponding load object.
460 470 .sp
461 471 .LP
462 472 The size of the core file created by a process can be controlled by the user
463 473 (see \fBgetrlimit\fR(2)).
464 474 .SH SEE ALSO
465 -.sp
466 475 .LP
467 476 \fBelfdump\fR(1), \fBgcore\fR(1), \fBmdb\fR(1), \fBproc\fR(1), \fBps\fR(1),
468 477 \fBcoreadm\fR(1M), \fBgetrlimit\fR(2), \fBsetrlimit\fR(2), \fBsetuid\fR(2),
469 478 \fBsysinfo\fR(2), \fBuname\fR(2), \fBgetzonenamebyid\fR(3C),
470 479 \fBgetzoneid\fR(3C), \fBelf\fR(3ELF), \fBsignal.h\fR(3HEAD), \fBa.out\fR(4),
471 -\fBproc\fR(4), \fBzones\fR(5)
480 +\fBproc\fR(4), \fBzones\fR(5), \fBsecurity-flags\fR(5)
472 481 .sp
473 482 .LP
474 483 \fIANSI C Programmer's Guide\fR
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX