Git Product home page Git Product logo

rvkrypto-fips's People

Contributors

mjosaarinen avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

rvkrypto-fips's Issues

Compilation Error

When I am cross-compiling, the following error occurs. Do you have any suggestions?
image

Error while cross compiling

Have installed RISCV toolchain from https://github.com/riscv/riscv-crypto/ with the arch of RISCV64. However, the cross compiling (make -f rv64.mk) showed error "unsupported extension 'zkn'".

The detailed log is shown as below.

% make -f rv64.mk
/path/to/build/riscv64-unknown-elf/bin/spike --isa=rv64imac_zkn_zks_zkr /path/to/build/riscv64-unknown-elf/riscv64-unknown-elf/bin/pk ./xtest
error: bad --isa option 'rv64imac_zkn_zks_zkr'. unsupported extension 'zkn'
make: *** [rv64.mk:25: spike64] Error 255

Any suggestion would be much appreciated.

Bitmanip v0.93 intrinsics?

Some code here relies on (pretty bad) rvintrin.h file from bitmanip v0.93.
This is not how rvintrin.h should look like.
See: riscv/riscv-bitmanip#29 (comment)
"the idea is put in all intrinsics in one file, and conditionalize them based on enabled extensions, similar to x86intrin.h."

Here is how rvintrin.h may look like:

/****************************************************************************
 *
 *  RISC-V intrinsics top-level header file.
 *
 *  Permission to use, copy, modify, and/or distribute this software for any
 *  purpose with or without fee is hereby granted, provided that the above
 *  copyright notice and this permission notice appear in all copies.
 *
 *  THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
 *  WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
 *  MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
 *  ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
 *  WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
 *  ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
 *  OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 *
 ****************************************************************************/

#ifndef __RVINTRIN_H__
#define __RVINTRIN_H__

// Bitmanip intrinsics (Zba, Zbb, Zbc, Zbs) are not implemented.
// Bitmanip spec ver. 1.0.0. does not require any of them.
// There are some reasons not to implement them:
//   > Redundantness: all these functions have their machine descriptions --
//     because they are simple enough for compiler to emit them.
//   > Readability: e.g. a | ~b is more readable than __rv_orn(a, b).
//   > Robustness: no unexpected type cast issues / redundant warnings.

#include "rvzkndintrin.h"
#include "rvzkneintrin.h"
...

#endif // __RVINTRIN_H__

Lower-level files should neither rely on depricated options nor require anything implicitly.
This is how rvzkndintrin.h may look like:

/****************************************************************************
 *
 *  RISC-V intrinsics header file with AES decoding intrinsics.
 *
 *  Permission to use, copy, modify, and/or distribute this software for any
 *  purpose with or without fee is hereby granted, provided that the above
 *  copyright notice and this permission notice appear in all copies.
 *
 *  THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
 *  WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
 *  MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
 *  ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
 *  WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
 *  ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
 *  OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 *
 ****************************************************************************/

#ifndef __RVZKNDINTRIN_H__
#define __RVZKNDINTRIN_H__


#ifndef __RVINTRIN_H__
#error Never use <rvzkndintrin.h> directly; include <rvintrin.h> instead.
#endif

// if you rely on any other intrinsic file, you may either include it explicitly or generate some error
#ifndef __RVZBKBINTRIN_H__
#error <rvzbkbintrin.h> must be included before <rvzkndintrin.h>.
#endif
// but never rely on other extension's intrinsics.

As there is no upstream file with bitmanip intrinsics, do not heir its bad habits, i.e.:

  • Use __rv_ as the only prefix for intrinsic functions;
  • Do not use RVINTRINEMULATE or other non-spec defines. Compiler-defined __riscv_zknd (and similar) is enough for compile-time discovery of enabled extensions;
  • Do not use long. Use [u]int(32,64,XLEN)_t instead.

[scala crypto] parameter type of sm3 intrinsic

Hi, all

We notice that the definition of intrinsic for sm3 is

static inline long _rv_sm3p1(long rs1)
	{ return _RVK_INTRIN_IMPL(sm3p1)(rs1); }				//	SM3P1

while the operation defined in the specification is
image

We found that sm3p1 only use low 32 bit of rs1 in both rv32 and rv64, but the type of parameter rs1 in intrinsic is long.

so, what about we change the type of rs1 into uint32_t?

PQC support

Bonjour, Do you have any planned support for CRSTALS Kyber or any other PQ algorithm in RISC-V simulation?

Question about the use of long instead of int32_t in some intrinsic definitions

While reading the current intrinsic definition, I noticed that some functions are using long type instead of a fixed length type like int32_t as many other occurrences do. An example is static inline long _rv_sha256sum1(long rs1) here.

Thus, I am wondering whether are there some special reasons for this difference? If not, would changing it into int32_t a better option? The reason is, the function above uses _rv32_ror intrinsic from B extension whose function signature uses int32_t type and this change could increase the clarity of the type and may make it more uniformed across extensions and the file itself. Thanks in advance.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.