Chao Peng writes:
From: "Kirill A. Shutemov"
Introduce 'memfd_restricted' system call with the ability to create
memory areas that are restricted from userspace access through ordinary
MMU operations (e.g. read/write/mmap). The memory content is expected to
be used through the new in-kernel
On Thu, Feb 16, 2023 at 03:21:21PM +0530, Nikunj A. Dadhania wrote:
>
> > +static struct file *restrictedmem_file_create(struct file *memfd)
> > +{
> > + struct restrictedmem_data *data;
> > + struct address_space *mapping;
> > + struct inode *inode;
> > + struct file *file;
> > +
> > +
> > int restrictedmem_bind(struct file *file, pgoff_t start, pgoff_t end,
> >struct restrictedmem_notifier *notifier, bool exclusive)
> > {
> > struct restrictedmem *rm = file->f_mapping->private_data;
> > int ret = -EINVAL;
> >
> > down_write(&rm->lock);
> >
> >
On 14/1/23 08:54, Sean Christopherson wrote:
On Fri, Dec 02, 2022, Chao Peng wrote:
The system call is currently wired up for x86 arch.
Building on other architectures (except for arm64 for some reason) yields:
CALL/.../scripts/checksyscalls.sh
:1565:2: warning: #warning syscall mem
> +static struct file *restrictedmem_file_create(struct file *memfd)
> +{
> + struct restrictedmem_data *data;
> + struct address_space *mapping;
> + struct inode *inode;
> + struct file *file;
> +
> + data = kzalloc(sizeof(*data), GFP_KERNEL);
> + if (!data)
> +
On 1/23/23 16:18, Kirill A. Shutemov wrote:
> On Mon, Jan 23, 2023 at 03:03:45PM +0100, Vlastimil Babka wrote:
>> On 12/22/22 01:37, Huang, Kai wrote:
>> >>> I argue that this page pinning (or page migration prevention) is not
>> >>> tied to where the page comes from, instead related to how the pag
On Mon, Jan 23, 2023 at 06:43:34PM +0300, Kirill A. Shutemov wrote:
> On Thu, Dec 22, 2022 at 06:15:24PM +, Sean Christopherson wrote:
> > On Wed, Dec 21, 2022, Chao Peng wrote:
> > > On Tue, Dec 20, 2022 at 08:33:05AM +, Huang, Kai wrote:
> > > > On Tue, 2022-12-20 at 15:22 +0800, Chao Pen
On 1/23/23 16:43, Kirill A. Shutemov wrote:
> On Thu, Dec 22, 2022 at 06:15:24PM +, Sean Christopherson wrote:
>> On Wed, Dec 21, 2022, Chao Peng wrote:
>> > On Tue, Dec 20, 2022 at 08:33:05AM +, Huang, Kai wrote:
>> > > On Tue, 2022-12-20 at 15:22 +0800, Chao Peng wrote:
>> > > > On Mon, D
On Monday, January 30, 2023 1:26 PM, Ackerley Tng wrote:
>
> > +static int restrictedmem_getattr(struct user_namespace *mnt_userns,
> > +const struct path *path, struct kstat *stat,
> > +u32 request_mask, unsigned int query_flags)
> {
> > +
+static int restrictedmem_getattr(struct user_namespace *mnt_userns,
+const struct path *path, struct kstat *stat,
+u32 request_mask, unsigned int query_flags)
+{
+ struct inode *inode = d_inode(path->dentry);
+ struct
On 1/24/23 00:38, Sean Christopherson wrote:
> On Mon, Jan 23, 2023, Huang, Kai wrote:
>> On Mon, 2023-01-23 at 15:03 +0100, Vlastimil Babka wrote:
>>> On 12/22/22 01:37, Huang, Kai wrote:
>> I argue that this page pinning (or page migration prevention) is not
>> tied to where the page come
On Mon, Jan 23, 2023, Huang, Kai wrote:
> On Mon, 2023-01-23 at 15:03 +0100, Vlastimil Babka wrote:
> > On 12/22/22 01:37, Huang, Kai wrote:
> > > > > I argue that this page pinning (or page migration prevention) is not
> > > > > tied to where the page comes from, instead related to how the page
>
On Mon, 2023-01-23 at 15:03 +0100, Vlastimil Babka wrote:
> On 12/22/22 01:37, Huang, Kai wrote:
> > > > I argue that this page pinning (or page migration prevention) is not
> > > > tied to where the page comes from, instead related to how the page will
> > > > be used. Whether the page is restrict
On Thu, Dec 22, 2022 at 06:15:24PM +, Sean Christopherson wrote:
> On Wed, Dec 21, 2022, Chao Peng wrote:
> > On Tue, Dec 20, 2022 at 08:33:05AM +, Huang, Kai wrote:
> > > On Tue, 2022-12-20 at 15:22 +0800, Chao Peng wrote:
> > > > On Mon, Dec 19, 2022 at 08:48:10AM +, Huang, Kai wrote:
On Mon, Jan 23, 2023 at 03:03:45PM +0100, Vlastimil Babka wrote:
> On 12/22/22 01:37, Huang, Kai wrote:
> >>> I argue that this page pinning (or page migration prevention) is not
> >>> tied to where the page comes from, instead related to how the page will
> >>> be used. Whether the page is restric
On 12/22/22 01:37, Huang, Kai wrote:
>>> I argue that this page pinning (or page migration prevention) is not
>>> tied to where the page comes from, instead related to how the page will
>>> be used. Whether the page is restrictedmem backed or GUP() backed, once
>>> it's used by current version of T
On Wed, Jan 18, 2023 at 04:16:41PM +0800,
Chao Peng wrote:
> On Tue, Jan 17, 2023 at 04:34:15PM +, Sean Christopherson wrote:
> > On Tue, Jan 17, 2023, Chao Peng wrote:
> > > On Fri, Jan 13, 2023 at 09:54:41PM +, Sean Christopherson wrote:
> > > > > + list_for_each_entry(notifier, &da
On Tue, Jan 17, 2023 at 04:34:15PM +, Sean Christopherson wrote:
> On Tue, Jan 17, 2023, Chao Peng wrote:
> > On Fri, Jan 13, 2023 at 09:54:41PM +, Sean Christopherson wrote:
> > > > + list_for_each_entry(notifier, &data->notifiers, list) {
> > > > + notifier->ops->inval
On Tue, Jan 17, 2023, Chao Peng wrote:
> On Fri, Jan 13, 2023 at 09:54:41PM +, Sean Christopherson wrote:
> > > + list_for_each_entry(notifier, &data->notifiers, list) {
> > > + notifier->ops->invalidate_start(notifier, start, end);
> >
> > Two major design issues that we overlooked lo
On Fri, Jan 13, 2023 at 09:54:41PM +, Sean Christopherson wrote:
> On Fri, Dec 02, 2022, Chao Peng wrote:
> > The system call is currently wired up for x86 arch.
>
> Building on other architectures (except for arm64 for some reason) yields:
>
> CALL/.../scripts/checksyscalls.sh
> :156
On Fri, Dec 02, 2022, Chao Peng wrote:
> The system call is currently wired up for x86 arch.
Building on other architectures (except for arm64 for some reason) yields:
CALL/.../scripts/checksyscalls.sh
:1565:2: warning: #warning syscall memfd_restricted not implemented
[-Wcpp]
Do we car
On Thu, Dec 22, 2022 at 06:15:24PM +, Sean Christopherson wrote:
> On Wed, Dec 21, 2022, Chao Peng wrote:
> > On Tue, Dec 20, 2022 at 08:33:05AM +, Huang, Kai wrote:
> > > On Tue, 2022-12-20 at 15:22 +0800, Chao Peng wrote:
> > > > On Mon, Dec 19, 2022 at 08:48:10AM +, Huang, Kai wrote:
On Thu, Dec 22, 2022 at 12:37:19AM +, Huang, Kai wrote:
> On Wed, 2022-12-21 at 21:39 +0800, Chao Peng wrote:
> > > On Tue, Dec 20, 2022 at 08:33:05AM +, Huang, Kai wrote:
> > > > > On Tue, 2022-12-20 at 15:22 +0800, Chao Peng wrote:
> > > > > > > On Mon, Dec 19, 2022 at 08:48:10AM +, H
On Thu, 2022-12-22 at 18:15 +, Sean Christopherson wrote:
> On Wed, Dec 21, 2022, Chao Peng wrote:
> > On Tue, Dec 20, 2022 at 08:33:05AM +, Huang, Kai wrote:
> > > On Tue, 2022-12-20 at 15:22 +0800, Chao Peng wrote:
> > > > On Mon, Dec 19, 2022 at 08:48:10AM +, Huang, Kai wrote:
> > >
On Wed, Dec 21, 2022, Chao Peng wrote:
> On Tue, Dec 20, 2022 at 08:33:05AM +, Huang, Kai wrote:
> > On Tue, 2022-12-20 at 15:22 +0800, Chao Peng wrote:
> > > On Mon, Dec 19, 2022 at 08:48:10AM +, Huang, Kai wrote:
> > > > On Mon, 2022-12-19 at 15:53 +0800, Chao Peng wrote:
> > But for non-
On Wed, 2022-12-21 at 21:39 +0800, Chao Peng wrote:
> > On Tue, Dec 20, 2022 at 08:33:05AM +, Huang, Kai wrote:
> > > > On Tue, 2022-12-20 at 15:22 +0800, Chao Peng wrote:
> > > > > > On Mon, Dec 19, 2022 at 08:48:10AM +, Huang, Kai wrote:
> > > > > > > > On Mon, 2022-12-19 at 15:53 +0800,
On Tue, Dec 20, 2022 at 08:33:05AM +, Huang, Kai wrote:
> On Tue, 2022-12-20 at 15:22 +0800, Chao Peng wrote:
> > On Mon, Dec 19, 2022 at 08:48:10AM +, Huang, Kai wrote:
> > > On Mon, 2022-12-19 at 15:53 +0800, Chao Peng wrote:
> > > > >
> > > > > [...]
> > > > >
> > > > > > +
> > > > > >
On Tue, 2022-12-20 at 15:22 +0800, Chao Peng wrote:
> On Mon, Dec 19, 2022 at 08:48:10AM +, Huang, Kai wrote:
> > On Mon, 2022-12-19 at 15:53 +0800, Chao Peng wrote:
> > > >
> > > > [...]
> > > >
> > > > > +
> > > > > + /*
> > > > > + * These pages are currently unmovable so don't pl
On Mon, Dec 19, 2022 at 08:48:10AM +, Huang, Kai wrote:
> On Mon, 2022-12-19 at 15:53 +0800, Chao Peng wrote:
> > >
> > > [...]
> > >
> > > > +
> > > > + /*
> > > > +* These pages are currently unmovable so don't place them into
> > > > movable
> > > > +* pageblocks (e.g
On Mon, 2022-12-19 at 15:53 +0800, Chao Peng wrote:
> >
> > [...]
> >
> > > +
> > > + /*
> > > + * These pages are currently unmovable so don't place them into
> > > movable
> > > + * pageblocks (e.g. CMA and ZONE_MOVABLE).
> > > + */
> > > + mapping = memfd->f_mapping;
> > > + mapping_set_une
On Tue, Dec 13, 2022 at 11:49:13PM +, Huang, Kai wrote:
> >
> > memfd_restricted() itself is implemented as a shim layer on top of real
> > memory file systems (currently tmpfs). Pages in restrictedmem are marked
> > as unmovable and unevictable, this is required for current confidential
> > u
>
> memfd_restricted() itself is implemented as a shim layer on top of real
> memory file systems (currently tmpfs). Pages in restrictedmem are marked
> as unmovable and unevictable, this is required for current confidential
> usage. But in future this might be changed.
>
>
I didn't dig full his
On Tue, Dec 06, 2022 at 02:57:04PM +, Fuad Tabba wrote:
> Hi,
>
> On Fri, Dec 2, 2022 at 6:18 AM Chao Peng wrote:
> >
> > From: "Kirill A. Shutemov"
> >
> > Introduce 'memfd_restricted' system call with the ability to create
> > memory areas that are restricted from userspace access through
Hi,
On Fri, Dec 2, 2022 at 6:18 AM Chao Peng wrote:
>
> From: "Kirill A. Shutemov"
>
> Introduce 'memfd_restricted' system call with the ability to create
> memory areas that are restricted from userspace access through ordinary
> MMU operations (e.g. read/write/mmap). The memory content is expe
From: "Kirill A. Shutemov"
Introduce 'memfd_restricted' system call with the ability to create
memory areas that are restricted from userspace access through ordinary
MMU operations (e.g. read/write/mmap). The memory content is expected to
be used through the new in-kernel interface by a third ke
35 matches
Mail list logo
