From: Collin Walling <walling@linux.ibm.com>
To: Zhuoying Cai <zycai@linux.ibm.com>,
thuth@redhat.com, berrange@redhat.com, jrossi@linux.ibm.com,
qemu-s390x@nongnu.org, qemu-devel@nongnu.org
Cc: richard.henderson@linaro.org, pierrick.bouvier@linaro.org,
david@kernel.org, jjherne@linux.ibm.com, pasic@linux.ibm.com,
borntraeger@linux.ibm.com, farman@linux.ibm.com,
mjrosato@linux.ibm.com, iii@linux.ibm.com, eblake@redhat.com,
armbru@redhat.com, alifm@linux.ibm.com, brueckner@linux.ibm.com,
jdaley@linux.ibm.com
Subject: Re: [PATCH v9 20/30] pc-bios/s390-ccw: Add signed component address overlap checks
Date: Tue, 17 Mar 2026 00:25:25 -0400 [thread overview]
Message-ID: <21bf545b-52d4-4aba-898a-a6c99853ce4e@linux.ibm.com> (raw)
In-Reply-To: <20260305224146.664053-21-zycai@linux.ibm.com>
On 3/5/26 17:41, Zhuoying Cai wrote:
> Add address range tracking and overlap checks to ensure that no
> component overlaps with a signed component during secure IPL.
>
> Signed-off-by: Zhuoying Cai <zycai@linux.ibm.com>
> ---
> pc-bios/s390-ccw/secure-ipl.c | 52 +++++++++++++++++++++++++++++++++++
> pc-bios/s390-ccw/secure-ipl.h | 6 ++++
> 2 files changed, 58 insertions(+)
>
> diff --git a/pc-bios/s390-ccw/secure-ipl.c b/pc-bios/s390-ccw/secure-ipl.c
> index 8d281c1cea..68596491c5 100644
> --- a/pc-bios/s390-ccw/secure-ipl.c
> +++ b/pc-bios/s390-ccw/secure-ipl.c
> @@ -211,6 +211,53 @@ static void init_lists(IplDeviceComponentList *comp_list,
> cert_list->ipl_info_header.len = sizeof(cert_list->ipl_info_header);
> }
>
> +static bool is_comp_overlap(SecureIplCompAddrRange *comp_addr_range,
> + int addr_range_index,
> + uint64_t start_addr, uint64_t end_addr)
> +{
> + /* neither a signed nor an unsigned component can overlap with a signed component */
How about: "Check component's address range does not overlap with any
signed component's address range."
> + for (int i = 0; i < addr_range_index; i++) {
> + if ((comp_addr_range[i].start_addr < end_addr &&
> + start_addr < comp_addr_range[i].end_addr) &&
> + comp_addr_range[i].is_signed) {
> + return true;
> + }
> + }
> +
> + return false;
> +}
> +
> +static void comp_addr_range_add(SecureIplCompAddrRange *comp_addr_range,
> + int addr_range_index, bool is_signed,
> + uint64_t start_addr, uint64_t end_addr)
> +{
> + if (addr_range_index >= MAX_CERTIFICATES) {
> + zipl_secure_handle("Component address range update failed due to out-of-range"
> + " index; Overlapping validation cannot be guaranteed");
> + }
> +
> + comp_addr_range[addr_range_index].is_signed = is_signed;
> + comp_addr_range[addr_range_index].start_addr = start_addr;
> + comp_addr_range[addr_range_index].end_addr = end_addr;
> +}
> +
> +static void addr_overlap_check(SecureIplCompAddrRange *comp_addr_range,
> + int *addr_range_index,
> + uint64_t start_addr, uint64_t end_addr, bool is_signed)
> +{
> + bool overlap;
> +
> + overlap = is_comp_overlap(comp_addr_range, *addr_range_index,
> + start_addr, end_addr);
> + if (overlap) {
> + zipl_secure_handle("Component addresses overlap");
> + }
> +
> + comp_addr_range_add(comp_addr_range, *addr_range_index, is_signed,
> + start_addr, end_addr);
> + *addr_range_index += 1;
> +}
> +
> static int zipl_load_signature(ComponentEntry *entry, uint64_t sig_sec)
> {
> if (zipl_load_segment(entry, sig_sec) < 0) {
> @@ -254,6 +301,8 @@ int zipl_run_secure(ComponentEntry **entry_ptr, uint8_t *tmp_sec)
> * exists for the certificate).
> */
> int cert_list_table[MAX_CERTIFICATES] = { [0 ... MAX_CERTIFICATES - 1] = -1 };
> + SecureIplCompAddrRange comp_addr_range[MAX_CERTIFICATES];
> + int addr_range_index = 0;
> int signed_count = 0;
>
> if (!secure_ipl_supported()) {
> @@ -283,6 +332,9 @@ int zipl_run_secure(ComponentEntry **entry_ptr, uint8_t *tmp_sec)
> goto out;
> }
>
> + addr_overlap_check(comp_addr_range, &addr_range_index,
> + comp_addr, comp_addr + comp_len, sig_len > 0);
super nit: I'd prefer !!sig_len versus sig_len > 0.
> +
> if (!sig_len) {
> break;
> }
> diff --git a/pc-bios/s390-ccw/secure-ipl.h b/pc-bios/s390-ccw/secure-ipl.h
> index eb5ba0ed47..69edfce241 100644
> --- a/pc-bios/s390-ccw/secure-ipl.h
> +++ b/pc-bios/s390-ccw/secure-ipl.h
> @@ -16,6 +16,12 @@
> VCStorageSizeBlock *zipl_secure_get_vcssb(void);
> int zipl_run_secure(ComponentEntry **entry_ptr, uint8_t *tmp_sec);
>
> +typedef struct SecureIplCompAddrRange {
> + bool is_signed;
> + uint64_t start_addr;
> + uint64_t end_addr;
> +} SecureIplCompAddrRange;
> +
Since this is a custom construct made for keeping track of address
ranges, why not define your own list data structure that also keeps
track of the index? Could do:
typedef struct SecureIplCompAddrRangeList {
SecureIplCompAddrRange comp_addr_range[MAX_CERTIFICATES];
int index;
}
Then you could greatly simplify the function signatures by passing the
list and single entry. Depending on how reduced the code is after the
changes, it might look better to just do something like this in
zipl_run_secure and get rid of addr_overlap_check:
```
if (is_comp_overlap(list, comp)) {
zipl_secure_handle("message");
}
comp_addr_range_list_add(list, comp);
```
Would make things look a lot cleaner imho :)
Note: it may make sense to carry this list structure in other areas too
-- it would help keep track of the respective list indexes and result in
less variables passed around.
> static inline void zipl_secure_handle(const char *message)
> {
> switch (boot_mode) {
--
Regards,
Collin
next prev parent reply other threads:[~2026-03-17 4:26 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-05 22:41 [PATCH v9 00/30] Secure IPL Support for SCSI Scheme of virtio-blk/virtio-scsi Devices Zhuoying Cai
2026-03-05 22:41 ` [PATCH v9 01/30] Add boot-certs to s390-ccw-virtio machine type option Zhuoying Cai
2026-03-05 22:41 ` [PATCH v9 02/30] crypto/x509-utils: Refactor with GNUTLS fallback Zhuoying Cai
2026-03-05 22:41 ` [PATCH v9 03/30] crypto/x509-utils: Add helper functions for certificate store Zhuoying Cai
2026-03-05 22:41 ` [PATCH v9 04/30] hw/s390x/ipl: Create " Zhuoying Cai
2026-03-05 22:41 ` [PATCH v9 05/30] s390x/diag: Introduce DIAG 320 for Certificate Store Facility Zhuoying Cai
2026-03-05 22:41 ` [PATCH v9 06/30] s390x/diag: Refactor address validation check from diag308_parm_check Zhuoying Cai
2026-03-05 22:41 ` [PATCH v9 07/30] s390x/diag: Implement DIAG 320 subcode 1 Zhuoying Cai
2026-03-05 22:41 ` [PATCH v9 08/30] crypto/x509-utils: Add helper functions for DIAG 320 subcode 2 Zhuoying Cai
2026-03-05 22:41 ` [PATCH v9 09/30] s390x/diag: Implement " Zhuoying Cai
2026-03-13 19:58 ` Collin Walling
2026-03-16 18:04 ` Zhuoying Cai
2026-03-05 22:41 ` [PATCH v9 10/30] s390x/diag: Introduce DIAG 508 for secure IPL operations Zhuoying Cai
2026-03-05 22:41 ` [PATCH v9 11/30] crypto/x509-utils: Add helper functions for DIAG 508 subcode 1 Zhuoying Cai
2026-03-05 22:41 ` [PATCH v9 12/30] s390x/diag: Implement DIAG 508 subcode 1 for signature verification Zhuoying Cai
2026-03-05 22:41 ` [PATCH v9 13/30] s390x/ipl: Introduce IPL Information Report Block (IIRB) Zhuoying Cai
2026-03-13 20:00 ` Collin Walling
2026-03-05 22:41 ` [PATCH v9 14/30] pc-bios/s390-ccw: Define memory for IPLB and convert IPLB to pointers Zhuoying Cai
2026-03-05 22:41 ` [PATCH v9 15/30] hw/s390x/ipl: Add IPIB flags to IPL Parameter Block Zhuoying Cai
2026-03-05 22:41 ` [PATCH v9 16/30] s390x: Guest support for Secure-IPL Facility Zhuoying Cai
2026-03-05 22:41 ` [PATCH v9 17/30] pc-bios/s390-ccw: Refactor zipl_run() Zhuoying Cai
2026-03-05 22:41 ` [PATCH v9 18/30] pc-bios/s390-ccw: Rework zipl_load_segment function Zhuoying Cai
2026-03-05 22:41 ` [PATCH v9 19/30] pc-bios/s390-ccw: Add signature verification for secure IPL in audit mode Zhuoying Cai
2026-03-17 3:41 ` Collin Walling
2026-03-25 19:11 ` Zhuoying Cai
2026-03-05 22:41 ` [PATCH v9 20/30] pc-bios/s390-ccw: Add signed component address overlap checks Zhuoying Cai
2026-03-17 4:25 ` Collin Walling [this message]
2026-03-05 22:41 ` [PATCH v9 21/30] s390x: Guest support for Secure-IPL Code Loading Attributes Facility (SCLAF) Zhuoying Cai
2026-03-05 22:41 ` [PATCH v9 22/30] pc-bios/s390-ccw: Add additional security checks for secure boot Zhuoying Cai
2026-03-17 6:54 ` Collin Walling
2026-03-05 22:41 ` [PATCH v9 23/30] Add secure-boot to s390-ccw-virtio machine type option Zhuoying Cai
2026-03-05 22:41 ` [PATCH v9 24/30] hw/s390x/ipl: Set IPIB flags for secure IPL Zhuoying Cai
2026-03-05 22:41 ` [PATCH v9 25/30] pc-bios/s390-ccw: Handle true secure IPL mode Zhuoying Cai
2026-03-17 7:02 ` Collin Walling
2026-03-05 22:41 ` [PATCH v9 26/30] hw/s390x/ipl: Handle secure boot with multiple boot devices Zhuoying Cai
2026-03-05 22:41 ` [PATCH v9 27/30] hw/s390x/ipl: Handle secure boot without specifying a boot device Zhuoying Cai
2026-03-05 22:41 ` [PATCH v9 28/30] tests/functional/s390x: Add secure IPL functional test Zhuoying Cai
2026-03-05 22:41 ` [PATCH v9 29/30] docs/specs: Add secure IPL documentation Zhuoying Cai
2026-03-05 22:41 ` [PATCH v9 30/30] docs/system/s390x: " Zhuoying Cai
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=21bf545b-52d4-4aba-898a-a6c99853ce4e@linux.ibm.com \
--to=walling@linux.ibm.com \
--cc=alifm@linux.ibm.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=borntraeger@linux.ibm.com \
--cc=brueckner@linux.ibm.com \
--cc=david@kernel.org \
--cc=eblake@redhat.com \
--cc=farman@linux.ibm.com \
--cc=iii@linux.ibm.com \
--cc=jdaley@linux.ibm.com \
--cc=jjherne@linux.ibm.com \
--cc=jrossi@linux.ibm.com \
--cc=mjrosato@linux.ibm.com \
--cc=pasic@linux.ibm.com \
--cc=pierrick.bouvier@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=thuth@redhat.com \
--cc=zycai@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox