OpenBMC community telecon - 11/20 Agenda

OpenBMC community telecon - 11/20 Agenda

[Brad Bishop]

IBM testing overview
Code review velocity
Boost
Open Mic
—————————
Monday, 10:00pm EDT
888-426-6840
password: 85891389

RE: OpenBMC community telecon - 11/20 Agenda

[Tanous, Ed]

Please rename/append to code review velocity:  master branch stability (assuming it was my topic from email last week)

Also, please add:
Runtime configurability:
I'd like to have a discussion around our desires for runtime configurability and runtime data-driven platform configurations.  This includes runtime configurable sensors, platform hardware configuration changes, and Chassis detection.  I'd like to have a short rundown of how we've handled these things in past codebases, and see if there's any alignment with other community needs.

Secure coding guidelines:
What secure coding guidelines are other groups/individuals using?    I'd like to have an open discussion about how to move toward more secure coding guidelines with the minimum possible interruption while alienating the minimum number of people.  Some subtopics:
1. Can anything be enforced at the master branch?  
2. Can anything be enforced by policy?  (example: reference components must be secure)
3. Does anyone have experience with automating secure coding guidelines?

(to be clear, by secure coding guidelines I mean range checked buffer interfaces, not using memory unsafe functions, exception safe code, anti stack smashing compiler flags, ect)

Thanks,

-Ed

> -----Original Message-----
> From: openbmc [mailto:openbmc-
> bounces+ed.tanous=intel.com@lists.ozlabs.org] On Behalf Of Brad Bishop
> Sent: Monday, November 20, 2017 11:27 AM
> To: OpenBMC Maillist <openbmc@lists.ozlabs.org>
> Subject: OpenBMC community telecon - 11/20 Agenda
> 
> IBM testing overview
> Code review velocity
> Boost
> Open Mic
> —————————
> Monday, 10:00pm EDT
> 888-426-6840
> password: 85891389

RE: OpenBMC community telecon - 11/20 Agenda

[Stewart Smith]

"Tanous, Ed" <ed.tanous@intel.com> writes:
> Secure coding guidelines:
> What secure coding guidelines are other groups/individuals using?    I'd like to have an open discussion about how to move toward more secure coding guidelines with the minimum possible interruption while alienating the minimum number of people.  Some subtopics:
> 1. Can anything be enforced at the master branch?  
> 2. Can anything be enforced by policy?  (example: reference components must be secure)
> 3. Does anyone have experience with automating secure coding
> guidelines?

A minimal starting point would be to run every code repository through
Coverity Scan. Setting this up with travs-ci isn't too hard (we do it
for parts of host firmware today).

Efforts to limit the damage could also be good, like strict SELinux
policy. After all, much of the current design would work quite well for
that.

-- 
Stewart Smith
OPAL Architect, IBM.

RE: OpenBMC community telecon - 11/20 Agenda

[Tanous, Ed]

> A minimal starting point would be to run every code repository through
> Coverity Scan. Setting this up with travs-ci isn't too hard (we do it for parts of
> host firmware today).
> 
> Efforts to limit the damage could also be good, like strict SELinux policy. After
> all, much of the current design would work quite well for that.

I meant more along the lines of "would the community be ok with this" more than "is it technically possible".  I think the tooling story has come a long ways in the last few years, especially for open source tools, but I know any attempt to limit what's allowed tends to lead to controversy, so I wanted to see where we all stand.

-Ed

Re: OpenBMC community telecon - 11/20 Agenda

[Andrew Jeffery]

[-- Attachment #1: Type: text/plain, Size: 1329 bytes --]

On Tue, 2017-11-21 at 01:04 +0000, Tanous, Ed wrote:
> > A minimal starting point would be to run every code repository through
> > Coverity Scan. Setting this up with travs-ci isn't too hard (we do it for parts of
> > host firmware today).
> > 
> > Efforts to limit the damage could also be good, like strict SELinux policy. After
> > all, much of the current design would work quite well for that.
> 
> I meant more along the lines of "would the community be ok with this"
> more than "is it technically possible".  I think the tooling story
> has come a long ways in the last few years, especially for open
> source tools, but I know any attempt to limit what's allowed tends to
> lead to controversy, so I wanted to see where we all stand.

I don't follow your points here - limiting the damage by defining
SELinux profiles for the distributed set of applications doesn't strike
me as anything that's controversial. Stopping applications from doing
things that they shouldn't under the guise of them "being allowed"
despite it not being intended behaviour seems like a stretch. Can you
elaborate?

Also being relatively clean with respect to Coverity seems like a
decent goal - we certainly shouldn't be using patterns that trigger it.
Why do you think this would be controversial?

Cheers,

Andrew

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]