bug-hurd
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]