Re: Proposal v2: fs/iso9660: Prevent skipping CE or ST at start of continuation area

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

Lidong Chen wrote:
> To test it, I am thinking to add the ISO entry in 40_custom script, then select
> the ISO from Grub menu. Is it the right way to test it? Or, is there a better way
> to it?

I have to leave the answer to the experienced GRUB developers.

Testing is my weak spot with GRUB. About 6 weeks ago i tried to demonstrate
a risk for memory fault and grub-fstest simply did not want to fail.

This reminds me that i should have tested my ISOs with grub-fstest before
posting them. To my luck the program as pulled 6 weeks ago behaves like i
predicted:

  $ ./grub-fstest ce_loop.iso ls /
  x
  $ ./grub-fstest ce_loop2.iso ls /
  ^C
  $

I waited about half a minute (on a 4 GHz Xeon) for the second run to end.
Then i aborted it by Ctrl+C.
As i am at it, i tried with Linux kernel "5.10.0-13-amd64 #1 SMP Debian
5.10.106-1 (2022-03-17)":

  # mount ce_loop.iso /mnt/iso
  mount: /mnt/iso: WARNING: source write-protected, mounted read-only.
  # ls -l /mnt/iso
  total 0
  #

No file /x but also no special messages in dmesg. Only:
  [ ...] loop: module loaded
  [ ...] ISO 9660 Extensions: RRIP_1991A

Same behavior with the ISO which drives grub-fstest into the endless loop:

  # umount /mnt/iso
  # mount ce_loop2.iso /mnt/iso
  mount: /mnt/iso: WARNING: source write-protected, mounted read-only.
  # ls -l /mnt/iso
  total 0
  #

So Linux seems to be safe against this hack.
(I will have a look into the source in order to learn how this situation
gets handled.)


> Thanks a lot for the detail instruction! It is very helpful for the test as
> well as for my learning.

That's the topic where i can be of use.
Don't hesitate to ask for explanations, pointers to the specs, or nastily
manipulated ISOs.


Have a nice day :)

Thomas