GNU bug report logs -
#18289
libparted ped_disk_clobber() overwrites firmware on some arm systems
Previous Next
To reply to this bug, email your comments to 18289 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-parted <at> gnu.org:
bug#18289; Package
parted.
(Mon, 18 Aug 2014 06:42:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Karsten Merker <merker <at> debian.org>:
New bug report received and forwarded. Copy sent to
bug-parted <at> gnu.org.
(Mon, 18 Aug 2014 06:42:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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
bug-parted <at> gnu.org.
Kind regards,
Karsten
----- Forwarded message from Jim Meyering <jim <at> meyering.net> -----
Date: Sun, 17 Aug 2014 14:51:41 -0700
From: Jim Meyering <jim <at> meyering.net>
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 <merker <at> debian.org> 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 <cjwatson <at> debian.org> 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
bug-parted <at> gnu.org 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.
Information forwarded
to
bug-parted <at> gnu.org:
bug#18289; Package
parted.
(Mon, 18 Aug 2014 17:01:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 18289 <at> debbugs.gnu.org (full text, mbox):
On Mon, Aug 18, 2014 at 08:19:17AM +0200, Karsten Merker wrote:
> 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
> bug-parted <at> gnu.org.
Thanks for forwarding this. parted should only be clobbering these extra
sectors when a new disklabel is applied (eg. mklabel in the ui) which, I
think, is the appropriate thing to do.
If you are operating on an existing disklabel and want to preserver a
boot loader in the space before the 1st partition you shouldn't be
calling ped_disk_new_fresh(). If you are creating a new disklabel then
any boot loader code should be installed after partitioning.
I don't think parted needs any changes.
--
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)
Information forwarded
to
bug-parted <at> gnu.org:
bug#18289; Package
parted.
(Mon, 18 Aug 2014 20:09:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 18289 <at> debbugs.gnu.org (full text, mbox):
On Mon, Aug 18, 2014 at 09:59:49AM -0700, Brian C. Lane wrote:
> On Mon, Aug 18, 2014 at 08:19:17AM +0200, Karsten Merker wrote:
> > 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
> > bug-parted <at> gnu.org.
>
> Thanks for forwarding this. parted should only be clobbering these extra
> sectors when a new disklabel is applied (eg. mklabel in the ui) which, I
> think, is the appropriate thing to do.
>
> If you are operating on an existing disklabel and want to preserver a
> boot loader in the space before the 1st partition you shouldn't be
> calling ped_disk_new_fresh(). If you are creating a new disklabel then
> any boot loader code should be installed after partitioning.
>
> I don't think parted needs any changes.
Hello,
thanks for your swift reply. I fully understand your position,
but unfortunately things on arm are fundamentally different from
the PC world. U-Boot is more of a BIOS than a bootloader like
GRUB; it is highly board specific and handles low-level stuff
such as setting the IO pinmuxing for the specific board and
configuring the DRAM controller. Without it, the board is
completely dead from a user perspective.
On a PC, the BIOS is always available in ROM/Flash even when all
disk devices have been wiped and the user can still select some
other device (such as the network, a CDROM drive or a USB memory
stick) to boot from. On the arm systems we are talking about,
there is no ROM BIOS and the u-boot image on the SD card (or on
an eMMC chip) is the only way to interact with the system at all.
The usual case is that the u-boot image is written raw onto the
storage medium, i.e. there is no partition table or filesystem
on it by default, so we need to create a new disklabel in the
installer.
You are fully right that normally a bootloader should be
installed after partitioning. This works well for the case of a
bootloader that uses universally available BIOS functions and is
not hardware-specific, such as is the case on PCs. In the case
of u-boot on the other hand, in PC-lingo we would have to provide
the installer with the ability to flash the BIOS for every PC
model on the market as part of the operating system installation,
which is not feasible. We might be able to do that for a small
selection of devices, but not for all of them --> we need to keep
the u-boot image that is on the device even when creating a new
disklabel, but we are unsure what is the best way to handle this.
The approach in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751704#60
(setting PedDisk.needs_clobber to 0 before calling ped_disk_commit
for specific devices) works in practice, but the question was
whether it is ok for the calling application to fiddle around with
the needs_clobber flag, or whether we should take some other
approach.
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.
Information forwarded
to
bug-parted <at> gnu.org:
bug#18289; Package
parted.
(Wed, 27 Aug 2014 22:08:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 18289 <at> debbugs.gnu.org (full text, mbox):
On Mon, Aug 18, 2014 at 10:07:59PM +0200, Karsten Merker wrote:
> You are fully right that normally a bootloader should be
> installed after partitioning. This works well for the case of a
> bootloader that uses universally available BIOS functions and is
> not hardware-specific, such as is the case on PCs. In the case
> of u-boot on the other hand, in PC-lingo we would have to provide
> the installer with the ability to flash the BIOS for every PC
> model on the market as part of the operating system installation,
> which is not feasible. We might be able to do that for a small
> selection of devices, but not for all of them --> we need to keep
> the u-boot image that is on the device even when creating a new
> disklabel, but we are unsure what is the best way to handle this.
>
> The approach in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751704#60
> (setting PedDisk.needs_clobber to 0 before calling ped_disk_commit
> for specific devices) works in practice, but the question was
> whether it is ok for the calling application to fiddle around with
> the needs_clobber flag, or whether we should take some other
> approach.
Hello Brian,
may I ping you again regarding the last paragraph? The question
whether this approach is ok from a libparted point of view is
still open and I would very much apprechiate your feedback on it.
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.
Information forwarded
to
bug-parted <at> gnu.org:
bug#18289; Package
parted.
(Wed, 27 Aug 2014 22:17:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 18289 <at> debbugs.gnu.org (full text, mbox):
On Thu, Aug 28, 2014 at 12:06:21AM +0200, Karsten Merker wrote:
> On Mon, Aug 18, 2014 at 10:07:59PM +0200, Karsten Merker wrote:
>
> > You are fully right that normally a bootloader should be
> > installed after partitioning. This works well for the case of a
> > bootloader that uses universally available BIOS functions and is
> > not hardware-specific, such as is the case on PCs. In the case
> > of u-boot on the other hand, in PC-lingo we would have to provide
> > the installer with the ability to flash the BIOS for every PC
> > model on the market as part of the operating system installation,
> > which is not feasible. We might be able to do that for a small
> > selection of devices, but not for all of them --> we need to keep
> > the u-boot image that is on the device even when creating a new
> > disklabel, but we are unsure what is the best way to handle this.
> >
> > The approach in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751704#60
> > (setting PedDisk.needs_clobber to 0 before calling ped_disk_commit
> > for specific devices) works in practice, but the question was
> > whether it is ok for the calling application to fiddle around with
> > the needs_clobber flag, or whether we should take some other
> > approach.
>
> Hello Brian,
>
> may I ping you again regarding the last paragraph? The question
> whether this approach is ok from a libparted point of view is
> still open and I would very much apprechiate your feedback on it.
Oops, sorry about that. I think that's probably ok. I'm not sure what
other option you have.
--
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)
This bug report was last modified 10 years and 297 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.