> 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, what I mean is that the same value could be taken from msgh_size, but MIG only uses the syscall parameter. Also the other option, i.e. deprecating msgh_size, would be ok, I was just thinking about a more uniform interface, now that messages can have a different size in kernel and user space. 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). I didn't see any upper bound on the message size, maybe there could be one for inline data (4K?). > > > As far as I understand, these routines should use stac/clac if the SMAP cpu > > feature is supported on x86 as the Linux counterparts, so we would catch > > these cases earlier. > > Yes. > > > I didn't find anything related to cpu features yet, > > git grep -i feature i386/ silly me, I did see CPU_HAS_FEATURE in pmap, but then I forgot... > > Is there a minimum that we can assume to have? > > I'd rather not. And particularly not SMAP which is very recent :) Ok. So a good way to test the worst case could be using qemu with -cpu base. Luca
