All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roberto Sassu <roberto.sassu@huawei.com>
To: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: "zohar@linux.ibm.com" <zohar@linux.ibm.com>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"linux-integrity@vger.kernel.org"
	<linux-integrity@vger.kernel.org>,
	"linux-security-module@vger.kernel.org" 
	<linux-security-module@vger.kernel.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-kselftest@vger.kernel.org"
	<linux-kselftest@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [RFC][PATCH v2 02/12] diglim: Basic definitions
Date: Wed, 28 Jul 2021 13:47:36 +0000	[thread overview]
Message-ID: <caa43f36ce764f16ba56bc38cbd43319@huawei.com> (raw)
In-Reply-To: <20210728150823.705623ad@sal.lan>

> From: Mauro Carvalho Chehab [mailto:mchehab+huawei@kernel.org]
> Sent: Wednesday, July 28, 2021 3:08 PM
> Em Wed, 28 Jul 2021 11:45:02 +0000
> Roberto Sassu <roberto.sassu@huawei.com> escreveu:
> 
> > > From: Mauro Carvalho Chehab [mailto:mchehab+huawei@kernel.org]
> > > Sent: Wednesday, July 28, 2021 1:31 PM
> > > Em Mon, 26 Jul 2021 18:36:50 +0200
> > > Roberto Sassu <roberto.sassu@huawei.com> escreveu:
> > >
> 
> > > > +struct compact_list_hdr {
> > > > +	__u8 version;
> > > > +	__u8 _reserved;
> > > > +	__le16 type;
> > > > +	__le16 modifiers;
> > > > +	__le16 algo;
> > > > +	__le32 count;
> > > > +	__le32 datalen;
> > > > +} __packed;
> > > > +#endif /*_UAPI__LINUX_DIGLIM_H*/
> > >
> > > Besides Greg's notes, I'm wondering why to enforce a particular
> > > endness here. I mean, this is uAPI. I would expect it to use the
> > > CPU endianness instead, in order to avoid uneeded conversions.
> >
> > Also Greg had the same concern. I hoped the Lifecycle section clarified
> > the fact that digest lists are generated by software vendors not the
> > local system. Should I add something more in the documentation?
> 
> It shouldn't matter what kind of endness software vendors use on
> userspace (either CPU or a fixed endiannes - either LE or BE).
> 
> I mean, I won't doubt that some package tools use LE while others
> would use BE. At some point, this needs to be converted to
> CPU endiannes.

If you let digest list generators decide the endianness, probably
it is necessary to also add the endianness information in the
structure. Otherwise, the kernel wouldn't know what to do.

If the kernel knows that the digest list is always in little endian,
it simply calls le32_to_cpu().

> IMO, the best would be to isolate whatever RPM/DEB/... endianness
> is used on userspace from what the Kernel will use internally.

This is a different case. The conversion happens if the digest list
is not in native format. The kernel can also parse an untouched
digest list if it is in native format.

Thanks

Roberto

HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Li Jian, Shi Yanli

> Just my 2 cents.
> 
> Regards,
> Mauro

  reply	other threads:[~2021-07-28 13:54 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-26 16:36 [RFC][PATCH v2 00/12] integrity: Introduce DIGLIM Roberto Sassu
2021-07-26 16:36 ` [RFC][PATCH v2 01/12] diglim: Overview Roberto Sassu
2021-07-28 11:10   ` Mauro Carvalho Chehab
2021-07-28 11:40     ` Roberto Sassu
2021-07-26 16:36 ` [RFC][PATCH v2 02/12] diglim: Basic definitions Roberto Sassu
2021-07-27 14:43   ` Greg KH
2021-07-27 15:35     ` Roberto Sassu
2021-07-27 15:44       ` Greg KH
2021-07-27 16:09         ` Roberto Sassu
2021-07-27 16:13           ` Greg KH
2021-07-28  6:59             ` Roberto Sassu
2021-07-28 11:31   ` Mauro Carvalho Chehab
2021-07-28 11:45     ` Roberto Sassu
2021-07-28 13:08       ` Mauro Carvalho Chehab
2021-07-28 13:47         ` Roberto Sassu [this message]
2021-07-26 16:36 ` [RFC][PATCH v2 03/12] diglim: Objects Roberto Sassu
2021-07-28 11:38   ` Mauro Carvalho Chehab
2021-07-28 11:47     ` Roberto Sassu
2021-07-26 16:36 ` [RFC][PATCH v2 04/12] diglim: Methods Roberto Sassu
2021-07-28 12:18   ` Mauro Carvalho Chehab
2021-07-28 12:30     ` Roberto Sassu
2021-07-26 16:36 ` [RFC][PATCH v2 05/12] diglim: Parser Roberto Sassu
2021-07-28 12:35   ` Mauro Carvalho Chehab
2021-07-26 16:36 ` [RFC][PATCH v2 06/12] diglim: Interfaces - digest_list_add, digest_list_del Roberto Sassu
2021-07-28 12:38   ` Mauro Carvalho Chehab
2021-07-29 21:20   ` Mimi Zohar
2021-07-30  7:16     ` Roberto Sassu
2021-07-30 12:39       ` Mimi Zohar
2021-07-30 13:16         ` Roberto Sassu
2021-07-30 14:03           ` Mimi Zohar
2021-07-30 14:24             ` Roberto Sassu
2021-08-02  8:14               ` Roberto Sassu
2021-08-02 15:01                 ` Mimi Zohar
2021-08-02 14:42           ` Mimi Zohar
2021-08-02 15:12             ` Roberto Sassu
2021-08-02 16:54             ` Roberto Sassu
2021-08-05 15:38               ` Mimi Zohar
2021-08-05 17:04                 ` Roberto Sassu
2021-07-26 16:36 ` [RFC][PATCH v2 07/12] diglim: Interfaces - digest_lists_loaded Roberto Sassu
2021-07-26 16:36 ` [RFC][PATCH v2 08/12] diglim: Interfaces - digest_label Roberto Sassu
2021-07-26 16:36 ` [RFC][PATCH v2 09/12] diglim: Interfaces - digest_query Roberto Sassu
2021-07-26 16:36 ` [RFC][PATCH v2 10/12] diglim: Interfaces - digests_count Roberto Sassu
2021-07-28 12:45   ` Mauro Carvalho Chehab
2021-07-26 16:36 ` [RFC][PATCH v2 11/12] diglim: Remote Attestation Roberto Sassu
2021-07-28 12:47   ` Mauro Carvalho Chehab
2021-07-28 12:54     ` Roberto Sassu
2021-07-26 16:37 ` [RFC][PATCH v2 12/12] diglim: Tests Roberto Sassu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=caa43f36ce764f16ba56bc38cbd43319@huawei.com \
    --to=roberto.sassu@huawei.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mchehab+huawei@kernel.org \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.