Luca Dariz, le mar. 30 août 2022 09:23:50 +0200, a ecrit: > > Il 30/08/2022 08:17 CEST Samuel Thibault <samuel.thiba...@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
