Received-SPF: pass (google.com: domain of linux-crypto+bounces-4698-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <5b32106b-bb7b-463d-8b0b-589e3d466bf3@oracle.com>
Date: Tue, 4 Jun 2024 10:33:54 -0700
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 08/19] x86: Secure Launch kernel early boot stub
To: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
        linux-integrity@vger.kernel.org, linux-doc@vger.kernel.org,
        linux-crypto@vger.kernel.org, kexec@lists.infradead.org,
        linux-efi@vger.kernel.org, iommu@lists.linux-foundation.org,
        dpsmith@apertussolutions.com, tglx@linutronix.de, mingo@redhat.com,
        bp@alien8.de, hpa@zytor.com, dave.hansen@linux.intel.com,
        mjg59@srcf.ucam.org, James.Bottomley@hansenpartnership.com,
        peterhuewe@gmx.de, jarkko@kernel.org, jgg@ziepe.ca,
        luto@amacapital.net, nivedita@alum.mit.edu,
        herbert@gondor.apana.org.au, davem@davemloft.net, corbet@lwn.net,
        ebiederm@xmission.com, dwmw2@infradead.org, baolu.lu@linux.intel.com,
        kanth.ghatraju@oracle.com, andrew.cooper3@citrix.com,
        trenchboot-devel@googlegroups.com, ross.philipson@oracle.com
References: <20240531010331.134441-1-ross.philipson@oracle.com>
 <20240531010331.134441-9-ross.philipson@oracle.com>
 <CAMj1kXHaH6atsvwr6oVPdZuhR5YEXU33-2kYEn6xb1e=gidOCw@mail.gmail.com>
 <CAMj1kXHcYOPTLTh-hEtfHk+JaORGK+fEatTT+UOqLJww+_cNTg@mail.gmail.com>
 <5bffa507-75e8-4cce-ac0c-fe13d6efd3bb@oracle.com>
 <CAMj1kXHLaqyPAw5Jjg91pqFbHoMT2jDqui4rosyerHVudRsq-w@mail.gmail.com>
