| 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
| ||
|
Message-ID: <m1u05jr014.fsf@ebiederm.dsl.xmission.com> Date: Fri, 14 Jul 2006 21:59:19 -0600 From: ebiederm@...ssion.com (Eric W. Biederman) To: Andrew Morton <akpm@...l.org> Cc: <linux-kernel@...r.kernel.org>, <fastboot@...l.org> Subject: [PATCH] machine_kexec.c: Fix the description of segment handling. One of my original comments in machine_kexec was unclear and this should fix it. Signed-off-by: Eric W. Biederman <ebiederm@...ssion.com> --- Be very careful with this patch. It seems to be surrounded by a somebody else's problem field. I wrote it months ago, and then forgot it. I started writing this email message several days ago and then forgot it. Hopefully including this patch won't cause this effect to spread and cause the entire kernel to be universally treated as somebody else's problem. :) arch/i386/kernel/machine_kexec.c | 13 +++++-------- arch/x86_64/kernel/machine_kexec.c | 13 +++++-------- 2 files changed, 10 insertions(+), 16 deletions(-) diff --git a/arch/i386/kernel/machine_kexec.c b/arch/i386/kernel/machine_kexec.c index 511abe5..a696f93 100644 --- a/arch/i386/kernel/machine_kexec.c +++ b/arch/i386/kernel/machine_kexec.c @@ -189,14 +189,11 @@ NORET_TYPE void machine_kexec(struct kim memcpy((void *)reboot_code_buffer, relocate_new_kernel, relocate_new_kernel_size); - /* The segment registers are funny things, they are - * automatically loaded from a table, in memory wherever you - * set them to a specific selector, but this table is never - * accessed again you set the segment to a different selector. - * - * The more common model is are caches where the behide - * the scenes work is done, but is also dropped at arbitrary - * times. + /* The segment registers are funny things, they have both a + * visible and an invisible part. Whenever the visible part is + * set to a specific selector, the invisible part is loaded + * with from a table in memory. At no other time is the + * descriptor table in memory accessed. * * I take advantage of this here by force loading the * segments, before I zap the gdt with an invalid value. diff --git a/arch/x86_64/kernel/machine_kexec.c b/arch/x86_64/kernel/machine_kexec.c index 83fb24a..ba9b571 100644 --- a/arch/x86_64/kernel/machine_kexec.c +++ b/arch/x86_64/kernel/machine_kexec.c @@ -207,14 +207,11 @@ NORET_TYPE void machine_kexec(struct kim __flush_tlb(); - /* The segment registers are funny things, they are - * automatically loaded from a table, in memory wherever you - * set them to a specific selector, but this table is never - * accessed again unless you set the segment to a different selector. - * - * The more common model are caches where the behide - * the scenes work is done, but is also dropped at arbitrary - * times. + /* The segment registers are funny things, they have both a + * visible and an invisible part. Whenever the visible part is + * set to a specific selector, the invisible part is loaded + * with from a table in memory. At no other time is the + * descriptor table in memory accessed. * * I take advantage of this here by force loading the * segments, before I zap the gdt with an invalid value. -- 1.4.1.gac83a - 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/
Powered by blists - more mailing lists