[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal v2: fs/iso9660: Prevent skipping CE or ST at start of conti
From: |
Thomas Schmitt |
Subject: |
Re: Proposal v2: fs/iso9660: Prevent skipping CE or ST at start of continuation area |
Date: |
Thu, 12 Jan 2023 09:45:21 +0100 |
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