Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

assembly routine in a unsecure fixed memory address #5

Open
AlmuHS opened this issue Jul 20, 2019 · 0 comments
Open

assembly routine in a unsecure fixed memory address #5

AlmuHS opened this issue Jul 20, 2019 · 0 comments

Comments

@AlmuHS
Copy link
Owner

AlmuHS commented Jul 20, 2019

The assembly routine to configure the AP processors (cpuboot.S), after raise startup IPI, is stored in the 0x7000 address. This address is not reserved for the BIOS, so It's possible that can be overwritten for another process.

Samuel Thibault recommended to reserve a memory page for this routine, and for the GDT and IDT structures.

<youpi> you then need to reserve a well-known 16bit area from biosmem
<youpi> i.e. make biosmem_bootstrap() etc remove it from the allocation pool
<AlmuHS> Isn't It dangerous?
<youpi> on the contrary, you *have* to do this to be on the safe side
<youpi> at that point nothing is allocated yet
<youpi> so it's the right time to reserve areas
<AlmuHS> apboot is reserved in mp_desc.c
<AlmuHS> I think
<youpi> nothing reserved AP_BOOT_ADDR
<youpi> in your source code it's just a random value
<AlmuHS> oh, It's true!! 
<AlmuHS> Now, I remember that 0x7000 is the address where I copy the routine, with a memcpy
<AlmuHS> in mp_desc.c, in start_other_cpus(), before the for loop
<youpi> line  65, I don't think you need to use M()
<youpi> because you have enabled protected mode, you have access to the full 32bit space
<youpi> line 59, I believe lgdt can take a relative address
<youpi> so you don't need to use the absolute 0x7000 address either
<youpi> see linux' arch/x86/realmode/rm/trampoline_32.S
<AlmuHS> I go to test It
<AlmuHS> but I remember that my previous test without M used to crash 
<youpi> probably because your temporary gdt misses the segmentation
<youpi> you need to make it take KERNELBASE into account
<AlmuHS> It's possible
<AlmuHS> the temporary gdt is in the bottom of the file
<youpi> yes, and it doesn't talk about KERNELBASE at all :)
<youpi> see how the real gdt is configured
<AlmuHS> I see
<AlmuHS> Really, I don't know if temporary gdt is really necessary
<youpi> you could copy the real gdt to your trampoline area
<youpi> (and idt)
<youpi> to be able to directly load the right one
<youpi> i.e. the set up would be:
<youpi> - allocate a page
<youpi> - copy the trampoline code (your cpuboot.S) there
<youpi> - copy the idt/gdt at the right place in it
<youpi> - send the IPI
<youpi> - once CPU is booted off that trampoline code, release the page
<youpi> the page needs to be allocated <= 1M
<AlmuHS> ok, I'll take notes about this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant