Re: [DNG] Google abandons UEFI in Chromebooks

2017-11-03 Thread Alessandro Selli 
On Fri, 3 Nov 2017 at 17:15:02 +0100
Alessandro Selli  wrote:

> On Fri, 3 Nov 2017 at 00:54:44 -0400
> "taii...@gmx.com"  wrote:

[...]

>> there isn't anything special about their laptops that justifies the $2K 
>> price tag  


  Besides, just to futher prove how little you are to be trusted, this is not
the first time you write this blatant lie about the cost of a Puri.sm
top-of-the-line laptop:

https://puri.sm/shop/librem-15/

Librem 15

$1,599.00


  This is a secondary matter compared to people's freedom and privacy, of
course, but it's worth pointing out who's doing the lying.


Alessandro
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-11-03 Thread Alessandro Selli 
On Fri, 3 Nov 2017 at 00:52:30 -0400
"taii...@gmx.com"  wrote:

> In the interest of not starting a big argument again this will by my 
> last reply on this thread.
> 
> On 11/02/2017 01:14 PM, Alessandro Selli wrote:
>
>>They are fully worth it.  
> Certainly not for the price they are charging, for $2K one could buy 5 
> Lenovo G505S laptops which are owner controlled with no ME/PSP, an open 
> source init process (no FSP) or hardware code signing enforcement.

   They certainly are worth it as ME is fully and demonstrably disabled on
their systems and it taked about a dozen Lenovo G505S to sustain the workload
a 6th gen i7 does.

>> «the LibreM contains a proprietary BIOS»
>>
>>Wrong.  I already wrote about it but I see your pathological hate for
>> anything other than Talos/IBM is just too strong, facts cannot stop you
>> from spreading lies:  
> I don't like IBM, but I accept that POWER is the best option and their 
> marketing of it is honest.

  And what do the personal tastes of an unknown person prove?

> I don't like purism and will never support them until they change their 
> marketing to be actually honest and stop pretending that they can make 
> free an intel CPU some vague time in the future.

  They are not pretending, they proved their point.  You're free do prove
your own on a technical basis.

>> https://puri.sm/faq/
>>
>> Technical & Advanced
>> Can I buy a Librem with a proprietary BIOS/UEFI?
>>
>> No. We ship with the free software firmware coreboot. We don’t ship
>> Librem 13 or Librem 15 with any proprietary BIOS/UEFI.  
> It isn't libre and it isn't free software as the hardware and memory 
> init process is entirely done by Intel's FSP binary blob.

  No, the signature check of the bootloader is, nothing else.  Read nefooce
commenting out of ignorance:

https://puri.sm/posts/deep-dive-into-intel-me-disablement/

When the ME is disabled using the “HAP” method (thanks to the Positive
Technologies for discovering this trick), however, it doesn’t throw
an error “because it can’t load a module”: it actually stops itself
in a graceful manner, by design.

The two approaches are similar in that they both stop the execution
of the ME during the hardware initialization (BUP) phase, but with
the ME disabled through the HAP method, the ME stops on its own,
without putting up a fight, potentially disabling things that the
forceful “me_cleaner” approach, with the “unexpected error” state,
wouldn’t have disabled. The PCI interface for example, is entirely
unable to communicate with the ME processor, and the status of the ME
is not even retrievable.

  So, again, I urge you to stop spreading deliberate lies and misinformation.

> They call their laptops the "LibreM" - what is libre about them?
>
> Fail to include the ME firmware binary in the firmware and your purism 
> laptop will shut down in 30 minutes "disabled"

  It does not, read the docs before^Winstead of belching out you ignorance.


Alessandro
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-11-03 Thread Alessandro Selli 
On Fri, 3 Nov 2017 at 00:54:44 -0400
"taii...@gmx.com"  wrote:

> On 11/02/2017 09:47 PM, Alessandro Selli wrote:
> 
>>Yes, I know, they failed disabling ME and they stopped even trying.  
> Their website/marketing says that it is "disabled" when it isn't.

  Yes, it is, and it is verifiable and repeatable:
https://puri.sm/posts/purism-librem-laptops-completely-disable-intel-management-engine/

The Librem 13 and Librem 15 products can be purchased today and will
arrive with the Management Engine disabled by default, and it can be
verified to be disabled with the source code released to confirm the
disablement is accurate. Showing “ME: FW Partition Table : BAD; ME:
Bringup Loader Failure : YES”

  Of course you could prove their claim false and sink them.  This is you
golden opportunity to do away with their competition, do it!
 

>>Purism
>> has gone farther than anyone though possible just two years ago  
> They didn't make ME_cleaner or contribute to its development at all FYI,

  I never made that claim, in fact I wrote (if only would you do some reading
from time to time):

From: Alessandro Selli 
To: dng@lists.dyne.org
Message-ID: <20171103024713.68feecc1@ayu.localdomain>

  Where did you read anything about intel_me cleaner in
https://puri.sm/posts/deep-dive-into-intel-me-disablement/ ?  You're
stuck with old news.

> there isn't anything special about their laptops that justifies the $2K 
> price tag

  There is much more than justifies a desktop produced by no-one knows whom
that promises to deliver a free system after people will have turned out
$4,750.00 for their basic system based on pure faith and no documentation, no
blueprints, no insight into their dealings of any nature.

> If one insists on a new intel laptop and doesn't mind a blobbed/ME'd 
> coreboot there are a variety of much less expensive options that support 
> me cleaner.

  People do mind, that's the reason they could fully disable it and that's
the reason they gained the trust of thousand of customers for their present
and future products.
  Most of what in the past was proprietary and closed-sourced is today at
least usable on libre software because people took the heavy task of
reverse-engineering it to produce a workable free version.  The job is tought
and always takes a long time, but those who do it are worthy people working
for freedom, those who are today doing this work on Intel chipsets and CPUs
are just as worthy.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-11-03 Thread zap 


On 11/03/2017 04:27 AM, Narcis Garcia wrote:
> Please shutdown this giant thread completely.
> I'm near to unsubscribe from list.
> Most of subjects you are chattering can be found with web browsing.
> Devuan project is very fragile with this behaviour.
>
Very well, If it will help, this will be the last time I reply, given
the nature of where the topic is headed.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-11-03 Thread m712 


On November 3, 2017 11:27:21 AM GMT+03:00, Narcis Garcia 
 wrote:
>Please shutdown this giant thread completely.
>I'm near to unsubscribe from list.
>Most of subjects you are chattering can be found with web browsing.
>Devuan project is very fragile with this behaviour.
Allow me to remind you that this mailing isn't purely for Devuan discussion, 
dev1galaxy is a place for that. Also, this thread is largely related to Devuan, 
because UEFI usually makes it harder (or prevents) installing GNU distributions 
such as Devuan, and if a company like Google is abandoning UEFI this might be 
good news.
Also, the threads don't have to be completely on-topic. Internet is not serious 
business. If you really don't like a discussion filter it or killfile the 
senders. You have the technology.
--- :^) --- :^) --- :^) --- :^) --- :^) --- :^) --- :^) --- :^) ---
https://nextchan.org - https://gitgud.io/m712/blazechan
I am awake between 7AM-12AM UTC, hit me up if something's wrong

signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-11-03 Thread Narcis Garcia 
Please shutdown this giant thread completely.
I'm near to unsubscribe from list.
Most of subjects you are chattering can be found with web browsing.
Devuan project is very fragile with this behaviour.


El 03/11/17 a les 06:25, Rick Moen ha escrit:
> I wrote:
> 
>> As it happens, as I mentioned, I just recently bought (to play with)  a
>> reconditioned Zotac CI321 w/4GB RAM and a 64GB SSD for US $125 with 1
>> year warranty from Zotac after John Franklin mentioned the Zotac
>> C-series here.  (TY, John!)  It has the Intel ME and Intel FSM problems,
>> too.
> [...]
>> The FSP is a separate problem (for both the Purism laptops and my
>> little toy Zotac), and I can't say much about more about that.
> 
> I'll do that now.  
> 
> Long ago, I had a Lucent Silver Wavelan PCMCIA 802.11b wireless card for
> my laptops.  At the time, this was the most universally best supported
> wireless chipset ever, using the orinoco_cs driver starting with the
> 2.4.3 Linux kernel.  Like all NICs of that generation, the card had a
> built-in ROM that hooked into hardware initialisation.
> 
> Newer cards (and motherboard chipsets) have often had hauntingly similar
> functionality to my old 802.11b card, but relegated the ROM
> initialisation to a binary-only firmware BLOB that must be hurled into
> RAM during hardware recognition -- a change made, as far as I can tell,
> just to save a trivial amount of money on ROM costs.  It occurred to me
> that the functionality of the new BLOBs and of my old Lucent card's ROM
> contents was the same.  In a few cases, the new BLOBs might even be
> exactly the same code, just dd'd to a file from what was formerly burned
> into a ROM.
> 
> I sometimes have Richard Stallman as a house guest, and I don't _think_ 
> I've yet raised this with him, but I keep intending to.  So, here's my
> attempt to imagine the conversation:
> 
> RM:  Here's my point:  Why are the firmware BLOBs a software freedom
>  issue, and the Lucent ROM was not?
> 
> RMS:  We at FSF seek freedom to modify in all general-use software, and
> the BLOBs, if they were freed, could give developers ability to
> improve them, the ability to ensure that they are
> freedom-protecting, and the ability to adapt that code to other
> purposes for everyone's benefit.
> 
> RM:  Sure, but why wasn't that by the same token an issue for the 
> Lucent ROM code?  And, for that matter, why not CPU microcode?
> 
> RMS:  Because those are hardware, and you can't change them.  Maybe
> one day we'll have full visibility into microcode, but one fight
> at a time.
> 
> RM:  Fair enough, but are you saying that FSF would have no problem
> with BLOB firmware images if they get burned into ROMs?  I'm
> not clear on why that would matter.  It's the same code doing
> the same functionality.  Also, I'm not sure the ROM code in
> a Lucent Silver could not be changed.  Often, these aren't 
> classic burn-once ROMs but rather EEPROMs.
> 
> RMS:  [here, I run out of imagination]
> 
> The Stallman in my head _might_ have countered that, well, the frontiers
> of free software (I almost said 'open source') change over time
> depending on what is feasible.  Back then, hardware init 'feature' ROMs
> were black boxes and we couldn't reasonably dream of changing that.
> Now, we may have many obstacles, but we can aspire.
> 
> Angling back to the Intel Firmware Support Package:  In 1997, it never
> would have even occurred to you to object to the (then-current analogue
> of the) Intel FSM as a free software issue, because you'd just call it
> 'the feature ROMs', and it was just an unavoidable black-box feature of
> your computer, like the CPU microcode.  Twenty years later, a bunch of
> people see that as an intolerable affront to freedom-respecting hardware
> design, even though nothing has actually changed.
> 
> But if that's not a grey area, then I don't know my greyscales.
> 
> (In fairness, Libreboot Project clarifies on
> https://libreboot.org/faq.html#intel that the FSP handles System
> Management Mode, which raises a genuine security concern, in addition to
> doing 1997-style hardware initialisation.  To quote my favourite line
> from 'The West Wing', 'Ah, the rare valid point.')
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-11-02 Thread Rick Moen 
I wrote:

> As it happens, as I mentioned, I just recently bought (to play with)  a
> reconditioned Zotac CI321 w/4GB RAM and a 64GB SSD for US $125 with 1
> year warranty from Zotac after John Franklin mentioned the Zotac
> C-series here.  (TY, John!)  It has the Intel ME and Intel FSM problems,
> too.
[...]
> The FSP is a separate problem (for both the Purism laptops and my
> little toy Zotac), and I can't say much about more about that.

I'll do that now.  

Long ago, I had a Lucent Silver Wavelan PCMCIA 802.11b wireless card for
my laptops.  At the time, this was the most universally best supported
wireless chipset ever, using the orinoco_cs driver starting with the
2.4.3 Linux kernel.  Like all NICs of that generation, the card had a
built-in ROM that hooked into hardware initialisation.

Newer cards (and motherboard chipsets) have often had hauntingly similar
functionality to my old 802.11b card, but relegated the ROM
initialisation to a binary-only firmware BLOB that must be hurled into
RAM during hardware recognition -- a change made, as far as I can tell,
just to save a trivial amount of money on ROM costs.  It occurred to me
that the functionality of the new BLOBs and of my old Lucent card's ROM
contents was the same.  In a few cases, the new BLOBs might even be
exactly the same code, just dd'd to a file from what was formerly burned
into a ROM.

I sometimes have Richard Stallman as a house guest, and I don't _think_ 
I've yet raised this with him, but I keep intending to.  So, here's my
attempt to imagine the conversation:

RM:  Here's my point:  Why are the firmware BLOBs a software freedom
 issue, and the Lucent ROM was not?

RMS:  We at FSF seek freedom to modify in all general-use software, and
the BLOBs, if they were freed, could give developers ability to
improve them, the ability to ensure that they are
freedom-protecting, and the ability to adapt that code to other
purposes for everyone's benefit.

RM:  Sure, but why wasn't that by the same token an issue for the 
Lucent ROM code?  And, for that matter, why not CPU microcode?

RMS:  Because those are hardware, and you can't change them.  Maybe
one day we'll have full visibility into microcode, but one fight
at a time.

RM:  Fair enough, but are you saying that FSF would have no problem
with BLOB firmware images if they get burned into ROMs?  I'm
not clear on why that would matter.  It's the same code doing
the same functionality.  Also, I'm not sure the ROM code in
a Lucent Silver could not be changed.  Often, these aren't 
classic burn-once ROMs but rather EEPROMs.

RMS:  [here, I run out of imagination]

The Stallman in my head _might_ have countered that, well, the frontiers
of free software (I almost said 'open source') change over time
depending on what is feasible.  Back then, hardware init 'feature' ROMs
were black boxes and we couldn't reasonably dream of changing that.
Now, we may have many obstacles, but we can aspire.

Angling back to the Intel Firmware Support Package:  In 1997, it never
would have even occurred to you to object to the (then-current analogue
of the) Intel FSM as a free software issue, because you'd just call it
'the feature ROMs', and it was just an unavoidable black-box feature of
your computer, like the CPU microcode.  Twenty years later, a bunch of
people see that as an intolerable affront to freedom-respecting hardware
design, even though nothing has actually changed.

But if that's not a grey area, then I don't know my greyscales.

(In fairness, Libreboot Project clarifies on
https://libreboot.org/faq.html#intel that the FSP handles System
Management Mode, which raises a genuine security concern, in addition to
doing 1997-style hardware initialisation.  To quote my favourite line
from 'The West Wing', 'Ah, the rare valid point.')

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-11-02 Thread taii...@gmx.com 

On 11/02/2017 09:47 PM, Alessandro Selli wrote:


   Yes, I know, they failed disabling ME and they stopped even trying.

Their website/marketing says that it is "disabled" when it isn't.

   Purism
has gone farther than anyone though possible just two years ago
They didn't make ME_cleaner or contribute to its development at all FYI, 
there isn't anything special about their laptops that justifies the $2K 
price tag
If one insists on a new intel laptop and doesn't mind a blobbed/ME'd 
coreboot there are a variety of much less expensive options that support 
me cleaner.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-11-02 Thread taii...@gmx.com 
In the interest of not starting a big argument again this will by my 
last reply on this thread.


On 11/02/2017 01:14 PM, Alessandro Selli wrote:


   They are fully worth it.
Certainly not for the price they are charging, for $2K one could buy 5 
Lenovo G505S laptops which are owner controlled with no ME/PSP, an open 
source init process (no FSP) or hardware code signing enforcement.

«the LibreM contains a proprietary BIOS»

   Wrong.  I already wrote about it but I see your pathological hate for
anything other than Talos/IBM is just too strong, facts cannot stop you from
spreading lies:
I don't like IBM, but I accept that POWER is the best option and their 
marketing of it is honest.
I don't like purism and will never support them until they change their 
marketing to be actually honest and stop pretending that they can make 
free an intel CPU some vague time in the future.

https://puri.sm/faq/

Technical & Advanced
Can I buy a Librem with a proprietary BIOS/UEFI?

No. We ship with the free software firmware coreboot. We don’t ship Librem 13
or Librem 15 with any proprietary BIOS/UEFI.
It isn't libre and it isn't free software as the hardware and memory 
init process is entirely done by Intel's FSP binary blob.

They call their laptops the "LibreM" - what is libre about them?

Fail to include the ME firmware binary in the firmware and your purism 
laptop will shut down in 30 minutes "disabled"

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-11-02 Thread zap 

>> Coreboot does load blobs for certain devices, so it shouldn't be any
>> surprise that coreboot supports librem.
>   They did not lie about this.
Hmm... Doesn't it seem odd though that they call themselves purism and
haven't fully removed the intel ME stuff...?

I dunno, it just seems fishy to me. IF you really think I am being
judgmental, ask the people on the trisquel forums... they go even
further to say that they are lying scum bags who only have interest in
money and no interest in freedom.

Me personally? Well I think they have some shady dealings but I do hope
someday they get honest about some of the stuff they hid. If they do
that, and clean up their act and succeed in cleaning everything up, then
I will support them easily.

>
> Alessandro
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-11-02 Thread Rick Moen 
Quoting zap (calmst...@posteo.de):

> Very well then,
> https://libreboot.org/faq.html#will-the-purism-laptops-be-supported
> 
> that is one perfect example. If it were possible, I think libreboot
> would have said something by now about the intel_me cleaner making it
> possible.

This is significant and worthy of note, but please be careful to not
over-read.  Libreboot Project take the sensible stance that it is best
to avoid hardware containing Intel ME, including the Purism laptops,
because of (1) Intel ME, and (2) the Intel Firmware Support Package
(FSP) that coreboot uses to handles all hardware initialisation,
including memory and CPU initialisation.  (Among other things, Libreboot
Project point out that FSP sets up System Management Mode, which is a
known-problematic system layer underlying the regular OS level).

As it happens, as I mentioned, I just recently bought (to play with)  a
reconditioned Zotac CI321 w/4GB RAM and a 64GB SSD for US $125 with 1
year warranty from Zotac after John Franklin mentioned the Zotac
C-series here.  (TY, John!)  It has the Intel ME and Intel FSM problems,
too.

If I understand correctly, it would be self-defeating to totally disable
the Intel ME on hardware that uses it -- because the ME is instrumental
in initialising the hardware for use.  The best possible outcome under
the circumstances is to be able to programmatically disable the ME as
part of boot-up, as can be done at least for ME version 11 using the
technique discovered by Positive Technologies.
http://blog.ptsecurity.com/2017/08/disabling-intel-me.html
Intel Corp. have confirmed that this technique does disable ME version
11.  Call me excessively trusting if you will, but I believe them.  And
FWIW I do _not_ believe the people thinking ME is a plot to
security-compromise our computers.  It's a (regrettable) technology
intended to facilitate OOB management.  The rationale makes perfect
sense, even if the unintended side-effects are woeful.)

I think, if you credit Purism with a modicum of good will, you might
concede that an Intel ME (version 11) that gets programmatically lobotomised
immediately upon boot using the Positive Technologies (which I hope and
expect Purism are using) is as close to no Intel ME as makes no
difference.

The FSP is a separate problem (for both the Purism laptops and my
little toy Zotac), and I can't say much about more about that.


My own semi-considered opinion:  Purism have been repeatedly guilty of
the, on balance, venial and rather common sin of shading the truth just
a bit.  Public relations.  They may not be unstained saints of the
Church of Free Software, but then, who is?

Shades of grey.  We have 'em.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-11-02 Thread Alessandro Selli 
On Thu, 2 Nov 2017 at 20:46:58 -0400
zap  wrote:

> On 11/02/2017 07:35 PM, Alessandro Selli wrote:
>> On Thu, 2 Nov 2017 at 15:03:36 -0400
>> zap  wrote:
>>  
   Prove it.

 https://puri.sm/posts/purism-librem-laptops-completely-disable-intel-management-engine/
   
>>> Something tells me you won't accept any other answer except your own, so
>>> I will pass.  
>>   I take any verifiable fact as proof.  Don't duck away blaming the
>> others of your cowardice.  
> Very well then,
> https://libreboot.org/faq.html#will-the-purism-laptops-be-supported
>
> that is one perfect example.

  It isn't, as, AFAIK, purism didn't advertise it's laptops as running on
libreboot, so they did not lie.

> If it were possible, I think libreboot
> would have said something by now about the intel_me cleaner making it
> possible.

  Where did you read anything about intel_me cleaner in
https://puri.sm/posts/deep-dive-into-intel-me-disablement/ ?  You're stuck
with old news.

> Another thing, if you want to know if is truly possible to support
> purism try opening a pull request on
> https://notabug.org/libreboot/libreboot/pulls.
>
> I guarantee Leah will specify how impossible it is.

  Yes, I know, they failed disabling ME and they stopped even trying.  Purism
has gone farther than anyone though possible just two years ago, and they are
not saying ME is 100% removed:

https://puri.sm/posts/purism-librem-laptops-completely-disable-intel-management-engine/

“Purism, in the long-term pursuit of liberating hardware at the lowest
levels, still has more work to do. Removing the management engine entirely is
the next step beyond just disabling it. Coreboot also includes another
binary, the Intel FSP, a less worrisome but still important binary to
liberate, incorporating a free vBIOS is another step Purism plans to take.
The road to a completely free system on current Intel CPUs is not over, but
the largest step of disabling the Management Engine is arguably the largest
milestone to cross.” says Youness Alaoui, Hardware Enablement Developer at
Purism.

> Coreboot does load blobs for certain devices, so it shouldn't be any
> surprise that coreboot supports librem.

  They did not lie about this.


Alessandro
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-11-02 Thread zap 


On 11/02/2017 08:28 PM, Rick Moen wrote:
> I wrote:
>
>> Coreboot itself is free software but by design hosts proprietary
>> plugins.  In that regard, it differs from its militantly free software
>> fork libreboot, which of course in consequence supports much less
>> software.
>   
>
> I meant hardware.
>
> And I'd still appreciate it if Alessandro would please calm down.
+1 Agreed.
>
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-11-02 Thread zap 


On 11/02/2017 07:35 PM, Alessandro Selli wrote:
> On Thu, 2 Nov 2017 at 15:03:36 -0400
> zap  wrote:
>
>>>   Prove it.
>>>
>>> https://puri.sm/posts/purism-librem-laptops-completely-disable-intel-management-engine/
>> Something tells me you won't accept any other answer except your own, so
>> I will pass.
>   I take any verifiable fact as proof.  Don't duck away blaming the others of
> your cowardice.
Very well then,
https://libreboot.org/faq.html#will-the-purism-laptops-be-supported

that is one perfect example. If it were possible, I think libreboot
would have said something by now about the intel_me cleaner making it
possible.

Another thing, if you want to know if is truly possible to support
purism try opening a pull request on
https://notabug.org/libreboot/libreboot/pulls.

I guarantee Leah will specify how impossible it is.

Coreboot does load blobs for certain devices, so it shouldn't be any
surprise that coreboot supports librem.

If it can be used on libreboot that is different and I will gladly
recommend it to everyone and anyone.

Even despite the bad press stuff, etc,
>
>
> Alessandro
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-11-02 Thread Rick Moen 
I wrote:

> Coreboot itself is free software but by design hosts proprietary
> plugins.  In that regard, it differs from its militantly free software
> fork libreboot, which of course in consequence supports much less
> software.
  

I meant hardware.

And I'd still appreciate it if Alessandro would please calm down.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-11-02 Thread Alessandro Selli 
On Thu, 2 Nov 2017 at 15:03:36 -0400
zap  wrote:

> 
> >   Prove it.
> >
> > https://puri.sm/posts/purism-librem-laptops-completely-disable-intel-management-engine/
> Something tells me you won't accept any other answer except your own, so
> I will pass.

  I take any verifiable fact as proof.  Don't duck away blaming the others of
your cowardice.


Alessandro
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-11-02 Thread zap 

>   Prove it.
>
> https://puri.sm/posts/purism-librem-laptops-completely-disable-intel-management-engine/
Something tells me you won't accept any other answer except your own, so
I will pass.
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-11-02 Thread Rick Moen 
Quoting Alessandro Selli (alessandrose...@linux.com):

> https://puri.sm/faq/
> 
> Technical & Advanced
> Can I buy a Librem with a proprietary BIOS/UEFI?
> 
> No. We ship with the free software firmware coreboot. We don’t ship Librem 13
> or Librem 15 with any proprietary BIOS/UEFI.

(Note:  This is an ambiguous situation, where Purism are attempting 
to do the right thing and doing laudable work concerning among other
things the Intel ME issue.  I'm making no accusations.  I'm dismayed
by needless hostility erupting in this thread, and would appreciate if
people calmed down.)

