Date: Sat, 15 Jan 2022 13:54:31 +0000 From: bugzilla-noreply@freebsd.org To: standards@FreeBSD.org Subject: [Bug 255072] boot (legacy): no progress beyond 'BIOS DRIVE D: is disk1' Message-ID: <bug-255072-99-1I8EccMjse@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-255072-99@https.bugs.freebsd.org/bugzilla/> References: <bug-255072-99@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D255072 --- Comment #30 from Toomas Soome <tsoome@freebsd.org> --- (In reply to spell from comment #28) just remind me, what version of freebsd is this, current? the bbuf assignment test is suggesting we do get some sort of buffer overrun there. ok, V86_IO_BUFFER is at 0x8000 and with size 0x1000 (4KB), BIO_BUFFER_SIZE = is 0x4000 (16KB), the buffer is allocated from bss segment (see bio.c bio_buffer[BIO_BUFFER_SIZE]. so, both areas should be safe - in low memory and therefore usable by BIOS = INT calls. Now the catch there is, the btx (our V86 mode "kernel") is at 0x9000, and loader is at 0xA000 (code start, followed by data, bss segments and then stack). So, if the INT will write past 0x8000 + 0x1000, it will corrupt BTX= ; if INT will write past end of bio_buffer, it will corrupt next variable in BSS. So, if you are using IO size 512, then both buffer spaces should be just fi= ne. If the INT call will actually use more of that memory, then we may be in trouble. I guess the only way to detect how much buffer memory was actually used, can be detected by storing know value into entire buffer, and test how big are it is where the buffer is changed. With no buffer overrun, we would expect exactly the IO size to be changed... --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-255072-99-1I8EccMjse>