similar to: [PATCH 1/2] secboot: don't use hardcoded mask to enable falcon

On GM20x and later GPUs, firmware for some essential falcons (notably FECS) must be authenticated by a NVIDIA-produced signature and loaded by a high-secure falcon in order to access certain registers, in a process known as Secure Boot. Secure Boot requires the building of a binary blob containing the firmwares and signatures of the falcons to be loaded. This blob is then given to a high-secure

This is a highly changed revision of the first patch series that adds secure boot support to Nouveau. This code still depends on NVIDIA releasing official firmware files, but the files released with SHIELD TV and Pixel C can already be used on a Jetson TX1. As you know we are working hard to release the official firmware files, however in the meantime it doesn't hurt to review the code so it

New version of the secure boot code that works with the blobs just merged into linux-firmware. Since the required Mesa patches are also merged, this set is the last piece of the puzzle to get out-of-the-box accelerated Maxwell 2. The basic code remains the same, with a few improvements with respect to how secure falcons are started. Hopefully the patchset is better split too. I have a

Hi Alexandre, On 18 January 2016 at 06:10, Alexandre Courbot <acourbot at nvidia.com> wrote: [snip] > +static const char * > +managed_falcons_names[] = { > + [NVKM_SECBOOT_FALCON_PMU] = "PMU", > + [NVKM_SECBOOT_FALCON_RESERVED] = "<invalid>", "<reserved>" perhaps ? we already have one invalid below. > +

This was the first step of the secure boot refactoring - as Ben asked for some fixes, I now submit it as its own series to make it easier to review (and also because rebasing secure boot on top of this takes time and I don't want to do it until this is validated!). This series attempts to factorize the duplicate falcon-related code into a single library, using the existing nvkm_falcon

On 01/21/2016 10:09 PM, Emil Velikov wrote: > Hi Alexandre, > > On 18 January 2016 at 06:10, Alexandre Courbot <acourbot at nvidia.com> wrote: > > [snip] >> +static const char * >> +managed_falcons_names[] = { >> + [NVKM_SECBOOT_FALCON_PMU] = "PMU", >> + [NVKM_SECBOOT_FALCON_RESERVED] = "<invalid>", >

This was the first step of the secure boot refactoring - as Ben asked for some fixes, I now submit it as its own series to make it easier to review (and also because rebasing secure boot on top of this takes time and I don't want to do it until this is validated!). This series attempts to factorize the duplicate falcon-related code into a single library, using the existing nvkm_falcon

Make sure we are not disturbed by spurious interrupts, as we poll the halt bit anyway. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/nvkm/subdev/secboot/gm200.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drm/nouveau/nvkm/subdev/secboot/gm200.c b/drm/nouveau/nvkm/subdev/secboot/gm200.c index 4932757ab1a2..5801babdf959 100644 ---

This is needed for using Nouveaus PMU image after performing secboot. This will be helpfull for Maxwell2 reclocking on boards without externally controlled fans like on most laptops or fanless boards. Signed-off-by: Karol Herbst <karolherbst at gmail.com> --- drm/nouveau/nvkm/subdev/secboot/acr_r352.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git

Hi Konrad / Yu Ke, I have tried konrad''s master tree: commit 329408d788f62629131ea28c112e973878d52c9e Merge: e370fe2 773f8cf Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Date: Thu May 19 14:37:32 2011 -0400 Merge branch ''linux-next'' With a xen-4.1.0 hypervisor, on my AMD x6 phenom. Curious if Xen Power Management would work... Output of all xenpm

In case memory resources for *bl_desc* were allocated, release them before return. Addresses-Coverity-ID: 1472021 ("Resource leak") Fixes: 0d466901552a ("drm/nouveau/secboot/acr: Remove VLA usage") Signed-off-by: Gustavo A. R. Silva <gustavo at embeddedor.com> --- drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r352.c | 1 + 1 file changed, 1 insertion(+) diff --git

On 8/2/18 12:51 PM, Gustavo A. R. Silva wrote: > Hi all, > > Friendly ping! Who can take this? > > Thanks > -- > Gustavo > > On 07/24/2018 08:27 AM, Gustavo A. R. Silva wrote: >> In case memory resources for *bl_desc* were allocated, release >> them before return. >> >> Addresses-Coverity-ID: 1472021 ("Resource leak") >> Fixes:

If 'ioremap()' returns 0, 'gm20b_tegra_read_wpr()' will return 0 as well, which means success. Return -ENOMEM instead Signed-off-by: Christophe JAILLET <christophe.jaillet at wanadoo.fr> --- Not sure that -ENOMEM is the best value. I've taken it because it is often used in such a case. --- drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c | 2 +- 1 file changed, 1

We accidentally set "psb" which is a no-op instead of "*psb" so it generates a static checker warning. We should probably set it before the first error return so that it's always initialized. Fixes: 923f1bd27bf1 ("drm/nouveau/secboot/gm20b: add secure boot support") Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> --- Static analysis. I'm

In preparation to enabling -Wvla, remove VLA. In this particular case directly use macro NVKM_MSGQUEUE_CMDLINE_SIZE instead of local variable cmdline_size. Also, remove cmdline_size as it is not actually useful anymore. The use of stack Variable Length Arrays needs to be avoided, as they can be a vector for stack exhaustion, which can be both a runtime bug or a security flaw. Also, in general, as

Ourput an info message when secure boot has been successfully performed. This is useful when troubleshooting issues that may be caused by firmware loading being delayed - without an explicit message we have no way to know whether secure boot has been performed or not. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- This has been inspired by Ilia's comment on FD bug 94725.

Hello Alexandre Courbot, The patch 5429f82f3415: "drm/nouveau/secboot: add gp102/gp104/gp106/gp107 support" from Jan 26, 2017, leads to the following static checker warning: drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gp102.c:63 gp102_run_secure_scrub() warn: passing zero to 'PTR_ERR' drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gp102.c 46 static int 47

On Fri, Jun 22, 2018 at 10:50 AM, Karol Herbst <kherbst at redhat.com> wrote: > On Thu, May 24, 2018 at 7:24 PM, Kees Cook <keescook at chromium.org> wrote: >> In the quest to remove all stack VLA usage from the kernel[1], this >> allocates the working buffers before starting the writing so it won't >> abort in the middle. This needs an initial walk of the

This series fixes two cases where behavior on secure boot errors could be improved: 1) Patch 2 propages secure-boot errors from GR init, making sure initialization fails as it should. Failure to do so results in a black screen during boot, as reported in FD bug 94990. 2) Patches 3-4 make the absence of required secure firmware files a non-fatal error. The previous behavior was to give up

Fixes secure boot on my gp107. No idea why. Otherwise the GPU enters complete lockdown after starting the gpccs and fecs with the LS images loaded. Signed-off-by: Karol Herbst <kherbst at redhat.com> --- drm/nouveau/nvkm/engine/gr/gf100.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drm/nouveau/nvkm/engine/gr/gf100.c b/drm/nouveau/nvkm/engine/gr/gf100.c index