bzero(3) - f39

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
53              memset_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-
62       conscious 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
66       sensitive  data  (e.g.,  passwords) to prevent the possibility that the
67       data was leaked by an  incorrect  or  compromised  program.   Calls  to
68       explicit_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
84          variable),  then the explicit_bzero() call will force the data to be
85          copied from  the  register  to  a  location  in  RAM  that  is  then
86          immediately   erased   (while  the  copy  in  the  register  remains
87          unaffected).  The problem here is that data in RAM is more likely to
88          be  exposed  by  a  bug  than  data  in  a  register,  and  thus the
89          explicit_bzero()  call  creates  a  brief  time  window  where   the
90          sensitive  data is more vulnerable than it would otherwise have been
91          if no attempt had been made 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