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:	Thu, 10 Jan 2008 18:55:49 -0800
From:	Zach Brown <zach.brown@...cle.com>
To:	Kevin Winchester <kjwinchester@...il.com>
CC:	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: hwclock failure in x86.git

I'm no expert, but I happened to notice this go by.

> The first thing I notice about the path is that ioport_32.c and the unified ioport.c use __clear_bit,
> while ioport_64.c uses clear_bit.

That doesn't seem too critical.

> +#ifdef CONFIG_X86_32
> +asmlinkage long sys_iopl(unsigned long regsp)
> +{
> +	volatile struct pt_regs *regs = (struct pt_regs *)&regsp;
> +	unsigned int level = regs->bx;
> +	unsigned int old = (regs->flags >> 12) & 3;
> +
> +	if (level > 3)
> +		return -EINVAL;
> +	/* Trying to gain more privileges? */
> +	if (level > old) {
> +		if (!capable(CAP_SYS_RAWIO))
> +			return -EPERM;
> +	}
> +	regs->flags = (regs->flags & ~X86_EFLAGS_IOPL) | (level << 12);
> +
> +	return 0;
> +}

> -asmlinkage long sys_iopl(unsigned long regsp)
> -{
> -	volatile struct pt_regs *regs = (struct pt_regs *)&regsp;
> -	unsigned int level = regs->bx;
> -	unsigned int old = (regs->flags >> 12) & 3;
> -	struct thread_struct *t = &current->thread;
> -
> -	if (level > 3)
> -		return -EINVAL;
> -	/* Trying to gain more privileges? */
> -	if (level > old) {
> -		if (!capable(CAP_SYS_RAWIO))
> -			return -EPERM;
> -	}
> -
> -	t->iopl = level << 12;
> -	regs->flags = (regs->flags & ~X86_EFLAGS_IOPL) | t->iopl;
> -	set_iopl_mask(t->iopl);
> -
> -	return 0;
> -}

Is it OK that we lost the different final steps of those two functions?
 It looks like someone might have missed the differing tail sections of
the function when copying and pasting and updating just the start of the
functions?

Sorry if I missed why this is OK and intended, I didn't read very closely.

- z
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