/* * Diffie-Hellman secret to be used with kpp API along with helper functions * * 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_DH_ #define _CRYPTO_DH_ /** * DOC: DH Helper Functions * * To use DH with the KPP cipher API, the following data structure and * functions should be used. * * To use DH with KPP, the following functions should be used to operate on * a DH private key. The packet private key that can be set with * the KPP API function call of crypto_kpp_set_secret. */ /** * struct dh - define a DH private key * * @key: Private DH key * @p: Diffie-Hellman parameter P * @g: Diffie-Hellman generator G * @key_size: Size of the private DH key * @p_size: Size of DH parameter P * @g_size: Size of DH generator G */ struct dh { void *key; void *p; void *g; unsigned int key_size; unsigned int p_size; unsigned int g_size; }; /** * crypto_dh_key_len() - Obtain the size of the private DH key * @params: private DH key * * This function returns the packet DH key size. A caller can use that * with the provided DH private key reference to obtain the required * memory size to hold a packet key. * * Return: size of the key in bytes */ int crypto_dh_key_len(const struct dh *params); /** * crypto_dh_encode_key() - encode the private key * @buf: Buffer allocated by the caller to hold the packet DH * private key. The buffer should be at least crypto_dh_key_len * bytes in size. * @len: Length of the packet private key buffer * @params: Buffer with the caller-specified private key * * The DH implementations operate on a packet representation of the private * key. * * Return: -EINVAL if buffer has insufficient size, 0 on success */ int crypto_dh_encode_key(char *buf, unsigned int len, const struct dh *params); /** * crypto_dh_decode_key() - decode a private key * @buf: Buffer holding a packet key that should be decoded * @len: Lenth of the packet private key buffer * @params: Buffer allocated by the caller that is filled with the * unpacket DH 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_dh_decode_key(const char *buf, unsigned int len, struct dh *params); #endif value='range'>range
path: root/include/net/tcp_states.h
rl'>
AgeCommit message (Expand)AuthorFilesLines
authorMarc Zyngier <marc.zyngier@arm.com>2016-05-25 15:26:38 +0100
committerChristoffer Dall <christoffer.dall@linaro.org>2016-05-31 16:12:17 +0200
commita057001e9e446f2195c34bc55c57e5cf353c99d6 (patch)
tree82f88a4890ffae9c4555e898b2e3ac8964c0b547
parentb34f2bcbf59fe2d27c37d6553c33611754677103 (diff)
arm64: KVM: vgic-v3: Prevent the guest from messing with ICC_SRE_EL1
Both our GIC emulations are "strict", in the sense that we either emulate a GICv2 or a GICv3, and not a GICv3 with GICv2 legacy support. But when running on a GICv3 host, we still allow the guest to tinker with the ICC_SRE_EL1 register during its time slice: it can switch SRE off, observe that it is off, and yet on the next world switch, find the SRE bit to be set again. Not very nice. An obvious solution is to always trap accesses to ICC_SRE_EL1 (by clearing ICC_SRE_EL2.Enable), and to let the handler return the programmed value on a read, or ignore the write. That way, the guest can always observe that our GICv3 is SRE==1 only. Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Diffstat