[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 10/15] x86_64: expand and shrink messages in copy{in, out}msg
From: |
Samuel Thibault |
Subject: |
Re: [PATCH 10/15] x86_64: expand and shrink messages in copy{in, out}msg routines |
Date: |
Tue, 30 Aug 2022 13:41:37 +0200 |
User-agent: |
NeoMutt/20170609 (1.8.3) |
Luca Dariz, le mar. 30 août 2022 09:23:50 +0200, a ecrit:
> > Il 30/08/2022 08:17 CEST Samuel Thibault <samuel.thibault@gnu.org> ha
> > scritto:
> > Luca, le mar. 30 août 2022 07:57:23 +0200, a ecrit:
> > > Il 28/08/22 15:13, Samuel Thibault ha scritto:
> > > > This was breaking the 32bit kernel case. I have pushed a fix for that,
> > > > that does this move of setting msgh_size to copyinmsg itself.
> > >
> > > The 32-bit case was breaking because it needed an updated MIG,
> >
> > ? You mean that the kernel would have to trust userland to set msgh_size
> > properly? We cannot do that :)
>
> The kernel is already taking the send size as a syscall parameter,
Yes, and that's what we use for performing the copy, i.e. that's the
size we actually verified as being valid. That's why I made copyinmsg
put it in msgh_size, like was previously done by the callers.
> About trusting this value, maybe the kernel should check whether the whole
> incoming message is in a valid range for the task (the same validation would
> be useful to all syscall and ipc).
That's already what it does with copyin, doesn't it?
> I didn't see any upper bound on the message size, maybe there could be one
> for inline data (4K?).
Uh, we really need to set an upper bound indeed. Maybe check what is
actually used at most, and use that (and document it).
Samuel