From: Greg KH [mailto:gregkh@linuxfoundation.org] Sent: Tuesday, July 27, 2021 5:44 PM 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?
After the digest list is parsed, I'm accessing the digest with the offset from the beginning of the digest list. If the offset was relative to the header, it could have been useful. I could add the new field, but I'm afraid of the incompatibility with existing tools that we have.
Thanks
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Li Jian, Shi Yanli
thanks,
greg k-h