glibc 2.14-4 eats my data (Re: F15 ext3, eCryptfs + samba = data corruption (Re: F15 "Error mounting eCryptfs: [-5] Input/output error" on different disks))
9:04 a.m.
CC'ing devel
---------- Wiadomość przekazana dalej ----------
Od: Michał Piotrowski <mkkp4x4(a)gmail.com>
Data: 9 lipca 2011 10:59
Temat: Re: glibc 2.14-4 eats my data (Re: F15 ext3, eCryptfs + samba =
data corruption (Re: F15 "Error mounting eCryptfs: [-5] Input/output
error" on different disks))
Do: Michal Hlavinka <mhlavink(a)redhat.com>
W dniu 9 lipca 2011 10:29 użytkownik Michał Piotrowski
<mkkp4x4(a)gmail.com> napisał:
Hi,
W dniu 8 lipca 2011 20:08 użytkownik Michal Hlavinka
<mhlavink(a)redhat.com> napisał:
> Hi,
>
> please check if this package changes anything for you:
>
> http://kojipkgs.fedoraproject.org/scratch/mhlavink/task_3187528/
unfortunately there is no difference
I'm attaching valgrind output. I checked your patch and it removes
correctly all uses of memcpy so it seems that memcpy only covered the
root of the problem.
>
> thanks
>
> On Friday 08 of July 2011 18:32:55 you wrote:
>> W dniu 8 lipca 2011 18:21 użytkownik Michał Piotrowski
>>
>> <mkkp4x4(a)gmail.com> napisał:
>> > Hi,
>> >
>> > 2011/7/8 Andreas Schwab <schwab(a)redhat.com>:
>> >> Use valgrind.
>> >
>> > I attach valgrind output.
>> >
>> > ==1312== 1 errors in context 1 of 116:
>> > ==1312== Source and destination overlap in memcpy(0xaef1590, 0xaef1593,
>> > 76) ==1312== at 0x4C283B6: memcpy@(a)GLIBC_2.14
>> > (mc_replace_strmem.c:653) ==1312== by 0x401835: ??? (in
>> > /sbin/mount.ecryptfs)
>> > ==1312== by 0x5E3039C: (below main) (in /lib64/libc-2.14.so)
>>
>> I installed ecryptfs-utils-debuginfo package and now it's more readable
>>
>> ==1815== 1 errors in context 1 of 116:
>> ==1815== Source and destination overlap in memcpy(0xaef1590, 0xaef1593, 76)
>> ==1815== at 0x4C283B6: memcpy@(a)GLIBC_2.14 (mc_replace_strmem.c:653)
>> ==1815== by 0x401835: main (string3.h:52)
>>
>> > Could this be related to
>> > - Fix static linking with checking x86/x86-64 memcpy (BZ#12653)
>> > or is it an eCryptfs problem?
>> >
>> >> Andreas.
>> >>
>> >> --
>> >> Andreas Schwab, schwab(a)redhat.com
>> >> GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00
>> >> 984E
>> >> "And now for something completely different."
>> >> --
>> >> devel mailing list
>> >> devel(a)lists.fedoraproject.org
>> >> https://admin.fedoraproject.org/mailman/listinfo/devel
>> >
>> > --
>> > Best regards,
>> > Michal
>> >
>> > http://eventhorizon.pl/
>
--
Best regards,
Michal
http://eventhorizon.pl/
10:09 a.m.
>>> W dniu 8 lipca 2011 18:21 użytkownik Michał Piotrowski
>>>
>>> <mkkp4x4(a)gmail.com> napisał:
>>>> Hi,
>>>>
>>>> 2011/7/8 Andreas Schwab<schwab(a)redhat.com>:
>>>>> Use valgrind.
>>>>
>>>> I attach valgrind output.
>>>>
>>>> ==1312== 1 errors in context 1 of 116:
>>>> ==1312== Source and destination overlap in memcpy(0xaef1590, 0xaef1593,
>>>> 76) ==1312== at 0x4C283B6: memcpy@(a)GLIBC_2.14
>>>> (mc_replace_strmem.c:653) ==1312== by 0x401835: ??? (in
>>>> /sbin/mount.ecryptfs)
>>>> ==1312== by 0x5E3039C: (below main) (in /lib64/libc-2.14.so)
>>>
>>> I installed ecryptfs-utils-debuginfo package and now it's more readable
>>>
>>> ==1815== 1 errors in context 1 of 116:
>>> ==1815== Source and destination overlap in memcpy(0xaef1590, 0xaef1593, 76)
>>> ==1815== at 0x4C283B6: memcpy@(a)GLIBC_2.14 (mc_replace_strmem.c:653)
>>> ==1815== by 0x401835: main (string3.h:52)
>>>
>>>> Could this be related to
>>>> - Fix static linking with checking x86/x86-64 memcpy (BZ#12653)
>>>> or is it an eCryptfs problem?
> W dniu 8 lipca 2011 20:08 użytkownik Michal Hlavinka
> <mhlavink(a)redhat.com> napisał:
>> Hi,
>>
>> please check if this package changes anything for you:
>>
>> http://kojipkgs.fedoraproject.org/scratch/mhlavink/task_3187528/
>
> unfortunately there is no difference
I'm attaching valgrind output. I checked your patch and it removes
correctly all uses of memcpy so it seems that memcpy only covered the
root of the problem.
ok, complain about memcpy in ecryptfs-utils is gone. I've checked all of
them and I think I've fixed those which needed it. I was not able to
reproduce original problem nor valgrind complaint, so please test if
following package produces memcpy complain in valgrind output or not:
http://kojipkgs.fedoraproject.org/scratch/mhlavink/task_3190860/
Anyway, I don't think there is any problem in ecryptfs-utils, because
it's just mount helper. It's not running when files are being
encrypted/decrypted and you said it works fine when you use ecryptfs
directly (without samba). We've fixed memcpy bug in ecryptfs which is
definitely a good think, but problem is elsewhere.
If you want, you can test following build of samba which has all
occurrences of memcpy replaced by memmove. I don't dare to guess if it
changes anything, but give it a try if you want:
http://kojipkgs.fedoraproject.org/scratch/mhlavink/task_3190918/
Could you describe your environment in more details so we can try to
reproduce it? For example what ecryptfs options you use (including fstab
line if you have any), samba configuration etc...
Michal
10:40 a.m.
Hi,
W dniu 11 lipca 2011 17:09 użytkownik Michal Hlavinka
<mhlavink(a)redhat.com> napisał:
ok, complain about memcpy in ecryptfs-utils is gone. I've checked
all of
them and I think I've fixed those which needed it. I was not able to
reproduce original problem nor valgrind complaint, so please test if
following package produces memcpy complain in valgrind output or not:
http://kojipkgs.fedoraproject.org/scratch/mhlavink/task_3190860/
Your mtab handling patch fixed both issues - mount warning and data
corruption :) Huge thanks!
Anyway, I don't think there is any problem in ecryptfs-utils, because it's
just mount helper. It's not running when files are being encrypted/decrypted
and you said it works fine when you use ecryptfs directly (without samba).
We've fixed memcpy bug in ecryptfs which is definitely a good think, but
problem is elsewhere.
If you want, you can test following build of samba which has all occurrences
of memcpy replaced by memmove. I don't dare to guess if it changes anything,
but give it a try if you want:
http://kojipkgs.fedoraproject.org/scratch/mhlavink/task_3190918/
Could you describe your environment in more details so we can try to
reproduce it? For example what ecryptfs options you use (including fstab
line if you have any), samba configuration etc...
I do not think that it had any significance - it seems to me that
these options are pretty standard
mount -t ecryptfs /home/$SHARE/ /home/$SHARE/ -o
key=passphrase,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_passthrough=n,ecryptfs_fnek_sig=some_value
It's a little strange that you could not reproduce that mount warning.
Michal
--
Best regards,
Michal
http://eventhorizon.pl/
10:57 a.m.
On 07/11/2011 05:40 PM, Michał Piotrowski wrote:
Hi,
W dniu 11 lipca 2011 17:09 użytkownik Michal Hlavinka
<mhlavink(a)redhat.com> napisał:
> ok, complain about memcpy in ecryptfs-utils is gone. I've checked all of
> them and I think I've fixed those which needed it. I was not able to
> reproduce original problem nor valgrind complaint, so please test if
> following package produces memcpy complain in valgrind output or not:
>
> http://kojipkgs.fedoraproject.org/scratch/mhlavink/task_3190860/
Your mtab handling patch fixed both issues - mount warning and data
corruption :) Huge thanks!
I can't imagine *how* it could affect this, so I'd advice to monitor it
carefully if it is fixed for real. Btw, there is not only mtab patch,
but 2x memcpy -> memmove too, just not all of them as in previous test
package (which did not help).
> Could you describe your environment in more details so we can try
to
> reproduce it? For example what ecryptfs options you use (including fstab
> line if you have any), samba configuration etc...
I do not think that it had any significance - it seems to me that
these options are pretty standard
mount -t ecryptfs /home/$SHARE/ /home/$SHARE/ -o
key=passphrase,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_passthrough=n,ecryptfs_fnek_sig=some_value
It's a little strange that you could not reproduce that mount warning.
AFAIK that memcpy warning from valgrind gets triggered only if you use
"correct" -o ... option
11:05 a.m.
W dniu 11 lipca 2011 17:57 użytkownik Michal Hlavinka
<mhlavink(a)redhat.com> napisał:
On 07/11/2011 05:40 PM, Michał Piotrowski wrote:
>
> Hi,
>
> W dniu 11 lipca 2011 17:09 użytkownik Michal Hlavinka
> <mhlavink(a)redhat.com> napisał:
>>
>> ok, complain about memcpy in ecryptfs-utils is gone. I've checked all of
>> them and I think I've fixed those which needed it. I was not able to
>> reproduce original problem nor valgrind complaint, so please test if
>> following package produces memcpy complain in valgrind output or not:
>>
>> http://kojipkgs.fedoraproject.org/scratch/mhlavink/task_3190860/
>
> Your mtab handling patch fixed both issues - mount warning and data
> corruption :) Huge thanks!
I can't imagine *how* it could affect this, so I'd advice to monitor it
carefully if it is fixed for real.
Ok, so I will do. Before each time I mounted ecryptfs I get this
"Error mounting eCryptfs: [-5] Input/output error" error. Now it's
gone - I tried a few times.
Btw, there is not only mtab patch, but 2x
memcpy -> memmove too, just not all of them as in previous test package
(which did not help).
>> Could you describe your environment in more details so we can try to
>> reproduce it? For example what ecryptfs options you use (including fstab
>> line if you have any), samba configuration etc...
>
> I do not think that it had any significance - it seems to me that
> these options are pretty standard
> mount -t ecryptfs /home/$SHARE/ /home/$SHARE/ -o
>
>
key=passphrase,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_passthrough=n,ecryptfs_fnek_sig=some_value
>
> It's a little strange that you could not reproduce that mount warning.
AFAIK that memcpy warning from valgrind gets triggered only if you use
"correct" -o ... option
--
Best regards,
Michal
http://eventhorizon.pl/
11:28 a.m.
On 07/11/2011 06:05 PM, Michał Piotrowski wrote:
W dniu 11 lipca 2011 17:57 użytkownik Michal Hlavinka
<mhlavink(a)redhat.com> napisał:
> On 07/11/2011 05:40 PM, Michał Piotrowski wrote:
>>
>> Hi,
>>
>> W dniu 11 lipca 2011 17:09 użytkownik Michal Hlavinka
>> <mhlavink(a)redhat.com> napisał:
>>>
>>> ok, complain about memcpy in ecryptfs-utils is gone. I've checked all of
>>> them and I think I've fixed those which needed it. I was not able to
>>> reproduce original problem nor valgrind complaint, so please test if
>>> following package produces memcpy complain in valgrind output or not:
>>>
>>> http://kojipkgs.fedoraproject.org/scratch/mhlavink/task_3190860/
>>
>> Your mtab handling patch fixed both issues - mount warning and data
>> corruption :) Huge thanks!
>
> I can't imagine *how* it could affect this, so I'd advice to monitor it
> carefully if it is fixed for real.
Ok, so I will do. Before each time I mounted ecryptfs I get this
"Error mounting eCryptfs: [-5] Input/output error" error. Now it's
gone - I tried a few times.
yes, this is related to mtab patch, but it mounted it anyway. I was able
to reproduce this warning. It should not affect smb+ecryptfs data
corruption in any way. Btw, did you test if this version works in
valgrind or not? (the "Source and destination overlap in memcpy" warning).
btw, we should move this conversation off list if it's related only to
ecryptfs.
Michal
12:41 p.m.
W dniu 11 lipca 2011 18:28 użytkownik Michal Hlavinka
<mhlavink(a)redhat.com> napisał:
On 07/11/2011 06:05 PM, Michał Piotrowski wrote:
>
> W dniu 11 lipca 2011 17:57 użytkownik Michal Hlavinka
> <mhlavink(a)redhat.com> napisał:
>>
>> On 07/11/2011 05:40 PM, Michał Piotrowski wrote:
>>>
>>> Hi,
>>>
>>> W dniu 11 lipca 2011 17:09 użytkownik Michal Hlavinka
>>> <mhlavink(a)redhat.com> napisał:
>>>>
>>>> ok, complain about memcpy in ecryptfs-utils is gone. I've checked
all
>>>> of
>>>> them and I think I've fixed those which needed it. I was not able to
>>>> reproduce original problem nor valgrind complaint, so please test if
>>>> following package produces memcpy complain in valgrind output or not:
>>>>
>>>> http://kojipkgs.fedoraproject.org/scratch/mhlavink/task_3190860/
>>>
>>> Your mtab handling patch fixed both issues - mount warning and data
>>> corruption :) Huge thanks!
>>
>> I can't imagine *how* it could affect this, so I'd advice to monitor it
>> carefully if it is fixed for real.
>
> Ok, so I will do. Before each time I mounted ecryptfs I get this
> "Error mounting eCryptfs: [-5] Input/output error" error. Now it's
> gone - I tried a few times.
yes, this is related to mtab patch, but it mounted it anyway. I was able to
reproduce this warning. It should not affect smb+ecryptfs data corruption in
any way.
I uploaded another large file (> 1 GB) and unfortunately data
corruption problem still exist - I do not know why it worked
previously.
Btw, did you test if this version works in valgrind or not? (the
"Source and destination overlap in memcpy" warning).
Yes, I tested this version, but log isn't generated - so I suppose
there are no problems that can be found by valgrind.
btw, we should move this conversation off list if it's related only to
ecryptfs.
Michal
--
Best regards,
Michal
http://eventhorizon.pl/
11:23 a.m.
>>>>> ok, complain about memcpy in ecryptfs-utils is
gone. I've checked all
>>>>> of
>>>>> them and I think I've fixed those which needed it. I was not able
to
>>>>> reproduce original problem nor valgrind complaint, so please test if
>>>>> following package produces memcpy complain in valgrind output or
not:
>>>>>
>>>>> http://kojipkgs.fedoraproject.org/scratch/mhlavink/task_3190860/
>>>>
>>>> Your mtab handling patch fixed both issues - mount warning and data
>>>> corruption :) Huge thanks!
>>>
>>> I can't imagine *how* it could affect this, so I'd advice to monitor
it
>>> carefully if it is fixed for real.
>>
>> Ok, so I will do. Before each time I mounted ecryptfs I get this
>> "Error mounting eCryptfs: [-5] Input/output error" error. Now it's
>> gone - I tried a few times.
>
> yes, this is related to mtab patch, but it mounted it anyway. I was able to
> reproduce this warning. It should not affect smb+ecryptfs data corruption in
> any way.
I uploaded another large file (> 1 GB) and unfortunately data
corruption problem still exist - I do not know why it worked
previously.
this was expected. ecryptfs-utils is really just a mount helper, but
thanks memcpy bug in ecryptfs-utils was fixed, glibc/samba can get its
attention without distractions
You can test that samba build I've sent you. I'll try to reproduce this
too, but this requires someone with better knowledge of glibc/samba
where I can't help too much.
Michal
3:45 p.m.
W dniu 12 lipca 2011 18:23 użytkownik Michal Hlavinka
<mhlavink(a)redhat.com> napisał:
>>>>>> ok, complain about memcpy in ecryptfs-utils
is gone. I've checked all
>>>>>> of
>>>>>> them and I think I've fixed those which needed it. I was not
able to
>>>>>> reproduce original problem nor valgrind complaint, so please test
if
>>>>>> following package produces memcpy complain in valgrind output or
not:
>>>>>>
>>>>>> http://kojipkgs.fedoraproject.org/scratch/mhlavink/task_3190860/
>>>>>
>>>>> Your mtab handling patch fixed both issues - mount warning and data
>>>>> corruption :) Huge thanks!
>>>>
>>>> I can't imagine *how* it could affect this, so I'd advice to
monitor it
>>>> carefully if it is fixed for real.
>>>
>>> Ok, so I will do. Before each time I mounted ecryptfs I get this
>>> "Error mounting eCryptfs: [-5] Input/output error" error. Now
it's
>>> gone - I tried a few times.
>>
>> yes, this is related to mtab patch, but it mounted it anyway. I was able
>> to
>> reproduce this warning. It should not affect smb+ecryptfs data corruption
>> in
>> any way.
>
> I uploaded another large file (> 1 GB) and unfortunately data
> corruption problem still exist - I do not know why it worked
> previously.
>
this was expected. ecryptfs-utils is really just a mount helper, but thanks
memcpy bug in ecryptfs-utils was fixed, glibc/samba can get its attention
without distractions
You can test that samba build I've sent you.
I tested it, but it still corrupts data. On Thursday I'll do more
tests. Data corruption does not happen always, so now I'm not too sure
whether this has to do with eCryptfs itself. May simply not happened
when I tested samba on not encrypted filesystem.
I'll try to reproduce this too,
but this requires someone with better knowledge of glibc/samba where I can't
help too much.
Michal
--
Best regards,
Michal
http://eventhorizon.pl/
4680
days inactive
4681
days old
8 comments
2 participants
participants (2)
-
Michal Hlavinka -
Michał Piotrowski