On Wed, Jun 25, 2025 at 10:56:04AM +0200, Dmitry Vyukov wrote:
On Tue, 24 Jun 2025 at 22:04, Sasha Levin wrote:
>9. I see that syscalls and ioctls say:
>KAPI_CONTEXT(KAPI_CTX_PROCESS | KAPI_CTX_SLEEPABLE)
>Can't we make this implicit? Are there any other options?
Maybe? I wasn't sure how we'd
On Tue, 24 Jun 2025 at 16:05, Cyril Hrubis wrote:
>
> Hi!
> > 6. What's the goal of validation of the input arguments?
> > Kernel code must do this validation anyway, right.
> > Any non-trivial validation is hard, e.g. even for open the validation
> > function
> > for file name would need to have
On Tue, 24 Jun 2025 at 22:04, Sasha Levin wrote:
> >9. I see that syscalls and ioctls say:
> >KAPI_CONTEXT(KAPI_CTX_PROCESS | KAPI_CTX_SLEEPABLE)
> >Can't we make this implicit? Are there any other options?
>
> Maybe? I wasn't sure how we'd describe somthing like getpid() which
> isn't supposed to
Hi!
> > >6. What's the goal of validation of the input arguments?
> > >Kernel code must do this validation anyway, right.
> > >Any non-trivial validation is hard, e.g. even for open the validation
> > >function
> > >for file name would need to have access to flags and check file precense
> > >for
On Wed, Jun 25, 2025 at 10:52:46AM +0200, Dmitry Vyukov wrote:
On Tue, 24 Jun 2025 at 22:04, Sasha Levin wrote:
>6. What's the goal of validation of the input arguments?
>Kernel code must do this validation anyway, right.
>Any non-trivial validation is hard, e.g. even for open the validation f
On Tue, 24 Jun 2025 at 22:04, Sasha Levin wrote:
> >3. To reduce duplication we could use more type information, e.g. I was
> >always
> >frustrated that close is just:
> >
> >SYSCALL_DEFINE1(close, unsigned int, fd)
> >
> >whereas if we would do:
> >
> >typedef int fd_t;
> >SYSCALL_DEFINE1(close
On Tue, 24 Jun 2025 at 22:04, Sasha Levin wrote:
> >6. What's the goal of validation of the input arguments?
> >Kernel code must do this validation anyway, right.
> >Any non-trivial validation is hard, e.g. even for open the validation
> >function
> >for file name would need to have access to fl
On Mon, Jun 23, 2025 at 03:28:03PM +0200, Dmitry Vyukov wrote:
Nice!
A bag of assorted comments:
1. I share the same concern of duplicating info.
If there are lots of duplication it may lead to failure of the whole effort
since folks won't update these and/or they will get out of sync.
If a sys
Hi!
> 6. What's the goal of validation of the input arguments?
> Kernel code must do this validation anyway, right.
> Any non-trivial validation is hard, e.g. even for open the validation function
> for file name would need to have access to flags and check file precense for
> some flags combinatio
Hi!
> > You may wonder if such kind of tests are useful at all, since quite a
> > few of these errors are checked for and generated from a common
> > functions. There are at least two cases I can think of. First of all it
> > makes sure that errors are stable when particular function/subsystem is
>
Nice!
A bag of assorted comments:
1. I share the same concern of duplicating info.
If there are lots of duplication it may lead to failure of the whole effort
since folks won't update these and/or they will get out of sync.
If a syscall arg is e.g. umode_t, we already know that it's an integer
of
On Wed, Jun 18, 2025 at 02:29:37PM -0700, Kees Cook wrote:
On Sat, Jun 14, 2025 at 09:48:39AM -0400, Sasha Levin wrote:
This patch series introduces a framework for formally specifying kernel
APIs, addressing the long-standing challenge of maintaining stable
interfaces between the kernel and use
On Sat, Jun 14, 2025 at 09:48:39AM -0400, Sasha Levin wrote:
> This patch series introduces a framework for formally specifying kernel
> APIs, addressing the long-standing challenge of maintaining stable
> interfaces between the kernel and user-space programs. As outlined in
> previous discussions
On Sat, 14 Jun 2025 09:48:39 -0400
Sasha Levin wrote:
> This patch series introduces a framework for formally specifying kernel
> APIs, addressing the long-standing challenge of maintaining stable
> interfaces between the kernel and user-space programs. As outlined in
> previous discussions about
This patch series introduces a framework for formally specifying kernel
APIs, addressing the long-standing challenge of maintaining stable
interfaces between the kernel and user-space programs. As outlined in
previous discussions about kernel ABI stability, the lack of
machine-readable API specific
15 matches
Mail list logo
