lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210728150823.705623ad@sal.lan>
Date:   Wed, 28 Jul 2021 15:08:23 +0200
From:   Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
To:     Roberto Sassu <roberto.sassu@...wei.com>
Cc:     "zohar@...ux.ibm.com" <zohar@...ux.ibm.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
        "linux-security-module@...r.kernel.org" 
        <linux-security-module@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH v2 02/12] diglim: Basic definitions

Em Wed, 28 Jul 2021 11:45:02 +0000
Roberto Sassu <roberto.sassu@...wei.com> escreveu:

> > From: Mauro Carvalho Chehab [mailto:mchehab+huawei@...nel.org]
> > Sent: Wednesday, July 28, 2021 1:31 PM
> > Em Mon, 26 Jul 2021 18:36:50 +0200
> > Roberto Sassu <roberto.sassu@...wei.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.

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

Just my 2 cents.

Regards,
Mauro

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