zyantific/zycore-c

Internal library providing platform independent types, macros and a fallback for environments without LibC.

zycore-c's Issues

Implement more basic containers

• (Linked)List
• Queue
• Stack
• HashTable
• HashSet
• Deque

add support for riscv64

Hi,
I am porting the package to riscv64 arch on Debian, the build is ok and it pass its test suite from my local build log. The patch is here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1015787;filename=zycore-c-add-support-for-riscv64.patch;msg=5

And the reportbug is here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015787

If there is any issue please let me know, thanks

Implement LRU cache

Implement a simple LRU cache container based on a linked list (could support multiple caching strategies in the future).

Support in linux kernel 5.4

Hi :)
I'm using your ZYDIS in my LKM and therefore zycore-c submodule, and since kernel 5.4 (using gcc >7), I'm receiving the following error:

./include/linux/compiler_attributes.h:200:41: error: expected ‘)’ before ‘__attribute__’
  200 | # define fallthrough                    __attribute__((__fallthrough__))
      |                                         ^~~~~~~~~~~~~
/home/chameleon/mlp.main/mlp.kernel/main-module/include/Zycore/Defines.h:246:45: note: in expansion of macro ‘fallthrough’
  246 | #   define ZYAN_FALLTHROUGH __attribute__ ((fallthrough))
      |                                             ^~~~~~~~~~~
/home/chameleon/mlp.main/mlp.kernel/main-module/repos/zydis/src/Decoder.c:2617:17: note: in expansion of macro ‘ZYAN_FALLTHROUGH’
 2617 |                 ZYAN_FALLTHROUGH;
      |                 ^~~~~~~~~~~~~~~~

Now, after some research it seems that the problem was due the fact that in kernel 5.4 this commit inserted a fallthrough define.
the same issue was at vbox
And after testing, the solution was replace the

#   define ZYAN_FALLTHROUGH __attribute__ ((fallthrough))

to

#   define ZYAN_FALLTHROUGH __attribute__ ((__fallthrough__))

Can you apply this change?

Many thanks

Coverity complains about likely NPE in zycore

I just pulled a recent zydis (4d4fe4c293c5438f32688b14b29017ae3f48369e) into Firefox. We run Coverity in the background on everything, and Coverity throws up a potential problem in zycore, the report is here: https://phabricator.services.mozilla.com/D59915#inline-364191. I have not tried to substantiate whether this is an actual problem, and we don't ship zydis in release builds so it's not a security issue for us, but perhaps you want to look into it.

Support running on big-endian architectures

Hi, it seems that the VectorTest.Destructor test is failing on Debian's powerpc and powerpc64 architectures :/

I have not looked into the issue, but I guess that this might be related to ppc's big endianness.

You can find the logs for both here:

• https://buildd.debian.org/status/logs.php?pkg=zycore-c&arch=powerpc
• https://buildd.debian.org/status/logs.php?pkg=zycore-c&arch=ppc64

More generally, the build logs for all architectures are here: https://buildd.debian.org/status/logs.php?pkg=zycore-c

typo in ifdef in Types.h

