From owner-freebsd-hackers@freebsd.org Thu Mar 22 20:50:40 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 410D1F6AA78; Thu, 22 Mar 2018 20:50:40 +0000 (UTC) (envelope-from scdbackup@gmx.net) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9FF4B6AEB6; Thu, 22 Mar 2018 20:50:39 +0000 (UTC) (envelope-from scdbackup@gmx.net) Received: from scdbackup.webframe.org ([91.8.164.220]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MPUFR-1euyIQ298D-004iSk; Thu, 22 Mar 2018 21:50:31 +0100 Date: Thu, 22 Mar 2018 21:48:42 +0100 From: "Thomas Schmitt" To: freebsd-hackers@freebsd.org Subject: Re: Testing requested: Hybrid ISO/USB boot Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org References: In-Reply-To: Message-Id: <3373772881814803857@scdbackup.webframe.org> X-Provags-ID: V03:K0:X2ZuHSvTFNxirIwoIzSyYKMMq5K0YJ4wwI8UKwoxNR1XGIClnvj dhbogVGwnXVFgNJxOMxLHU//hh6Dz1q8AKcmTOXa9EvUCyzTmSsGrPtF6vaWcO5t4fjjz2L 25uxTAMKPE7ofu1IWH/pavoRY1KkpXTfbVOr+gN+bv7cjPHae+tlqEikRUOmHqw3KZXIXG0 s+lzRbF2DR5U3V/eWI60A== X-UI-Out-Filterresults: notjunk:1;V01:K0:6BNIbhrnOSU=:DV0JCJBopVIsUjCu1b1DD6 dtLU5n4ZumsjMr3J4S9H7c0DWnv0GigAHsNEWniN7MOYxG4wOQgVkmLirRHgoT/+xPE5FgVG2 0+0e2ghhxC6XYSUpE/xvCY1Crl6wicmSBtlyPGfcdqn9urTqV+tOBS6QffP93KwOXQrEJj6CA 4KvsQxbPdi6Z8lqazEst2Y8l1iIWQDjaVVWTSJv4kNkkirUns985riIYKy5QV9SU7Ijdn5Cla bXuIxopVBzyolDDOUytftrtV6lkCTNr1obW843VKONpNssX1xwzYn2nzTADTxzp50TPiRxQig dMw41nCiPzg8FAimRvCC5pFTUmeOANSJZ9P/j+vVQIphB/X7VonD+TMAd8og/yD8LOhR+yw8I hiPLqo1Q63MmX3L7TM3fpPDscalhXUyRSfro3+Txchw2Tzlfc9x31qcmGoQxEZn1ouassmxTu Y5qDlPWfwUBN4Z9s/K46CkNPsoZNugoOa76AZo9CR4W/44Gc4GYOQ4w2nckMjbvUoyMz60Jac fuj5u8SEvDwS7IuGu+1oy2Kn8nqGkT1enrUrEdWWIhsTfC6JEw37g6ekwRYHbIYHeIhV3JsfN FeJJelm3Uo/jBV4PUMyF8W/O7HQ6205Ai6JHB6+XAFyfjKoGfqSJjCmBRg+NUHg5Th/HpARaP 4O7jES1cec1iiggLvlvUTAS8k003L2fm3tjl0xQH+N2WdE9VVqiGlKj/Odo0zWbt8WXV1pmXk 4+3fqHEcrFF61RHALtIjFjW+QqrrKVFg9qnWKcdiEdf+Z76Z2O/CROEACSWRk2I3gPTfDeIVy BisfdEakiMFp6qnHMg17DxC5/nXrMretNtHNdLHg1I6CZdpoRE= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2018 20:50:40 -0000 Hi, Benno Rice wrote: > I’ve been working on the ability to create hybrid ISO/HDD boot images for > x86, a la what Linux systems do with ISOHYBRID. Waving friendly over the fence i feel entitled to give some neighbor's review. > The general theory seems to > be that ISO images have a 32KB hunk of zeroes at the front that they > generally ignore It is called System Area. ECMA-119, 6.2.1: "The System Area shall occupy the Logical Sectors with Logical Sector Numbers 0 to 15. The System Area shall be reserved for system use. Its content is not specified by this Standard." I collected some info about possible stuffings in https://dev.lovelyhq.com/libburnia/libisofs/raw/master/doc/boot_sectors.txt > Legacy BIOS with HDD: Sees a DOS MBR [...] sees an active BSD > slice containing a variant of our BSD boot code that reads from the ISO > [...] This finds loader in the ISO filesystem The isohybrid MBRs of SYSLINUX and GRUB expect to get patched-in the block address of the El Torito no-emulation boot image. To be done by SYSLINUX program "isohybrid", or xorrisofs options -isohybrid-mbr , --grub2-mbr. They try to stay small in order to create room for fancy partition tables GPT and APM. The MBR code even begins by a no-op area where one can put APM magic numbers which happen to be harmless x86 machine code. > https://people.freebsd.org/~benno/hybrid-bootonly.iso.xz This does not look much like it addresses EFI. $ xorriso -indev hybrid-bootonly.iso -report_el_torito plain -report_system_area plain ... El Torito catalog : 19 1 El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA El Torito boot img : 1 BIOS y none 0x0000 0x00 4 20 El Torito boot img : 2 BIOS y none 0x0000 0x00 1600 24 ... MBR partition table: N Status Type Start Blocks MBR partition : 1 0x80 0xa5 1 16 UEFI 2.4, 12.3.2.1, says about El Torito: "A Platform Id of 0xEF indicates an EFI System Partition." But entry 2 of this catalog is in a section with Platform Id 0x00 (x86 BIOS). If byte 38977 (decimal) was 0xef rather than 0x00, then it would be marked as an El Torito boot image for EFI. Further: This section begins at byte address 38976 by a byte value 0x90. According to El Torito specs this means that another section follows. Correct would be value 0x91, which announces the end of the catalog. (El Torito 1.0, Figure 4, Offset 0) On HDD, EFI looks for specially marked partitions in GPT or MBR partition table. In MBR partiton table it looks for a partition of type 0xEF. (UEFI 2.4, 5.2.2) In GPT it looks for Type GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B. (UEFI 2.4, Table 19) So to mark the EFI partition, hybrid-bootonly.iso should have a MBR partition number 2 with type 0xEF, start at 512-byte block 24*2048/512 = 96, size 1600 blocks. (Strangely El Torito addresses by 2048-byte blocks but counts by 512-byte blocks. Size limit is 65535 blocks. But counts 0 and 1 mean to EFI "up to end of medium".) > I’ve tested this image under qemu OVMF/SDK-II/Tianocore is too tolerant with the EFI specs and with silently using BIOS boot equipment. Real iron EFIs insist much more in compliance. Have a nice day :) Thomas