On Tue, Jul 27, 2021 at 03:35:16PM +0000, Roberto Sassu wrote:
From: Greg KH [mailto:gregkh@linuxfoundation.org] Sent: Tuesday, July 27, 2021 4:44 PM On Mon, Jul 26, 2021 at 06:36:50PM +0200, Roberto Sassu wrote:
--- /dev/null +++ b/include/uapi/linux/diglim.h @@ -0,0 +1,51 @@ +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ +/*
- Copyright (C) 2017-2021 Huawei Technologies Duesseldorf GmbH
- Author: Roberto Sassu roberto.sassu@huawei.com
- DIGLIM definitions exported to user space, useful for generating digest
- lists.
- */
+#ifndef _UAPI__LINUX_DIGLIM_H +#define _UAPI__LINUX_DIGLIM_H
+#include <linux/types.h> +#include <linux/hash_info.h>
+enum compact_types { COMPACT_KEY, COMPACT_PARSER,
COMPACT_FILE,
COMPACT_METADATA, COMPACT_DIGEST_LIST,COMPACT__LAST };
+enum compact_modifiers { COMPACT_MOD_IMMUTABLE,
COMPACT_MOD__LAST };
+enum compact_actions { COMPACT_ACTION_IMA_MEASURED,
COMPACT_ACTION_IMA_APPRAISED,COMPACT_ACTION_IMA_APPRAISED_DIGSIG,COMPACT_ACTION__LAST };+enum ops { DIGEST_LIST_ADD, DIGEST_LIST_DEL, DIGEST_LIST_OP__LAST };
+/**
- struct compact_list_hdr - header of the following concatenated digests
- @version: version of the digest list
- @_reserved: field reserved for future use
- @type: type of digest list among enum compact_types
- @modifiers: additional attributes among (1 << enum compact_modifiers)
I do not understand this description, what does it mean?
Hi Greg
yes, it is not very clear.
@modifiers is a bitmask where each bit corresponds to a different attribute. enum compact_modifiers defines which bit position is assigned to each attribute.
Watch out with endian issues and bitmasks... Anyway, please document this.
- @algo: digest algorithm
Is this also a #define or an enum? Where is the list of them?
@algo is an enum defined in include/uapi/linux/hash_info.h.
Please say that.
- @count: number of digests
- @datalen: length of concatenated digests
Where does this count and length come into play as nothing else is in this structure?
Each digest list must begin with this structure. From it, the parser knows how much data it should expect afterwards. After the data, there could be another or more blocks of this structure and following data.
Ah, that was not obvious at all :)
Why do you not have a __u8 data[]; type field as the last one here for that memory so you can access it easier?
thanks,
greg k-h