Content-Language: en-US
From: ross.philipson@oracle.com
In-Reply-To: <CAMj1kXHLaqyPAw5Jjg91pqFbHoMT2jDqui4rosyerHVudRsq-w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: 
	=?utf-8?B?L0xzSkJsQXNsV2FPZHJEVG5GOFRnNHIrWlIyR1BIMmk5QnlVVDNSQkZNdnBu?=
 =?utf-8?B?dVVydXduRDlpanhwL0pzK1B0a0w0YUNBZWQ0WllRS3FZT1daVm5VaHZFUTcx?=
 =?utf-8?B?UU43NmVOYy9aRGFYK0tpZWJtRHN6SFNEMkZCZ3lTSE1OUzNBM0xVRVcwZkgr?=
 =?utf-8?B?bEpzRlFQc2E4aFBneGlrciswYzZENFpRZ1lkOWhoeUNOOHJOYlNXd3dCZXhk?=
 =?utf-8?B?Wk5xTmk4a3psSWxwdHpYMXU4Z1Bjb2grS1lwdWxFVkYxSkZnREVmV2F5YkZD?=
 =?utf-8?B?UGd1MEM0NGovOGpOYkZmWVd4TDc0ZTJOYTE4ZEpSMWJ2NnhvZjI0ajEyNndt?=
 =?utf-8?B?dFVjcTZienVlZkhTN09sTmpaWWpSTWVGVkk5TTN3R2lYTWFSV3BOc3dqakNx?=
 =?utf-8?B?dXhhcktkR3NlREgvR01nZzF5MUxnUEVlSUgwNmdmQXRtUXA5M1hvZkR0eFlO?=
 =?utf-8?B?MVZGZ1cxTlorV05MNm93c1R6b1lRYWZYaVgrWjg5SkZsMzE4Qk00RzlKZFFm?=
 =?utf-8?B?Z0lIUTJ5eFg5MzREaFBMcUxmM3hYVXNET0ZxaEtROUxmT3IrY2lGMGo2UERk?=
 =?utf-8?B?R1dJbmx0NEFBZmg0NGxhdkV0U0laRzFUb2hzdzQyRWE0Qjg1V29IdzVPNGVy?=
 =?utf-8?B?RWxNK2FCd0xRZjFWR1ZsR3RXOEVOVmRlbWpVVEFUMzZrLzJMQWtPQXpkenhR?=
 =?utf-8?B?elZZU1JPdzlmRXZOZytMRW1qWlZvclJMMEhtWWpnVVdIdFBrK3kxelRHbTRy?=
 =?utf-8?B?QUhCYjBqVEpjcHU2Y1NjcmpjcUp5bW4vTkVlcktJVExuTVoxVTlRSFo4THVz?=
 =?utf-8?B?clovVFFiR2c3eUtNVEJRUDZ0ZlpiaHNSbUNzb3RPaEtGbnlFcHV2VU5nOXlk?=
 =?utf-8?B?NFA3RnMrK1NkaElpQ2Nlc3Z3OXpDbnhvTStibWNjN2F2bmYwNjZpbW9CVmVY?=
 =?utf-8?B?Sm93L0dkMS94c2FQZ0NRdkRHYkxIOFp6M0FybHRnbStOVVF3T1F6eXo1OENi?=
 =?utf-8?B?M0dSYW9LYVFBc2tiRThOcjd3NTFWTnpVSXlxSTRYNEo4ZTdQRlhFWDdITWMy?=
 =?utf-8?B?L3JkTVB5UHUrc3Z2emV2Z2lqRHNzeEplOEF5THhuTmVNbG8yc0hIUEZBeHdI?=
 =?utf-8?B?bGsxU2JuNUVuYlkwZFMyQkl0d1FUUjA1WDBzOHI2V3FEYkpGeDFSbTlhK3lO?=
 =?utf-8?B?K3RFbmxDb0hFakFmNndGTmNmRmpEWW14T2FMeXlFYlk3a0VEQ2RTdEExWFhV?=
 =?utf-8?B?NjJvNnM2TEdGZ2d6cUZJSHZEVUlwb0x1VG1ZZ3hlMm03bmRxK1Y3eHEvbDY0?=
 =?utf-8?B?WnNKWHJPOU1aRmkxblBxTGJRY0N5bGlZU0FQOHI4UmF6elJYaUJEckdkWm5V?=
 =?utf-8?B?WitoS1JSNkhQbkREN05UWEp3eEJnOUZkc1V4MVBlOHVTbHFmcXp4ZkJ4RTEr?=
 =?utf-8?B?ajB4UFhKYVVYaXIzNVZUSnh1OElZZ1dTU0hkaDNTdlpNdXJKUGcxdXZpeDZU?=
 =?utf-8?B?aHY3cytlRlRYMFB3ZW53bVJFZGNENEFJSnJPY3FBeEtRRnVxVXhOV3VOWjFh?=
 =?utf-8?B?aDBpbUFUbGtIQmRIY1FRV2FnNFdsdVJBS214bHh2cUVGSGtaeFFzQkwwVTJw?=
 =?utf-8?B?dC9sbTNQenZlR0xhclRmNVVCZzA2VkRDN3laRkZTK2hlQTFYMzFMZmtaMW1T?=
 =?utf-8?B?OFFtSlcxcWM0dUxmYWFLK2F0dFpDMkw5L2ROSU43bTk3QWpUZnE4UnBnS2VB?=
 =?utf-8?B?Mlg0M1JFOWUyeXprNmZxREkvTjFUdzhJWVFDeUJqSUdqOE5aOElqaldyTEMy?=
 =?utf-8?B?M0hqMWgrZWZyTzcrT01ZcFNMdmZSV0d6ZjhBT2FobHI0TUowZ0VuYkJrT0hL?=
 =?utf-8?B?UngzemlJUW1EdXBMQnozZVNWcS9LQ1lSSjNtVUZWNnV2a0ZkUFJXS3c2U1Bh?=
 =?utf-8?B?V1VTdzFOMEVoeE9taHNNUTV0MzdrRCtIaHVDOHk5SEhLMVhIUW0rWEM0WlFZ?=
 =?utf-8?B?eFF4WDYrTDh6NGVrYzMzUzEvVEFQZ2pFUWtMcjBkNkpxNE5aWkNKMlVMTU5k?=
 =?utf-8?B?aWphUFBuL2YwLzYyNGdRdmlIZWR4YW1jT1Rsdmx1MUtNMHFkcnJobTcrWjVM?=
 =?utf-8?B?M1hmWWpRcFo4bFZjWFpQbEloYVpEVTUxL2k2SjN4OVdzZm9TbHhjM05MWDZr?=
 =?utf-8?B?Q1E9PQ==?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 
	Sk3dzT8EFojTuSk7rfaArHH4ad+UPpsQiUr8swz5EK/ybpvFzkodzQcSUhAgxhjzCnV8lCyW2UzW582zBVx8v2EyRbIpmI4wm31g/Rc91G0kbBRrJHfp/tNYMbhB+Qe7SqRIBeImpjDMx8ABAjrFpvWfF4s3FZk7UmWjbyGhbntnvm1lQ7nJF3GutG8wPZS2+WXcsOoCoSNO5YRr9JF0o2SG+C4hGcQ/B4bLfEUkGr3Pi89rqATP+fY8OYQnFPt4uaf+OXnsRTQAjgRMOHupZ/Owx7WxxkRZO29dNTRoI2XHrcTfK+rG7cyjmEcY/6TNat3FU2gdNEVyS3BSZom9uZZxtW+CN5+WGAGpIN7KBI2rt8Ggewr14EKmCkHWGNWjcpbXC7LpCVNx9xO9cT7+juEO6QzsFv1Ajme4LBc9hjvQaLNooXBjGo3Jz9paQZidEZicWRvwMd2r4bR8Xe/o3EvbsDrYjgQgFmbunsaWjfaC252GqJ7GWABRxc2GPjxjqtx1te/9n6hYbfymbxNlsZpeK545RfHqZBPCuZkRMkTvGXPhsUXT30SbcOmAobY0aIWLEPX6IChXraepgnTTpTFPsPTQWLqtMDVKmzjqQSA=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5d790ca2-fc61-481f-5051-08dc84bc83a4
