aboutsummaryrefslogtreecommitdiff
path: root/crypto/ecb.c
diff options
context:
space:
mode:
authorRoland McGrath <roland@redhat.com>2007-03-23 14:26:33 -0700
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-03-23 15:32:58 -0700
commit6ea65ff79ceb36a1195761be857da1fdf9878450 (patch)
treeca843e86b273db1d0cd6be4e5a3f4b93ca888562 /crypto/ecb.c
parent2e7c28382b8426c6b7ac6f147177a664065f95f4 (diff)
[PATCH] i386: clear segment register padding in core dumps
The segment register slots in struct pt_regs are padded to 32 bits. Some of these are stored with instructions like "pushl %es", which leaves the high 16 bits as they were. So the high bits of these fields in struct pt_regs contain kernel stack garbage. These bits are ignored by everything and never leak to user space, except in core dumps. The user struct pt_regs is always at the base of the thread's kernel stack and so it seems unlikely the information that leaks from here is ever worthwhile so as to be a security concern, but I'm not sure about that. It has been this way for ages; userland consumers of core dumps all mask off these high bits themselves. So it is not urgent. This change masks off the padding bits of the segment register slots in core dumps. ptrace already masks off these high bits, so this makes the values in core dumps consistent with what ptrace would report just before the process died. As I read the processor manuals, the cs and ss values will always be padded with zero bits rather than stack garbage. But unlike "pushl %es", this is not simple to test with a userland program. So I added the two instructions rather than wonder if they are really never necessary. I think that x86_64 does not have this problem (for either 32-bit or 64-bit processes). It only uses "mov" instructions from segment registers, which zero-extend. Signed-off-by: Roland McGrath <roland@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'crypto/ecb.c')
0 files changed, 0 insertions, 0 deletions