linux-kernel - Re: [PATCH v2 3/4] dt-bindings: rng: Add vmgenid support

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] [day] [month] [year] [list]

Date: Tue, 26 Mar 2024 15:43:55 +0100
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: "Landge, Sudan" <sudanl@...zon.co.uk>
Cc: Rob Herring <robh@...nel.org>, Sudan Landge <sudanl@...zon.com>,
	tytso@....edu, krzysztof.kozlowski+dt@...aro.org,
	conor+dt@...nel.org, sathyanarayanan.kuppuswamy@...ux.intel.com,
	thomas.lendacky@....com, dan.j.williams@...el.com,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	graf@...zon.de, dwmw@...zon.co.uk, bchalios@...zon.es,
	xmarcalx@...zon.co.uk
Subject: Re: [PATCH v2 3/4] dt-bindings: rng: Add vmgenid support

On Tue, Mar 26, 2024 at 01:06:16PM +0000, Landge, Sudan wrote:
> >>> Does the spec say anything about endianness or access size? DT assumes
> >>> native endianness by default. We have properties to deal these, but
> >>> would be better to be explicit if that's defined already.
> >>>
> >> The spec doesn't mention anything about the endianness but, I have
> >> updated the description with some more data.
> > 
> > Then what does your driver assume? Microsoft may not have thought
> > about it because they don't care, but now you want to use DT so you
> > have to because it is frequently used on BE systems. If we define
> > something, then there's some hope. Otherwise, it's pretty much a
> > guarantee folks will do the opposite.
> > 
> > Rob
> The driver does not assume any endianness. To provide more context, The 
> hypervisor stores a 128bit unique ID at the address pointed by the 
> "reg"'s 1st cell, driver memcpy's this ID to an internal context and 
> uses memcmp to compare if the ID is new or old.
> But yes, it will be good to define a fixed endianness to avoid any 
> error. I will update the description to use little endian.

It's a 16-byte blob. Why care about endianness at all here? Treat it as
a byte string, not an integer.

Jason