I ran into a compile error trying to compile zydis on an old linux machine. I think the reason is the typo fixed by the diff below. The typo causes even regular linux compiles to use compiler-builtin versions of types instead of the stdint versions. (For some reason, my older machine doesn't have __UINT8_TYPE__ variants, despite using gcc-9.2, so I actually need to use the stdint versions.)

diff --git a/include/Zycore/Types.h b/include/Zycore/Types.h
index b844d1d..7e7e934 100644
--- a/include/Zycore/Types.h
+++ b/include/Zycore/Types.h
@@ -39,7 +39,7 @@
 /* ============================================================================================== */
 
 #if !defined(ZYAN_NO_LIBC) && \
-    (!defined(ZYAN_MSVC) && defined(ZYAN_KERNEL)) // The WDK LibC lacks stdint.h.
+    !(defined(ZYAN_MSVC) && defined(ZYAN_KERNEL)) // The WDK LibC lacks stdint.h.
     // If is LibC present, we use stdint types.
 #   include <stdint.h>
 #   include <stddef.h>

WDK compatibility

At the moment Zycore does not build when trying to compile as a Windows Kernel Driver project using the WDK.

• Use the ZYAN_KERNEL macro to detect kernel mode in the Zycore/API/* includes and disable compilation of affected code that uses Windows.h
• Later: Replace the APIs from Windows.h with native APIs from the WDK

Potential security issue

Hey there!

I belong to an open source security research community, and a member (@geeknik) has found an issue, but doesn’t know the best way to disclose it.

If not a hassle, might you kindly add a SECURITY.md file with an email, or another contact method? GitHub recommends this best practice to ensure security issues are responsibly disclosed, and it would serve as a simple instruction for security researchers in the future.

Thank you for your consideration, and I look forward to hearing from you!

(cc @huntr-helper)

Tag/release zycore-c?

Hi - I am building zydis, which depends on zycore-c. The internal packaging tool I'm using works nicely when there are versioned releases of the source code - in particular, where there are "official" tagged versioned releases, which github.com will offer as tar.gz (otherwise, I have to create my own versioning scheme). Could you provide tags/releases for zycore-c, similar to what is setup for zydis's releases?

thanks!

Warning when building with clang-cl

When building zydis with clang-cl on windows, it produces the following warning:
clang-cl : warning : unknown argument ignored in clang-cl: '-std=c99' [-Wunknown-argument]

This is because clang-cl expects a MSVC-like command line. I've tracked this down to the zyan_set_common_flags in zycore's CMakeLists.txt file here, where it checks if CMAKE_C_COMPILER_ID is Clang.

I worked around this locally by also checking if the semi-undocumented CMAKE_CXX_SIMULATE_ID is set to MSVC.

Replacing:
"${CMAKE_C_COMPILER_ID}" STREQUAL "Clang" OR
with:
"${CMAKE_C_COMPILER_ID}" STREQUAL "Clang" AND (NOT "${CMAKE_CXX_SIMULATE_ID}" STREQUAL "MSVC") OR

However, I'm not familiar enough with CMake to make full PR that I would trust to not break other things.

Inconsistent naming scheme (`ZYCORE_` vs `ZYAN_`)

Defines, include-guards and CMake options don't have a consistent naming scheme right now. We should change that.

Please consider tagging releases

Hi, I know Zycore is mainly used as an internal library of some Zyantific projects (like Zydis), so working with releases for this library is not really that useful to you, but while maintaining the Zydis Debian package (that is now in Debian Unstable :D) I noticed that Zydis requires some features not present in Zycore 1.0.0, so I have to manually backport every change you make to Zycore that is also used in Zydis.

This is quite laborious and error prone, since with these backports I just aim at making the compiler happy - some behavioral changes and security fixes will certainly be missed, and Debian could end up having a Zydis library that depends on a buggy/unsafe Zycore, resulting in a buggy/unsafe Zydis.

Debian packages should be built from stable releases, so I can't just package the latest master (well, I could, but it is highly discouraged, and creates some issues like the impossibility of applying security fixes to packages in Debian stable, as they can't receive feature updates).

While certainly handy, I'm not asking for API or ABI stability, just some way to make sure that Zydis can be safely built from a tagged release - downstream and upstream should always collaborate :)

Build error ZycoreExportConfig.h

Trying to build updated https://github.com/zyantific/zydis/tree/4aaf4e09a1ea3b197ef3a114b92acbf6237b7beb with included https://github.com/zyantific/zycore-c/tree/688e56a85acd0079d91de7a8a0be1647f5c4f3bc as dependency and get compile error:

Cannot open include file: 'ZycoreExportConfig.h': No such file or directory
#include <ZycoreExportConfig.h>
Zydis	x:\zydis\dependencies\zycore\include\zycore\string.h	35

CMake Error

When this is compiled with CMake 3.13.1 from an Amazon Linux 2 installation, it throws the error:

CMake Error at CMakeLists.txt:209 (install):
  install TARGETS given no ARCHIVE DESTINATION for static library target
  "Zycore".

I can't find any other version of CMake or distribution on which this happens.

zycore doesn't build on NetBSD

When building zycore on NetBSD it is said to be an unsupported platform.
There are two ways to fix this either do as FreeBSD and check for NetBSD
or extend the unix check and check for unix and not just __unix .
I will submit a patch for the latter.

Don't use floating-point types to provide kernel-mode support

FPU usage is not safe for kernel-mode.