Add missing system calls for ADC driver subsystem

[andrewboie]

• Added syscalls for adc_channel_setup() and adc_read()
• adc_read_async() support will require significant additional refactoring and possibly some kernel-side memory allocations, punting for this PR
• Increased privileged stack size to fix observed stack overflows

Tested on frdm_k64f and sam_e70_xplained

Partial fix for #14084

[codecov-io]

Codecov Report

Merging #15001 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #15001   +/-   ##
=======================================
  Coverage   52.92%   52.92%           
=======================================
  Files         309      309           
  Lines       45268    45268           
  Branches    10451    10451           
=======================================
  Hits        23956    23956           
  Misses      16544    16544           
  Partials     4768     4768

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9e81cbe...14c5054. Read the comment docs.

[ceolin]

shouldn't copy from src->options ?

[andrewboie]

at this point in the code, src and dst have the same contents since we just previously copied src (a pointer into user memory) into dst (a pointer on the supervisor mode call stack)

[ceolin]

this is not making sense to me though. Why do you need this check and copy then ? dst is an uninitialised variable:

Z_SYSCALL_HANDLER(adc_read, dev, user_sequence)
{
	struct adc_sequence sequence;
	struct adc_sequence_options options;

	Z_OOPS(Z_SYSCALL_DRIVER_ADC(dev, read));
	Z_OOPS(Z_SYSCALL_VERIFY_MSG(copy_sequence(&sequence, &options,
					(struct adc_sequence *)user_sequence),
				    "invalid ADC sequence"));
	if (sequence.options != NULL) {
		Z_OOPS(Z_SYSCALL_VERIFY_MSG(sequence.options->callback == NULL,
			    "ADC sequence callbacks forbidden from user mode"));
	}

	return z_impl_adc_read((struct device *)dev, &sequence);
}

[andrewboie]

you need to copy user_sequence (lives somehere in user memory) into kernel memory (sequence) in order to prevent TOCTOU issues. notice I am not passing user_sequence to the syscall implementation.

[ceolin]

yeah, but this code is not copying user sequence, it is copying sequence that was allocate in this function stack and was not initialized. Well, it seems that I'm not understanding it :/

[andrewboie]

you're not reading the code right, you have it backwards. user_sequence=src sequence=dst

[ceolin]

that is the problem, in copy_sequence you are not using user_sequence=src but sequece=dst

static bool copy_sequence(struct adc_sequence *dst,
			  struct adc_sequence_options *options,
			  struct adc_sequence *src)
{
...

	if (dst->options) { /* dst == sequence that is no uninitialised */
		if (z_user_from_copy(options, dst->options,
				sizeof(struct adc_sequence_options)) != 0) {
			printk("couldn't copy adc_options struct\n");
			return false;
		}
		dst->options = options;
	}
...
}

[andrewboie]

Please post the whole function.

You will see that immediately before the check to dst->options, all of src got copied into dst. It is initialized.

dst->options points to a different memory buffer provided by the user, we copy it and then update dst->options.

[ceolin]

I missed that first copy, damn it. My bad, sorry for all noise

[ceolin]

Looks ok, only one comment to check.

[agross-oss]

aside from flavio's comment, this looks good.

[ioannisg]

I agree with the rationale, here, but, I see that the priv stack starts getting too big

[andrewboie]

not sure what you mean by too big
The actual minimum value for this, that satisfies maximum depth for all kernel/driver syscalls is unknown at this time.

[ioannisg]

Looks fine to me (only did a high-level pass)

[anangl]

I apologize I haven't managed to add this comment before this PR got merged.
Just to ensure it wasn't overlooked. The ADC API allows to provide a callback also to the adc_read function, not only to adc_read_async. I thought this excluded adc_read from being a candidate for a system call. And that's why I haven't provided system calls for this API when reworking it (#7691 (comment)).