explicit_bzero(3)

1bzero(3)                   Library Functions Manual                   bzero(3)
2
3
4

NAME

6       bzero, explicit_bzero - zero a byte string
7

LIBRARY

9       Standard C library (libc, -lc)
10

SYNOPSIS

12       #include <strings.h>
13
14       void bzero(void s[.n], size_t n);
15
16       #include <string.h>
17
18       void explicit_bzero(void s[.n], size_t n);
19

DESCRIPTION

21       The  bzero()  function  erases  the  data  in the n bytes of the memory
22       starting at the location pointed to by s, by writing zeros (bytes  con‐
23       taining '\0') to that area.
24
25       The  explicit_bzero()  function  performs the same task as bzero().  It
26       differs from bzero() in that it guarantees that compiler  optimizations
27       will  not  remove  the erase operation if the compiler deduces that the
28       operation is "unnecessary".
29

RETURN VALUE

31       None.
32

ATTRIBUTES

34       For an  explanation  of  the  terms  used  in  this  section,  see  at‐
35       tributes(7).
36
37       ┌────────────────────────────────────────────┬───────────────┬─────────┐
38       │Interface                                   │ Attribute     │ Value   │
39       ├────────────────────────────────────────────┼───────────────┼─────────┤
40       │bzero(), explicit_bzero()                   │ Thread safety │ MT-Safe │
41       └────────────────────────────────────────────┴───────────────┴─────────┘
42

STANDARDS

44       None.
45

HISTORY

47       explicit_bzero()
48              glibc 2.25.
49
50              The explicit_bzero() function is a nonstandard extension that is
51              also present on some of the BSDs.   Some  other  implementations
52              have  a  similar  function,  such  as  memset_explicit() or mem‐
53              set_s().
54
55       bzero()
56              4.3BSD.
57
58              Marked as LEGACY in POSIX.1-2001.  Removed in POSIX.1-2008.
59

NOTES

61       The explicit_bzero() function addresses a  problem  that  security-con‐
62       scious  applications  may  run into when using bzero(): if the compiler
63       can deduce that the location to be zeroed will never again  be  touched
64       by  a  correct program, then it may remove the bzero() call altogether.
65       This is a problem if the intent of the bzero() call was to erase sensi‐
66       tive  data  (e.g.,  passwords) to prevent the possibility that the data
67       was leaked by an incorrect or compromised program.   Calls  to  explic‐
68       it_bzero() are never optimized away by the compiler.
69
70       The  explicit_bzero()  function  does not solve all problems associated
71       with erasing sensitive data:
72
73       •  The explicit_bzero() function does not guarantee that sensitive data
74          is  completely  erased  from memory.  (The same is true of bzero().)
75          For example, there may be copies of the sensitive data in a register
76          and  in "scratch" stack areas.  The explicit_bzero() function is not
77          aware of these copies, and can't erase them.
78
79       •  In some circumstances, explicit_bzero() can decrease  security.   If
80          the  compiler  determined that the variable containing the sensitive
81          data could be optimized to be stored in a register  (because  it  is
82          small  enough  to fit in a register, and no operation other than the
83          explicit_bzero() call would need to take the address  of  the  vari‐
84          able),  then  the  explicit_bzero()  call  will force the data to be
85          copied from the register to a location in RAM that is  then  immedi‐
86          ately  erased  (while  the copy in the register remains unaffected).
87          The problem here is that data in RAM is more likely to be exposed by
88          a  bug  than  data in a register, and thus the explicit_bzero() call
89          creates a brief time window where the sensitive data is more vulner‐
90          able  than  it would otherwise have been if no attempt had been made
91          to erase the data.
92
93       Note that declaring the sensitive variable with the volatile  qualifier
94       does  not  eliminate  the  above  problems.   Indeed, it will make them
95       worse, since, for example, it may force a variable that would otherwise
96       have  been  optimized into a register to instead be maintained in (more
97       vulnerable) RAM for its entire lifetime.
98
99       Notwithstanding the above details, for security-conscious applications,
100       using  explicit_bzero()  is  generally preferable to not using it.  The
101       developers of explicit_bzero() anticipate that  future  compilers  will
102       recognize  calls  to explicit_bzero() and take steps to ensure that all
103       copies of the sensitive data are erased, including copies in  registers
104       or in "scratch" stack areas.
105