Coreboot itself is free software but by design hosts proprietary
plugins.  In that regard, it differs from its militantly free software
fork libreboot, which of course in consequence supports much less
software.

Purism stating that the ship with the free software firmware coreboot
thus does not totally answer the question posed in the FAQ.  If Purism
wished, it could elaborate to state whether or not proprietary Intel
firmware BLOB must be loaded by coreboot to initialise the Librem 15's
chipsets.  The need to do so is sadly common, hence why use of coreboot
is much more common than that of Libreboot.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-11-02 Thread Alessandro Selli 
On Wed, 1 Nov 2017 at 23:30:45 -0400
zap  wrote:

> 
>>> You might consider the Purism laptops, one of which has a detachable
>>> keyboard.  https://puri.sm/products/
>> https://www.reddit.com/r/linux/comments/3anjgm/on_the_librem_laptop_purism_doesnt_believe_in/
>>
>> They aren't worth it.
> Yep mhm, they are deliberately lying too people saying they have the
> intel me 100% disabled.

  Prove it.

https://puri.sm/posts/purism-librem-laptops-completely-disable-intel-management-engine/


October 19, 2017
Purism Librem Laptops Completely Disable Intel’s Management Engine

SAN FRANCISCO, Calif., October 19, 2017 — Purism’s Librem Laptops, running
coreboot, are now available with the Intel Management Engine completely and
verifiably disabled.

https://puri.sm/posts/deep-dive-into-intel-me-disablement/


October 19, 2017
Deep dive into Intel Management Engine disablement

Starting today, our second generation of laptops (based on the 6th gen Intel
Skylake platform) will now come with the Intel Management Engine neutralized
and disabled by default. Users who already received their orders can also
update their flash to disable the ME on their machines.

In this post, I will dig deeper and explain in more details what this means
exactly, and why it wasn’t done before today for the laptops that were
shipping this spring and summer.


Alessandro
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-11-01 Thread zap 

>> You might consider the Purism laptops, one of which has a detachable
>> keyboard.  https://puri.sm/products/
> https://www.reddit.com/r/linux/comments/3anjgm/on_the_librem_laptop_purism_doesnt_believe_in/
>
> They aren't worth it.
Yep mhm, they are deliberately lying too people saying they have the
intel me 100% disabled. but its more like 95% disabled. which is not
completely removed and therefore a lie.

They shouldn't call themselves purism unless they do what they say.
which in this case they don't.

the Eoma68 standard is much, much closer to such a point. and it also is
very energy efficient too.

I at one point believed them, but libreboot's claims and coreboots
claims on this set me straight.

Intel is almost impossible to remove the me on in later gens.  maybe
even impossible once everything is signed at least for the next 50+ years.

irony is not lost on me...

copyright = *H*azarous *A*nd *D*ownright *E*vil *S*cum


> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-11-01 Thread taii...@gmx.com 

On 11/01/2017 08:23 AM, Hendrik Boom wrote:


On Tue, Oct 31, 2017 at 01:56:06PM +0100, Martin Steigerwald wrote:

As my next music playback machine I may even use such a Pine64. As anything
from ThinkPad X240 and upwards appears to be "protected" by Intel Boot Guard
Verified Boot crap, instead of just offering the Measured Boot feature for
those who want it. Or I go with a ThinkPad X230 where it appears that Intel ME
cleaner can do its work. May still be better the Pine64 appears to be a tad
bit limited especially by memory, although for music playback it would be
enough if expanded with a large MicroSD card. And it would have the advantage
that I would not have to mess with removing crap as it does not appear to have
crap inside. And cheaper too.

Other alternative may be a Chromebook if I can rid it easily enough of Chrome
OS and install my distro of choice on it.
I would get a Lenovo G505S, it is the last and best owner controlled 
x86-64 laptop. No ME/PSP and no hardware code signing enforcement. There 
is a blob for video and power but they are removable.
If you want a dock or better build quality the X230 (with an x220 
keyboard) is a good choice if you don't mind ME (please note ME cleaner 
is nerfing not disabling it)


An affordable desktop/server choice is the KCMA-D8 ($250) with a $20 
CPU, features include IOMMU, OpenBMC remote access and a 100% libre init 
coreboot.

You might consider the Purism laptops, one of which has a detachable
keyboard.  https://puri.sm/products/

https://www.reddit.com/r/linux/comments/3anjgm/on_the_librem_laptop_purism_doesnt_believe_in/
They aren't worth it.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-11-01 Thread Alessandro Selli 
On Wed, 1 Nov 2017 at 15:27:48 -0400
Steve Litt  wrote:

> On Tue, 31 Oct 2017 11:47:51 +0100
> Martin Steigerwald  wrote:
>
>> Steve Litt - 30.10.17, 12:08:  
>>> On Mon, 30 Oct 2017 12:53:45 +0100
>>>
>>> Martin Steigerwald  wrote:
 Actually I´d make firmware pretty dumb and implement as much as I
 can in loaded software. Just enough firmware to actually
 install / boot a bootloader which loads an operating kernel and
 initial ram disk.
>>>
>>> Which is pretty much what we had in MBR. Which is why I always try
>>> to boot MBR.
>>
>> I now read through the slides about NERF and well… it appears that
>> with non extensible they have simplicity in mind. They relay all the
>> extensibility to the go based user space Initramfs. I am not sure
>> whether some go based thing would have been needed her but I am
>> thankful for any efforts to rid systems of proprietary firmware crap.
>> Even better tough: Not putting in the crap in the first place. No
>> crap inside? No effort needed to rip it out again.  
>
> Initramfs is another mess.

  It's just a (sometimes compressed) cpio archive.

> You can't debug it directly:

  What do you mean by this?

> You sort of
> have to take a time machine back (or forward) to ultra-early boot.
>
> I've lost the battle to keep your average Linux distro sans-initramfs,
> so now I'm fighting a lesser battle: How much stuff do you want in your
> initramfs, where realtime debugging is increasingly difficult and
> increasingly owned by Redhat?

  Initramfs is indispensable when you boot a system:
*) on an encrypted root partition;
*) having a merged root and usr partitions and /usr on it's own partition;
*) both of the above.

  I fact most embedded Linux systems do not have it.

  Red Hat used dracut to manage initramfs, De*an and like distros use
initramfs-tools.


Alessandro
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-11-01 Thread Alessandro Selli 
On Tue, 31 Oct 2017 at 12:41:47 +0100
Adam Borowski  wrote:

[...]

> The "secure" world marks certain resources (memory regions, interrupts,
> peripherals, etc).  Upon an attempt to access a marked resource, there's a
> "world switch" that most of us would call an "interrupt" (except that they
> decided to invent a new word, to disambiguate from regular interrupts).

  I think speaking of a context switch is more appropriate, rather than of an
interrupt.


Alessandro


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-11-01 Thread Steve Litt 
On Tue, 31 Oct 2017 11:47:51 +0100
Martin Steigerwald  wrote:

> Steve Litt - 30.10.17, 12:08:
> > On Mon, 30 Oct 2017 12:53:45 +0100
> > 
> > Martin Steigerwald  wrote:  
> > > Actually I´d make firmware pretty dumb and implement as much as I
> > > can in loaded software. Just enough firmware to actually
> > > install / boot a bootloader which loads an operating kernel and
> > > initial ram disk.  
> > 
> > Which is pretty much what we had in MBR. Which is why I always try
> > to boot MBR.  
> 
> I now read through the slides about NERF and well… it appears that
> with non extensible they have simplicity in mind. They relay all the
> extensibility to the go based user space Initramfs. I am not sure
> whether some go based thing would have been needed her but I am
> thankful for any efforts to rid systems of proprietary firmware crap.
> Even better tough: Not putting in the crap in the first place. No
> crap inside? No effort needed to rip it out again.

Initramfs is another mess. You can't debug it directly: You sort of
have to take a time machine back (or forward) to ultra-early boot.

I've lost the battle to keep your average Linux distro sans-initramfs,
so now I'm fighting a lesser battle: How much stuff do you want in your
initramfs, where realtime debugging is increasingly difficult and
increasingly owned by Redhat?

The stated purpose of initramfs is to boot far enough to mount the root
partition, after which everything else can be mounted via /etc/fstab.
Unless the executables do do such mounting have been placed off the
root's tree, in which case those must be available on the initramfs.
The more that goes in initramfs, the higher the barrier to entry for
the DIY Linux person.

