/* * ECDH params to be used with kpp API * * Copyright (c) 2016, Intel Corporation * Authors: Salvatore Benedetto * * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the Free * Software Foundation; either version 2 of the License, or (at your option) * any later version. * */ #ifndef _CRYPTO_ECDH_ #define _CRYPTO_ECDH_ /** * DOC: ECDH Helper Functions * * To use ECDH with the KPP cipher API, the following data structure and * functions should be used. * * The ECC curves known to the ECDH implementation are specified in this * header file. * * To use ECDH with KPP, the following functions should be used to operate on * an ECDH private key. The packet private key that can be set with * the KPP API function call of crypto_kpp_set_secret. */ /* Curves IDs */ #define ECC_CURVE_NIST_P192 0x0001 #define ECC_CURVE_NIST_P256 0x0002 /** * struct ecdh - define an ECDH private key * * @curve_id: ECC curve the key is based on. * @key: Private ECDH key * @key_size: Size of the private ECDH key */ struct ecdh { unsigned short curve_id; char *key; unsigned short key_size; }; /** * crypto_ecdh_key_len() - Obtain the size of the private ECDH key * @params: private ECDH key * * This function returns the packet ECDH key size. A caller can use that * with the provided ECDH private key reference to obtain the required * memory size to hold a packet key. * * Return: size of the key in bytes */ int crypto_ecdh_key_len(const struct ecdh *params); /** * crypto_ecdh_encode_key() - encode the private key * @buf: Buffer allocated by the caller to hold the packet ECDH * private key. The buffer should be at least crypto_ecdh_key_len * bytes in size. * @len: Length of the packet private key buffer * @p: Buffer with the caller-specified private key * * The ECDH implementations operate on a packet representation of the private * key. * * Return: -EINVAL if buffer has insufficient size, 0 on success */ int crypto_ecdh_encode_key(char *buf, unsigned int len, const struct ecdh *p); /** * crypto_ecdh_decode_key() - decode a private key * @buf: Buffer holding a packet key that should be decoded * @len: Lenth of the packet private key buffer * @p: Buffer allocated by the caller that is filled with the * unpacket ECDH private key. * * The unpacking obtains the private key by pointing @p to the correct location * in @buf. Thus, both pointers refer to the same memory. * * Return: -EINVAL if buffer has insufficient size, 0 on success */ int crypto_ecdh_decode_key(const char *buf, unsigned int len, struct ecdh *p); #endif >committer

path: root/include/asm-generic

Age	Commit message (Collapse)	Author	Files	Lines
2017-02-03	modversions: treat symbol CRCs as 32 bit quantities	Ard Biesheuvel	1	-5/+6
	The modversion symbol CRCs are emitted as ELF symbols, which allows us to easily populate the kcrctab sections by relying on the linker to associate each kcrctab slot with the correct value. This has a couple of downsides: - Given that the CRCs are treated as memory addresses, we waste 4 bytes for each CRC on 64 bit architectures, - On architectures that support runtime relocation, a R_<arch>_RELATIVE relocation entry is emitted for each CRC value, which identifies it as a quantity that requires fixing up based on the actual runtime load offset of the kernel. This results in corrupted CRCs unless we explicitly undo the fixup (and this is currently being handled in the core module code) - Such runtime relocation entries take up 24 bytes of __init space each, resulting in a x8 overhead in [uncompressed] kernel size for CRCs. Switching to explicit 32 bit values on 64 bit architectures fixes most of these issues, given that 32 bit values are not treated as quantities that require fixing up based on the actual runtime load offset. Note that on some ELF64 architectures [such as PPC64], these 32-bit values are still emitted as [absolute] runtime relocatable quantities, even if the value resolves to a build time constant. Since relative relocations are always resolved at build time, this patch enables MODULE_REL_CRCS on powerpc when CONFIG_RELOCATABLE=y, which turns the absolute CRC references into relative references into .rodata where the actual CRC value is stored. So redefine all CRC fields and variables as u32, and redefine the __CRC_SYMBOL() macro for 64 bit builds to emit the CRC reference using inline assembler (which is necessary since 64-bit C code cannot use 32-bit types to hold memory addresses, even if they are ultimately resolved using values that do not exceed 0xffffffff). To avoid potential problems with legacy 32-bit architectures using legacy toolchains, the equivalent C definition of the kcrctab entry is retained for 32-bit architectures. Note that this mostly reverts commit d4703aefdbc8 ("module: handle ppc64 relocating kcrctabs when CONFIG_RELOCATABLE=y") Acked-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>