On 28/09/2018, Peter Stuge wrote:
> Youness Alaoui wrote:
>> avoid any malware writing to the flash
>
> Just disallow flash writes by the platform. Allow flash writes only
> by dedicated hardware (maybe ChromeEC?) which implements a simple and
> efficient security protocol.
Relevant URL:
>
>
> The problem is we want to allow users to update their flash and
> coreboot doesn't have a "flash update utility" integrated, so it has
> to happen in the payload, which is why coreboot needs to not lock
> anything then let the payload do the locking for us instead. Heads is
> the linux-based
Youness Alaoui wrote:
> avoid any malware writing to the flash
Just disallow flash writes by the platform. Allow flash writes only
by dedicated hardware (maybe ChromeEC?) which implements a simple and
efficient security protocol.
Looking for a software solution is IMO like Intel trying to secure
ron minnich wrote:
> yeah, also is there a programmer you recommend for 32MiB parts?
I don't have a recommendation just yet, but a question:
Speed aside, is single bit IO good enough for 32MiB, or is DIO/QIO required?
//Peter
--
coreboot mailing list: coreboot@coreboot.org
Ivan Ivanov wrote:
> If you've ever heard the spkmodem output, please could you try to
> decode this stuff if its' easy for you, or at least to tell if it
> sounds OK or not?
It sounds somehow like I remember spkmodem, but the file is very low
amplitude (too quiet) and I can't confirm whether the
On 27.09.2018 22:34, Nico Huber wrote:
> On 9/27/18 10:11 PM, ron minnich wrote:
>> yeah, also is there a programmer you recommend for 32MiB parts?
> Any programmer that can handle arbitrary SPI commands, e.g. single-
> board computers with native SPI interface (RPi, BeagleBone Black etc.),
>
On 9/27/18 10:11 PM, ron minnich wrote:
> yeah, also is there a programmer you recommend for 32MiB parts?
Any programmer that can handle arbitrary SPI commands, e.g. single-
board computers with native SPI interface (RPi, BeagleBone Black etc.),
CH341A is popular but slow, FTDI based programmers
Thanks everyone for the responses.
So far my understanding on the task at hand is :
- Add a CONFIG to decide if we set FLOCKDN or not (and one to decide
if we lock it on the resume path?)
- Remove the chipset_lockdown devicetree config and change the code to
always assume it's LOCKDOWN_COREBOOT
yeah, also is there a programmer you recommend for 32MiB parts?
thanks
ron
On Thu, Sep 27, 2018 at 1:10 PM Nico Huber wrote:
> Ah, dediprog... you happen to have the one programmer that is hard to
> support.
>
> On 9/27/18 9:49 PM, ron minnich wrote:
> > hmm, is this useful?
> >
> > Found
Ah, dediprog... you happen to have the one programmer that is hard to
support.
On 9/27/18 9:49 PM, ron minnich wrote:
> hmm, is this useful?
>
> Found Spansion flash chip "S25FL256S..0" (32768 kB, SPI) on dediprog.
> Erasing and writing flash chip... 4-byte address requested but master can't
Erasing and writing flash chip... Erase/write done.
Verifying flash... FAILED at 0x0100! Expected=0x00, Found=0xff, failed
byte count from 0x-0x01ff: 0xffc000
Your flash chip is in an unknown state.
Please report this on IRC at chat.freenode.net (channel #flashrom) or
mail
hmm, is this useful?
Found Spansion flash chip "S25FL256S..0" (32768 kB, SPI) on dediprog.
Erasing and writing flash chip... 4-byte address requested but master can't
handle 4-byte addresses.
Looking for another erase function.
On Thu, Sep 27, 2018 at 12:40 PM ron minnich wrote:
>
Thanks, let me send you the output I got. I am looking at the code too.
On Thu, Sep 27, 2018 at 12:29 PM Nico Huber wrote:
> Hi Ron,
>
> On 9/27/18 8:05 PM, ron minnich wrote:
> > sadly, they do not work ...
>
> what does work? does flashrom detect the chip reliably?
> What programmer do you
Hi Ron,
On 9/27/18 8:05 PM, ron minnich wrote:
> sadly, they do not work ...
what does work? does flashrom detect the chip reliably?
What programmer do you use? what is your physical setup?
If these patches don't work, I would expect that the failure is not
about the flash chip model.
Nico
--
sadly, they do not work ...
but many thanks for the pointer!
On Wed, Sep 26, 2018 at 1:16 PM Angel Pons wrote:
> Hello Ron,
>
> I do not have such chip, but I am aware there are three patches
> regarding the S25FL256S: [1]
>
> Best regards,
>
> Angel Pons
>
> [1]:
"but once you boot an OS, Heads would first lock the flash so it can't be
written to'. Is this some kind of a OS driver? The typical usage of all
locking register which are write once is to have them locked up within BIOS
itself which is within the most trusted boundary. Best we could do it push
Okay, then I believe we should leave the decision on CONFIG instead of
force lockdown blindly. As of now, that's still optional I believe.
On Thu, Sep 27, 2018 at 3:49 AM Nico Huber wrote:
> Am 26.09.18 um 22:26 schrieb Lance Zhao:
> > I am reading the "flash security recommendation" from PCH
On 09/27/2018 05:22 AM, Ivan Ivanov wrote:
I suspect: despite that the "PC Speaker"-style beeping output is
working fine at this laptop/speakers while we are using Linux or even
some very simple OS like FreeDOS or Kolibri - that coreboot's spkmodem
might be buggy at G505S laptop, since there
Am 26.09.18 um 22:26 schrieb Lance Zhao:
> I am reading the "flash security recommendation" from PCH BIOS writer
> guide now, it did say strongly recommend to take those actions. The EISS
> feature to ensure BIOS region can only get modfiyed from SMM.
The EISS bit is a highly questionable
On 2018-09-26 10:29 PM, Philipp Hug wrote:
> In my local tree I just added the ram address in selfboot.
> Doing this beforehand with cbfstool would be even better. (E.g. only
> when choosing linux payload)
>
The proposed mechanism was already implemented here:
20 matches
Mail list logo
