Re: [PATCH v2 1/2] uprobes: Pass probed vaddr toarch_uprobe_analyze_insn()

[Oleg Nesterov]

Srikar,

To clarify: I am not arguing, I am asking because I know nothing about
asm/opcodes/etc.

On 06/15, Srikar Dronamraju wrote:
>
> > But this can't protect from the malicious user who does
> > mmap(64-bit-code, PROT_EXEC) from a 32-bit app, and this can confuse
> > uprobes even if that 32-bit app never tries to actually execute that
> > 64-bit-code.
> >
>
> So if we read just after we allocate uprobe struct but before
> probe insertion, then we dont need to check this for each process.
>
> So if the library was 64 bit mapped in 32 bit process and has a valid
> instruction for 64 bit, then we just check for valid 64 bit instructions
> and allow insertion of the breakpoint even in the 32 bit process.

And what happens if this insn is not valid from validate_insn_32bits()
pov and that 32-bit application tries to execute it? Or vice versa,
see below.

> Here is a very crude implementation of the same.
> Also this depends on read_mapping_page taking NULL as an valid argument
> for file. As a side-effect we can do away with UPROBE_COPY_INSN which
> was set and read at just one place.
>
> 1. Move the copy_insn to just after alloc_uprobe.
> 2. Assume that copy_insn can work without struct file
> ...
> 5. Move the analyze instruction to before the actual probe insertion.

OK, this is what I think we should do anyway (at least try to do).

> 3. Read the elfhdr for the file.
> 4. Pass the elfhdr to the arch specific analyze insn

This assumes that everything is elf. Why? An application is free to
create a file in any format and do mmap(PROT_EXEC).

But OK, probably we can restrict uprobe_register() to work only with
elf files which do not mix 32/64 bits.




My concern is, are you sure an evil user can't confuse uprobes and
do something bad?

Just to explain what I mean. For example, we certainly do not want
to allow to probe the "syscall" insn, at least with the current
implementation. So I assume that validate_insn_64bits("syscall")
must fail.

Are you sure that validate_insn_32bits("syscall") will fail too?

Of course, I am not asking about "syscall" in particular. In general,
suppose that, say, validate_insn_64bits() returns true. Are you sure
this insn can't do something different and harmful if it is executed
by __USER32_CS task?

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/