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: <20250508105502.GAaByNhlpwwdK6_ZyL@fat_crate.local>
Date: Thu, 8 May 2025 12:55:02 +0200
From: Borislav Petkov <bp@...en8.de>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: Ard Biesheuvel <ardb+git@...gle.com>, linux-kernel@...r.kernel.org,
	linux-efi@...r.kernel.org, x86@...nel.org,
	Ingo Molnar <mingo@...nel.org>,
	Dionna Amalie Glaze <dionnaglaze@...gle.com>,
	Kevin Loughlin <kevinloughlin@...gle.com>,
	Tom Lendacky <thomas.lendacky@....com>
Subject: Re: [RFT PATCH v2 00/23] x86: strict separation of startup code

On Wed, May 07, 2025 at 02:05:37PM +0200, Ard Biesheuvel wrote:
> So I'd actually argue for splitting this up even more rather than
> bundling it all together,

Splitting it into logically separated bits? Yes. Just because: no.

The SEV stuff is still largely in motion so once it starts settling down,
splitting it would be the first thing that irks me and I'll go do it.

> although the sev vs sev-internal distinction is a bit dubious - it would be
> better to split this across functional lines.
> 
> I added sev-internal.h so that that single mother-of-all-source-files
> could be hacked up without exposing implementation details to external
> users that were hidden before. I.e., the high-level APIs that other
> callers need to use should be in sev.h, and the implementation of that
> API should be carved up meaningfully. For example, perhaps the #VC
> handling stuff (which now lives in a separate source file) could be
> exposed via sev-vc.h, and only included in places where that
> particular functionality is being used.

Right, please put those considerations in the commit messages - it helps a lot
with the review.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