X-MS-Exchange-CrossTenant-AuthSource: DS0PR10MB7224.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jun 2024 17:33:57.8598
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: AFi2ySnDs9URxEP1TlEenz2JixeEM2ExvF7FaIzZLxxZyO3U4qT5xn6Oy4Yvyf69a3Sf1BKWqxqhTCIB/fuvuAkCbGWHkbidfwRuCNX0uMg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW5PR10MB5825
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.28.16
 definitions=2024-06-04_09,2024-06-04_01,2024-05-17_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 bulkscore=0 spamscore=0
 malwarescore=0 suspectscore=0 phishscore=0 mlxlogscore=999 adultscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2405010000
 definitions=main-2406040141
X-Proofpoint-GUID: 2jeY6i5kTd45XkiGhbifNwZU3zfTi2Ih
X-Proofpoint-ORIG-GUID: 2jeY6i5kTd45XkiGhbifNwZU3zfTi2Ih

On 6/4/24 10:27 AM, Ard Biesheuvel wrote:
> On Tue, 4 Jun 2024 at 19:24, <ross.philipson@oracle.com> wrote:
>>
>> On 5/31/24 6:33 AM, Ard Biesheuvel wrote:
>>> On Fri, 31 May 2024 at 13:00, Ard Biesheuvel <ardb@kernel.org> wrote:
>>>>
>>>> Hello Ross,
>>>>
>>>> On Fri, 31 May 2024 at 03:32, Ross Philipson <ross.philipson@oracle.com> wrote:
>>>>>
>>>>> The Secure Launch (SL) stub provides the entry point for Intel TXT (and
>>>>> later AMD SKINIT) to vector to during the late launch. The symbol
>>>>> sl_stub_entry is that entry point and its offset into the kernel is
>>>>> conveyed to the launching code using the MLE (Measured Launch
>>>>> Environment) header in the structure named mle_header. The offset of the
>>>>> MLE header is set in the kernel_info. The routine sl_stub contains the
>>>>> very early late launch setup code responsible for setting up the basic
>>>>> environment to allow the normal kernel startup_32 code to proceed. It is
>>>>> also responsible for properly waking and handling the APs on Intel
>>>>> platforms. The routine sl_main which runs after entering 64b mode is
>>>>> responsible for measuring configuration and module information before
>>>>> it is used like the boot params, the kernel command line, the TXT heap,
>>>>> an external initramfs, etc.
>>>>>
>>>>> Signed-off-by: Ross Philipson <ross.philipson@oracle.com>
>>>>> ---
>>>>>    Documentation/arch/x86/boot.rst        |  21 +
>>>>>    arch/x86/boot/compressed/Makefile      |   3 +-
>>>>>    arch/x86/boot/compressed/head_64.S     |  30 +
>>>>>    arch/x86/boot/compressed/kernel_info.S |  34 ++
>>>>>    arch/x86/boot/compressed/sl_main.c     | 577 ++++++++++++++++++++
>>>>>    arch/x86/boot/compressed/sl_stub.S     | 725 +++++++++++++++++++++++++
>>>>>    arch/x86/include/asm/msr-index.h       |   5 +
>>>>>    arch/x86/include/uapi/asm/bootparam.h  |   1 +
>>>>>    arch/x86/kernel/asm-offsets.c          |  20 +
>>>>>    9 files changed, 1415 insertions(+), 1 deletion(-)
>>>>>    create mode 100644 arch/x86/boot/compressed/sl_main.c
>>>>>    create mode 100644 arch/x86/boot/compressed/sl_stub.S
>>>>>
>>>>> diff --git a/Documentation/arch/x86/boot.rst b/Documentation/arch/x86/boot.rst
>>>>> index 4fd492cb4970..295cdf9bcbdb 100644
>>>>> --- a/Documentation/arch/x86/boot.rst
>>>>> +++ b/Documentation/arch/x86/boot.rst
>>>>> @@ -482,6 +482,14 @@ Protocol:  2.00+
>>>>>               - If 1, KASLR enabled.
>>>>>               - If 0, KASLR disabled.
>>>>>
>>>>> +  Bit 2 (kernel internal): SLAUNCH_FLAG
>>>>> +
>>>>> +       - Used internally by the setup kernel to communicate
>>>>> +         Secure Launch status to kernel proper.
>>>>> +
>>>>> +           - If 1, Secure Launch enabled.
>>>>> +           - If 0, Secure Launch disabled.
>>>>> +
>>>>>      Bit 5 (write): QUIET_FLAG
>>>>>
>>>>>           - If 0, print early messages.
>>>>> @@ -1028,6 +1036,19 @@ Offset/size:     0x000c/4
>>>>>
>>>>>      This field contains maximal allowed type for setup_data and setup_indirect structs.
>>>>>
>>>>> +============   =================
>>>>> +Field name:    mle_header_offset
>>>>> +Offset/size:   0x0010/4
>>>>> +============   =================
>>>>> +
>>>>> +  This field contains the offset to the Secure Launch Measured Launch Environment
>>>>> +  (MLE) header. This offset is used to locate information needed during a secure
>>>>> +  late launch using Intel TXT. If the offset is zero, the kernel does not have
>>>>> +  Secure Launch capabilities. The MLE entry point is called from TXT on the BSP
>>>>> +  following a success measured launch. The specific state of the processors is
>>>>> +  outlined in the TXT Software Development Guide, the latest can be found here:
>>>>> +  https://urldefense.com/v3/__https://www.intel.com/content/dam/www/public/us/en/documents/guides/intel-txt-software-development-guide.pdf__;!!ACWV5N9M2RV99hQ!Mng0gnPhOYZ8D02t1rYwQfY6U3uWaypJyd1T2rsWz3QNHr9GhIZ9ANB_-cgPExxX0e0KmCpda-3VX8Fj$
>>>>> +
>>>>>
>>>>
>>>> Could we just repaint this field as the offset relative to the start
>>>> of kernel_info rather than relative to the start of the image? That
>>>> way, there is no need for patch #1, and given that the consumer of
>>>> this field accesses it via kernel_info, I wouldn't expect any issues
>>>> in applying this offset to obtain the actual address.
>>>>
>>>>
>>>>>    The Image Checksum
>>>>>    ==================
>>>>> diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
>>>>> index 9189a0e28686..9076a248d4b4 100644
>>>>> --- a/arch/x86/boot/compressed/Makefile
>>>>> +++ b/arch/x86/boot/compressed/Makefile
>>>>> @@ -118,7 +118,8 @@ vmlinux-objs-$(CONFIG_EFI) += $(obj)/efi.o
>>>>>    vmlinux-objs-$(CONFIG_EFI_MIXED) += $(obj)/efi_mixed.o
>>>>>    vmlinux-objs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a
>>>>>
>>>>> -vmlinux-objs-$(CONFIG_SECURE_LAUNCH) += $(obj)/early_sha1.o $(obj)/early_sha256.o
>>>>> +vmlinux-objs-$(CONFIG_SECURE_LAUNCH) += $(obj)/early_sha1.o $(obj)/early_sha256.o \
>>>>> +       $(obj)/sl_main.o $(obj)/sl_stub.o
>>>>>
>>>>>    $(obj)/vmlinux: $(vmlinux-objs-y) FORCE
>>>>>           $(call if_changed,ld)
>>>>> diff --git a/arch/x86/boot/compressed/head_64.S b/arch/x86/boot/compressed/head_64.S
>>>>> index 1dcb794c5479..803c9e2e6d85 100644
>>>>> --- a/arch/x86/boot/compressed/head_64.S
>>>>> +++ b/arch/x86/boot/compressed/head_64.S
>>>>> @@ -420,6 +420,13 @@ SYM_CODE_START(startup_64)
>>>>>           pushq   $0
>>>>>           popfq
>>>>>
>>>>> +#ifdef CONFIG_SECURE_LAUNCH
>>>>> +       /* Ensure the relocation region is coverd by a PMR */
>>>>
>>>> covered
>>>>
>>>>> +       movq    %rbx, %rdi
>>>>> +       movl    $(_bss - startup_32), %esi
>>>>> +       callq   sl_check_region
>>>>> +#endif
>>>>> +
>>>>>    /*
>>>>>     * Copy the compressed kernel to the end of our buffer
>>>>>     * where decompression in place becomes safe.
>>>>> @@ -462,6 +469,29 @@ SYM_FUNC_START_LOCAL_NOALIGN(.Lrelocated)
>>>>>           shrq    $3, %rcx
>>>>>           rep     stosq
>>>>>
>>>>> +#ifdef CONFIG_SECURE_LAUNCH
>>>>> +       /*
>>>>> +        * Have to do the final early sl stub work in 64b area.
>>>>> +        *
>>>>> +        * *********** NOTE ***********
>>>>> +        *
>>>>> +        * Several boot params get used before we get a chance to measure
>>>>> +        * them in this call. This is a known issue and we currently don't
>>>>> +        * have a solution. The scratch field doesn't matter. There is no
>>>>> +        * obvious way to do anything about the use of kernel_alignment or
>>>>> +        * init_size though these seem low risk with all the PMR and overlap
>>>>> +        * checks in place.
>>>>> +        */
>>>>> +       movq    %r15, %rdi
>>>>> +       callq   sl_main
>>>>> +
>>>>> +       /* Ensure the decompression location is covered by a PMR */
>>>>> +       movq    %rbp, %rdi
>>>>> +       movq    output_len(%rip), %rsi
>>>>> +       callq   sl_check_region
>>>>> +#endif
>>>>> +
>>>>> +       pushq   %rsi
>>>>
>>>> This looks like a rebase error.
>>>>
>>>>>           call    load_stage2_idt
>>>>>
>>>>>           /* Pass boot_params to initialize_identity_maps() */
>>>>> diff --git a/arch/x86/boot/compressed/kernel_info.S b/arch/x86/boot/compressed/kernel_info.S
>>>>> index c18f07181dd5..e199b87764e9 100644
>>>>> --- a/arch/x86/boot/compressed/kernel_info.S
>>>>> +++ b/arch/x86/boot/compressed/kernel_info.S
>>>>> @@ -28,6 +28,40 @@ SYM_DATA_START(kernel_info)
>>>>>           /* Maximal allowed type for setup_data and setup_indirect structs. */
>>>>>           .long   SETUP_TYPE_MAX
>>>>>
>>>>> +       /* Offset to the MLE header structure */
>>>>> +#if IS_ENABLED(CONFIG_SECURE_LAUNCH)
>>>>> +       .long   rva(mle_header)
>>>>
>>>> ... so this could just be mle_header - kernel_info, and the consumer
>>>> can do the math instead.
>>>>
>>>>> +#else
>>>>> +       .long   0
>>>>> +#endif
>>>>> +
>>>>>    kernel_info_var_len_data:
>>>>>           /* Empty for time being... */
>>>>>    SYM_DATA_END_LABEL(kernel_info, SYM_L_LOCAL, kernel_info_end)
>>>>> +
>>>>> +#if IS_ENABLED(CONFIG_SECURE_LAUNCH)
>>>>> +       /*
>>>>> +        * The MLE Header per the TXT Specification, section 2.1
>>>>> +        * MLE capabilities, see table 4. Capabilities set:
>>>>> +        * bit 0: Support for GETSEC[WAKEUP] for RLP wakeup
>>>>> +        * bit 1: Support for RLP wakeup using MONITOR address
>>>>> +        * bit 2: The ECX register will contain the pointer to the MLE page table
>>>>> +        * bit 5: TPM 1.2 family: Details/authorities PCR usage support
>>>>> +        * bit 9: Supported format of TPM 2.0 event log - TCG compliant
>>>>> +        */
>>>>> +SYM_DATA_START(mle_header)
>>>>> +       .long   0x9082ac5a  /* UUID0 */
>>>>> +       .long   0x74a7476f  /* UUID1 */
>>>>> +       .long   0xa2555c0f  /* UUID2 */
>>>>> +       .long   0x42b651cb  /* UUID3 */
>>>>> +       .long   0x00000034  /* MLE header size */
>>>>> +       .long   0x00020002  /* MLE version 2.2 */
>>>>> +       .long   rva(sl_stub_entry) /* Linear entry point of MLE (virt. address) */
>>>>
>>>> and these should perhaps be relative to mle_header?
>>>>
>>>>> +       .long   0x00000000  /* First valid page of MLE */
>>>>> +       .long   0x00000000  /* Offset within binary of first byte of MLE */
>>>>> +       .long   rva(_edata) /* Offset within binary of last byte + 1 of MLE */
>>>>
>>>> and here
>>>>
>>>
>>> Ugh never mind - these are specified externally.
>>
>> Can you clarify your follow on comment here?
>>
> 
> I noticed that -as you pointed out in your previous reply- these
> fields cannot be repainted at will, as they are defined by an external
> specification.
> 
> I'll play a bit more with this code tomorrow - I would *really* like
> to avoid the need for patch #1, as it adds another constraint on how
> we construct the boot image, and this is already riddled with legacy
> and other complications.

Yea I should have read forward through all your replies before 
responding to the first one but I think it clarified things as you point 
out here. We appreciate you help and suggestions.

Ross