SyZero and crypto #38
Нет назначенных лиц
devnexen
devnexen
Уведомления
Срок выполнения
Срок выполнения не установлен.
Зависимости
Зависимостей нет.
Ссылка: aerscript/Aer#38
Ссылка в новой задаче
Block a user
Удалить ветку «%!s()»
Удаление ветки необратимо. Несмотря на то, что удаленная ветка может просуществовать некоторое время перед тем, как она будет окончательно удалена, это действие НЕВОЗМОЖНО отменить в большинстве случаев. Продолжить?
More a question actually ... it is used as well to clear the MD5 context.
Would be interesting to know if SyZero can be possibly optimised by aggressive optimisation by the compiler thus not guarantying it. In other hash algo implementations before memset was used but then SecureZero* or explicit_bzero replaced these.
That is something I did myself for php, I implemented explicit_bzero for musl for the next release for this kind of purpose too.
In fact SecureZero* functions from Win32 API and explicit_bzero/explicit_memset (NetBSD flavor if I recall) had been created to guarantee the address is gueninely cleared regardless of the code consumer compiler optimisation used(basically either adding a memory barrier like musl or a particular compiler settings different from the rest of the libc like openbsd does for example ...).
Do not know if I am clear enough though :-)
Ah the question is SyZero able to guarantee to clear the context regardless of the optimisation ? :-)
When I look at PH7 as overall and the amount of bugs as well as Symisc Systems approach, I doubt it can guarantee anything. :)
For example SyStringInitFromBuf() simply takes the char* and int and stores into a structure. The string can be of any length, and any length can be specifies. However, the length is not checked anywhere and I already several times came across SyString showing some trash after the requested string. Symisc resolved that by adding %z to their string formating functions. But if you want to convert SyString to char*, you should be careful.
Ok ... something to keep in mind even though not the highest priority at the moment.
Found odd too first time I read it unless it is to avoid some compiler optimisations ?
No idea, but its not first time I see something like that in PH7. There are more of them. In this particular case, the whole loop could be even replaced by:
I have contacted with Symisc. They told me, that's an old manual optimisation technique targeting Intel CPUs and was inspired from the qmail source tree. Basically if you unloop your code and duplicate it four times, you can get non insignificant speed boost on some old x86 architecture. They also told me, they didnt want to use memset, as they wanted a minimal dependency with libc.
Nova days, I think we can rely on compiler optimisations.
To sum up, I think SyZero is currently able to guarantee to clear the context regardless of the optimisation. @devnexen: Do we need anything else, or can we close this ticket?
Nothing to add.