SteveT

Steve Litt 
October 2017 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-11-01 Thread Hendrik Boom 
On Tue, Oct 31, 2017 at 01:56:06PM +0100, Martin Steigerwald wrote:
> 
> As my next music playback machine I may even use such a Pine64. As anything 
> from ThinkPad X240 and upwards appears to be "protected" by Intel Boot Guard 
> Verified Boot crap, instead of just offering the Measured Boot feature for 
> those who want it. Or I go with a ThinkPad X230 where it appears that Intel 
> ME 
> cleaner can do its work. May still be better the Pine64 appears to be a tad 
> bit limited especially by memory, although for music playback it would be 
> enough if expanded with a large MicroSD card. And it would have the advantage 
> that I would not have to mess with removing crap as it does not appear to 
> have 
> crap inside. And cheaper too.
> 
> Other alternative may be a Chromebook if I can rid it easily enough of Chrome 
> OS and install my distro of choice on it.

You might consider the Purism laptops, one of which has a detachable 
keyboard.  https://puri.sm/products/

I don't know if price/performance and the set of I/O ports are in 
your range, though.

-- hendrik

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-10-31 Thread Arnt Gulbrandsen 

Didier Kryn writes:
The distinction trust-zone vs normal doesn't look very 
different of kernel-mode vs user-mode, does it?


Or, for that matter, like the privsep distinctions used in some programs. 
It's all the same kind of thing.


Arnt
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-10-31 Thread Didier Kryn 

Le 31/10/2017 à 12:58, Arnt Gulbrandsen a écrit :

Martin Steigerwald writes:
I don´t know much about Trustzone. Do you have any links to a good 
explaination of it (preferable from a non-vendor source)?


Not offhand, sorry. But let me summarise the one I read:

You can put code and data in a part of RAM and then turn off regular 
access to those pages. After that point, the memory is only accessible 
when a CPU core is in a special mode, the "secure world". Then there's 
a way to switch to that mode and call functions, and a way to start a 
thread in the special mode. A file system encryption system or 
keystore would do the former, a hypervisor the latter.


Notably, it's regular RAM and not a dedicated core. You can easily 
tell how big the secure world is and how much CPU the hypervisor uses. 
There's no builtin hypervisor, it's something the boot process has to 
set up (or not). 


    The distinction trust-zone vs normal doesn't look very different of 
kernel-mode vs user-mode, does it?


        Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-10-31 Thread Adam Borowski 
On Tue, Oct 31, 2017 at 01:56:06PM +0100, Martin Steigerwald wrote:
> I agree that such a feature if done like in
> 
> > The ROM code executes (at least partially) in the secure world, and may or
> > may not let the bootloader replace it with your own code (typically you
> > compile ATF, with or without modifications, instead of writing everything
> > from scratch).  On free machines like Pine64 or Pinebook, you can do this.
> > On most others, you can't, with obvious freedom consequences.  Insert the
> > usual lecture about hardware you don't truly own.
> can be useful.
> 
> As my next music playback machine I may even use such a Pine64. As anything 
> from ThinkPad X240 and upwards appears to be "protected" by Intel Boot Guard 
> Verified Boot crap, instead of just offering the Measured Boot feature for 
> those who want it. Or I go with a ThinkPad X230 where it appears that Intel 
> ME 
> cleaner can do its work. May still be better the Pine64 appears to be a tad 
> bit limited especially by memory, although for music playback it would be 
> enough if expanded with a large MicroSD card. And it would have the advantage 
> that I would not have to mess with removing crap as it does not appear to 
> have 
> crap inside. And cheaper too.
> 
> Other alternative may be a Chromebook if I can rid it easily enough of Chrome 
> OS and install my distro of choice on it.

Note that both Pine64 and Pinebook share the same weaknesses:
* kernel drivers are not fully upstreamed, nor even fully working for
  near-mainline yet.  The SoC (A64) manufacturer provides no real support,
  board vendors ship just BSP, thus it all hinges on individuals such as
  Icenowy Zheng, Corentin Labbe, Jernej Skrabec, Maxime Ripard, etc.  For
  now, parts needed for headless operation are mostly all in vanilla,
  display uses SimpleFB with proper DRM[1] being only in the process of
  upstreaming.  Noteworthy, audio support is missing -- although I've
  overheard someone on #linux-sunxi saying he got it working.  Let's see
  how fast audio patches hit the usual pre-linus place (ie,
  https://github.com/Icenowy/linux).
* there _is_ a fully working kernel, based on BSP (vendor) sources, with
  display, audio and the stuff.  This kernel is quite old linux-wise (3.10)
  which means you can't run current systemd (what a pity...) but even Debian
  unstable is otherwise ok.  Alas, while the kernel is fully free, BSP
  requires a small blob to initialize stuff before loading u-boot.  Unlike
  x86 stuff, you can at least disassemble and read it (~30KB of code) thus
  you know there are no backdoors, but it still leaves a bad taste.
  (Note: I'm using exclusively Icenowy's near-mainline, thus I have no
  experiences with BSP.)
* the SoC is pretty slow, one of slowest ARM64 boards around (although it
  still beats RPi3 handily).

Thus, it doesn't fulfill some needs you may have.  It's a nearly[2] fully
open, very cheap board that gets things done, but it's good for tinkering,
not for "consumer" type usage.


Meow!

[1]. The good DRM (kernel-based rendering), not MAFIAA restrictions.
[2]. There's no documentation for Mali400 GPU acceleration: ie, don't expect
fast OpenGL anytime soon.  Unlike x86 GPUs, though, display and acceleration
are separate chips, thus you don't need Mali for anything 2D.
-- 
⢀⣴⠾⠻⢶⣦⠀ Laws we want back: Poland, Dz.U. 1921 nr.30 poz.177 (also Dz.U. 
⣾⠁⢰⠒⠀⣿⡁ 1920 nr.11 poz.61): Art.2: An official, guilty of accepting a gift
⢿⡄⠘⠷⠚⠋⠀ or another material benefit, or a promise thereof, [in matters
⠈⠳⣄ relevant to duties], shall be punished by death by shooting.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-10-31 Thread Adam Borowski 
On Tue, Oct 31, 2017 at 04:43:10PM +0100, J. Fahrner wrote:
> Am 2017-10-31 16:40, schrieb Hendrik Boom:
> 
> > Is it still possible to use MBR boot on a GPT disk?
> 
> You can install a hybrid partition table.
> http://www.rodsbooks.com/gdisk/hybrid.html

Beware, a hybrid partition table is notoriously fragile, and support for it
in tools is sketchy even when a tool is advertised to do it.

On the other hand, this is the only way to boot Windows from a >2TB disk on
a non-UEFI machine, and the hell I'm giving crap I'm booting once a quarter
any space on SSD on my home box.

Thus: this can be done, but it'll bite you in the ass and probably is not
worth your time.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Laws we want back: Poland, Dz.U. 1921 nr.30 poz.177 (also Dz.U. 
⣾⠁⢰⠒⠀⣿⡁ 1920 nr.11 poz.61): Art.2: An official, guilty of accepting a gift
⢿⡄⠘⠷⠚⠋⠀ or another material benefit, or a promise thereof, [in matters
⠈⠳⣄ relevant to duties], shall be punished by death by shooting.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-10-31 Thread Antony Stone 
On Tuesday 31 October 2017 at 16:40:13, Hendrik Boom wrote:

> On Mon, Oct 30, 2017 at 12:08:55PM -0400, Steve Litt wrote:
> > 
> > I always try to boot MBR.
> 
> Beyond a certains size of disk you need GPT partitioning.  Is it
> still possible to use MBR boot on a GPT disk?

Yes.

https://en.wikipedia.org/wiki/GUID_Partition_Table#MBR_variants

Linux utilities such as gdisk and grub will quite happily install a protective 
MBR partition on a 2+Tb disk and this lets you use big disks on machines which 
only recognise MBR.

Here's an example from a 3Tbyte disk I have here in an HP NL40 Microserver:

# fdisk -l /dev/sda

WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk 
doesn't support GPT. Use GNU Parted.

Disk /dev/sda: 3000.6 GB, 3000592982016 bytes
256 heads, 63 sectors/track, 363376 cylinders, total 5860533168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x

   Device Boot  Start End  Blocks   Id  System
/dev/sda1   1  4294967295  2147483647+  ee  GPT

# gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.5

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 5860533168 sectors, 2.7 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): E1C51CB7-22C1-4EAD-BFB0-A63DE10FBCC6
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 5860533134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)End (sector)  Size   Code  Name
   120484095   1024.0 KiB  EF02  BIOS boot partition
   2409641947135   20.0 GiBFD00  Linux RAID
   34194713644044287   1024.0 MiB  8200  Linux swap
   444044288  5860533134   2.7 TiB FD00  Linux RAID


