bug#18289: libparted ped_disk_clobber() overwrites firmware on some arm systems

[Karsten Merker]

Hello,

the following is a discussion from the Debian bugtracking system regarding
Debian Bug#751704 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751704).
It needs involvement from parted upstream, therefore I am forwarding it to 
address@hidden

Kind regards,
Karsten

----- Forwarded message from Jim Meyering <address@hidden> -----

Date: Sun, 17 Aug 2014 14:51:41 -0700
From: Jim Meyering <address@hidden>
Subject: Bug#751704: libparted questions (was: Bug#751704: partman-base 173: 
partman overwrites
        parts of u-boot)

On Wed, Aug 13, 2014 at 12:07 PM, Karsten Merker <address@hidden> wrote:
> [CCing Otavio Salvador and Jim Meyering; the following is a short summary
>  of the situation; the full history can be read in bug #751704:
>
>  Debian-Installer uses partman for partitioning, which in turn is
>  based on libparted. On sunxi-based systems, upon writing the partition
>  table, partman/libparted overwrites parts of u-boot which are
>  located between the end of the partition table and the beginning of the
>  first partition which results in an unbootable system.
>  An attempt to solve this problem has been to conditionally set
>  PedDisk.needs_clobber to 0 in partman when it detects that it is
>  trying to write to a boot device on sunxi-based systems.]
>
> Colin Watson <address@hidden> wrote:
>> PedDisk.needs_clobber is marked as "office use only" in parted; I
>> interpret that as meaning that it really shouldn't be fiddled with
>> outside parted, even though it's technically exposed.  Could you please
>> look at fixing parted to avoid clobbering the firmware area instead?  I
>> think that would be more correct.
>
> I have no idea what is really meant with the comment
>
>   /* office use only ;-) */
>           int                 needs_clobber;
>
> in /usr/include/parted/disk.h, so I would like to ask upstream
> for clarification. Otavio, Jim: you are listed as parted
> upstream maintainers on http://www.gnu.org/software/parted/ - could
> you shed some light on this? Is it ok for an application to fiddle
> with the needs_clobber element or is this to be considered
> strictly libparted-internal?
>
>
> @Colin: If the solution is to be completely encapsulated in
> libparted, I see a large problem in how to solve the conflict between
> space after the partition table being very differently used by
> firmware for different SoCs on one side, and libparted trying to make
> sure that there are no remains of other partition table formats in
> the respective area on the other side - at least with the
> prerequisite of keeping both the current defaults (clobbering) as
> well as keeping the libparted API unchanged.  With the current "there
> is one erase size for all platforms" method in ped_disk_clobber() in
> libparted/disk.c, we inevitably end up with conflicting requirements.
> An example: the source for ped_disk_clobber() states:
>
>         /* How many sectors to zero out at each end.
>            This must be large enough to zero out the magic bytes
>            starting at offset 8KiB on a DASD partition table.
>            Doing the same from the end of the disk is probably
>            overkill, but at least on GPT, we do need to zero out
>            the final sector.  */
>
> So for at least one platform (according to Wikipedia DASD seems to be
> some s/390 format), the area at offset 8KiB has to be wiped out while
> for another (armhf/sunxi) it may not be wiped out as the u-boot SPL is
> located there and cannot be relocated because its sector address is
> hardcoded in the SoC.
>
> According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751704#25,
> similar problems (but at other offsets) come up for other SoCs.
> According to the examples listed there, for TI SoCs libparted would
> have to stop clobbering the GPT header after writing a DOS MBR, but
> could wipe the DASD area.  For a Freescale i.MX SoC libparted could
> legally clobber the GPT header, but would have to refrain from
> clobbering the areas behind it.  If you extrapolate this to the large
> number of different SoC families, to handle this completely inside
> libparted, the library would have to know what exactly is the target
> system for which it writes a partition table and special-case the
> handling for each of them.  While one might assume that the partition
> table is for an s/390 system when a DASD partition table is
> generated, this does not work as easily for the plethora of different
> architectures and systems that use DOS MBR partition tables.  This
> gets even more complicated by the fact that libparted may run on one
> platform but modify partition tables for another platform, such as
> when operating on disk images for use with emulators or when
> operating on hd-media images for different arm platforms (with
> different firmware/bootloader requirements) on one autobuild host, so
> trying to do runtime detection of the host system would still not cover
> all use cases. In the case of creating images from scratch, the problem
> can be circumvented by (re-)writing the bootloader at the end of the
> process, but when the task is to modify existing images with unknown
> content, this workaround is not available.
>
> As a conclusion, I think that the decision whether to clobber the
> area between the partition table and the beginning of the first
> partition has to be taken by the calling application and not
> internally by the library.
>
> Kind Regards,
> Karsten
> --
> Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
> sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
> Werbung sowie der Markt- oder Meinungsforschung.

Thanks for the analysis and report.

I have not had much time for parted in the last 18 months.
During that time, Phillip Susi and Brian C. Lane have been doing most
of the work.  Would you please repost this message to the debbug-based
address@hidden mailing list, so that this issue will automatically
be assigned a parted bug number, and so that they will see it?

Thanks,
Jim

----- End forwarded message -----

-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.