Is reallocarray() planned to be standardized? Looking
at the man page on Fedora 44, it says this function
has been in glibc since version 2.26, OpenBSD libc
since release 5.6m and FreeBSD libc release 11.0.
So is this function becoming part of ISO C? Or SUS?
Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
Is reallocarray() planned to be standardized? Looking
at the man page on Fedora 44, it says this function
has been in glibc since version 2.26, OpenBSD libc
since release 5.6m and FreeBSD libc release 11.0.
So is this function becoming part of ISO C? Or SUS?
Testing my luck with chatGPT again, it claims:
[snip]
According to this page:
[snip]
reallocarray() is indeed a newly added function. So this
time chatGPT got it right. I guess I have to submit a bug
report to the Linux man pages maintainers.
Aaargh... I should have checked out FreeBSD before even
asking! Their man page correctly mentions:
reallocarray() conforms to IEEE Std 1003.1-2024 (rCLPOSIX.1rCY).
Is reallocarray() planned to be standardized? Looking
at the man page on Fedora 44, it says this function
has been in glibc since version 2.26, OpenBSD libc
since release 5.6m and FreeBSD libc release 11.0.
So is this function becoming part of ISO C? Or SUS?
`reallocarray` is, indeed, in POSIX-2024, but has yet to make it
into C. `recallocarray` is not yet in POSIX, however.
[...]
`reallocarray` is, indeed, in POSIX-2024, but has yet to make it
into C. `recallocarray` is not yet in POSIX, however.
I don't think that's what you meant to say.
I'm unaware of any proposal to add reallocarray to ISO C.
kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
Is reallocarray() planned to be standardized? Looking
at the man page on Fedora 44, it says this function
has been in glibc since version 2.26, OpenBSD libc
since release 5.6m and FreeBSD libc release 11.0.
So is this function becoming part of ISO C? Or SUS?
reallocarray() does not appear in the latest ISO C2y draft.
It does appear in POSIX. It's in The Open Group Base Specifications
Issue 8, but not in Issue 7.
(I'm not convinced it's all that useful.)
In article <10u5qch$uo0d$8@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
cross@spitfire.i.gajendra.net (Dan Cross) writes:
[...]
`reallocarray` is, indeed, in POSIX-2024, but has yet to make it
into C. `recallocarray` is not yet in POSIX, however.
I don't think that's what you meant to say.
I mean that `reallocarray` is in POSIX-2024, but not in ISO C.
There is a related function, `recallocarray`, that is not in
POSIX.
I'm unaware of any proposal to add reallocarray to ISO C.
I'm mildly surprised it hasn't been proposed.
Aaargh... I should have checked out FreeBSD before even asking!
Their man page correctly mentions:
reallocarray() conforms to IEEE Std 1003.1-2024 (rCLPOSIX.1rCY).
In article <10u5qch$uo0d$8@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
[...]
`reallocarray` is, indeed, in POSIX-2024, but has yet to make it
into C. `recallocarray` is not yet in POSIX, however.
I don't think that's what you meant to say.
I mean that `reallocarray` is in POSIX-2024, but not in ISO C.
There is a related function, `recallocarray`, that is not in
POSIX.
Ah, I completely missed that "reallocarray" and "recallocarray"
("re" vs. "rec") are distinct.
"recallocarray" is apparently BSD-specific, and is not implemented
in glibc. "recallocarray" differs from "reallocarray" in that
freed memory is cleared with explicit_bzero().
I'm unaware of any proposal to add reallocarray to ISO C.
I'm mildly surprised it hasn't been proposed.
As far as I can tell, reallocarray() differs from realloc() only
in that it takes two arguments to specify the size, and fails
if the multiplication would overflow (um, I mean wrap around).
realloc(p, n*size) does the same thing in the absence of overflow.
Obviously somebody thought it was worthwhile.
On Thu, 14 May 2026 21:10:05 -0000 (UTC), Kalevi Kolttonen wrote:
Aaargh... I should have checked out FreeBSD before even asking!
Their man page correctly mentions:
reallocarray() conforms to IEEE Std 1003.1-2024 (rCLPOSIX.1rCY).
If yourCOre on a Linux systemrCa, its man pages should be among the first things you check.
<https://manpages.debian.org/reallocarray(3)> looks out of date:
my machine says rCLreallocarray() ... POSIX.1-2024rCY.
rCaOr have one handy. On a geek-oriented group like this, why wouldnrCOt
you have one handy?
"recallocarray" is apparently BSD-specific, and is not implemented
in glibc
So some versions of FreeBSD libc have recallocarray(),
but the latest official RELEASE does not.
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
"recallocarray" is apparently BSD-specific, and is not implemented
in glibc
I do not see this function on:
root@fbsd15:~ # freebsd-version -ku
15.0-RELEASE-p8
15.0-RELEASE-p8
But I once tried "make world" or something like that
to stress test my used laptop. The remains of the build are
still left and they reveal this:
root@fbsd15:~ # nm /usr/obj/home/kalevi/src/freebsd-src/amd64.amd64/tmp/lib/libc.so.7
/usr/obj/home/kalevi/src/freebsd-src/amd64.amd64/tmp/lib/libc.so.7: no symbols >root@fbsd15:~ # strings /usr/obj/home/kalevi/src/freebsd-src/amd64.amd64/tmp/lib/libc.so.7|grep recall
recallocarray
So some versions of FreeBSD libc have recallocarray(),
but the latest official RELEASE does not.
By the way, is reallocarray() or recallocarray()
available on the latest MacOS? ChatGPT gave only a
vague response concerning this, implying "maybe or
maybe not".
No idea about Solaris, AIX [...]
Dan Cross <cross@spitfire.i.gajendra.net> wrote:
No idea about Solaris, AIX [...]
Thanks for the detailed information.
Solaris and AIX, the last two big surviving commercial
UNIX systems? I suppose both are still supported but
the userbase must be rapidly diminishing and their
end is near.
I wonder just how long can those two last against the
ever mounting pressure from Linux? It was a pleasure
using Solaris long time ago, a very stable and
forward-looking OS with many innovations it was.
I have never used AIX.
Ya' ain't missing much. [AIX] was odd.
Not particularly relevant to C though, I'm afraid.
I have never used AIX.
In article <10u601c$uo0d$12@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <10u5qch$uo0d$8@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
cross@spitfire.i.gajendra.net (Dan Cross) writes:
[...]
`reallocarray` is, indeed, in POSIX-2024, but has yet to make it
into C. `recallocarray` is not yet in POSIX, however.
I don't think that's what you meant to say.
I mean that `reallocarray` is in POSIX-2024, but not in ISO C.
There is a related function, `recallocarray`, that is not in
POSIX.
Ah, I completely missed that "reallocarray" and "recallocarray"
("re" vs. "rec") are distinct.
"recallocarray" is apparently BSD-specific, and is not implemented
in glibc. "recallocarray" differs from "reallocarray" in that
freed memory is cleared with explicit_bzero().
And newly allocated memory is cleared, a la `calloc`.
I'm unaware of any proposal to add reallocarray to ISO C.
I'm mildly surprised it hasn't been proposed.
As far as I can tell, reallocarray() differs from realloc() only
in that it takes two arguments to specify the size, and fails
if the multiplication would overflow (um, I mean wrap around).
realloc(p, n*size) does the same thing in the absence of overflow.
Obviously somebody thought it was worthwhile.
It's a security thing, similar to `explicit_bzero` or
`memset_explicit`.
I believe that when it was introduced into
OpenBSD, it actually found a number of overflow bugs; whether
those were exploitable or not, I don't know. The OpenBSD people
are known to be zealous when it comes to security.
- Dan C.
On 2026-05-15 19:50, Kalevi Kolttonen wrote:
I have never used AIX.
It had been a progress back then, especially e.g. if compared to
SunOS 4.x; it supported SysV and BSD IPC, and you didn't need to
recompile the kernel if you just wanted to add (or configure) a
kernel module.
We used it in huge (really *huge*) telecommunication projects as
the standard OS (later extended our platforms by HP-UX).
Re Dan's comment; from a user/programmer perspective I didn't see
or noticed any noteworthy oddity.
On 5/15/2026 4:02 AM, Dan Cross wrote:
In article <10u601c$uo0d$12@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
[snip]
As far as I can tell, reallocarray() differs from realloc() only
in that it takes two arguments to specify the size, and fails
if the multiplication would overflow (um, I mean wrap around).
realloc(p, n*size) does the same thing in the absence of overflow.
Obviously somebody thought it was worthwhile.
It's a security thing, similar to `explicit_bzero` or
`memset_explicit`.
Fwiw, iirc wrt security. Instead of filling it with 0's, you fill it
with data from a TRNG. An attacker can look for parts that are zeros.
In article <10u844d$i6t3$1@dont-email.me>,
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
On 5/15/2026 4:02 AM, Dan Cross wrote:
In article <10u601c$uo0d$12@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
[snip]
As far as I can tell, reallocarray() differs from realloc() only
in that it takes two arguments to specify the size, and fails
if the multiplication would overflow (um, I mean wrap around).
realloc(p, n*size) does the same thing in the absence of overflow.
Obviously somebody thought it was worthwhile.
It's a security thing, similar to `explicit_bzero` or
`memset_explicit`.
Fwiw, iirc wrt security. Instead of filling it with 0's, you fill it
with data from a TRNG. An attacker can look for parts that are zeros.
No.
On 5/15/2026 2:50 PM, Dan Cross wrote:
In article <10u844d$i6t3$1@dont-email.me>,
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
On 5/15/2026 4:02 AM, Dan Cross wrote:
In article <10u601c$uo0d$12@kst.eternal-september.org>,
Keith Thompson-a <Keith.S.Thompson+u@gmail.com> wrote:
[snip]
As far as I can tell, reallocarray() differs from realloc() only
in that it takes two arguments to specify the size, and fails
if the multiplication would overflow (um, I mean wrap around).
realloc(p, n*size) does the same thing in the absence of overflow.
Obviously somebody thought it was worthwhile.
It's a security thing, similar to `explicit_bzero` or
`memset_explicit`.
Fwiw, iirc wrt security. Instead of filling it with 0's, you fill it
with data from a TRNG. An attacker can look for parts that are zeros.
No.
Iirc, a long time ago I kind of remember reading something about
overwrite sensitive data multiple times (e.g., the DoD 5220.22-M
standard for storage, though adapted for RAM), sometimes using a pass of random data followed by a pass of fixed characters, or using a fast
CSPRNG (like ChaCha20) to generate fast pseudo-random bytes so they
don't deplete the physical TRNG.
Dan Cross <cross@spitfire.i.gajendra.net> wrote:
Ya' ain't missing much. [AIX] was odd.
Not particularly relevant to C though, I'm afraid.
I started a new thread on comp.unix.misc. I am
quite curious whether someone there still runs
Solaris or AIX in 2026. That newsgroup seems quite
dead, though.
On 2026-05-15 19:50, Kalevi Kolttonen wrote:
I have never used AIX.
It had been a progress back then, especially e.g. if compared to
SunOS 4.x; it supported SysV and BSD IPC, and you didn't need to
recompile the kernel if you just wanted to add (or configure) a
kernel module.
We used it in huge (really *huge*) telecommunication projects as
the standard OS (later extended our platforms by HP-UX).
Re Dan's comment; from a user/programmer perspective I didn't see
or noticed any noteworthy oddity.
On 5/15/2026 2:50 PM, Dan Cross wrote:
Iirc, a long time ago I kind of remember reading something about
overwrite sensitive data multiple times (e.g., the DoD 5220.22-M
standard for storage, though adapted for RAM), sometimes using a pass of >random data followed by a pass of fixed characters, or using a fast
CSPRNG (like ChaCha20) to generate fast pseudo-random bytes so they
don't deplete the physical TRNG.
On 2026-05-15 19:50, Kalevi Kolttonen wrote:
I have never used AIX.
It had been a progress back then, especially e.g. if compared to
SunOS 4.x; it supported SysV and BSD IPC, and you didn't need to
recompile the kernel if you just wanted to add (or configure) a
kernel module.
We used it in huge (really *huge*) telecommunication projects as
the standard OS (later extended our platforms by HP-UX).
Re Dan's comment; from a user/programmer perspective I didn't see
or noticed any noteworthy oddity.
On 5/15/2026 2:50 PM, Dan Cross wrote:
In article <10u844d$i6t3$1@dont-email.me>,
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
On 5/15/2026 4:02 AM, Dan Cross wrote:
In article <10u601c$uo0d$12@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
[snip]
As far as I can tell, reallocarray() differs from realloc() only
in that it takes two arguments to specify the size, and fails
if the multiplication would overflow (um, I mean wrap around).
realloc(p, n*size) does the same thing in the absence of overflow.
Obviously somebody thought it was worthwhile.
It's a security thing, similar to `explicit_bzero` or
`memset_explicit`.
Fwiw, iirc wrt security. Instead of filling it with 0's, you fill it
with data from a TRNG. An attacker can look for parts that are zeros.
No.
Iirc, a long time ago I kind of remember reading something about
overwrite sensitive data multiple times (e.g., the DoD 5220.22-M
standard for storage, though adapted for RAM), sometimes using a pass of >random data followed by a pass of fixed characters, or using a fast
CSPRNG (like ChaCha20) to generate fast pseudo-random bytes so they
don't deplete the physical TRNG.
Funny. I still have Solaris installed on an old hard drive. Last time I
had to use it was over 20 years ago when I was working with the SPARC.
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
On 2026-05-15 19:50, Kalevi Kolttonen wrote:
I have never used AIX.
It had been a progress back then, especially e.g. if compared to
SunOS 4.x; it supported SysV and BSD IPC, and you didn't need to
recompile the kernel if you just wanted to add (or configure) a
kernel module.
We used it in huge (really *huge*) telecommunication projects as
the standard OS (later extended our platforms by HP-UX).
Re Dan's comment; from a user/programmer perspective I didn't see
or noticed any noteworthy oddity.
There was the somewhat unusual memory overcommit issues in AIX,
if I recall correctly, that would cause SIGSEGV's randomly
when available RAM + backing space was exhausted.
It was a long time ago now, and I may not be remembering it
correctly.
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
Funny. I still have Solaris installed on an old hard drive. Last time I
had to use it was over 20 years ago when I was working with the SPARC.
We used to run Solaris on UltraSPARC servers to host email services
like Sendmail and Cyrus IMAPD. They were good machines for the time
when amd64 had not yet been invented. They were eventually replaced
by amd64 hardware and Red Hat Enterprise Linux.
I guess SPARC CPUs are going to die with Solaris.
I did check Fedora 44 man pages and found out later that they are
outdated version 6.13-3. The latest is 6.15 series.
I have never used AIX.
I guess SPARC CPUs are going to die with Solaris.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
On 5/15/2026 2:50 PM, Dan Cross wrote:
Iirc, a long time ago I kind of remember reading something about
overwrite sensitive data multiple times (e.g., the DoD 5220.22-M
standard for storage, though adapted for RAM), sometimes using a pass of
random data followed by a pass of fixed characters, or using a fast
CSPRNG (like ChaCha20) to generate fast pseudo-random bytes so they
don't deplete the physical TRNG.
Yes, that was normal when sanitizing disk platters, to ensure
no residual analog signal existed on the magnetic media that
could be teased out with a sillyscope or other analyzers.
It's not a problem that DRAM has.
On 16/05/2026 00:12, Scott Lurndal wrote:
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
On 5/15/2026 2:50 PM, Dan Cross wrote:
Iirc, a long time ago I kind of remember reading something about
overwrite sensitive data multiple times (e.g., the DoD 5220.22-M
standard for storage, though adapted for RAM), sometimes using a pass of >>> random data followed by a pass of fixed characters, or using a fast
CSPRNG (like ChaCha20) to generate fast pseudo-random bytes so they
don't deplete the physical TRNG.
Yes, that was normal when sanitizing disk platters, to ensure
no residual analog signal existed on the magnetic media that
could be teased out with a sillyscope or other analyzers.
The only lab test of recovering zero overwritten data on a hard disk
managed to recover a small handful of bits, after several weeks of work
with a lab full of top-class equipment.-a The risk of someone reading
data on a disk that was overwritten with zeros is non-existent
- but
that hasn't stopped people making money from selling multi-pass software
to the paranoid.
[...]
On 2026-05-16 11:38, David Brown wrote:
On 16/05/2026 00:12, Scott Lurndal wrote:
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
On 5/15/2026 2:50 PM, Dan Cross wrote:
Iirc, a long time ago I kind of remember reading something about
overwrite sensitive data multiple times (e.g., the DoD 5220.22-M
standard for storage, though adapted for RAM), sometimes using a
pass of
random data followed by a pass of fixed characters, or using a fast
CSPRNG (like ChaCha20) to generate fast pseudo-random bytes so they
don't deplete the physical TRNG.
Yes, that was normal when sanitizing disk platters, to ensure
no residual analog signal existed on the magnetic media that
could be teased out with a sillyscope or other analyzers.
During the early 1990's, working in a systems security department, we
purged the HDDs by triple-pass overwrite (I think zeroes, random, and patterns, or so). It was mandated back then. There were also national standards requiring that. (But the formal details evade my memories.)
The only lab test of recovering zero overwritten data on a hard disk
managed to recover a small handful of bits, after several weeks of
work with a lab full of top-class equipment.-a The risk of someone
reading data on a disk that was overwritten with zeros is non-existent
"a handful of bits" might already compromise security to an unacceptable degree.
Also, it's not about whether it needs weeks or minutes. The cost
of the damage of a leak (or successful attack) is important. There's
sorts of data that are supposed to not be disclosed (even only partly or
only fragmentary) even after decades.
- but that hasn't stopped people making money from selling multi-pass
software to the paranoid.
Spreading FUD is easy. But paying the damages because of sloppiness or assuming false safety may be serious! Also if you delegate financial responsibility to insurances, these companies have their requirements
that you have to follow and means to establish to minimize risks. All
based on scientific knowledge and practical evidence.
On 16/05/2026 13:00, Janis Papanagnou wrote:
On 2026-05-16 11:38, David Brown wrote:
On 16/05/2026 00:12, Scott Lurndal wrote:
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
Iirc, a long time ago I kind of remember reading something about
overwrite sensitive data multiple times (e.g., the DoD 5220.22-M
standard for storage, though adapted for RAM), sometimes using a
pass of
random data followed by a pass of fixed characters, or using a fast
CSPRNG (like ChaCha20) to generate fast pseudo-random bytes so they
don't deplete the physical TRNG.
Yes, that was normal when sanitizing disk platters, to ensure
no residual analog signal existed on the magnetic media that
could be teased out with a sillyscope or other analyzers.
During the early 1990's, working in a systems security department, we
purged the HDDs by triple-pass overwrite (I think zeroes, random, and
patterns, or so). It was mandated back then. There were also national
standards requiring that. (But the formal details evade my memories.)
Yes, there have been all sorts of standards by all sorts of groups about >what needed to be done to "securely" erase disks. Some of these were >completely pointless, like re-writing more than once - anything that
wasn't wiped the first time, such as redundant sectors or sectors marked >"bad", would not be affected by additional writes. Some procedures were
not particularly good - a lot of magnet-based wipes were not very
effective, and there are companies that specialise in reading data from >physically damaged disks.
The only lab test of recovering zero overwritten data on a hard disk
managed to recover a small handful of bits, after several weeks of
work with a lab full of top-class equipment.-a The risk of someone
reading data on a disk that was overwritten with zeros is non-existent
"a handful of bits" might already compromise security to an unacceptable
degree.
No. A very large handful of very specifically chosen bits might reveal
a tiny bit of the "we attack at dawn" secret. A dozen bits scattered at >random across a 4 KB sector (I don't remember the size of their sample) >reveals nothing.
Also, it's not about whether it needs weeks or minutes. The cost
of the damage of a leak (or successful attack) is important. There's
sorts of data that are supposed to not be disclosed (even only partly or
only fragmentary) even after decades.
Sure.
But reading data from a hard disk block that has been re-written is not
a source of leaked information.
- but that hasn't stopped people making money from selling multi-pass
software to the paranoid.
Spreading FUD is easy. But paying the damages because of sloppiness or
assuming false safety may be serious! Also if you delegate financial
responsibility to insurances, these companies have their requirements
that you have to follow and means to establish to minimize risks. All
based on scientific knowledge and practical evidence.
The point is it was not in any way based on scientific knowledge or >practical evidence. All scientific knowledge and practical evidence >available made it clear that reading an erased bit on a hard disk was
purely hypothetical, and totally implausible in practice.
When someone higher up the food chain - insurance companies, men in
black, etc., - makes rules, then you have to follow them. That does not >mean the rules are at all realistic.
There are all sorts of ways that some amount of data can be recovered
from storage media that people throw away. Using high-tech systems to
read bits that have been written over, is not one of them.
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
Funny. I still have Solaris installed on an old hard drive. Last time I
had to use it was over 20 years ago when I was working with the SPARC.
We used to run Solaris on UltraSPARC servers to host email services
like Sendmail and Cyrus IMAPD. They were good machines for the time
when amd64 had not yet been invented. They were eventually replaced
by amd64 hardware and Red Hat Enterprise Linux.
I guess SPARC CPUs are going to die with Solaris.
In article <10u9m51$u6ms$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
On 16/05/2026 13:00, Janis Papanagnou wrote:
On 2026-05-16 11:38, David Brown wrote:
On 16/05/2026 00:12, Scott Lurndal wrote:
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
Iirc, a long time ago I kind of remember reading something about
overwrite sensitive data multiple times (e.g., the DoD 5220.22-M
standard for storage, though adapted for RAM), sometimes using a
pass of
random data followed by a pass of fixed characters, or using a fast >>>>>> CSPRNG (like ChaCha20) to generate fast pseudo-random bytes so they >>>>>> don't deplete the physical TRNG.
(Just to be clear, I did not write the above text; earlier edits
kinda sorta could be read as if I did, but I've tried to clarify attribution.)
Yes, that was normal when sanitizing disk platters, to ensure
no residual analog signal existed on the magnetic media that
could be teased out with a sillyscope or other analyzers.
During the early 1990's, working in a systems security department, we
purged the HDDs by triple-pass overwrite (I think zeroes, random, and
patterns, or so). It was mandated back then. There were also national
standards requiring that. (But the formal details evade my memories.)
Yes, there have been all sorts of standards by all sorts of groups about
what needed to be done to "securely" erase disks. Some of these were
completely pointless, like re-writing more than once - anything that
wasn't wiped the first time, such as redundant sectors or sectors marked
"bad", would not be affected by additional writes. Some procedures were
not particularly good - a lot of magnet-based wipes were not very
effective, and there are companies that specialise in reading data from
physically damaged disks.
I can't help but feel like this discussion has been overcome by
events in the storage landscape. Spinning rust is pretty old
technology, and storage media have changed. With flash storage,
software at the host-level writing a bunch of bits to the device
may not "overwrite" much of anything: writes from the OS are
most often directed through a translation layer using bits on
device, to spread "wear" across available flash areas. To
effectively "wipe" the device, you really need to get the FTL
involved, which means effectively asking the device's firmware
to do it for you.
If you really want to destroy the data, probably the best thing
to do is incinerate it and reduce it to ash, but that's got its
own problems. Maybe that's appropriate for devices holding
state-level secrets, it's overkill from hiding your diary from
your kid sister.
The only lab test of recovering zero overwritten data on a hard disk
managed to recover a small handful of bits, after several weeks of
work with a lab full of top-class equipment.-a The risk of someone
reading data on a disk that was overwritten with zeros is non-existent
"a handful of bits" might already compromise security to an unacceptable >>> degree.
No. A very large handful of very specifically chosen bits might reveal
a tiny bit of the "we attack at dawn" secret. A dozen bits scattered at
random across a 4 KB sector (I don't remember the size of their sample)
reveals nothing.
You have provided more context than explains your conclusion,
and I more or less agree. But Janus's statement was not wrong
when written. "A handful of bits" _could_ mean, "a fragment of
ASCII text" but if it's really truly just a few random bits
scattered at random, and not making up a larger quantity, then
yeah, that's pretty useless.
Here's a vignette about how small amounts of information _can_
be used to inadvertantly spill "secrets", however. Maybe 20-ish
years ago, when I was working at Google, someone wrote a paper
about storage and presented it at a conference. If I recall
correctly, it was something about how they replaced failed disks
in batches. Anyway, at the time, Google was pretty tight-lipped
about the size of its fleet (much more is known about it now),
and the paper was carefully sanitized to remove exact quantities
of parts, and so forth. But there was a graph that showed some
metric of interest; perhaps failures over time or something like
that. Anyway, after the paper was published, someone outside of
google looked at the graph and said, "well, given the device
manufacturer's predicted MTBF and this graph, we can extrapolate
that they've got on the order of X hard disks...but that's a
huge number that is obviously wrong." Ho ho; they were correct,
to within a factor of two, just two too small. :-)
Also, it's not about whether it needs weeks or minutes. The cost
of the damage of a leak (or successful attack) is important. There's
sorts of data that are supposed to not be disclosed (even only partly or >>> only fragmentary) even after decades.
Sure.
But reading data from a hard disk block that has been re-written is not
a source of leaked information.
- but that hasn't stopped people making money from selling multi-pass
software to the paranoid.
Spreading FUD is easy. But paying the damages because of sloppiness or
assuming false safety may be serious! Also if you delegate financial
responsibility to insurances, these companies have their requirements
that you have to follow and means to establish to minimize risks. All
based on scientific knowledge and practical evidence.
The point is it was not in any way based on scientific knowledge or
practical evidence. All scientific knowledge and practical evidence
available made it clear that reading an erased bit on a hard disk was
purely hypothetical, and totally implausible in practice.
When someone higher up the food chain - insurance companies, men in
black, etc., - makes rules, then you have to follow them. That does not
mean the rules are at all realistic.
There are all sorts of ways that some amount of data can be recovered
from storage media that people throw away. Using high-tech systems to
read bits that have been written over, is not one of them.
The rules don't always make sense, and are often dated.
I am reminded of the time when the US DoD banned the use of USB
flash drives, due to concerns about supply chain attacks through
auto-loaded Windows drivers. I was in Afghanistan at the time,
and this came up in a Battalion staff meeting; we used computers
for all sorts of stuff, but the government supplied machines
were not great, and there weren't enough of them to go around:
the upshot was that _most_ people resorted to storing data on
USB flash keys out of necessity. This ban obviously caused some consternation, with some senior leaders in the Bn saying, "ok,
but what do we do instead?" The answer was that USB _flash_
drives were banned, but USB _hard disks_ were OK, so use those
(you could buy them on the little PX on our FOB). Listening to
the Battalion XO (a Marine Major) try to explain this was
painful. I, one of the only people with industry experience
(having been called up from the reserves to deploy) just shook
my head.
- Dan C.
(PS: any dumb rule in the military is the result of someone
doing the dumb thing. "Ok Marines, do not tie the corners of
a PONCHO to your arms and legs and try to turn youself into a
HUMAN KITE during the coming Typhoon....Your three buddies
holding the rope tied around your waist will NOT precvent you
from SLAMMING into the deck" [Yes, that happened. No, not me.])
On 16/05/2026 13:00, Janis Papanagnou wrote:
On 2026-05-16 11:38, David Brown wrote:
On 16/05/2026 00:12, Scott Lurndal wrote:
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
On 5/15/2026 2:50 PM, Dan Cross wrote:
Iirc, a long time ago I kind of remember reading something about
overwrite sensitive data multiple times (e.g., the DoD 5220.22-M
standard for storage, though adapted for RAM), sometimes using a
pass of
random data followed by a pass of fixed characters, or using a fast
CSPRNG (like ChaCha20) to generate fast pseudo-random bytes so they
don't deplete the physical TRNG.
Yes, that was normal when sanitizing disk platters, to ensure
no residual analog signal existed on the magnetic media that
could be teased out with a sillyscope or other analyzers.
During the early 1990's, working in a systems security department, we
purged the HDDs by triple-pass overwrite (I think zeroes, random, and
patterns, or so). It was mandated back then. There were also national
standards requiring that. (But the formal details evade my memories.)
Yes, there have been all sorts of standards by all sorts of groups about what needed to be done to "securely" erase disks.-a Some of these were completely pointless, like re-writing more than once - anything that
wasn't wiped the first time, such as redundant sectors or sectors marked "bad", would not be affected by additional writes.-a Some procedures were not particularly good - a lot of magnet-based wipes were not very
effective, and there are companies that specialise in reading data from physically damaged disks.
The only lab test of recovering zero overwritten data on a hard disk
managed to recover a small handful of bits, after several weeks of
work with a lab full of top-class equipment.-a The risk of someone
reading data on a disk that was overwritten with zeros is non-existent
"a handful of bits" might already compromise security to an
unacceptable degree.
No.-a A very large handful of very specifically chosen bits might reveal
a tiny bit of the "we attack at dawn" secret.-a A dozen bits scattered at random across a 4 KB sector (I don't remember the size of their sample) reveals nothing.
Also, it's not about whether it needs weeks or minutes. The cost
of the damage of a leak (or successful attack) is important. There's
sorts of data that are supposed to not be disclosed (even only partly or
only fragmentary) even after decades.
Sure.
But reading data from a hard disk block that has been re-written is not
a source of leaked information.
- but that hasn't stopped people making money from selling multi-pass
software to the paranoid.
Spreading FUD is easy. But paying the damages because of sloppiness or
assuming false safety may be serious! Also if you delegate financial
responsibility to insurances, these companies have their requirements
that you have to follow and means to establish to minimize risks. All
based on scientific knowledge and practical evidence.
The point is it was not in any way based on scientific knowledge or practical evidence.-a All scientific knowledge and practical evidence available made it clear that reading an erased bit on a hard disk was
purely hypothetical, and totally implausible in practice.
When someone higher up the food chain - insurance companies, men in
black, etc., - makes rules, then you have to follow them.-a That does not mean the rules are at all realistic.
There are all sorts of ways that some amount of data can be recovered
from storage media that people throw away.-a Using high-tech systems to
read bits that have been written over, is not one of them.
[...]
If you really want to destroy the data, probably the best thing
to do is incinerate it and reduce it to ash, but that's got its
own problems.
Maybe that's appropriate for devices holding
state-level secrets, it's overkill from hiding your diary from
your kid sister.
[...]
"a handful of bits" might already compromise security to an unacceptable >>> degree.
[...]
On 5/16/2026 7:25 AM, David Brown wrote:We know. But given a hard disk, what percentage of the bits on that
[...]
You don't want any bit/byte leak for say an encryption process wrt the password. If a side channel attacker can gain any of it, its bad.
Have you ever used a program called SpinRite?
Have you ever used a program called SpinRite?
https://www.grc.com/sr/spinrite.htm
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
[76 lines deleted]
Have you ever used a program called SpinRite?
https://www.grc.com/sr/spinrite.htm
Chris, *please* resist the temptation to post every thought and
URL that springs to your mind. If a link is relevant, at least say
something about it. If it isn't (remember, this is comp.lang.c),
then just don't post it. And trim irrelevant context when you post
a followup.
On 16/05/2026 00:12, Scott Lurndal wrote:
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
On 5/15/2026 2:50 PM, Dan Cross wrote:
Iirc, a long time ago I kind of remember reading something about
overwrite sensitive data multiple times (e.g., the DoD 5220.22-M
standard for storage, though adapted for RAM), sometimes using a pass of >>> random data followed by a pass of fixed characters, or using a fast
CSPRNG (like ChaCha20) to generate fast pseudo-random bytes so they
don't deplete the physical TRNG.
Yes, that was normal when sanitizing disk platters, to ensure
no residual analog signal existed on the magnetic media that
could be teased out with a sillyscope or other analyzers.
The only lab test of recovering zero overwritten data on a hard disk
managed to recover a small handful of bits, after several weeks of work
with a lab full of top-class equipment. The risk of someone reading
data on a disk that was overwritten with zeros is non-existent - but
that hasn't stopped people making money from selling multi-pass software
to the paranoid.
David Brown <david.brown@hesbynett.no> writes:
On 16/05/2026 00:12, Scott Lurndal wrote:
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
On 5/15/2026 2:50 PM, Dan Cross wrote:
Iirc, a long time ago I kind of remember reading something about
overwrite sensitive data multiple times (e.g., the DoD 5220.22-M
standard for storage, though adapted for RAM), sometimes using a pass of >>>> random data followed by a pass of fixed characters, or using a fast
CSPRNG (like ChaCha20) to generate fast pseudo-random bytes so they
don't deplete the physical TRNG.
Yes, that was normal when sanitizing disk platters, to ensure
no residual analog signal existed on the magnetic media that
could be teased out with a sillyscope or other analyzers.
The only lab test of recovering zero overwritten data on a hard disk
managed to recover a small handful of bits, after several weeks of work
with a lab full of top-class equipment. The risk of someone reading
data on a disk that was overwritten with zeros is non-existent - but
that hasn't stopped people making money from selling multi-pass software
to the paranoid.
Al Kossow posted a link to a video describing recovery of the Unix v4
data from 9-track that's quite interesting; while the tape hadn't
been overwritten, it had degraded to the point where it wasn't
readable by a 9-track drive, so they used signal processing on the
analog data from each track to recover the data.
https://www.youtube.com/watch?v=-xlq_MPWNKk
Al Kossow posted a link to a video describing recovery of the Unix v4
data from 9-track that's quite interesting; while the tape hadn't
been overwritten, it had degraded to the point where it wasn't
readable by a 9-track drive, so they used signal processing on the
analog data from each track to recover the data.
On 17/05/2026 21:19, Scott Lurndal wrote:
David Brown <david.brown@hesbynett.no> writes:
On 16/05/2026 00:12, Scott Lurndal wrote:
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
On 5/15/2026 2:50 PM, Dan Cross wrote:
Iirc, a long time ago I kind of remember reading something about
overwrite sensitive data multiple times (e.g., the DoD 5220.22-M
standard for storage, though adapted for RAM), sometimes using a pass of >>>>> random data followed by a pass of fixed characters, or using a fast
CSPRNG (like ChaCha20) to generate fast pseudo-random bytes so they
don't deplete the physical TRNG.
Yes, that was normal when sanitizing disk platters, to ensure
no residual analog signal existed on the magnetic media that
could be teased out with a sillyscope or other analyzers.
The only lab test of recovering zero overwritten data on a hard disk
managed to recover a small handful of bits, after several weeks of work
with a lab full of top-class equipment. The risk of someone reading
data on a disk that was overwritten with zeros is non-existent - but
that hasn't stopped people making money from selling multi-pass software >>> to the paranoid.
Al Kossow posted a link to a video describing recovery of the Unix v4
data from 9-track that's quite interesting; while the tape hadn't
been overwritten, it had degraded to the point where it wasn't
readable by a 9-track drive, so they used signal processing on the
analog data from each track to recover the data.
https://www.youtube.com/watch?v=-xlq_MPWNKk
Recovering from damaged tape or disk is a different matter than
recovering data that has been erased or overwritten with zeros. I've
read of some very impressive recovery of data from hard disks that have
been in fires or otherwise physically damaged.
In article <10ud6b2$1tjoi$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
On 17/05/2026 21:19, Scott Lurndal wrote:
David Brown <david.brown@hesbynett.no> writes:
On 16/05/2026 00:12, Scott Lurndal wrote:
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
On 5/15/2026 2:50 PM, Dan Cross wrote:
Iirc, a long time ago I kind of remember reading something about
overwrite sensitive data multiple times (e.g., the DoD 5220.22-M
standard for storage, though adapted for RAM), sometimes using a pass of >>>>>> random data followed by a pass of fixed characters, or using a fast >>>>>> CSPRNG (like ChaCha20) to generate fast pseudo-random bytes so they >>>>>> don't deplete the physical TRNG.
Yes, that was normal when sanitizing disk platters, to ensure
no residual analog signal existed on the magnetic media that
could be teased out with a sillyscope or other analyzers.
The only lab test of recovering zero overwritten data on a hard disk
managed to recover a small handful of bits, after several weeks of work >>>> with a lab full of top-class equipment. The risk of someone reading
data on a disk that was overwritten with zeros is non-existent - but
that hasn't stopped people making money from selling multi-pass software >>>> to the paranoid.
Al Kossow posted a link to a video describing recovery of the Unix v4
data from 9-track that's quite interesting; while the tape hadn't
been overwritten, it had degraded to the point where it wasn't
readable by a 9-track drive, so they used signal processing on the
analog data from each track to recover the data.
https://www.youtube.com/watch?v=-xlq_MPWNKk
Recovering from damaged tape or disk is a different matter than
recovering data that has been erased or overwritten with zeros. I've
read of some very impressive recovery of data from hard disks that have
been in fires or otherwise physically damaged.
I think one has to make a set of reasonable assumptions about
a particular scenario to actually have a useful discussion.
Let's propose the following scenario: a company's proprietary
payroll information is on a device that is overwritten by a
computer writing zeros to that device. How much should one
worry about a well-equipped actor recovering data from that
device?
Is it a disk? Yeah, I'm not gonna lose much sleep over that.
An SSD? Large chunks of that data is still on the device; I'd
worry.
A tape? I think somewhere in the middle; probably closer to the
disk, but I'd be worried about echos in between bits and weird
stuff like that.
Scott Lurndal <scott@slp53.sl.home> wrote:
Al Kossow posted a link to a video describing recovery of the Unix v4
data from 9-track that's quite interesting; while the tape hadn't
been overwritten, it had degraded to the point where it wasn't
readable by a 9-track drive, so they used signal processing on the
analog data from each track to recover the data.
It was a great effort to recover the data. I actually tried V4
on simh for a brief while just to experience an early UNIX.
Speaking of tapes, it is quite surprising how old 8-bit games
still load from 40-year-old c-cassettes.
The biggest risk, IME, is that old tapes are somewhat brittle and break
when playing them back.
Commercially produced games tapes were written with very high recording levels (if that's the correct term) - the distinction between a 0 and a
1 was about as large as the magnetic domains on the tape could handle,
and spread across as wide a stripe as possible.-a So they can be readable even after a fair bit of signal degradation.
It's much more of a gamble when you are trying to read copies of copies
of copies made via a chain of friends and questionable quality audio cassette equipment.-a (Though I'm sure lab equipment could read them fine.)
(Not that /I/ ever made unlicensed copies of commercial games as a kid - it's just something I heard other people did :-) )
On 17/05/2026 22:01, Kalevi Kolttonen wrote:
Scott Lurndal <scott@slp53.sl.home> wrote:
Al Kossow posted a link to a video describing recovery of the Unix v4
data from 9-track that's quite interesting; while the tape hadn't
been overwritten, it had degraded to the point where it wasn't
readable by a 9-track drive, so they used signal processing on the
analog data from each track to recover the data.
It was a great effort to recover the data. I actually tried V4
on simh for a brief while just to experience an early UNIX.
Speaking of tapes, it is quite surprising how old 8-bit games
still load from 40-year-old c-cassettes.
The biggest risk, IME, is that old tapes are somewhat brittle and break
when playing them back.
Commercially produced games tapes were written with very high recording levels (if that's the correct term) - the distinction between a 0 and a
1 was about as large as the magnetic domains on the tape could handle,
and spread across as wide a stripe as possible. So they can be readable even after a fair bit of signal degradation.
It's much more of a gamble when you are trying to read copies of copies
of copies made via a chain of friends and questionable quality audio cassette equipment. (Though I'm sure lab equipment could read them fine.)
(Not that /I/ ever made unlicensed copies of commercial games as a kid - it's just something I heard other people did :-) )
David Brown <david.brown@hesbynett.no> wrote:
On 17/05/2026 22:01, Kalevi Kolttonen wrote:
Scott Lurndal <scott@slp53.sl.home> wrote:
Al Kossow posted a link to a video describing recovery of the Unix v4
data from 9-track that's quite interesting; while the tape hadn't
been overwritten, it had degraded to the point where it wasn't
readable by a 9-track drive, so they used signal processing on the
analog data from each track to recover the data.
It was a great effort to recover the data. I actually tried V4
on simh for a brief while just to experience an early UNIX.
Speaking of tapes, it is quite surprising how old 8-bit games
still load from 40-year-old c-cassettes.
The biggest risk, IME, is that old tapes are somewhat brittle and break
when playing them back.
You are probably right. I have had that problem with a few audio
c-cassettes. I bought Santana Welcome c-cassette that was released
in 1973 and the tape broke during the first play.
Commercially produced games tapes were written with very high recording
levels (if that's the correct term) - the distinction between a 0 and a
1 was about as large as the magnetic domains on the tape could handle,
and spread across as wide a stripe as possible. So they can be readable
even after a fair bit of signal degradation.
I did not know that.
It's much more of a gamble when you are trying to read copies of copies
of copies made via a chain of friends and questionable quality audio
cassette equipment. (Though I'm sure lab equipment could read them fine.) >>
(Not that /I/ ever made unlicensed copies of commercial games as a kid -
it's just something I heard other people did :-) )
Are you kidding or being honest here?
I had a C64 and all my friends
who had it too, had lots of pirate turbo tapes. I had them too, but
also about 10 original tapes. The original games were quite expensive
and the floppy versions even more so.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 65 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 01:06:38 |
| Calls: | 862 |
| Files: | 1,311 |
| D/L today: |
10 files (20,373K bytes) |
| Messages: | 264,187 |