Antony.

-- 
Numerous psychological studies over the years have demonstrated that the 
majority of people genuinely believe they are not like the majority of people.

   Please reply to the list;
 please *don't* CC me.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-10-31 Thread J. Fahrner 

Am 2017-10-31 16:40, schrieb Hendrik Boom:


Is it still possible to use MBR boot on a GPT disk?


You can install a hybrid partition table.
http://www.rodsbooks.com/gdisk/hybrid.html

Jochen
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-10-31 Thread Hendrik Boom 
On Mon, Oct 30, 2017 at 12:08:55PM -0400, Steve Litt wrote:
> On Mon, 30 Oct 2017 12:53:45 +0100
> Martin Steigerwald  wrote:
> 
> 
> > Actually I´d make firmware pretty dumb and implement as much as I can
> > in loaded software. Just enough firmware to actually install / boot a
> > bootloader which loads an operating kernel and initial ram disk.
> 
> Which is pretty much what we had in MBR. Which is why I always try to
> boot MBR.

Beyond a certains size of disk you need GPT partitioning.  Is it 
still possible to use MBR boot on a GPT disk?

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-10-31 Thread Martin Steigerwald 
Adam Borowski - 31.10.17, 12:41:
> On Tue, Oct 31, 2017 at 11:48:35AM +0100, Martin Steigerwald wrote:
> > Arnt Gulbrandsen - 30.10.17, 12:25:
> > > Martin Steigerwald writes:
> > > > I wonder about ARM64 as an alternative? But they have some
> > > > Trustzone crap if I remember correctly.
> > > 
> > > ARM64 is fine from a performance viewpoint. The mobile phone vendors
> > > have
> > > spent a decade optimising ARM SOCs for performance on small batteries. I
> > > haven't found laptops with ≥8GB RAM so far though.
> > > 
> > > Personally I consider the Trustzone well-justified and good. It makes it
> > > easy to provide security regimes that rely on an unchangeable past and
> > > already-closed windows of opportunity.
> > 
> > I don´t know much about Trustzone. Do you have any links to a good 
> > explaination of it (preferable from a non-vendor source)?
> 
> There's nothing inherently evil in TrustZone, although it can (and often is)
> used for evil.  Think of it as a hypervisor: unlike IME, it's a privilege
> level of the main processor and executes regular ARM code.  There are two
> "worlds": secure and normal.

Thanks Adam and Arnt for explaination.

I agree that such a feature if done like in

> The ROM code executes (at least partially) in the secure world, and may or
> may not let the bootloader replace it with your own code (typically you
> compile ATF, with or without modifications, instead of writing everything
> from scratch).  On free machines like Pine64 or Pinebook, you can do this.
> On most others, you can't, with obvious freedom consequences.  Insert the
> usual lecture about hardware you don't truly own.

can be useful.

As my next music playback machine I may even use such a Pine64. As anything 
from ThinkPad X240 and upwards appears to be "protected" by Intel Boot Guard 
Verified Boot crap, instead of just offering the Measured Boot feature for 
those who want it. Or I go with a ThinkPad X230 where it appears that Intel ME 
cleaner can do its work. May still be better the Pine64 appears to be a tad 
bit limited especially by memory, although for music playback it would be 
enough if expanded with a large MicroSD card. And it would have the advantage 
that I would not have to mess with removing crap as it does not appear to have 
crap inside. And cheaper too.

Other alternative may be a Chromebook if I can rid it easily enough of Chrome 
OS and install my distro of choice on it.

Thanks,
-- 
Martin
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-10-31 Thread Arnt Gulbrandsen 

Martin Steigerwald writes:
I don´t know much about Trustzone. Do you have any links to a good 
explaination of it (preferable from a non-vendor source)?


Not offhand, sorry. But let me summarise the one I read:

You can put code and data in a part of RAM and then turn off regular access 
to those pages. After that point, the memory is only accessible when a CPU 
core is in a special mode, the "secure world". Then there's a way to switch 
to that mode and call functions, and a way to start a thread in the special 
mode. A file system encryption system or keystore would do the former, a 
hypervisor the latter.


Notably, it's regular RAM and not a dedicated core. You can easily tell how 
big the secure world is and how much CPU the hypervisor uses. There's no 
builtin hypervisor, it's something the boot process has to set up (or not).


You can imagine why DRM people like this, and that's what gets the media 
attention. But it's a nice building block for other things, and if it isn't 
used it's just a small bit of disused silicon (small size is a selling 
point).


Arnt

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-10-31 Thread Adam Borowski 
On Tue, Oct 31, 2017 at 11:48:35AM +0100, Martin Steigerwald wrote:
> Arnt Gulbrandsen - 30.10.17, 12:25:
> > Martin Steigerwald writes:
> > > I wonder about ARM64 as an alternative? But they have some
> > > Trustzone crap if I remember correctly.
> > 
> > ARM64 is fine from a performance viewpoint. The mobile phone vendors have
> > spent a decade optimising ARM SOCs for performance on small batteries. I
> > haven't found laptops with ≥8GB RAM so far though.
> > 
> > Personally I consider the Trustzone well-justified and good. It makes it
> > easy to provide security regimes that rely on an unchangeable past and
> > already-closed windows of opportunity.
> 
> I don´t know much about Trustzone. Do you have any links to a good 
> explaination of it (preferable from a non-vendor source)?

There's nothing inherently evil in TrustZone, although it can (and often is)
used for evil.  Think of it as a hypervisor: unlike IME, it's a privilege
level of the main processor and executes regular ARM code.  There are two
"worlds": secure and normal.

The "secure" world marks certain resources (memory regions, interrupts,
peripherals, etc).  Upon an attempt to access a marked resource, there's a
"world switch" that most of us would call an "interrupt" (except that they
decided to invent a new word, to disambiguate from regular interrupts).
The secure world handler then checks what you tried to do and reacts
appropriately.

Some SoCs have a small amount of memory that can ever be accessed only from
the secure world.  On some, secure world code can't even execute code from
regular memory (although it can obviously copy some in).

The ROM code executes (at least partially) in the secure world, and may or
may not let the bootloader replace it with your own code (typically you
compile ATF, with or without modifications, instead of writing everything
from scratch).  On free machines like Pine64 or Pinebook, you can do this.
On most others, you can't, with obvious freedom consequences.  Insert the
usual lecture about hardware you don't truly own.


One article you can read is for example
https://genode.org/documentation/articles/trustzone


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Laws we want back: Poland, Dz.U. 1921 nr.30 poz.177 (also Dz.U. 
⣾⠁⢰⠒⠀⣿⡁ 1920 nr.11 poz.61): Art.2: An official, guilty of accepting a gift
⢿⡄⠘⠷⠚⠋⠀ or another material benefit, or a promise thereof, [in matters
⠈⠳⣄ relevant to duties], shall be punished by death by shooting.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-10-31 Thread Martin Steigerwald 
Arnt Gulbrandsen - 30.10.17, 12:25:
> Martin Steigerwald writes:
> > I wonder about ARM64 as an alternative? But they have some
> > Trustzone crap if I remember correctly.
> 
> ARM64 is fine from a performance viewpoint. The mobile phone vendors have
> spent a decade optimising ARM SOCs for performance on small batteries. I
> haven't found laptops with ≥8GB RAM so far though.
> 
> Personally I consider the Trustzone well-justified and good. It makes it
> easy to provide security regimes that rely on an unchangeable past and
> already-closed windows of opportunity.

I don´t know much about Trustzone. Do you have any links to a good 
explaination of it (preferable from a non-vendor source)?

-- 
Martin
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-10-31 Thread Martin Steigerwald 
Steve Litt - 30.10.17, 12:08:
> On Mon, 30 Oct 2017 12:53:45 +0100
> 
> Martin Steigerwald  wrote:
> > Actually I´d make firmware pretty dumb and implement as much as I can
> > in loaded software. Just enough firmware to actually install / boot a
> > bootloader which loads an operating kernel and initial ram disk.
> 
> Which is pretty much what we had in MBR. Which is why I always try to
> boot MBR.

