Jeff Xu writes:
> On Mon, Jan 29, 2024 at 2:37 PM Jonathan Corbet wrote:
>>
>> jef...@chromium.org writes:
>>
>> > Although the initial version of this patch series is targeting the
>> > Chrome browser as its first user, it became evident during upstream
>> > discussions that we would also want
On Mon, Jan 29, 2024 at 2:37 PM Jonathan Corbet wrote:
>
> jef...@chromium.org writes:
>
> > Although the initial version of this patch series is targeting the
> > Chrome browser as its first user, it became evident during upstream
> > discussions that we would also want to ensure that the patch s
jef...@chromium.org writes:
> Although the initial version of this patch series is targeting the
> Chrome browser as its first user, it became evident during upstream
> discussions that we would also want to ensure that the patch set
> eventually is a complete solution for memory sealing and compa
Jeff Xu wrote:
> > I don't have a feeling about it.
> >
> > I spent a year engineering a complete system which exercises the maximum
> > amount of memory you can lock.
> >
> > I saw nothing like what you are describing. I had PROT_IMMUTABLE in my
> > drafts, and saw it turning into a dangerous a
On Tue, Jan 23, 2024 at 10:58 AM Theo de Raadt wrote:
>
> It's the same with MAP_MSEALABLE. I don't get it. So now there are 3
> memory types:
>- cannot be sealed, ever
>- not yet sealed
>- sealed
>
> What purpose does the first type serve? Please explain the use case.
>
On Mon, Jan 22, 2024 at 2:34 PM Theo de Raadt wrote:
>
> Jeff Xu wrote:
>
> > On Mon, Jan 22, 2024 at 7:49 AM Theo de Raadt wrote:
> > >
> > > Regarding these pieces
> > >
> > > > The PROT_SEAL bit in prot field of mmap(). When present, it marks
> > > > the map sealed since creation.
> > >
> > >
Liam R. Howlett wrote:
> * Theo de Raadt [240122 17:35]:
> > Jeff Xu wrote:
> >
> > > On Mon, Jan 22, 2024 at 7:49 AM Theo de Raadt wrote:
> > > >
> > > > Regarding these pieces
> > > >
> > > > > The PROT_SEAL bit in prot field of mmap(). When present, it marks
> > > > > the map sealed since
* Theo de Raadt [240122 17:35]:
> Jeff Xu wrote:
>
> > On Mon, Jan 22, 2024 at 7:49 AM Theo de Raadt wrote:
> > >
> > > Regarding these pieces
> > >
> > > > The PROT_SEAL bit in prot field of mmap(). When present, it marks
> > > > the map sealed since creation.
> > >
> > > OpenBSD won't be doin
Jeff Xu wrote:
> On Mon, Jan 22, 2024 at 7:49 AM Theo de Raadt wrote:
> >
> > Regarding these pieces
> >
> > > The PROT_SEAL bit in prot field of mmap(). When present, it marks
> > > the map sealed since creation.
> >
> > OpenBSD won't be doing this. I had PROT_IMMUTABLE as a draft. In my
> >
On Mon, Jan 22, 2024 at 7:49 AM Theo de Raadt wrote:
>
> Regarding these pieces
>
> > The PROT_SEAL bit in prot field of mmap(). When present, it marks
> > the map sealed since creation.
>
> OpenBSD won't be doing this. I had PROT_IMMUTABLE as a draft. In my
> research I found basically zero cir
Regarding these pieces
> The PROT_SEAL bit in prot field of mmap(). When present, it marks
> the map sealed since creation.
OpenBSD won't be doing this. I had PROT_IMMUTABLE as a draft. In my
research I found basically zero circumstances when you userland does
that. The most common circumstanc
From: Jeff Xu
This patchset proposes a new mseal() syscall for the Linux kernel.
In a nutshell, mseal() protects the VMAs of a given virtual memory
range against modifications, such as changes to their permission bits.
Modern CPUs support memory permissions, such as the read/write (RW)
and no-e
12 matches
Mail list logo
