9.756645] ? handle_mm_fault+0x256/0x370
[ 169.760813] ? do_user_addr_fault+0x347/0x640
[ 169.765235] ? exc_page_fault+0x73/0x160
[ 169.769228] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
_______
tboot-devel mailing list
tboot-devel
+0x89/0x160
[ 169.752143] ? __count_memcg_events+0xdf/0x170
[ 169.756645] ? handle_mm_fault+0x256/0x370
[ 169.760813] ? do_user_addr_fault+0x347/0x640
[ 169.765235] ? exc_page_fault+0x73/0x160
[ 169.769228] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
_______
tboot
? do_user_addr_fault+0x347/0x640
[ 169.765235] ? exc_page_fault+0x73/0x160
[ 169.769228] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
_______
tboot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tboot-devel
Mark, Michael,
Has this patch been submitted upstream yet?
If so, to what branch?
Thanks
On 10/17/2025 8:14 AM, [email protected] wrote:
Send tboot-devel mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World
T_20190708_PW.bin ...'
module2 /SNB_IVB_SINIT_20190708_PW.bin
}
smime.p7s
Description: S/MIME cryptographic signature
___
tboot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tboot-devel
at 0x8c000, this may also
conflict with logs.
As I said, my testing system does not boot with this patch, I expect
that this is not the only one. I don't know the exact motivation on
expanding space for logs, but you should consider to do this in another
way.
Thanks,
Lukasz
___
your system is ready to enable remote
attestation.
Thanks,
Lukasz
_______
tboot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tboot-devel
ne
> gets properly executed instead of "int_handler - 0x4000".
>
> NOTE: A simple way to test this is to insert 'asm volatile("ud2");' in
> begin_launch().
>
Thank you for the patch.
Lukasz
___
tboot-devel m
x27; flag to prevent kernel from using EFI. On
non-EFI systems this flag is pointless because kernel can't use EFI
services if they do not exist.
If removing 'noefi' flag solves your issue, you should find out why.
Maybe there is some information that kernel retrieves from EFI
OD_LOAD_PREFERENCE 11
#define MB2_HDR_TAG_REQUIRED 0
#define MB2_HDR_TAG_OPTIONAL 1
___
tboot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tboot-devel
re patch for tboot that combined should
fix the issue, will you be able to run tests?
Thanks,
Lukasz
_______
tboot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tboot-devel
is
change. It is much better to select proper SINIT during installation
that loads all possible ones every boot, only to always choose the same
right one.
Thanks,
Lukasz
___
tboot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tboot-devel
can see the issue. This experiment may
tell us if hang is related to tboot's shutdown handler or not.
Lukasz
_______
tboot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tboot-devel
rance
___
tboot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tboot-devel
his work will prove helpful, even if it is just the
information in README.md. Thanks for all your help over the past year!
-Paul
___
tboot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tboot-devel
the tboot code to debug this further.
If you haven't found it already, a good starting point is the
tboot/common/policy.c:set_policy() function.
> De : Paul Moore (pmoore2)
> Envoyé : mardi 4 février 2020 15:44
> À : LE ROY Olivier - Contractor; [email protected]
> Ob
closer to a working system. I'm in the process
of writing up some better notes, I'll send a note to the list when they
are available.
Good luck!
-Paul
_______
tboot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tboot-devel
at 00:18 +, Paul Moore (pmoore2) wrote:
> > > > On Mon, 2020-01-13 at 20:33 +, Paul Moore (pmoore2) via
> > > > tboot-devel wrote:
> > > > > On Thu, 2020-01-09 at 14:59 +, Hawrylko, Lukasz wrote:
> > > > > > On Fri, 2020-01-03 at 20:26
On Mon, 2020-01-13 at 20:33 +, Paul Moore (pmoore2) via tboot-devel wrote:
On Thu, 2020-01-09 at 14:59 +, Hawrylko, Lukasz wrote:
On Fri, 2020-01-03 at 20:26 +, Paul Moore (pmoore2) via tboot-devel
wrote:
On Fri, 2020-01-03 at 20:07 +, Paul Moore (pmoore2) via tboot-devel
wrote
On Thu, 2020-01-09 at 14:59 +, Hawrylko, Lukasz wrote:
On Fri, 2020-01-03 at 20:26 +, Paul Moore (pmoore2) via tboot-devel
wrote:
On Fri, 2020-01-03 at 20:07 +, Paul Moore (pmoore2) via tboot-devel
wrote:
On Thu, 2020-01-02 at 22:27 +, Paul Moore (pmoore2) via tboot-
devel
On Mon, 2019-12-23 at 21:20 +, Paul Moore (pmoore2) via tboot-devel
wrote:
> It appears that lcptools-v2 doesn't understand the "pconf" type ...
I just added a new "pconf2" policy element type to lcptools-v2 so you
can generate a LCP_PCONF_ELEMENT2 without havin
On Fri, 2020-01-03 at 20:07 +, Paul Moore (pmoore2) via tboot-devel
wrote:
> On Thu, 2020-01-02 at 22:27 +, Paul Moore (pmoore2) via tboot-
> devel
> wrote:
> > I hope everyone had a nice holiday and is enjoying the new year thus
> > far.
> >
> > As you
On Thu, 2020-01-02 at 22:27 +, Paul Moore (pmoore2) via tboot-devel
wrote:
> I hope everyone had a nice holiday and is enjoying the new year thus
> far.
>
> As you've seen in the other thread, I'm playing around with different
> tboot/TXT policies and I have a que
lgen seems limited to using SHA1, does anyone have any patches to
use SHA256 (or another hash)?
-Paul
_______
tboot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tboot-devel
On Wed, 2019-11-06 at 20:12 +, [email protected] wrote:
> > -Original Message-
> > From: Paul Moore (pmoore2)
> > Sent: Tuesday, November 5, 2019 19:28
> > To: Gilbert, Travis
> > Cc: [email protected]
> > Subject: Re: Creati
ave a
LCP to carry the certificates. Not to mention the benefits of a signed
LCP allowing you to update the policy without updating the values stored
in the TPM nvindex (assuming the same policy signing key).
> > Is there any advantage to storing the VLP directly in the TPM and
need to generate a new LCP to contain the certificate
payload, why not store the VLP in the LCP at that point?
Is there any advantage to storing the VLP directly in the TPM and not in
the LCP?
-Paul
___
tboot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tboot-devel
On Fri, 2019-12-06 at 21:28 +, Paul Moore (pmoore2) via tboot-devel
wrote:
> On Fri, 2019-12-06 at 11:37 +0100, Lukasz Hawrylko wrote:
> > On Wed, 2019-12-04 at 14:33 +, Paul Moore (pmoore2) wrote:
> > > Can you elaborate a bit more on what you mean by "the ro
language :)
No worries, no offense was taken, I just wanted to make sure that the
expectations were set appropriately. Also, I just wanted to say that
your English is just fine, it's *far* better than my Polish ;)
-Paul
___
tboot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tboot-devel
I'm assuming it is the VLP we loaded directly, and not from
> > inside
> > the LCP, but thought it was worth checking.
> >
>
> In "stock" TBOOT, VLP loaded from its own index has higher priority
> over
> one embedded in LCP, so I agree with you that here it should work like
> that.
>
> Thanks,
> Lukasz
>
___
tboot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tboot-devel
On Wed, 2019-12-04 at 14:33 +, Paul Moore (pmoore2) via tboot-devel
wrote:
> On Mon, 2019-12-02 at 14:09 +0100, Lukasz Hawrylko wrote:
> > If VLP is present under its own index (for TPM 2.0 it is
> > 0x01C10131),
> > tboot will not read LCP at all, so certificate will
rst problem that I found. At
> least, you should check if pointer to next element in chain is not
> NULL.
___
tboot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tboot-devel
On Fri, 2019-10-18 at 13:27 +, Paul Moore (pmoore2) via tboot-devel
wrote:
> On Thu, 2019-09-19 at 15:39 +, Paul Moore (pmoore2) via
> tboot-devel wrote:
> > Hello,
> >
> > I've been working on adding PECOFF/kernel signature verification to
> > tboot
ools-v2.
>
>
> On Wed, 2019-11-13 at 17:15 +, [email protected] wrote:
> > > -Original Message-
> > > From: Lukasz Hawrylko <
> > > [email protected]
> > > Sent: Wednesday, November 13, 2019 08:24
> > > T
On Wed, 2019-11-13 at 17:17 +, [email protected] wrote:
> > -Original Message-
> > From: Paul Moore (pmoore2)
> > Sent: Wednesday, November 13, 2019 09:51
> > To: [email protected]; Gilbert, Travis
> > Cc: [email protected]
[email protected]
> > > Sent: Friday, November 8, 2019 11:19
> > > To:
> > > [email protected]
> > > ; Gilbert, Travis
> > > Cc:
> > > [email protected]
> > >
> > > Subject: Re: [tboot-devel] Creating
't be resolved within the next month or two, is there
any reason why we couldn't continue to make changes to the lcptools-v2
tools?
-Paul
_______
tboot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tboot-devel
On Wed, 2019-11-06 at 20:12 +, [email protected] wrote:
> > -Original Message-
> > From: Paul Moore (pmoore2)
> > Sent: Tuesday, November 5, 2019 19:28
> > To: Gilbert, Travis
> > Cc: [email protected]
> > Subject: Re: Creati
On Tue, 2019-11-05 at 23:02 +, [email protected] wrote:
> > -Original Message-
> > From: Paul Moore (pmoore2) via tboot-devel > [email protected]>
> > Sent: Tuesday, November 5, 2019 16:50
> > To: [email protected];
> &g
a LCP using the current sources?
Thanks,
-Paul
_______
tboot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tboot-devel
On Thu, 2019-09-19 at 15:39 +, Paul Moore (pmoore2) via tboot-devel
wrote:
> Hello,
>
> I've been working on adding PECOFF/kernel signature verification to
> tboot and now that I have a rough working prototype I wanted to bring
> it to the list to see if this is something
heck
> > > how
> > > it works, idea of measuring kernel signature instead of whole
> > > binary
> > > is
> > > very interesting. I hope that next week I will find some time for
> > > that,
> > > as you said patch is quite big.
> > >
>
ture and extend PCRs with signature's public key hash, am I
> right?
> In this approach tboot is not able to verify if kernel is signed by
> proper authority, this need to be done be local/remote attestation in
> further boot process.
>
> Thanks,
> Lukasz
>
> On
boot repository once it is
more complete?
___________
tboot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tboot-devel
EMAIL: [email protected]
> --------
> --
> "... remember that innovation is saying 'no' to 1000 things."
> -- Moxie Marlinspike
>
> ---
---
> Systems Optimization Self Assessment
> Improve efficiency and utilization of IT resources. Drive out cost and
> improve service delivery. Take 5 minutes to use this Systems Optimization
> Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
>
provide a great way to learn Windows Azure and what it
provides. You can attend the event by watching it streamed LIVE online.
Learn more at http://p.sf.net/sfu/ms-windowsazure
___
tboot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tboot-devel
47 matches
Mail list logo