I now read through the slides about NERF and well… it appears that with non 
extensible they have simplicity in mind. They relay all the extensibility to 
the go based user space Initramfs. I am not sure whether some go based thing 
would have been needed her but I am thankful for any efforts to rid systems of 
proprietary firmware crap. Even better tough: Not putting in the crap in the 
first place. No crap inside? No effort needed to rip it out again.

-- 
Martin
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-10-30 Thread J. Fahrner 

A good german article on this:
https://www.pro-linux.de/news/1/25289/google-will-uefi-und-management-engine-loswerden.html

Jochen
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-10-30 Thread Didier Kryn 

Le 30/10/2017 à 13:33, Martin Steigerwald a écrit :

Regarding PowerPC based laptops there is an initiviate of Power 2 People.org


I imagine you mean https://www.powerpc-notebook.org/  . But they're 
still collecting money. The fact is no commercial company means to build 
such a thing for profit. I read Debian Powerpc mailing list and the guys 
there all run Linux on old Macs.


Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-10-30 Thread Steve Litt 
On Mon, 30 Oct 2017 12:53:45 +0100
Martin Steigerwald  wrote:


> Actually I´d make firmware pretty dumb and implement as much as I can
> in loaded software. Just enough firmware to actually install / boot a
> bootloader which loads an operating kernel and initial ram disk.

Which is pretty much what we had in MBR. Which is why I always try to
boot MBR.
 
SteveT

Steve Litt 
October 2017 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-10-30 Thread Martin Steigerwald 
Didier Kryn - 30.10.17, 13:13:
> Le 30/10/2017 à 12:53, Martin Steigerwald a écrit :
> > To my knowledge up to now Intel provides the mobile
> > processors with the best processing power / energy consumption ratio.
> 
>  Are there numbers somewhere?

I bet there are, but I have no links at hand.

Michael Larabel of Phoronix.com tested against ARM and an Intel i7 crunched a 
ton of ARM cores to nothing, but this has been some years already.

Granted, my impression is from what I read and also the utter and complete 
lack of any good quality business related laptops with AMD processors. Recent 
laptops from ThinkPad and other vendors have a greatly improved battery life 
and there are mobile versions of Intel CPU/GPU combos with 15 Watt Thermal 
Design Power (TDP). We use Intel NUCs for certain tasks meanwhile and they 
come daringly close to the performance of fully blown 19 inch servers. All 
TDPs I read about AMD Ryzen CPUs have been way higher… *except* some of their 
new Ryzen mobile CPUs. I know its just TDP… but if either AMD or ARM would 
offer any CPU that could compete on speed/energy ratio, I´d bet at least some 
manufacturers would be using it, but other than gaming laptops I have seen 
nothing with AMD technology so far. Which is a pity, cause I like to buy 
something from them as I am not happy with the Intel monopoly.

So I ask you: Are you aware of any other than Intel laptop with a good speed/
energy ratio? One that is actually a laptop and not a power hungry portable 
workstation?

Regarding PowerPC based laptops there is an initiviate of Power 2 People.org

Thanks,
-- 
Martin
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-10-30 Thread Arnt Gulbrandsen 

Martin Steigerwald writes:
I wonder about ARM64 as an alternative? But they have some 
Trustzone crap if I remember correctly.


ARM64 is fine from a performance viewpoint. The mobile phone vendors have 
spent a decade optimising ARM SOCs for performance on small batteries. I 
haven't found laptops with ≥8GB RAM so far though.


Personally I consider the Trustzone well-justified and good. It makes it 
easy to provide security regimes that rely on an unchangeable past and 
already-closed windows of opportunity.


Arnt

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-10-30 Thread Didier Kryn 

Le 30/10/2017 à 12:53, Martin Steigerwald a écrit :

To my knowledge up to now Intel provides the mobile
processors with the best processing power / energy consumption ratio.


Are there numbers somewhere?

Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-10-30 Thread Martin Steigerwald 
Didier Kryn - 30.10.17, 12:20:
> Le 30/10/2017 à 11:10, Dr. Nikolaus Klepp a écrit :
> > Am Montag, 30. Oktober 2017 schrieb Didier Kryn:
[…]
> > please look at the presentation, 2. slide: it says "This is to a shell
> > prompt in Linux" and "All userland written in Go", so it's not about any
> > application "on top of this written in go", but plain busybox rewritten
> > in  Go.
>  OK, I watched the whole talk now and it becomes more clear. They
> are working in the same direction as Purism; which was discussed a few
> weeks ago. Purism has gone a little farther in disabling parts of the
> Management Engine but they all agree it cannot be completely disabled up
> to now - some people are trying to decompile it.
> 
>  Actually their whole userland is written in Go, but please note the
> pecularity: their image is made of the Linux kernel, the Go compiler and
> *the source* of the userland. At boot, the userland is compiled and then
> executed. The whole takes less than 6MB. The speaker claims that
> programming in Go is easier than in shell. Compilation takes a fraction
> of a second.

I wonder when Intel will finally wake up that there is a significant amount of 
their customers who do not want that Intel Management Engine crap and that the 
only way moving forward with firmware that makes sense is by using free 
software and allowing the users the choice to replace it.

And its not only individual privacy and security aware users like us, but also 
companies and government authorities who do not want this crap.

Yet UEFI is a different thing. I prepared UEFI slides for my courses meanwhile 
and I have the impression it is one of the biggest craps ever. As much source 
code lines as a Linux kernel without drivers. Seriously? I think GPT is 
okayish.

Anyway I wonder why not just to use Coreboot/Libreboot and be done with it?

Actually I´d make firmware pretty dumb and implement as much as I can in loaded 
software. Just enough firmware to actually install / boot a bootloader which 
loads an operating kernel and initial ram disk.

>  If there was a choice, I would rather choose a PowerPC arch: they
> haven't that crap and their architecture is more modern. IBM and
> Freescale have a good card to play and I don't understand why they don't
> take the opportunity.

There is one thing tough: To my knowledge up to now Intel provides the mobile 
processors with the best processing power / energy consumption ratio. I get 
the impression that AMD is getting there is Ryzen mobile processors which 
would also have the advantage to have a more powerful CPU.

But AFAIK IBM Power is no where close to be usable in a laptop. Its also not 
meant for that as far as I understand. So Freescale remains?

I wonder about ARM64 as an alternative? But they have some Trustzone crap if I 
remember correctly. Or… but not right now yet, RISC-V.

Thanks,
-- 
Martin
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-10-30 Thread Didier Kryn 

Le 30/10/2017 à 11:10, Dr. Nikolaus Klepp a écrit :

Am Montag, 30. Oktober 2017 schrieb Didier Kryn:

Le 30/10/2017 à 08:44, Dr. Nikolaus Klepp a écrit :

Am Montag, 30. Oktober 2017 schrieb J. Fahrner:

https://osseu17.sched.com/event/ByYt/replace-your-exploit-ridden-firmware-with-linux-ronald-minnich-google

Nice. But it they suffer from the "not invented here"-syndrome: instead of using prooven 
good busysbox, they rewrite userspace in GO .. oops, who "invented" Go and wants to push 
it to the users?


  Nik, Though I agree that Busybox is proven good, it remains that
the said system is more than an OS and is to run at least one
application on top of Busybox. This application must be written in some
language.
   Busybox provides interpreted languages, Ash, Hush and Awk, but I
doubt they would be a good choice for a complex application. The
application should rather be written in some compiled language and one
cannot deny the author the choice of this language, provided it is open
source. You know what my preferred language would be, but, from what
I've briefly read about Go, it seems to be based on not so bad rationale.

Hi Didier,

please look at the presentation, 2. slide: it says "This is to a shell prompt in Linux" and 
"All userland written in Go", so it's not about any application "on top of this written in 
go", but plain busybox rewritten in  Go.


    OK, I watched the whole talk now and it becomes more clear. They 
are working in the same direction as Purism; which was discussed a few 
weeks ago. Purism has gone a little farther in disabling parts of the 
Management Engine but they all agree it cannot be completely disabled up 
to now - some people are trying to decompile it.


    Actually their whole userland is written in Go, but please note the 
