[linux-morello] Re: [PATCH v4 1/1] fs: Handle exact bounds for argv and envp

On 14/11/2023 13:06, Kevin Brodsky wrote:

On 13/11/2023 19:51, Teo Couprie Diaz wrote:

...

[...]

• /*

• * The start of the string should always be properly aligned, but
  

• * its representable length might be different. Get the representable
  

• * length by using the same length that was used during allocation:
  

• * the length of the original string.
  

• * This takes into account the padding due to length change, but not that
  

• * for alignment. Thus we might not end up at the start of the next arg.
  

• * If not, we will need to take a slow
  

• * path to go through the padding.
  

Nit: the text could be rewrapped (we end up with two short lines at the end).

...

• */
  

• len = cheri_representable_length(len);

+#if (ELF_COMPAT == 0)

• str_ptr = cheri_perms_and(str_ptr,

• (CHERI_PERM_GLOBAL | CHERI_PERM_STORE | CHERI_PERM_LOAD));
  

• str_ptr = cheri_bounds_set_exact(str_ptr, len);

+#endif

• if (elf_stack_put_user(str_ptr, stack_item++))

• return -EFAULT;
  

• /*

• * If right after the end of the argument length we have a zero,
  

• * that means the argument alignment was adjusted in order to create a
  

• * representable capability in purecap, even if we are not loading a
  

• * purecap binary. This padding is added at the end, so find the real
  

• * end by going through the padding.
  

• */
  

• for (pad_len = 0; len + pad_len < MAX_ARG_STRLEN; pad_len++) {

• if (get_user(c, ustr + len + pad_len))
  

• 	return -EFAULT;
  

• if (c != '\0')
  

• 	break;
  

• }
• ustr += pad_len;
• len += pad_len;

In fact I'm realising that things are even simpler: ustr doesn't need to be incremented (this has no effect, and it's now done in create_elf_tables()), and as a result we can do away with pad_len too:

for (; len < MAX_ARG_STRLEN; len++) {         if (get_user(c, ustr + len))             return -EFAULT;         if (c != '\0')             break;     }

I can amend that too if it makes sense.

Kevin