All of lore.kernel.org
 help / color / mirror / Atom feed
From: William Mills <wmills@ti.com>
To: Jeff Osier-Mixon <jefro@jefro.net>,
	Yocto Project <yocto@yoctoproject.org>,
	openembedded-core <openembedded-core@lists.openembedded.org>,
	"openembedded-devel@lists.openembedded.org"
	<openembedded-devel@lists.openembedded.org>
Subject: Re: [yocto] Subjects for YP Developer Day at ELCE
Date: Mon, 12 Sep 2016 10:48:06 -0400	[thread overview]
Message-ID: <57D6C026.1050701@ti.com> (raw)
In-Reply-To: <CA+YB3raLEFHAECfBVAspQni9fG0_X0oTPM-Z_F64FzV6PuNdUw@mail.gmail.com>


On 09/09/2016 11:51 AM, Jeff Osier-Mixon wrote:
> Hi all - we are in the planning stages for DevDay at ELCE right now,
> particularly the advanced track. This track changes every session,
> usually to cover the things we are working on hardest - for example,
> in San Diego we covered CROPS, devtool, the latest Toaster features,
> and much more.
>
> Whether you are able to attend DevDay or not, we would be grateful to
> hear your suggestions for subjects to cover in the advanced track. We
> are currently planning talks about CROPS, devtool and the ESDK,
> Toaster, wic, smack, security, and a few other things. If you have a
> burning desire to hear about something specific, please let us know.
>

*** Status and state of the art for read-only root filesystems.
1) r/o root + tmpfs only for ephemeral systems
2) r/o root + select r/w points (bind-volatile?)
3) r/o root + unionfs r/w

My interest would be in #1 & #2 as it is security related.
r/w mount would be nosuid, nodev, etc and perhaps noexec
A survey of the space should include #3 however.

I know there is a section in the developer manual for the basic 
mechanisms of r/o root but it appears a lot is left as an excrice for 
the user.  Are the full demo images etc?

*** What is the OE/YP response to Ubuntu-core?
4) Can Yocto build transactionally updated-able bundles for kernel and 
core-os/root-fs?
5) Can Yocto [cross-]build snaps or flatpaks?
6) Will snapd (or whatever flatpak needs) become 1st class ecosystem 
components?
	Ex: meta-snappy has a lot of good work but is early days
	    Currently meta-snappy disables AppArmor & seccomp
	    snapd does only light ns & cgroup control and relies on
	      AppArmor to do most of the containment
             so snapd w/o AppArmor is a demo
	    [Arch is no better BTW]

Bill


WARNING: multiple messages have this Message-ID (diff)
From: William Mills <wmills@ti.com>
To: Jeff Osier-Mixon <jefro@jefro.net>,
	Yocto Project <yocto@yoctoproject.org>,
	openembedded-core <openembedded-core@lists.openembedded.org>,
	"openembedded-devel@lists.openembedded.org"
	<openembedded-devel@lists.openembedded.org>
Subject: Re: Subjects for YP Developer Day at ELCE
Date: Mon, 12 Sep 2016 10:48:06 -0400	[thread overview]
Message-ID: <57D6C026.1050701@ti.com> (raw)
In-Reply-To: <CA+YB3raLEFHAECfBVAspQni9fG0_X0oTPM-Z_F64FzV6PuNdUw@mail.gmail.com>


On 09/09/2016 11:51 AM, Jeff Osier-Mixon wrote:
> Hi all - we are in the planning stages for DevDay at ELCE right now,
> particularly the advanced track. This track changes every session,
> usually to cover the things we are working on hardest - for example,
> in San Diego we covered CROPS, devtool, the latest Toaster features,
> and much more.
>
> Whether you are able to attend DevDay or not, we would be grateful to
> hear your suggestions for subjects to cover in the advanced track. We
> are currently planning talks about CROPS, devtool and the ESDK,
> Toaster, wic, smack, security, and a few other things. If you have a
> burning desire to hear about something specific, please let us know.
>

*** Status and state of the art for read-only root filesystems.
1) r/o root + tmpfs only for ephemeral systems
2) r/o root + select r/w points (bind-volatile?)
3) r/o root + unionfs r/w

My interest would be in #1 & #2 as it is security related.
r/w mount would be nosuid, nodev, etc and perhaps noexec
A survey of the space should include #3 however.

I know there is a section in the developer manual for the basic 
mechanisms of r/o root but it appears a lot is left as an excrice for 
the user.  Are the full demo images etc?

*** What is the OE/YP response to Ubuntu-core?
4) Can Yocto build transactionally updated-able bundles for kernel and 
core-os/root-fs?
5) Can Yocto [cross-]build snaps or flatpaks?
6) Will snapd (or whatever flatpak needs) become 1st class ecosystem 
components?
	Ex: meta-snappy has a lot of good work but is early days
	    Currently meta-snappy disables AppArmor & seccomp
	    snapd does only light ns & cgroup control and relies on
	      AppArmor to do most of the containment
             so snapd w/o AppArmor is a demo
	    [Arch is no better BTW]

Bill


  parent reply	other threads:[~2016-09-12 14:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-09 15:51 Subjects for YP Developer Day at ELCE Jeff Osier-Mixon
2016-09-09 15:54 ` Jeff Osier-Mixon
2016-09-12 14:48 ` William Mills [this message]
2016-09-12 14:48   ` William Mills
2016-09-12 15:34   ` [yocto] " Burton, Ross
2016-09-12 15:34     ` Burton, Ross
2016-09-12 15:34     ` [yocto] " Burton, Ross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57D6C026.1050701@ti.com \
    --to=wmills@ti.com \
    --cc=jefro@jefro.net \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.