pecularity: their image is made of the Linux kernel, the Go compiler and 
*the source* of the userland. At boot, the userland is compiled and then 
executed. The whole takes less than 6MB. The speaker claims that 
programming in Go is easier than in shell. Compilation takes a fraction 
of a second.


    If there was a choice, I would rather choose a PowerPC arch: they 
haven't that crap and their architecture is more modern. IBM and 
Freescale have a good card to play and I don't understand why they don't 
take the opportunity.


    Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-10-30 Thread John Hughes 

On 30/10/17 08:44, Dr. Nikolaus Klepp wrote:

Am Montag, 30. Oktober 2017 schrieb J. Fahrner:

https://osseu17.sched.com/event/ByYt/replace-your-exploit-ridden-firmware-with-linux-ronald-minnich-google

Nice. But it they suffer from the "not invented here"-syndrome: instead of using prooven 
good busysbox, they rewrite userspace in GO .. oops, who "invented" Go and wants to push 
it to the users?



The stated reason for using go is that the system is delivered as source 
and compiled on the fly -- see around the 23 minute mark.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-10-30 Thread Arnt Gulbrandsen 

Dr. Nikolaus Klepp writes:
Nice. But it they suffer from the "not invented here"-syndrome: 
instead of using prooven good busysbox, they rewrite userspace 
in GO .. oops, who "invented" Go and wants to push it to the 
users?


They use the linux kernel, but suffer from NIH syndrome? Has it crossed 
your mind that they might consider busybox deficient for reasons other than 
NIH?


Arnt

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-10-30 Thread Dr. Nikolaus Klepp 
oops, I forgot the link to the paper: look at page 4.

https://www.usenix.org/system/files/conference/atc15/atc15-paper-minnich.pdf

Nik

Am Montag, 30. Oktober 2017 schrieb Dr. Nikolaus Klepp:
> Am Montag, 30. Oktober 2017 schrieb Didier Kryn:
> > Le 30/10/2017 à 08:44, Dr. Nikolaus Klepp a écrit :
> > > Am Montag, 30. Oktober 2017 schrieb J. Fahrner:
> > >> https://osseu17.sched.com/event/ByYt/replace-your-exploit-ridden-firmware-with-linux-ronald-minnich-google
> > > Nice. But it they suffer from the "not invented here"-syndrome: instead 
> > > of using prooven good busysbox, they rewrite userspace in GO .. oops, who 
> > > "invented" Go and wants to push it to the users?
> > >
> > 
> >  Nik, Though I agree that Busybox is proven good, it remains that 
> > the said system is more than an OS and is to run at least one 
> > application on top of Busybox. This application must be written in some 
> > language.
> >   Busybox provides interpreted languages, Ash, Hush and Awk, but I 
> > doubt they would be a good choice for a complex application. The 
> > application should rather be written in some compiled language and one 
> > cannot deny the author the choice of this language, provided it is open 
> > source. You know what my preferred language would be, but, from what 
> > I've briefly read about Go, it seems to be based on not so bad rationale.
> 
> Hi Didier,
> 
> please look at the presentation, 2. slide: it says "This is to a shell prompt 
> in Linux" and "All userland written in Go", so it's not about any application 
> "on top of this written in go", but plain busybox rewritten in  Go. 
> 
> Nik
> 
> 
> 



-- 
Please do not email me anything that you are not comfortable also sharing with 
the NSA, CIA ...
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-10-30 Thread Dr. Nikolaus Klepp 
Am Montag, 30. Oktober 2017 schrieb Didier Kryn:
> Le 30/10/2017 à 08:44, Dr. Nikolaus Klepp a écrit :
> > Am Montag, 30. Oktober 2017 schrieb J. Fahrner:
> >> https://osseu17.sched.com/event/ByYt/replace-your-exploit-ridden-firmware-with-linux-ronald-minnich-google
> > Nice. But it they suffer from the "not invented here"-syndrome: instead of 
> > using prooven good busysbox, they rewrite userspace in GO .. oops, who 
> > "invented" Go and wants to push it to the users?
> >
> 
>  Nik, Though I agree that Busybox is proven good, it remains that 
> the said system is more than an OS and is to run at least one 
> application on top of Busybox. This application must be written in some 
> language.
>   Busybox provides interpreted languages, Ash, Hush and Awk, but I 
> doubt they would be a good choice for a complex application. The 
> application should rather be written in some compiled language and one 
> cannot deny the author the choice of this language, provided it is open 
> source. You know what my preferred language would be, but, from what 
> I've briefly read about Go, it seems to be based on not so bad rationale.

Hi Didier,

please look at the presentation, 2. slide: it says "This is to a shell prompt 
in Linux" and "All userland written in Go", so it's not about any application 
"on top of this written in go", but plain busybox rewritten in  Go. 

Nik



-- 
Please do not email me anything that you are not comfortable also sharing with 
the NSA, CIA ...
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-10-30 Thread Didier Kryn 

Le 30/10/2017 à 08:44, Dr. Nikolaus Klepp a écrit :

Am Montag, 30. Oktober 2017 schrieb J. Fahrner:

https://osseu17.sched.com/event/ByYt/replace-your-exploit-ridden-firmware-with-linux-ronald-minnich-google

Nice. But it they suffer from the "not invented here"-syndrome: instead of using prooven 
good busysbox, they rewrite userspace in GO .. oops, who "invented" Go and wants to push 
it to the users?



Nik, Though I agree that Busybox is proven good, it remains that 
the said system is more than an OS and is to run at least one 
application on top of Busybox. This application must be written in some 
language.
 Busybox provides interpreted languages, Ash, Hush and Awk, but I 
doubt they would be a good choice for a complex application. The 
application should rather be written in some compiled language and one 
cannot deny the author the choice of this language, provided it is open 
source. You know what my preferred language would be, but, from what 
I've briefly read about Go, it seems to be based on not so bad rationale.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-10-30 Thread Narcis Garcia 
No project website for NERF?


El 30/10/17 a les 06:59, J. Fahrner ha escrit:
> https://osseu17.sched.com/event/ByYt/replace-your-exploit-ridden-firmware-with-linux-ronald-minnich-google
> 
> 
> Jochen
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-10-30 Thread Jaromil 
On Mon, 30 Oct 2017, Dr. Nikolaus Klepp wrote:

> Am Montag, 30. Oktober 2017 schrieb J. Fahrner:
> > https://osseu17.sched.com/event/ByYt/replace-your-exploit-ridden-firmware-with-linux-ronald-minnich-google
> >  

> Nice. But it they suffer from the "not invented here"-syndrome:
> instead of using prooven good busysbox, they rewrite userspace in GO
> .. oops, who "invented" Go and wants to push it to the users?

the "not-invented-here" syndrome is well present in ICT multinationals
especially in the US. I suspect its the result of a competitive
mindset, the remnants of a patent based economy and the need to fill
in timesheets for office work. the fact there are young people hurling
fists and wanting to prove themselves may be just the cherry on top.

but I'm happy to stand corrected and would really like to read more
about the topic, perhaps even academic publications that explore the
"innovation" concepts in practical outcomes and with a critical
mindset.

ciao

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-10-30 Thread Dr. Nikolaus Klepp 
Am Montag, 30. Oktober 2017 schrieb J. Fahrner:
> https://osseu17.sched.com/event/ByYt/replace-your-exploit-ridden-firmware-with-linux-ronald-minnich-google

Nice. But it they suffer from the "not invented here"-syndrome: instead of 
using prooven good busysbox, they rewrite userspace in GO .. oops, who 
"invented" Go and wants to push it to the users?

Nik


-- 
Please do not email me anything that you are not comfortable also sharing with 
the NSA, CIA ...
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Google abandons UEFI in Chromebooks

2017-10-30 Thread Lars Noodén 
On 10/30/2017 07:59 AM, J. Fahrner wrote:
> https://osseu17.sched.com/event/ByYt/replace-your-exploit-ridden-firmware-with-linux-ronald-minnich-google

Thanks.  The presentation is online, too:

https://www.youtube.com/watch?v=iffTJ1vPCSo=65=PLbzoR-pLrL6pISWAq-1cXP4_UZAyRtesk

/Lars
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Google abandons UEFI in Chromebooks

2017-10-30 Thread J. Fahrner 

https://osseu17.sched.com/event/ByYt/replace-your-exploit-ridden-firmware-with-linux-ronald-minnich-google

Jochen
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng