Re: explicit_bzero vs. alternatives
>> >> WG14 has reserved some identifiers for future extensions of the >> standard. E.g. those starting with mem_. Naturally, others then choose >> identifiers that do not conflict with this, such as explicit_bzero. But >> if that name is then used in the standard unchanged, it would mean that >> future extensions only use exactly those identifiers not reserved for >> future extensions. >> >> Philipp > > But if we would use reserved identifiers, we would be castigated for that. > > Don't you see your process does not work? > > -Otto > This is not the only aspect broken about reserved identifiers. C2X will introduce thousands of new functions (nearly all of them for floating-point), many with names not previously reserved. C++ has their namespaces, but there is no such solution for C. I don't know how to solve this problem, and I don't think there will be a solution anytime soon. In the end, I wouldn't be surprised, if WG14 just goes with one of the existing names, not caring about reserved identifiers. But introducing a new name, from the reserved identifiers, for functionality, for which implementation experience already exists using a non-reserved name, still looks like a legitimate appoach to me. Philipp
Re: explicit_bzero vs. alternatives
Am 11.08.20 um 02:52 schrieb Theo de Raadt: > > But no, WG14 are the lords and masters in the high castle, and now 6 > years after the ship sailed something Must Be Done, it must look like > They Solved The Problem, and so they'll create an incompatible API. > > Will they be heroes? No, not really. Changing the name is villainous. > The purpose of WG14 is to codify existing practise, not to invent (see N2086 http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2086.htm, 8. and 13.). WG14 has reserved some identifiers for future extensions of the standard. E.g. those starting with mem_. Naturally, others then choose identifiers that do not conflict with this, such as explicit_bzero. But if that name is then used in the standard unchanged, it would mean that future extensions only use exactly those identifiers not reserved for future extensions. Philipp
Re: explicit_bzero vs. alternatives
Am 10.08.20 um 17:00 schrieb Theo de Raadt: > Philipp Klaus Krause wrote: > >> OpenBSD has the explicit_bzero function to reliably (i.e. even if not >> observable in the C abstract machine) overwrite memory with zeroes. >> >> WG14 is currently considering adding similar functionality to C2X. > > Then perhaps in the interests of the public they should use the same > name, but I suspect they won't. The functionality (i.e. some way to reliably overwrite memory) already exists under different names: explicit_bzero in OpenBSD, memzero_explicit in Linux, memset_s in the optional Annex K of the C standard, explicit_memset in NetBSD, SecureZeroMemory in Windows etc. A problem with the explicit_bzero name is that it is not an identifier reserved for future extensions of the C standard, unlike identifiers starting with mem. > >> Considered options include: >> >> * A function like explicit_bzero or memset_explicit, that overwrites the >> memory with a known value. > > We have never needed any value other than zero. Thanks. I assume this will help WG14. > >> * A function like memclear, that overwrites the memory in an >> implementation-defined manner, possibly using random data. > > This option is pretty laughable, because the compiler has no way to > collect random data. Their is nothing portable the compiler can call > to get the random data. I've personally worked on making this possible > for more than a decade, and it is still not all there. This option under the name secure_clear apparently is the one preferred by WG21, the C++ comittee. Philipp
explicit_bzero vs. alternatives
OpenBSD has the explicit_bzero function to reliably (i.e. even if not observable in the C abstract machine) overwrite memory with zeroes. WG14 is currently considering adding similar functionality to C2X. Considered options include: * A function like explicit_bzero or memset_explicit, that overwrites the memory with a known value. * A function like memclear, that overwrites the memory in an implementation-defined manner, possibly using random data. Is there a rationale why OpenBSD went with their explicit_bzero design? Were alternatives considered and rejected? Philipp
Any plans to support newer Loongson-based systems?
According to https://www.openbsd.org/loongson.html only some old Loongson-based systems are supported. Are there any plans to support the more recent Loongson 3A3000- or the current 3A4000-based systems? I do not know where OpenBSD MIPS developers are located. Apparently the Loongson-based systems are not easily available outside China, but it seems Chinese merchants are selling 3A4000+mainboard bundles for somewhat less than 500 €, though I do not know if any of them ship outside China. Philipp
