linux-kernel - Re: compat ioctl32 for /dev/snapshot?

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, 14 Jul 2009 10:57:06 +0400
From:	Michael Tokarev <mjt@....msk.ru>
To:	Pavel Machek <pavel@....cz>
CC:	Arnd Bergmann <arnd@...db.de>,
	Linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: compat ioctl32 for /dev/snapshot?

Pavel Machek wrote:
[]
>> In order to (try to) check if it works or not, another userspace
>> component has to be fixed to support 32/64 bit mode.  It's uswsusp,
>> which currently assumes swap space structures are all 32bits.  So
>> it isn't possible to immediately check if it works or not -- just
>> ioctl(s) aren't enough.  Complete fix (kernel+user space) requires
>> both, fixing all remaining (yet unknown) issues in old and new
>> code on the way.
> 
> Well, there seems to be single structure in s2disk; that does not seem
> that hard to fix.

Which one do you mean?

Also, do you want to make it 32/64 bit clean in userspace too, so that
an image produced by 32-bit s2disk can be read by 64bit resume and
vise versa?  Sure it's good thing to have, to avoid possible issues
with 32bit initramfs on 64bit system for example...

>> For now, I think it's best to let Pavel or Rafael to decide what
>> to do with all this.
> 
> I don't currently have easy access to 64bit machine, so I guess it is
> up to someone else.
[]

Ok.  I applied Arnd's patch again (with two fixes -- adding
#include <linux/compat.h> and s/compat_ulong/compat_ulong_t/ and
tried suspend/resume cycle with unmodified uswsusp-0.8.  Suspend
worked (seemengly - it reported about 4G pages written, on a
machine with 4G memory) but resume failed after reading all the
pages and submitting them to /dev/snapshot.

I've no time right now to debug it further (and again, yet again:
I don't know the code, neither kernel nor userspace part).

So I'd merge this change for now and deal with possible bugs later.

At least there's no failed ioctl()s on /dev/snapshot anymore,
neither at suspend nor at resume time.

/mjt
--
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/