linux-kernel - Re: [x86] fs, gs purpose & multicore prog

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200809060109.52419.goretux@gmail.com>
Date:	Sat, 6 Sep 2008 01:09:52 +0200
From:	Eric Lacombe <goretux@...il.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [x86] fs, gs purpose & multicore prog

Thanks again ;)

On Vendredi 05 Septembre 2008 16:51:39 Jeremy Fitzhardinge wrote:
> Eric Lacombe wrote:
[...]
> >>> - What is the purpose of MSR_FS_BASE and MSR_GS_BASE ?
> >>> (I thought they were filled with "gdt[fs_entry].base")
> >>
> >> On 64-bit, the GDT isn't large enough to hold a 64-bit offset, so it
> >> only stores the low 32-bits.  When you load a segment register with a
> >> selector, it picks up from the gdt.  If you want a full 64-bit offset,
> >> you need to write it to the msr.
> >
> > Ok, I just saw that a 64-bit base in segment descriptor is only available
> > for the system descriptor.
>
> Yes, the IDT has double-wide entries to fit 64-bit values, but they
> didn't extend that to the GDT.  Or something - I last looked at this a
> couple of months ago, and it never sticks in my brain for long.

It seems, there also are the TSS and LDT.

>
> > Ok, but how does the kernel technically run tasks on different processor
> > (or core)? My question was ambiguous, I was not assuming that I knew how
> > multiprocessor works.
>
> That's a very broad question.  A good proportion of the core kernel code
> is dedicated to doing just that.  Very roughly, at boot time it brings
> up all the cpus, and they more or less run independently each looking
> for work to do in the form of processes waiting to run on the run
> queue.  They collectively run the scheduler algorithms to work out who
> runs what when; almost everything run in the kernel is a task - both
> usermode processes and kernel threads.  Except for the stuff which isn't.

I know these things ;) but what I wanted to know is the "x86 architectural 
details". In fact, I saw that during the machine init the BIOS select a cpu on 
the bus to be the BSP (bootstrap proc). The others are then the APs (Appli 
proc). Then the kernel runs on the BSP. What I wonder is how the kernel gives 
execution flow to the APs.

Thanks.

	Eric

>
>     J

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/