linux-kernel - Re: [RFC 04/16] kgr: add testing kgraft patch

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]

Date:	Tue, 6 May 2014 13:03:18 +0200
From:	Pavel Machek <pavel@....cz>
To:	Jiri Slaby <jslaby@...e.cz>
Cc:	linux-kernel@...r.kernel.org, jirislaby@...il.com,
	Vojtech Pavlik <vojtech@...e.cz>, Michael Matz <matz@...e.de>,
	Jiri Kosina <jkosina@...e.cz>,
	Steven Rostedt <rostedt@...dmis.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: [RFC 04/16] kgr: add testing kgraft patch

Hi!

> This is intended to be a presentation of the kgraft engine, so it is
> placed into samples/ directory.
> 
> It patches sys_iopl() and sys_capable() to print an additional message
> to the original functionality.
> 
> Jiri Kosina <jkosina@...e.cz>

??

> Signed-off-by: Jiri Slaby <jslaby@...e.cz>
> Cc: Steven Rostedt <rostedt@...dmis.org>
> Cc: Frederic Weisbecker <fweisbec@...il.com>
> Cc: Ingo Molnar <mingo@...hat.com>

> +++ b/samples/kgr/kgr_patcher.c
> @@ -0,0 +1,97 @@
> +/*
> + * kgr_patcher -- just kick kgr infrastructure for test
> + *
> + *  Copyright (c) 2013-2014 SUSE
> + *   Authors: Jiri Kosina
> + *	      Vojtech Pavlik
> + *	      Jiri Slaby
> + */
> +
> +/*
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the Free
> + * Software Foundation; either version 2 of the License, or (at your option)
> + * any later version.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/kgr.h>
> +#include <linux/kallsyms.h>
> +#include <linux/sched.h>
> +#include <linux/types.h>
> +#include <linux/capability.h>
> +#include <linux/ptrace.h>
> +
> +#include <asm/processor.h>
> +
> +/*
> + * This all should be autogenerated from the patched sources
> + *
> + * IMPORTANT TODO: we have to handle cases where the new code is calling out
> + * into functions which are not exported to modules.

Is this todo still valid? Hey, its important :-).

> + * This can either be handled by calling all such functions indirectly, i.e
> + * obtaining pointer from kallsyms in the stub (and transforming all callsites
> + * to do pointer dereference), or by modifying the kernel module linker.
> + */
> +
> +asmlinkage long kgr_new_sys_iopl(unsigned int level)
> +{
> +        struct pt_regs *regs = current_pt_regs();
> +        unsigned int old = (regs->flags >> 12) & 3;
> +        struct thread_struct *t = &current->thread;
> +
> +	printk(KERN_DEBUG "kgr-patcher: this is a new sys_iopl()\n");

Tabs vs. spaces problem at more than one place.

> +KGR_PATCHED_FUNCTION(patch, SyS_iopl, kgr_new_sys_iopl);
> +
> +static bool new_capable(int cap)
> +{
> +	printk(KERN_DEBUG "kgr-patcher: this is a new capable()\n");
> +
> +        return ns_capable(&init_user_ns, cap);
> +}
> +KGR_PATCHED_FUNCTION(patch, capable, new_capable);

So for some reason when replacing sys_iopl, capable needs to be replaced, too?

> +static int __init kgr_patcher_init(void)
> +{
> +	/* removing not supported (yet?) */

So.. is it?
> +	__module_get(THIS_MODULE);
> +	kgr_start_patching(&patch);
> +	return 0;
> +}
> +
> +static void __exit kgr_patcher_cleanup(void)
> +{
> +	/* extra care needs to be taken when freeing ftrace_ops->private */
> +	printk(KERN_ERR "removing now buggy!\n");
> +}
> +

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/